FHIR integration
services
FHIR R4 and SMART on FHIR integration, without rebuilding your data model for every customer.
Two systems can both support FHIR and still not talk to each other
FHIR says how information should be described. It does not guarantee the system in front of you implements the parts you need, in the version you expect. Most projects run long because that gap is found in the build rather than in planning.
FHIR work we take on
FHIR APIs on your product
A conformant FHIR interface on your own platform, so enterprise customers can integrate with you rather than asking for something bespoke each time.
Consuming EHR FHIR APIs
Reading and writing patient, encounter, observation, condition, medication and document data from systems your customers already run.
SMART on FHIR applications
Applications that launch inside the EHR with patient and user context already set, so clinicians do not have to switch systems.
Resource mapping and profiling
Mapping your data model onto FHIR resources, applying the profiles a market expects, and handling extensions.
HL7 v2 to FHIR
Translating existing message flows into FHIR resources, usually alongside the v2 interfaces rather than instead of them.
FHIR facade over legacy
A FHIR interface in front of a system that will never be rewritten, so it can participate in an exchange it was not designed for.
Bulk data export
Population-level extraction using the FHIR bulk data specification, for analytics, reporting and model work.
Conformance and testing
Validating resources against profiles, publishing a CapabilityStatement that reflects what you support, and testing against vendor sandboxes first.
The parts that decide how long an integration takes
Versions and profiles
R4 is the version most production integrations use. Beyond the version, what matters is the implementation guide a market expects: US Core in the United States, the International Patient Summary for cross-border summaries, national guides elsewhere. A resource valid against the base specification can still fail validation against the profile your customer requires.
Authorisation and context
Access is usually negotiated through SMART App Launch, using OAuth 2.0 with scopes limiting an application to specific resources and patients. Asking for more access than the product needs slows every customer security review. Launch context decides whether your application arrives knowing which patient and user it is dealing with.
Data quality and terminology
FHIR describes structure rather than meaning. Two systems can exchange a perfectly valid Observation and still disagree about what was measured, because one uses LOINC and the other a local code. Terminology mapping, unit handling and identifier resolution are where most of the real work sits.
FHIR work in practice
The resources that come up in nearly every project
| Resource | What it carries | Where it matters |
|---|---|---|
Patient |
Demographics and identifiers | Every integration. Identifier resolution is the first thing to get right |
Encounter |
A visit or episode of care | Linking your data to the right clinical context |
Observation |
Measurements and results | Device readings, vital signs, laboratory results |
Condition |
Diagnoses and problems | Risk logic, cohorting, care pathways |
MedicationRequest |
Prescriptions | Adherence programmes, medication reconciliation |
DocumentReference |
Clinical documents | Writing summaries and reports back into the record |
Device & DeviceMetric |
Connected devices and what they measure | Remote monitoring and IoMT |
Appointment & Schedule |
Booking and availability | Telehealth and patient engagement products |
Questionnaire |
Structured forms | Digital intake and patient-reported outcomes |
How we run a FHIR integration
Discovery
Which system, which version, which implementation guide, which resources, what the customer’s IT team will authorise, and what the sandbox does differently from production.
Mapping
Your data model onto FHIR resources, including terminology, units, identifiers and the extensions needed for anything the base specification does not carry.
Authorisation
SMART App Launch or client credentials, scope design, registration with the vendor, and the approval route through the customer organisation.
Build
The interface itself, error handling, retry behaviour and the CapabilityStatement describing what you support.
Validation
Resource validation against the applicable profiles, testing against the vendor sandbox, then a controlled test against the customer environment.
Monitoring
Alerting on failed exchanges, stalled feeds and authorisation expiry, because integrations break quietly when a system is upgraded.
Reference architecture
Frequently asked questions
It depends on how many systems are involved and how much of your data model has to be mapped. A single read-only connection to one well-documented API is a small piece of work. Two-way exchange across several customers each running a different EHR is usually better solved with an integration layer than one connection per customer.
Not always. If you are only consuming another system’s FHIR API you do not need one. You need one when publishing data for others to consume, and even then a facade over your existing database is sometimes a better answer.
Usually yes, as a facade. Your application continues as it is, and a translation layer presents a conformant FHIR interface to the outside world. It is the standard route for systems that will not be rewritten.
[CLIENT INPUT REQUIRED: name only systems you have genuinely integrated with in production. A short honest list beats a long implied one, and this is the question that gets checked.]
HL7 v2 is a messaging standard, in wide use and unlikely to disappear, where systems send messages about events as they happen. FHIR is a resource and API standard, where a system asks for the information it needs when it needs it. Most healthcare organisations run both.
Talk to us about a FHIR integration
Tell us which system you need to connect to and what has to move between you. We can usually say quickly whether the approach you are considering will work.