What EHR Interoperability Requires Beyond System Connections 

Most hospitals and laboratories in the United States already have more EHR interfaces than they can comfortably count, and most of those interfaces work. Messages leave one system and arrive in another. Acknowledgments come back. The dashboard is green.

That is precisely why the industry keeps overstating how interoperable it is. A working connection proves that bytes moved. It says very little about whether the receiving clinician saw the result, whether the receiving system understood what the result was, or whether anyone is allowed, contractually and legally, to use it the way the sender intended. 

Ask an integration team how many of their live feeds deliver data that lands as discrete, correctly coded, clinically usable values, and the answer usually gets vaguer than the interface count.

The argument of this piece is simple. EHR interoperability is a stack of separate agreements, and the physical connection is the lowest and cheapest of them. The expensive failures happen higher up.

A Working Definition Before the Argument

EHR interoperability is the ability of separate electronic health record systems, and the lab, imaging, pharmacy, and other clinical systems around them, to exchange data and then use that data without a person re-keying, re-interpreting or re-checking it.

An EHR interface is narrower: a single configured channel that carries a defined type of message between two systems in a defined direction. Interfaces are the plumbing. Interoperability is what you get when the plumbing, the language, the workflow and the rules all line up.

The most widely cited framework for this comes from HIMSS, which describes interoperability in four levels: foundational (one system can securely send to and receive from another), structural (the format and syntax of the exchange are defined, down to the field), semantic (both sides share coded models and vocabularies, so the data means the same thing), and organizational (governance, policy, legal and consent arrangements that let organizations actually rely on what they exchange).

That model is a good starting point. In practice, we would add one layer it tends to fold into the others, workflow, and treat the ongoing upkeep of every layer as a problem in its own right. What follows takes the stack one layer at a time.

Layer One: The Connection

Foundational interoperability is the part everyone pictures: a VPN tunnel, an SFTP drop, a TLS-secured API endpoint, an interface engine listening on a port. It is the part most often confused with the whole job.

It is also the most solved. Transport and security patterns are well known, and an experienced team can stand up a secure connection between two organizations in days once the paperwork is signed. If an EHR integration project is late, the connection is rarely the reason.

What this layer cannot tell you:

• Whether the message that arrived is one the receiving system can parse.
• Whether a parsed message turned into structured data or into a block of text in a notes field.
• Whether anyone acted on it.

Layer Two: Agreeing on the Shape of a Message

Structural interoperability is about format. Two systems have to agree on which message type is being sent, which segments and fields it contains, which are required, and how repeats, nulls, and escape characters are handled.

HL7 version 2 still carries most of the order and result traffic between labs and EHRs in the US, and its flexibility is both its strength and its curse. The standard allows a great deal of optionality, which means two vendors can both be “HL7 compliant” and still expect results in different fields, with different identifier formats and different rules for corrected results. 

Integration engineers have a long-running joke about it: if you have seen one HL7 interface, you have seen one HL7 interface.

FHIR narrows that variation. ONC’s 2020 Cures Act Final Rule named FHIR Release 4 as the baseline for certified EHR APIs, and resources such as Patient, Observation, and DiagnosticReport give everyone a common, web-friendly shape for the same clinical facts. 

That is real progress. It still leaves implementation guides, profiles, and local extensions to negotiate, and it does nothing on its own about the next layer up.

Layer Three: Agreeing on What the Data Means

This is where EHR interoperability most often breaks quietly. A message can be perfectly formed, pass every structural check, and still say the wrong thing to the receiving system.

Semantic interoperability depends on shared code systems. 

For laboratory data, the central one is LOINC, maintained by the Regenstrief Institute, which publishes universal codes and names for identifying tests and observations. SNOMED CT does similar work for clinical findings, and UCUM standardizes units. 

When a lab’s local test code is mapped to the right LOINC code, a receiving EHR can trend a value over time, put it in the right flowsheet row, and feed it to decision support or a quality measure. When it is mapped wrongly, every one of those downstream uses inherits the error.

Mapping is harder than it looks. A study by Lin, Vreeman, McDonald and Huff, published in the 2010 AMIA Annual Symposium Proceedings, reviewed a sample of 884 laboratory tests drawn from three large institutions that had mapped their own local codes to LOINC. 

Thirty-six of those tests carried at least one mapping error across LOINC’s six descriptive axes, and four had been mapped to codes for entirely unrelated tests. 

The authors traced the errors to recurring causes, among them mapping at the wrong level of detail and unfamiliarity with what a given test actually measures. Those were large, sophisticated organizations doing the work voluntarily and carefully.

The semantic layer also includes things that rarely get called “terminology” but behave like it:

• Units. A glucose result in mg/dL and one in mmol/L are different numbers for the same fact.
• Reference ranges and abnormal flags, which differ by lab, method, and patient population.
• Specimen type and source, which change what a result means clinically.
• Panel composition, because the same orderable name can resolve into different components at different labs.

Layer Four: Workflow, or Whether Anyone Sees the Data

A result can clear all three lower layers and still fail the patient if it arrives somewhere nobody looks. Workflow interoperability is our label for the question the frameworks tend to skip: does the exchanged data show up at the point in the clinician’s day where it is needed, in the form they expect?

Some common examples of data that is technically exchanged but practically lost:

