What FHIR is
FHIR (Fast Healthcare Interoperability Resources) is a standard from HL7, the body behind most of the health-data formats in use today. It defines the things healthcare talks about as resources — a Patient, an Encounter, an Observation, a ServiceRequest, a MedicationRequest — each with an agreed shape, and a plain web API for reading and writing them.
Two further pieces matter in practice. Profiles constrain a resource for a particular use: which elements are required, which code systems are allowed, which identifiers must be present. And terminology — code systems and value sets — fixes what the codes inside those resources mean, so a result travelling between two organisations means the same thing at both ends.
The point of all this is that two systems that have never met can exchange health data without first agreeing a private format between them. That is what makes EHDS possible, and it is why Europe built its exchange format on FHIR rather than inventing another one.
How Jengu uses it
Most systems keep a private internal model and generate FHIR when something leaves. Jengu does the opposite: the FHIR resource is the domain model.
A lab order is a ServiceRequest from the moment it is created. A result is a
DiagnosticReport and its Observations. A visit is an Encounter. Those are
not representations produced for an integration — they are the objects each step
of a process reads and writes, held as typed objects in memory and stored as
themselves.
Three consequences follow, and they are the reason for the choice:
- Writes are validated against profiles, in the platform and again in the clinical data store. Data that does not conform does not get in, so conformance is a property of the record rather than of the export.
- Processes are FHIR too. The catalogue of clinical processes and their
steps is published as
PlanDefinitionandActivityDefinition, and running instances point back at it. What the platform does is as inspectable as what it holds. - Terminology carries its own translations, using FHIR's designation mechanism, so a partner reading a code display gets it in their language without us inventing a convention for that.
What this means if you integrate
You get a standards-based API over resources you already know, not a proprietary one with FHIR-shaped output. Your own tooling — validators, libraries, test fixtures — works against it.
Where we are still adding profiles, we say so on the EHDS page, which sets out what is in place and what is not.
Talk to us
Integrating something specific? Write to jengu@jengu.cloud.