Tighten up JSON vs FHIR JSON response formatting #5506
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
2 Skipped Deployments
|
mattlong
force-pushed
the
mattlong-json-response-formats
branch
from
e3ba7bf to
6802ecb
Compare
| @@ -534,14 532,16 @@ async function addBotSecrets( | |||
| } | |||
| } | |||
|
|
|||
| const MIRRORED_CONTENT_TYPES: string[] = [ContentType.FHIR_JSON, ContentType.TEXT, ContentType.HL7_V2]; | |||
There was a problem hiding this comment.
I would be in favor or removing FHIR_JSON from this list so that we never automatically use FHIR stringify on Bot responses; especially since FHIR stringify wouldn't have even been used up until about a week ago.
There was a problem hiding this comment.
I think this makes sense... Maybe this is a v4 change to avoid breaking people?
What do we think @mattwiller @codyebberson ?
There was a problem hiding this comment.
That would cause some Bots' output to change from application/fhir json to application/json, right? I think that should be a reasonable change, since both MIME types are compatible
There was a problem hiding this comment.
So just for readers from the future, here we stopped mirroring FHIR_JSON content type in the Bot/$execute response by default, since when content type defaults to FHIR_JSON in the client which would trigger that, and subsequently after the change in #5437, would strip out empty arrays which for non-FHIR responses is not expected.
I think we have most of the bases covered now. LGTM
| @@ -534,14 532,16 @@ async function addBotSecrets( | |||
| } | |||
| } | |||
|
|
|||
| const MIRRORED_CONTENT_TYPES: string[] = [ContentType.TEXT, ContentType.HL7_V2]; | |||
| // Default to FHIR | ||
| return ContentType.FHIR_JSON; | ||
| // Default to JSON | ||
| return ContentType.JSON; |
| export type FhirResponse = | ||
| | [OperationOutcome] | ||
| | [OperationOutcome, Resource] | ||
| | [OperationOutcome, Resource, ContentTypeOverride]; |
There was a problem hiding this comment.
For future compatibility, how would you feel about making the 3rd arg into an object such as ExtendedOptions? It seems likely that we will want to add more stuff here over time (http headers, cache control, etc)
There was a problem hiding this comment.
I think we were considering refactoring FhirResponse completely for v4 (making it an object)
There was a problem hiding this comment.
Ah, that makes even more sense.
|
## What's Changed * Update deb-s3 upload command (#5494) * More build-deb action fixes (#5497) * Added GCP Secret Manager support and configType: gcp (#5462) * Case-insensitive search on ContactPoint (#5455) * Centralize token index type determination logic (#5500) * Gather and validate all resource references at one time (#5496) * Revert "Gather and validate all resource references at one time (#5496)" (#5504) * Improve FHIR Datastore docs (#5484) * Check all references at once (#5508) * Fix QuestionnaireForm dependency on requestSchema (#5509) * fix(agent): harden reconnect logic (#5476) * Tighten up JSON vs FHIR JSON response formatting (#5506) **Full Changelog**: v3.2.19...v3.2.20
reshmakh
added
the
fhir-datastore
## What's Changed * Update deb-s3 upload command (#5494) * More build-deb action fixes (#5497) * Added GCP Secret Manager support and configType: gcp (#5462) * Case-insensitive search on ContactPoint (#5455) * Centralize token index type determination logic (#5500) * Gather and validate all resource references at one time (#5496) * Revert "Gather and validate all resource references at one time (#5496)" (#5504) * Improve FHIR Datastore docs (#5484) * Check all references at once (#5508) * Fix QuestionnaireForm dependency on requestSchema (#5509) * fix(agent): harden reconnect logic (#5476) * Tighten up JSON vs FHIR JSON response formatting (#5506) **Full Changelog**: v3.2.19...v3.2.20
The issue that prompted this further cleanup was that Bot execution responses had been getting the FHIR JSON treatment even when they do not return a FHIR resource.
For backwards compatibility, we still assume a FHIR response if the input to the bot execution was FHIR JSON. For the future, we should consider having a more explicit way to specify the content types.
Fixes #5502