• Results filed as attached documents or PDFs rather than discrete values, so they cannot be trended or alerted on.
• Results routed to an ordering provider who has left the practice, or to a shared inbox no one owns.
• Orders that have to be placed in a separate web portal rather than inside the EHR the physician already has open, which means they often get placed on paper instead.
• Corrected or amended results that arrive without clearly superseding the original.

None of these show up as interface errors. The message was accepted. This is why measuring EHR integration by uptime and message counts alone gives such a flattering picture.

Layer Five: Governance, Trust and the Rules of Exchange

The top of the stack is organizational. Before two parties can rely on exchanged data, someone has to settle who may see it, for what purpose, under what consent, with what liability if it is wrong, and who is responsible for fixing a mapping when it breaks.

US policy has been pushing hard on this layer. The 21st Century Cures Act of 2016 made sharing electronic health information the expected norm, and HealthIT.gov explains that its information blocking provisions apply to healthcare providers, developers of certified health IT, and health information exchanges and networks, with practices likely to interfere with access, exchange, or use of that information prohibited unless an exception applies. 

Regulation can make refusal to share costly. It cannot write the business associate agreement, assign an owner to the code mapping table, or decide who calls whom at 2 a.m. when a feed stops.

In our experience, organizations that struggle with interoperability usually have the technology and lack this layer: no single owner for the test compendium, no agreed process for announcing an EHR upgrade, and no shared definition of “done” between the lab, the practice, and the EHR vendor.

The Layer Nobody Budgets For: Keeping It Interoperable After Go-Live

Every layer above is a snapshot at go-live. Then things start to drift. The lab adds an assay or retires one, and the compendium changes. A practice upgrades its EHR and a field that used to be optional becomes required. A provider identifier scheme changes without notice. 

Each change can push a once-interoperable feed back down the stack, often without a single rejected message, which is what makes it dangerous: results keep arriving, just less correctly.

Sustaining interoperability therefore means treating EHR interfaces as a living service with ongoing semantic and operational upkeep. In practical terms, that looks like:

1. Version-controlled mapping tables, with a clinical or laboratory professional signing off on code changes rather than an interface analyst working alone.
2. A change calendar shared with every connected practice and vendor, so upgrades are tested before they arrive in production.
3. Monitoring that watches message flow and content (unmapped codes, sudden drops in volume, spikes in free-text results), rather than only whether a server is up.
4. A named human escalation path on both sides of each connection.

This is the layer where outside specialists tend to earn their keep, because few laboratories want to staff it around the clock themselves. One of the providers that has built its EHR integration services around this upkeep is Lifepoint Informatics, which has offered vendor-neutral lab connectivity since 1999.

Its EHR interface service bundles compendium management and translation, hub-based normalization of lab data for each receiving EHR, and a 24/7 support center that monitors every live EHR interface on a green, yellow, and red status dashboard, connecting a lab’s LIS to a provider community that the company says spans more than 500 EHR vendors. For an outreach or hospital laboratory, that combination is aimed squarely at the drift problem described above.

Whether a lab buys this layer or builds it, the point stands. An interoperability budget that ends at go-live is a budget for the easy part.

A Quick Way to Check Each Layer

Layer	The question it answers	Typical quiet failure
Connection	Can the systems reach each other securely?	Certificate or credential expires
Structure	Can the receiver parse the message?	Vendor-specific field expectations
Meaning	Does the receiver understand it correctly?	Wrong or missing code mapping, unit mismatch
Workflow	Does the right person see it at the right time?	Result filed as a PDF or to an orphaned inbox
Governance	Is everyone allowed and accountable?	No owner for the compendium or for changes
Upkeep	Is it still true six months later?	Drift after an assay or EHR upgrade

Three Beliefs Worth Retiring

“FHIR will fix interoperability.” FHIR improves the structural layer and makes APIs far easier to build against. Semantic mapping, workflow placement, and governance remain human work.”A certified EHR is an interoperable EHR.”
Certification establishes that a product can do certain things. It does not establish that a particular installation has been configured, mapped, and governed so that it does them with your partners.

“Once the interface is live, the project is finished.” The opening of this piece applies here. A live interface is the start of the job.

Applying the Same Connected Thinking to Healthcare Marketing

The need for connected systems extends beyond clinical data exchange. Healthcare organizations also rely on marketing data to understand which campaigns reach their audiences, how prospective patients discover their services, and where their advertising budgets produce results. When campaign information is spread across platforms, teams can face inconsistent reporting, duplicated work, and incomplete performance insights.

Tools such as Quickads.ai can help businesses streamline advertising creative production and campaign workflows using AI-powered tools. For healthcare organizations promoting their services, this type of platform can support marketing asset creation and help teams manage creative work more efficiently. However, marketing tools serve a different purpose from EHR interfaces and should not be treated as substitutes for clinical data interoperability.

The broader lesson is that connected workflows matter across different areas of healthcare operations. Whether an organization is exchanging laboratory results or coordinating marketing activities, reliable processes, clear ownership, and consistent information help teams work more effectively. Keeping these functions distinct while improving how each one operates allows healthcare organizations to address their clinical and operational needs without confusing their responsibilities.

Where That Leaves an Organization Evaluating Its Own Exchange

If you want an honest read on your own EHR interoperability, stop counting interfaces and start sampling outcomes. Pull a handful of recent results from each major connection and follow them to the receiving chart. Check whether they arrived as discrete coded values, whether the units and flags survived, whether they reached a clinician who acted on them, and whether anyone would have noticed if they had not. The gap between your interface count and the number that pass all of those checks is the real measure of how interoperable you are.