Skip to content
This repository has been archived by the owner on May 7, 2024. It is now read-only.

Updated DSTU2 Binary Resource #984

Merged
merged 4 commits into from
Sep 26, 2023
Merged

Updated DSTU2 Binary Resource #984

Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
7d18ecf
Updated DSTU2 Binary Resource
kckeim Sep 20, 2023
5ca9c6c
Update binary.md
kckeim Sep 21, 2023
87f3595
Changed to less "general" language
kckeim Sep 25, 2023
8634386
Missed a period
kckeim Sep 25, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
18 changes: 10 additions & 8 deletions content/millennium/dstu2/infrastructure/binary.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -10,12 +10,13 @@ title: Binary | DSTU 2 API
## Overview

The Binary resource can contain any clinical content such as text, images, and PDFs. This resource is currently limited to Continuity of Care Documents (CCD), clinical documents, and diagnostic reports.
_The list of clinical documents and diagnostic reports is subject to change, as the list of clinical events that may qualify can be customized by clients._

It is recommended to request all Binary resources only after obtaining a link to the resource via references from DiagnosticReport or DocumentReference. It is not recommended to start a workflow in the Binary resource.
It is recommended to request Binary resources only after obtaining a link to the resource via references from [DiagnosticReport](http://fhir.cerner.com/millennium/dstu2/diagnostic/diagnostic-report/) or [DocumentReference](http://fhir.cerner.com/millennium/dstu2/infrastructure/document-reference/). It is not recommended to start a workflow in the Binary resource.

The consumer must populate the Accept header with either application/json+fhir or the format returned in the attachment.contentType of the referring resource. If the Accept header is application/json+fhir, a FHIR Binary resource is returned with the raw data populated in the content. Otherwise, the raw data will be returned (not contained within a FHIR resource). For more information see [the Binary Documentation](http://hl7.org/fhir/dstu2/binary.html#rest).
The consumer must populate the `Accept` header with either `application/json+fhir` or the format returned in the `attachment.contentType` of the referring resource. If the `Accept` header is `application/json+fhir`, a FHIR Binary resource is returned with the raw data populated in the content. Otherwise, the raw data will be returned (not contained within a FHIR resource). For more information see the HL7<sup>®</sup> FHIR<sup>®</sup> [Binary Documentation](http://hl7.org/fhir/dstu2/binary.html#rest).
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

<sup> is unnecessary


NOTE: To retrieve documents with application/pdf contentType, the client must have installed Cerner’s Clinical Reporting (XR) solution. For additional information about Cerner’s Clinical Reporting (XR) solution see [Clinical Reporting (XR) Reference Pages](https://wiki.ucern.com/display/reference/Clinical+Reporting+XR+Reference+Pages).
NOTE: To retrieve documents with `application/pdf` contentType, the client must have installed Cerner’s Clinical Reporting (XR) solution. For additional information about Cerner’s Clinical Reporting (XR) solution see [Clinical Reporting (XR) Reference Pages](https://wiki.ucern.com/display/reference/Clinical+Reporting+XR+Reference+Pages).
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not sure on the updated naming, but I know we've had some communication already. is something we should note for some point


The following fields are returned if valued:

Expand All @@ -31,14 +32,14 @@ List an individual Binary by its id:

_Implementation Notes_

* This is usually linked from DocumentReference or DiagnosticReport 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/dstu2/infrastructure/document-reference/) or [DiagnosticReport](http://fhir.cerner.com/millennium/dstu2/diagnostic/diagnostic-report/) and should be accessed using the exact link given in the referring resource. Modifying the link has undefined consequences.
* Documents containing URL sections are unsupported with contentType of `application/pdf`
* See the [headers](#headers) section for concerns about the Accept header.
* See the [authorization](#authorization-types) section for concerns about the required OAuth scopes.

### Authorization Types

The necessary OAuth scopes can be determined by checking the attachment.contentType in the referring resource. For attachments with the `application/pdf` contentType, the Binary.read and DocumentReference.read scopes are required. For attachments with the `text/html` contentType, the Binary.read and DiagnosticReport.read scopes are required.
The necessary OAuth scopes can be determined by checking the `attachment.contentType` in the referring resource. For attachments with the `application/pdf` contentType, the `Binary.read` and `DocumentReference.read` scopes are required. For attachments with the `text/html` contentType, the `Binary.read` and `DiagnosticReport.read` scopes are required.

<%= authorization_types(provider: true, patient: true, system: true) %>

Expand Down Expand Up @@ -90,13 +91,13 @@ Generates the Continuity of Care Document (CCD) as a Binary for the supplied que

_Implementation Notes_

* This is usually linked from DocumentReference, and should generally be accessed using the exact link given in that resource. Modifying the link has undefined consequences.
* This is usually linked from [DocumentReference](http://fhir.cerner.com/millennium/dstu2/infrastructure/document-reference/), and should be accessed using the exact link given in that resource. Modifying the link has undefined consequences.
* See the [headers](#headers-1) section for concerns about the Accept header.
* See the [authorization](#authorization-types-1) section for concerns about the required OAuth scopes.

### Authorization Types

Requires both the appropriate Binary.read and DocumentReference.read scopes to be granted to the caller.
Requires both the appropriate `Binary.read` and `DocumentReference.read` scopes to be granted to the caller.

<%= authorization_types(provider: true, patient: true, system: true) %>

Expand All @@ -114,7 +115,8 @@ Notes:

### Headers

The `DocumentReference.content.attachment.contentType` should be used to set the `Accept` header. An `Accept` header of `application/json+fhir` could be supplied instead, if the JSON Binary resource is desired insetad of the raw data.
The `DocumentReference.content.attachment.contentType` should be used to set the `Accept` header.
An `Accept` header of `application/json+fhir` could be supplied instead, if the JSON Binary resource is desired insetad of the raw data.

This resource will not accept the `application/json` mime type unless the underlying binary data is json.

Expand Down
Loading