6 min readSEYON Insights
HL7 FHIR is a standard for exchanging healthcare information with resources, REST APIs, and JSON or XML representations. FHIR R4 is the release many interoperability programs still target because it is widely implemented. That popularity does not mean a project should expose every resource on day one.
Start with the consumers
List the applications that will call the API and the questions they need to answer. A scheduling tool, a quality report, and a patient summary do not need the same elements. Patient, Encounter, Observation, Practitioner, Organization, DiagnosticReport, and DocumentReference cover a large share of early use cases. Add others when a consumer has a real need.
Profiles, extensions, and terminology
A base resource is a starting point. Profiles constrain it for a workflow, and extensions carry data that the base resource does not. Write those choices down. Terminology needs the same treatment: local codes have to map to a value set the receiver understands, or both sides will store values they cannot compare.
Protect the API
Authentication and authorization belong at the boundary. OAuth 2.0 and SMART on FHIR are common patterns. The right choice depends on the identity platform the organization already runs. A demonstration API with synthetic records is the place to prove the contract. It is not a place for real patient data.
- Publish the resource list and the elements that are in scope.
- Document known gaps instead of silently dropping fields.
- Use synthetic examples for partner development.
- Test authorization with the same identity system production will use.