Interoperability
FHIR 101: The API Is the Easy Part
A FHIR server will answer its first request in an afternoon, which is why FHIR makes a better first impression than any other clinical standard and why it is so often underestimated. The API is deliberately simple. The agreement underneath it is not, and FHIR moved that agreement out of the wire format and into a separate artefact: the implementation guide. This paper is the orientation layer for the engineers, data scientists and technical product people who have to build against real systems, and it is organised around where the effort actually goes. It follows WP-03, HL7 101, which placed FHIR among its three older siblings and deliberately went no deeper. Current to September 2026, and checked against FHIR R4 (4.0.1), R5 (5.0.0), SMART App Launch 2.0.0 and US Core STU 9.
What’s inside
- The resource and the 80% rule, and why a resource id is not a medical record number
- The nine REST interactions, the CapabilityStatement to read first, and the three details that separate a working client from a fragile one
- Search, and the four features that decide an architecture: _include, _revinclude, chaining and paging
- Bundles and the four exchange paradigms, references and identity, and extensions set beside the Z-segment
- Profiling as the real project: binding strengths, slicing and discriminators, and what must support actually obliges
- Terminology as a service rather than a table, and the licensing that comes with it
- Guides as installable packages, the FHIR Shorthand authoring chain, and validation in continuous integration
- SMART App Launch and backend services, bulk export end to end, where model output belongs, and nine expensive mistakes
PDF · 26 pages
Request this resource
Related insights
- Guide · Interoperability
FHIR: the API is the easy part
A FHIR server answers its first request in an afternoon. Profiles, terminology and the implementation guide are the actual project, and none of them is the API.
· 12 min read - Guide · Interoperability
HL7 is four standards, and none of them has been retired
Ask three engineers in a hospital what HL7 is and you get three answers, all correct. Pipe-delimited text, an XML document, a JSON API: four generations, one name, none switched off.
· 13 min read - Guide · Interoperability
DICOM: not just a file format for medical images
Every scanner, archive and viewer on earth speaks DICOM. Almost every team building AI on medical images discovers, painfully, that it is a four-layer stack and not a header.
· 8 min read