Updated R4 Binary Resource #983
Conversation
General formatting updates. Itemized list follows on Pull Request. Verified good links throughout document, and have validated that example API calls behave as noted with examples
kckeim
requested review from
gmodrogan,
amcginn,
krycunn,
RicardoCrespo-ora and
AlexandruBasarab
|
|
||
| It is recommended to request Binary resources only after obtaining links to the resources via references from DiagnosticReport or DocumentReference. It is not recommended to start a workflow with Binary resources. | ||
| It is recommended to request Binary resources only after obtaining links to the resources via references from [DiagnosticReport](http://fhir.cerner.com/millennium/r4/clinical/diagnostics/diagnostic-report) or [DocumentReference](http://fhir.cerner.com/millennium/r4/foundation/documents/document-reference). It is not recommended to start a workflow with Binary resources. |
There was a problem hiding this comment.
is it possible to build internal reference links dynamically? If the R4 DocumentReference documentation moves from that URL, when this will break
There was a problem hiding this comment.
Spoke with George over IM about this.
We have identified links like these as something that will need to be updated in tandem with our hosting on the new site.
We'll be looking to complete that work over the coming sprints, and be tracking that work under separate stories.
For now, the links will work as intended to redirect users over to the correct endpoint.
We'd like to proceed with merging, understanding that these will be adjusted at a later date.
| @@ -31,7 +33,7 @@ List an individual Binary by its id: | |||
|
|
|||
| _Implementation Notes_ | |||
|
|
|||
| * This is usually linked from DocumentReference, DiagnosticReport, or Communication and should generally be accessed using the exact link given in the referring resource. Modifying the link has undefined consequences. | |||
| * This is usually linked from [DocumentReference](http://fhir.cerner.com/millennium/r4/foundation/documents/document-reference), [DiagnosticReport](http://fhir.cerner.com/millennium/r4/clinical/diagnostics/diagnostic-report), or [Communication](http://fhir.cerner.com/millennium/r4/clinical/request-and-response/communication) and should generally be accessed using the exact link given in the referring resource. Modifying the link has undefined consequences. | |||
There was a problem hiding this comment.
same as above, is it possible to have dynamic link?
There was a problem hiding this comment.
Spoke with George over IM about this.
We have identified links like these as something that will need to be updated in tandem with our hosting on the new site.
We'll be looking to complete that work over the coming sprints, and be tracking that work under separate stories.
For now, the links will work as intended to redirect users over to the correct endpoint.
We'd like to proceed with merging, understanding that these will be adjusted at a later date.
|
|
||
| The consumer must populate the Accept header with either `application/fhir+json` or the format returned in the `attachment.contentType` of the referring resource. If the Accept header is `application/fhir+json`, a FHIR Binary resource is returned with the raw data populated in `Binary.data`. If the Accept header is anything else, the raw data will be returned instead of a FHIR Binary resource. For more information, see the HL7<sup>®</sup> FHIR<sup>®</sup> [Binary documentation](http://hl7.org/fhir/r4/binary.html#rest). | ||
| The consumer must populate the `Accept` header with either `application/fhir+json` or the format returned in the `attachment.contentType` of the referring resource. If the `Accept` header is `application/fhir+json`, a FHIR Binary resource is returned with the raw data populated in `Binary.data`. If the `Accept` header is anything else, the raw data will be returned instead of a FHIR Binary resource. For more information, see the HL7<sup>®</sup> FHIR<sup>®</sup> [Binary documentation](http://hl7.org/fhir/r4/binary.html#rest). |
There was a problem hiding this comment.
Didn't know, and didn't want to break it on accident, so I left it there.
* Review and corrections for ChargeItem (#976) * typo fix for CapabilityStatement (#977) * fixing URLs for scope and purpose in consent (#979) * Updated DSTU2 care-plan (#980) * Updated R4 CarePlan Resource (#981) * Updated R4 CareTeam Resource (#982) * Updated R4 CareTeam Resource (#983) * Updated DSTU2 Binary Resource (#984) * Review and Corrections for Device (#985) * Consent updated examples (#986) * Updated AllergyIntolerance R4 resource (#987) * Custom encounter search (#989) * Updated AllergyIntolerance DSTU2 resource (#990)
General formatting updates.
Itemized list follows on Pull Request's Description
Verified good links throughout document, and have validated that example API calls behave as noted with examples
Description
PR Checklist
Overview paragraph before
Overview paragraph after
Resources w/o links
Resources w/ links
Example autogen-ccd-id update before
Example autogen-ccd-id update after
