25.31 — Health Data and Interoperability: HL7, FHIR and USCDI

A patient is admitted unconscious to a hospital in another state. He has a cardiac condition, takes an anticoagulant, and is allergic to a common antibiotic. His own hospital's record has all of this. The admitting team does not.

Ask why not, and the answer is never one thing. His record is in a system that speaks a different dialect. Nobody is certain he is the same "James Miller, born 1968" the other system holds. His consent to share is recorded on paper somewhere. His own hospital has no financial reason to make transferring his record easy. And the two systems are, in fact, connected — but only for laboratory results, in a message format built in the 1980s.

Interoperability is the industry's word for fixing that, and this chapter is why it has taken thirty years and where it now genuinely stands.

Why this is hard, stated honestly

Four separate problems hide behind the single word.

Syntax. Two systems must agree on the shape of the message. This is the easiest problem and it was solved first.

Semantics. They must mean the same thing by the same content. One system's "blood glucose" is fasting, another's is random, a third stores it in different units. Sending the number without its meaning is worse than sending nothing, because it looks usable.

Identity. They must agree that this is the same person. The United States has no national patient identifier, so matching is done on names, dates of birth and addresses, and it is imperfect in both directions — records missed, and worse, records wrongly merged.

And incentives. For a long time, a hospital that made it easy to move a patient's record made it easy to lose the patient. That is a business problem, and it was eventually addressed by law rather than by technology, in the information blocking rules described below.

HL7 version 2: the standard that actually runs hospitals

HL7 version 2 dates from the late 1980s and it still carries the overwhelming majority of real clinical messaging inside hospitals today. Any project touching a hospital will meet it.

A message is plain text, in segments separated by carriage returns, with fields separated by pipe characters. Each message has a type describing the event. The common ones are worth knowing by name: ADT for admissions, discharges and transfers, ORM for orders, ORU for results, SIU for scheduling, and DFT for charges.

A results message begins with a header segment identifying the sender, receiver and message type, followed by a patient identification segment, then order and observation segments carrying the actual values.

Its famous weakness is optionality. The standard leaves a great deal optional and allows local extension, so two conforming implementations can be mutually unintelligible. The industry joke that "if you have seen one HL7 interface, you have seen one HL7 interface" is precise rather than funny.

Which is why interface engines exist — middleware that receives, transforms, routes and monitors these messages between systems. A hospital typically runs hundreds of interfaces, and an interface engine is often the single most business-critical piece of software in the building.

Documents: CDA and the summary of care

The next generation took a different approach: instead of event messages, exchange documents.

The Clinical Document Architecture defines an XML document that is both human-readable and machine-processable, and the widely used American profile of it — the Consolidated CDA — defines documents such as the continuity of care document and the discharge summary.

These carry a patient's problems, medications, allergies, results and procedures as a package, and they became the standard artefact for transitions of care. The weakness is granularity: if you want one blood pressure reading you receive a whole document and have to parse it, which is why the next standard exists.

FHIR: what actually changed

FHIR — Fast Healthcare Interoperability Resources, pronounced "fire" — took the modern web's approach and applied it to health data. It has become the direction of travel for the entire field, and it is now written into regulation.

The core idea is resources. Health data is broken into discrete objects — Patient, Encounter, Observation, Condition, MedicationRequest, AllergyIntolerance, DiagnosticReport, Procedure, Coverage, Claim — each with a defined structure, an identity, and a URL.

They are exchanged over ordinary REST, in JSON or XML. Fetching a patient is a GET on a URL. Searching observations for that patient with a particular code is a query string. Anybody who has built a web API already knows how to consume this, which was the entire point.

Three extensions matter operationally.

Profiles and implementation guides. The base specification is deliberately general, so real use requires a profile constraining it: which fields are mandatory, which code systems must be used, which extensions exist. In the United States the baseline profile is US Core, and almost every American FHIR project is really a US Core project.

SMART on FHIR. A standard way for a third-party application to be launched from within an electronic health record, authenticate using standard authorisation flows, and access data scoped to the user and patient. This is what made an app ecosystem on top of hospital records possible.

And bulk data export. A defined way to extract data for a whole population asynchronously, which is what analytics, quality measurement and research actually need — the point-by-point API being useless at that scale.

Version numbering matters when reading documentation. R4 is the version that regulation and most implementations settled on, with later releases refining it. When somebody says "we are on FHIR", the first useful question is which version and which implementation guide.

The semantic layer: the vocabularies

FHIR carries the structure. Meaning comes from code systems, and getting these right is the difference between exchanging data and exchanging information.

