This page is part of the FHIR Specification (v1.4.0:
STU
3 Ballot 3). The current version which supercedes this version is
5.0.0
.
For
a
full
list
of
available
versions,
see
the
Directory
of
published
versions
. For a full list of available versions, see the
Directory of published versions
.
Page
versions:
. Page versions:
R5
R4B
R4
R3
R2
|
|
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:
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.
, when a FHIR server finds it convenient to manage the content within the same overall REST framework as the other resources.
Structure
| Name | Flags | Card. | Type |
|
|---|---|---|---|---|
|
Σ | Resource |
|
|
|
Σ | 1..1 | code |
|
|
Σ | 1..1 | base64Binary |
|
Documentation for this format
|
||||
UML
Diagram
UML Diagram
XML
Template
XML Template
<Binary xmlns="http://hl7.org/fhir"><!-- from Resource: id, meta, implicitRules, and language --> <contentType value="[code]"/><!-- 1..1 MimeType of the binary content
--> <content value="[base64Binary]"/><!-- 1..1 The actual content --> </Binary>
JSON
Template
JSON Template
{
"resourceType" : "Binary",
// from Resource: id, meta, implicitRules, and language
"contentType" : "<code>", // R! MimeType of the binary content
"content" : "<base64Binary>" // R! The actual content
}
Structure
| Name | Flags | Card. | Type |
|
|---|---|---|---|---|
|
Σ | Resource |
|
|
|
Σ | 1..1 | code |
|
|
Σ | 1..1 | base64Binary |
|
Documentation for this format
|
||||
XML
Template
XML Template
<Binary xmlns="http://hl7.org/fhir"><!-- from Resource: id, meta, implicitRules, and language --> <contentType value="[code]"/><!-- 1..1 MimeType of the binary content
--> <content value="[base64Binary]"/><!-- 1..1 The actual content --> </Binary>
JSON
Template
JSON Template
{
"resourceType" : "Binary",
// from Resource: id, meta, implicitRules, and language
"contentType" : "<code>", // R! MimeType of the binary content
"content" : "<base64Binary>" // R! The actual content
}
Alternate
definitions:
Alternate definitions:
Schema
/
Schematron
,
Resource
Profile
(
, Resource Profile (
XML
,
,
JSON
),
),
Questionnaire
| Path | Definition | Type | Reference |
|---|---|---|---|
|
|
|
Required |
|
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/xml+fhir" or "application/json+fhir", 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.
is not available directly, though some of it is replicated in the HTTP response headers.
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/xml+fhir" or "application/json+fhir", except for the special case where the content is actually a
Binary
resource.
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 .
Search parameters for this resource. The
common parameters
also apply. See
Searching
for
more
information
about
searching
in
REST,
messaging,
and
services.
for more information about searching in REST, messaging, and services.
| Name | Type | Description | Paths |
| contenttype | token |
|
Binary.contentType |