Binary — Opaque content container
Binary carries an unstructured payload: discharge letter PDF, DICOM image, consult audio, digital signature. Referenced by DocumentReference, Attachment and Bundle.
Purpose
Binary is the standard route for unstructured content inside a FHIR server. Two modes:
in JSON via data (base64), or via direct REST access on /Binary/[id]
with HTTP content negotiation.
Key fields
| Field | Type | Cardinality | Role |
|---|---|---|---|
contentType | code (MIME) | 1..1 | MIME content type (application/pdf, image/jpeg, application/dicom). |
securityContext | Reference(Any) | 0..1 | Security context — used by the authorisation engine. Typically Patient or Encounter. |
data | base64Binary | 0..1 | Inline base64-encoded data (reasonable sizes only). |
JSON example
Embedded discharge letter PDF:
{
"resourceType": "Binary",
"id": "discharge-letter-pdf",
"contentType": "application/pdf",
"securityContext": { "reference": "Encounter/stay-12345" },
"data": "JVBERi0xLjcKCjEgMCBvYmoKPDwgL1R5cGUgL0NhdGFsb2cgL1BhZ2VzIDIgMCBSID4+CmVuZG9iagovL0F2YWlsYWJsZSBhcyBpbmxpbmUgZGF0YSwgYmFzZTY0LWVuY29kZWQ="
} REST API
POST /Binarywith raw body +Content-Type: application/pdf— direct create with no JSON wrapper.GET /Binary/[id]withAccept: application/pdf— fetches raw binary content.GET /Binary/[id]withAccept: application/fhir+json— fetches JSON wrapper with base64data.
Common pitfalls
- Everything inline in JSON: for large files (> 1 MB), prefer direct REST access or DocumentReference + Attachment.url external.
- SecurityContext missing: without context, the authorisation engine cannot determine access.
- Corrupted base64: some middlewares (gateways) re-encode — verify integrity (hash) after transit.
Related resources
- DocumentReference — pointer + metadata to a clinical Binary.
- Attachment — FHIR data type to embed a binary (with
urlto Binary). - Bundle — can reference Binary by
fullUrl. - Media — deprecated in R5; clinical photos/videos migrate to DocumentReference + Binary.
See also: DocumentReference, Bundle.