Current Build

2.35 Resource Binary - Content

FHIR Infrastructure Work GroupMaturity Level: 5 Trial UseCompartments: Not linked to any defined compartments

A binary resource can contain any content, whether text, image, pdf, zip archive, etc.

There are situations where it is useful or required to handle pure binary content using the same framework as other resources. Typically, this is when the binary content is referred to from other FHIR Resources. Using the same framework means that the existing servers, security arrangements, code libraries etc. can handle additional related content. Typically, Binary resources are used for handling content such as:

  • CDA Documents (i.e. with XDS)
  • PDF Documents
  • Images (the Media resource is preferred for handling images, but not possible when the content is already binary - XDS)

A binary resource can contain any content, whether text, image, pdf, zip archive, etc. These resources are served in their native form on the rest interface, but can also be represented in XML or JSON, such as when including these resources in a bundle (used when it is convenient to include these in the feed directly rather than leaving them by reference).

This resource is generally used as the target of a Document Reference or an Attachment, when a FHIR server finds it convenient to manage the content within the same overall REST framework as the other resources.

Structure

NameFlagsCard.TypeDescription & Constraintsdoco
.. Binary ResourcePure binary content defined by a format other than FHIR
Elements defined in Ancestors: id, meta, implicitRules, language
... contentType Σ1..1codeMimeType of the binary content
MimeType (Required)
... securityContext Σ0..1Reference(Any)Access Control Management
... content 1..1base64BinaryThe actual content

doco Documentation for this format

XML Template

<Binary xmlns="http://hl7.org/fhir"> doco
 <!-- from Resource: id, meta, implicitRules, and language -->
 <contentType value="[code]"/><!-- 1..1 MimeType of the binary content  -->
 <securityContext><!-- 0..1 Reference(Any) Access Control Management --></securityContext>
 <content value="[base64Binary]"/><!-- 1..1 The actual content -->
</Binary>

Turtle Template

@prefix fhir: <http://hl7.org/fhir/> .doco


[ a fhir:Binary;
  fhir:nodeRole fhir:treeRoot; # if this is the parser root

  # from Resource: .id, .meta, .implicitRules, and .language
  fhir:Binary.contentType [ code ]; # 1..1 MimeType of the binary content
  fhir:Binary.securityContext [ Reference(Any) ]; # 0..1 Access Control Management
  fhir:Binary.content [ base64Binary ]; # 1..1 The actual content
]

Changes since DSTU2

Binary
Binary.securityContext
  • Added Element

See the Full Difference for further information

This analysis is available as XML or JSON.

See R2 <--> R3 Conversion Maps (status = 2 tests that all execute ok. All tests pass round-trip testing and all r3 resources are valid.).

Structure

NameFlagsCard.TypeDescription & Constraintsdoco
.. Binary ResourcePure binary content defined by a format other than FHIR
Elements defined in Ancestors: id, meta, implicitRules, language
... contentType Σ1..1codeMimeType of the binary content
MimeType (Required)
... securityContext Σ0..1Reference(Any)Access Control Management
... content 1..1base64BinaryThe actual content

doco Documentation for this format

XML Template

<Binary xmlns="http://hl7.org/fhir"> doco
 <!-- from Resource: id, meta, implicitRules, and language -->
 <contentType value="[code]"/><!-- 1..1 MimeType of the binary content  -->
 <securityContext><!-- 0..1 Reference(Any) Access Control Management --></securityContext>
 <content value="[base64Binary]"/><!-- 1..1 The actual content -->
</Binary>

Turtle Template

@prefix fhir: <http://hl7.org/fhir/> .doco


[ a fhir:Binary;
  fhir:nodeRole fhir:treeRoot; # if this is the parser root

  # from Resource: .id, .meta, .implicitRules, and .language
  fhir:Binary.contentType [ code ]; # 1..1 MimeType of the binary content
  fhir:Binary.securityContext [ Reference(Any) ]; # 0..1 Access Control Management
  fhir:Binary.content [ base64Binary ]; # 1..1 The actual content
]

Changes since DSTU2

Binary
Binary.securityContext
  • Added Element

See the Full Difference for further information

This analysis is available as XML or JSON.

See R2 <--> R3 Conversion Maps (status = 2 tests that all execute ok. All tests pass round-trip testing and all r3 resources are valid.).

 

Alternate definitions: Master Definition (XML, JSON), XML Schema/Schematron + JSON Schema, ShEx (for Turtle)

PathDefinitionTypeReference
Binary.contentType The mime type of an attachment. Any valid mime type is allowed.RequiredBCP 13 (RFCs 2045, 2046, 2047, 4288, 4289 and 2049)

Binary resources behave slightly differently to all other resources on the RESTful API. Specifically, when a read request is made for the binary resource that doesn't explicitly specify the FHIR content types "application/fhir+xml" or "application/fhir+json", then the content should be returned using the content type stated in the resource. e.g. if the content type in the resource is "application/pdf", then the content should be returned as a PDF directly.

Note that due to the way the web infrastructure works, it is not possible to make blanket rules about the relationship between the "Accept" field in the HTTP request, and the return type, which is why there is no hard rule about this. However the intent is that unless specifically requested, the FHIR XML/JSON representation is not returned.

Note that in the native binary representation, the normal resource metadata is not available directly, though some of it is replicated in the HTTP response headers. Specifically, the following elements of the resource have matching HTTP Headers:

  • Binary.meta.lastUpdated: Last-Modified
  • Binary.meta.versionId: ETag header
  • Binary.contentType: Content-Type
  • Binary.securityContext: X-Security-Context - this is a FHIR specific extension, primarily intended to allow a the security context for a Binary resource to be specified when it is posted in native form

When a binary is written the server (create/update - POST or PUT), the data is accepted as is and treated as a the binary content of a Binary, including when the content type is "application/fhir+xml" or "application/fhir+json", except for the special case where the content is actually a Binary resource.

Note that when client requests a binary resource using a generic mime type (application/xml, text/xml, or application/json), the server SHOULD return the content directly if the content-type format matches the requested mime type (e.g. if the Accept header is appplication/json, and the contentType is vnd.xacml+json). However servers may not always be able to interpret mime types correctly, and clients SHOULD be prepared to receive either format.

Note that the _summary parameter does not apply when the mime type is not one of the stanard FHIR content types.

Binary resources are not constrained, and therefore can be of any content type and encoding. Therefore extra care needs to be taken to validate the content of the Binary resource against malicious or malformed content. For more details see Security of Narrative.

Very often, the content of a binary resource is sensitive, and the server should apply appropriate access control to the content. When the server itself generates the content, it implicitly knows what access control to apply. When the client provides the binary to the server itself, it uses the securityContext element (or the matching X-Security-Context HTTP header) to inform the server that the Binary resource should be treated as if it was the other resource. Typically, the other resource is a DocumentReference or similar resource that refers directly to the Binary resource, but that is not mandatory.

Search parameters for this resource. The common parameters also apply. See Searching for more information about searching in REST, messaging, and services.

NameTypeDescriptionExpressionIn Common
contenttypetokenMimeType of the binary contentBinary.contentType