A photo uploaded by a Patient. A PDF report written by a surgeon after a procedure. A document built from other FHIR resources.
Does it belong in an Attachment element?
Maybe. The Attachment element can be used to store either the file itself or a link to that file if it’s stored elsewhere.
Here are some FHIR resources that contain Attachments:
But let’s say you’re building a screen displaying the most recent reports issued by a doctor. You make a GET request that returns 20 or 50 DiagnosticReport resources, each one containing an Attachment element.
The last thing you want to see in that Attachment is a 15 or 20 megabyte PDF file, as it could take forever to retrieve the data and to load your screen.
This is where the Binary resource comes into its own.
A Binary resource contains only the raw data in a file — nothing more.
No context for the file such as Subject or BasedOn. No meta data about the file such as author or Organization. No searchable parameters.
By storing the file contents in a Binary resource, and linking to that resource from the Attachment.url of your DiagnosticReport, the GET request used to populate your screen returns all the required data apart from the file itself.
The file can be retrieved individually when required using the link to the Binary resource contained within the Attachment.
It’s not always a good idea to store raw files within FHIR, but sometimes you have no choice. When that situation occurs, do yourself and your future developers a favour and consider storing it in the Binary resource.
Sign up to “The Tuesday FHIR Sessions” and receive an email every Tuesday where I go deep on a single FHIR topic.