On This Page
November 3, 20268 min read
A potassium result comes back high from an outside reference lab late on a Friday afternoon. The lab sent it electronically. The clinic received it as a fax because the EMR integration with that lab was never finished, and someone scanned the fax into the chart as an image attached to the visit.
The number is in the record in the sense that a person can read it. It is not in the record in any way the EMR can use. No abnormal flag fired, nothing landed in the physician's results queue, and the value will not appear on next month's trend graph. Nobody made a mistake, exactly. The data simply stopped one step short of where it needed to be.
That picture is more common than most vendor demos would suggest. In the American Hospital Association's 2025 IT survey, as published by the federal health IT office, about four in five U.S. hospitals (35% often, 46% sometimes) still received patient information from outside organizations by mail or fax (ASTP/ONC Health IT Quickstats, updated February 2026).
Hospitals are the better-resourced end of the market. Independent practices, which usually have no interface team at all, tend to sit further behind.
Anyone who has worked an interface error queue on the hospital side learns the same lesson eventually: stop asking "are we connected to them?" and start following one piece of data from where it was created to where somebody acted on it.
Most EMR data flow problems show up at a handful of predictable checkpoints along that route. This guide walks through them in the order the data meets them, with what to fix at each one.
Data flow, in this context, is the route a single clinical item (an order, a result, a referral note, a device reading, an eligibility response) takes between your EMR and a system you do not control.
External platforms are any of those outside systems: reference and hospital outreach laboratories, imaging centers, health information exchanges (HIEs), payer portals and APIs, remote patient monitoring vendors, pharmacies, and patient-facing apps.
EMR integration is the set of interfaces, code mappings, and routing rules that let those items move between systems as structured data rather than as paper, a PDF, or a phone call. There is a simple test for whether an EMR integration is doing its job. The receiving system has to be able to do something with the data on its own (file it, flag it, trend it, bill from it) without a person retyping or re-reading it.
Federal researchers measure interoperability in four parts: sending, receiving, finding (querying), and integrating. The fourth part is where most of the clinical value sits, and in our experience it is also the part most often left half finished.
The sequence below follows a lab result, because results are the largest stream of outside data most providers handle. The same checkpoints apply, with small changes, to imaging reports, consult notes, and device readings. Orders travel the same route in the opposite direction, which is covered further down.
If the source system captures a result as free text, or its outbound feed only carries a formatted report, nothing downstream can turn it back into discrete values. Before blaming the EMR interface, ask the sending organization what the feed actually contains: discrete observations with units and reference ranges, a document, or both.
Ask for both. Discrete values drive flags and trending, and a human-readable copy is what the physician will want to open.
Confirm that units and reference ranges travel with each value. Without them, the EMR cannot decide what is abnormal.
Get a sample message from production rather than from the specification document, because the two often differ in small ways that matter.
Most lab, order, and admission traffic in the U.S. still moves as HL7 version 2 messages, an older pipe-delimited format (orders and results each have their own message types). FHIR, the newer API-based standard, is growing quickly for patient access, payer exchange, and app connections. Most providers will need both for years.
The phrase "we support HL7" tells you less than it sounds like. Two systems can both claim HL7 v2 and still disagree about which optional fields they fill in and what goes in them.
Keep a one-page profile for every external EMR interface: standard, version, message types, and which optional fields are in use.
Treat FHIR as an addition for API-style needs (apps, payer exchange, on-demand queries) rather than as a reason to replace HL7 feeds that already work.
For an EMR interface, transport is usually a VPN tunnel, SFTP, a TLS-secured web service, or a Direct secure messaging address. When a connection goes down completely, people notice within hours. The quieter failure is a connection that stays up while the far end rejects messages one by one, and nobody notices because nobody reads the acknowledgments.
Require application-level acknowledgments, meaning the receiving system confirms it accepted and processed the message. A transport-level receipt that the bytes arrived is a weaker signal.
Send rejected-message alerts to a named owner with an agreed response time, rather than to a shared mailbox.
This is the checkpoint that decides whether most EMR integration efforts succeed, and it usually gets the least attention during planning. The outside lab calls a test by its own local code and name. Your EMR's order catalog has a different code and a different display name for the same test.
The HIE may send a LOINC code, which is a third version. Somebody has to keep a translation table between all of these, for every test, every ordering location, and every external partner, and update it whenever either side changes its test menu.
How that translation is organized matters more than most teams expect. In a point-to-point design, every pairing of a sending system and a receiving system carries its own interface and its own mapping table. A health system with 6 internal systems exchanging data with 40 community practices is, in principle, looking at up to 240 separate mappings to build and maintain.
In a hub design, each system connects once to a central layer that normalizes the data, so the same situation is closer to 46 connections, and a test code change is made once rather than dozens of times. That arithmetic, more than any single feature, is why the hub model became the standard approach for labs and imaging groups that serve large provider communities.
Running that normalization layer is specialist work, and many labs, imaging groups, and health systems choose to buy it as a service rather than staff it. Lifepoint Informatics is one of the long-running practitioners of the hub approach to EMR integration services.
Since 1999, it has connected LIS, RIS, and other health IT systems to provider EMRs through a single EMRHub interface, using translation tables inside the hub to route test orders correctly and to normalize results before they reach each EMR, in uni-directional or bi-directional configurations over HL7, FHIR, CCD, and CCR.
The company states that its EMR interface work spans more than 500 EMR vendors and over 20,000 established interfaces (these are its own published counts, not audited figures), and its EMR integration service adds 24/7 interface monitoring with a dashboard that grades each live connection green, yellow, or red.
Whichever way a provider goes, the structural point stands: translation is ongoing maintenance, and it needs an owner.
A perfectly translated result is still useless, or dangerous, if it files to the wrong chart or to no chart at all. Outside systems rarely share your medical record number, so matching on an inbound EMR interface relies on demographics (name, date of birth, sex, address) plus whatever identifiers the partner can pass back, such as your order number.
Ask external partners to return your original order number on every result. It is the most reliable matching key you have.
Review the unmatched-results queue daily. Results that cannot be matched do not disappear; they wait, and the patient waits with them.
Watch for registration habits (nicknames, swapped first and last names, missing middle initials) that create mismatches long before any interface is involved.
This is the "integrate" step of EMR integration, and it is where data flow most often looks finished on paper but is not finished in practice. A result can be received, translated and matched, and still end up filed as a document in a tab nobody opens, rather than as discrete values in the results flowsheet with a task in the ordering physician's inbox.
The gap shows in clinician surveys. Federal analysts found that in 2022, 38% of family physicians said information from clinicians on the same EHR developer was very easy to use, compared with 8% for information from clinicians on a different EHR developer (ASTP/ONC, "Raising the Bar on Interoperability," June 2024).
The same analysis found that 92% of routinely interoperable hospitals had the outside information they needed at the point of care, against 33% of other hospitals. In other words, the difference between "sometimes" and "routinely" connected is large enough to show up at the bedside.
Decide, for each external feed, exactly where each item should file and who gets the task.
File outside results as discrete data wherever the content allows it, and keep the PDF as an attachment, not as the only copy.
Suppress or merge duplicates. Clinicians stop trusting a section of the chart that repeats itself.
Every checkpoint above can fail quietly, which is why EMR integration needs ongoing monitoring as well as a careful build. A partner changes a code, a certificate expires, a new practice location starts sending under an unknown identifier. None of these produce a visible outage.
They produce a slow buildup of results in an error queue.
Monitor message volume per connection against its normal pattern. A feed that usually carries 300 results a day and suddenly carries 40 is broken even if it reports no errors.
Track the age of the oldest item in each error queue as well as the count.
Give every external connection a named owner on each side, with contact details that are kept current.
Outbound data flow (an order from your EMR to an outside lab, a referral to a specialist, an eligibility check to a payer) passes the same checkpoints in the opposite order, and it tends to fail in more interesting ways.
An outbound lab order has to carry the right test code for the receiving lab, any questions that must be answered when the order is placed, insurance details, and diagnosis codes that support medical necessity. If any of these is missing, the order does not fail on the interface. It fails at the lab's front desk, where someone phones the practice, or the specimen sits until the requisition is fixed.
For that reason, outbound EMR integration deserves its own testing pass with real order scenarios: a standing order, an add-on test, a test that requires a patient questionnaire, and an order for a patient whose insurance has just changed.
Without a few simple measures, improvement work drifts into opinion. The following are reasonable starting indicators (they are judgments about what is useful to track, not published benchmarks):
Share of outside results filed by the EMR interface as discrete data rather than as documents or scanned images.
Number of active external partners still sending by fax, tracked monthly and expected to fall.
Median time from result release in the outside system to its appearance in the ordering physician's inbox.
Count and age of unmatched or rejected messages at the end of each week.
Clinician-reported ease of finding outside information, gathered in a short survey once or twice a year.
The last measure matters more than it looks. In a KLAS Arch Collaborative study reported in September 2024, only 44% of surveyed clinicians were satisfied with how well their EHR integrated with outside organizations, and 47% said they had to sift through duplicated data.
Clinicians who felt well trained on finding outside information were far more likely (72% against 26%) to say their EHR delivered the external integration they expected (TechTarget, reporting the KLAS findings). Part of the fix for data flow is technical. Part of it is simply showing clinicians where the outside data now lands.
Interoperability is the broad ability of different systems to exchange information and use it. EMR integration is the specific, practical work of connecting one EMR to particular outside systems: the interfaces, code mappings, matching rules, and filing rules that make the exchange happen for real messages.
Usually because the interface was built to carry a formatted report rather than discrete values, or because the discrete values could not be mapped to your EMR's catalog and the document was the fallback. Ask the partner for a production sample message and check whether discrete results are present. If they are, the gap is in the mapping or filing rules on your side.
Not entirely. Networks and HIEs are well suited to finding and retrieving records about shared patients, such as summaries of care. High-volume transactional traffic, especially lab orders and results with a specific outside lab, still typically runs through dedicated interfaces because it needs order-level detail, acknowledgments, and tight turnaround.
At minimum: whether each connection is up, message volume compared with its normal daily pattern, rejected or unmatched messages, and the age of the oldest unresolved item. A short daily review of those four items catches most silent failures before a clinician does.
If you can only do one thing this quarter, pick your three highest-volume external partners and trace a single real result from each one, end to end, through all seven checkpoints. Write down where it stopped being structured, where it waited, and where a person had to touch it.
That list is your EMR integration roadmap, and it will be more accurate than any vendor assessment, because it is built from your own data, taking its own route.
Courses
Upskill with job-ready training.
Mock Tests
Measure your learning progress.
Create an online video course, reach students across the globe and earn money
