Cloud and Data Platforms / HL7 FHIR Integration

Healthcare data has to move between systems that were not built to work together

Electronic health records, lab systems, imaging, devices, research platforms — each with its own data model. HL7 FHIR is the standard that has become the common language, and its fourth release, R4, is the version most systems now target.

What FHIR is

FHIR represents healthcare data as resources, each a defined structure with defined fields, exchanged over standard web APIs using JSON or XML. A system that speaks FHIR can request a patient's lab results from another FHIR system with a single, well defined HTTP call, rather than negotiating a custom interface for each connection.

Patient Observation MedicationRequest DiagnosticReport
A break from HL7 v2

The older messaging standard still widespread in hospitals relies on delimited text messages and interface engines to translate between systems.

Most real deployments still involve both, with FHIR on the modern side and version 2 feeds coming from legacy systems.

Why it matters now

Regulation has pushed FHIR from optional to expected. In the US, the 21st Century Cures Act and the rules that followed require certified health IT to expose patient data through standardized FHIR APIs, which means hospital systems increasingly have FHIR endpoints available.

A platform that can consume and publish FHIR integrates with that ecosystem. One that cannot needs a custom interface for every connection.

Integration in practice

Reading from FHIR

Querying resources, handling the references between them — a DiagnosticReport pointing to its Observations pointing to their Patient — and dealing with the reality that different systems implement the standard with different levels of completeness. Profiles and implementation guides, like US Core, narrow the standard for a specific context and are what a practical integration targets.

Writing to FHIR

Mapping the platform's own data model to FHIR resources correctly. A device reading becomes an Observation with the right coding, the right units, the right reference to the patient and the device. Get the mapping wrong and the data arrives in the clinical record meaning something other than what was measured.

Real time exchange

Where events in one system appear in another as they happen, using FHIR subscriptions or event driven patterns layered on top. The reliability of that layer is what clinicians experience.

SequoiaAT's work

SequoiaAT built real time HL7 FHIR R4 data exchange across all facilities of a multi site hospital network as part of a HIPAA compliant AWS migration, and the company's healthcare capability includes EHR integration systems for healthcare data management. Connected device work publishes device data into that same interoperability layer.

Read the case study → Connected Device Cloud Platforms →
Public work
10 message types

HL7 v2, CCDA and report exports from an oncology EHR parsed, keyed to one master patient index and loaded into PostgreSQL on a schedule, for a healthcare data company.

Read the case study →