System	What it codes
SNOMED CT	Clinical findings, problems, procedures
LOINC	Laboratory tests and measurements
RxNorm	Medications, normalised across brands
ICD-10-CM	Diagnoses for billing and statistics
CPT / HCPCS	Procedures and services for billing
NDC	Specific drug products and packages
UCUM	Units of measure

The distinction that trips up newcomers is between clinical and billing vocabularies. SNOMED describes what the clinician believes about the patient; ICD-10 describes it in the categories the payment system uses. They overlap, they map imperfectly, and treating one as a substitute for the other produces subtly wrong analytics.

And LOINC deserves a specific mention because it solves the semantic problem from earlier in this chapter. A LOINC code specifies what was measured, in what, by what method, and in what units — so "glucose, fasting, in serum, mass concentration" is a different code from a random glucose, and the receiving system does not have to guess.

USCDI: the agreed minimum content

A standard for exchange does not settle what must be exchanged. That is the job of the United States Core Data for Interoperability — USCDI — which defines the data classes and elements that certified health IT must be able to share.

It is versioned and grows annually on a predictable cycle: a draft in January, a final version in July. Version 3 is the version adopted in the certification regulations, versions 4 and 5 became available for voluntary early adoption, and version 6 was published in July 2025, with a draft version 7 issued in January 2026.

The practical reading for an engineer. The certified baseline your client must meet and the newest published version are usually not the same, and there is a formal mechanism allowing developers to adopt newer versions voluntarily ahead of a regulatory requirement. So the correct answer to "which USCDI do we support" is a version number plus a statement of whether it is the required baseline or a voluntary advance.

Its content is what you would expect: patient demographics, problems, medications, allergies, laboratory results, vital signs, procedures, immunisations, care team, clinical notes, and — added in later versions — data about the social factors that affect health, such as housing and food security.

The law that made sharing mandatory

Technology did not solve interoperability; regulation did most of the recent work, and three pieces of it define the current landscape.

The 21st Century Cures Act of 2016 required certified health IT to provide programming interfaces allowing access to health information "without special effort", and prohibited information blocking.

Information blocking is a practice by a health IT developer, provider or health information network that is likely to interfere with access, exchange or use of electronic health information, where the actor knows or should know it will do so. Defined exceptions exist — for privacy, security, infeasibility, harm prevention and a few others — and anything outside them is a violation with financial consequences. This is what removed the incentive problem named at the start of the chapter: refusing to share is now unlawful rather than merely unhelpful.

And the certification programme, administered by the federal health IT office — renamed in 2024 to the Assistant Secretary for Technology Policy, so both names appear in current documents — which defines what a certified electronic health record must be able to do, including the FHIR interfaces and the USCDI content above.

On the payer side, the rules described in Chapter 25.28 require FHIR interfaces for patient access, provider access, payer-to-payer exchange and prior authorisation, with a compliance date of 1 January 2027.

Patient matching, the problem nobody has solved

Without a national identifier, every exchange has to decide whether two records describe the same person.

Organisations run a master patient index using probabilistic matching on names, dates of birth, sex, addresses, phone numbers and other identifiers, with thresholds for automatic matching and a queue for human review.

Both error types are harmful and they trade against each other. A missed match means a clinician does not see existing information — the scenario at the top of this chapter. A false match means one patient's data is merged into another's record, which is a patient safety event and is extremely difficult to unpick afterwards.

Anything you can do to improve the inputs is worth more than any improvement to the algorithm. Standardised address formatting, collecting a mobile number, and capturing identifiers consistently at registration move match rates more than tuning ever does.

What this means for the work

Three practical positions will serve you well on any interoperability project.

You will not get to work only in FHIR. Real integration work is FHIR at the edges, HL7 v2 inside the hospital, documents for transitions of care, flat files from laboratories, and at least one thing arriving as a spreadsheet by email. A design that assumes otherwise fails on contact with a real site.

Terminology mapping is the actual work. Moving data is a solved problem; making the receiving system understand it correctly is where projects run long. Budget for terminology work explicitly, and expect to need clinical input on the mappings.

And exchanging data is not the same as making it usable. A clinician handed 400 pages of imported records has not been helped. The valuable products are the ones that reconcile — merging duplicate medication lists, deduplicating problems, surfacing the six facts that matter for this visit — and that is a much harder and much more valuable problem than transport.

Next: Chapter 25.32, the national layer sitting above all of this — TEFCA, the QHINs, and how a query for a patient's records finds them across the country.