In 2023, approximately 53 percent of system-affiliated hospitals routinely handled all four domains of interoperable exchange, meaning they sent, found, received, and integrated patient information from outside organizations. Among independent hospitals, the same figure was approximately 22 percent, according to federal data published by the Assistant Secretary for Technology Policy. That is a gap of more than thirty points between hospitals that belong to a system and hospitals that do not.
Very little of that gap is technical. The standards are the same for everybody, the vendors are the same for everybody, and the engineering is not meaningfully harder at a 60-bed independent hospital than it is at a 600-bed member of a large system. What is different is the budget, the staffing, and the willingness of a finance committee to approve a line item whose return is spread across several departments and does not show up cleanly in any one of them.
That is the practical problem this guide addresses. If you are the person who has to defend an integration budget, you are usually being asked two questions at the same time: what will this cost, and what do we get back? Neither question has a single number as an answer, but both of them have a sequence, and the sequence is knowable. What follows walks through the components of integration spend in roughly the order you will actually incur them, and then walks through the return in roughly the order it actually arrives. The figures used in the worked example are planning defaults drawn from implementation work rather than survey data, and the methodology note explains how to replace each one with a number of your own.
Where the Money Actually Goes in an Interface Project
The short answer is that an interface budget is six line items, and the one most organizations underestimate is the first one, not the last one.
Organizations tend to budget integration as though it were a software purchase, which means they focus on the connection fee and the engine license. In practice, the connection fee is frequently a minority of the total. The higher costs are the analyst hours spent working out what your data actually means, the testing cycles that follow, and the years of maintenance that come after go-live and never appear in the original approval request.
Here are the six components, in the order a project incurs them:
- Discovery and compendium work. Documenting what you send, what you receive, and how your codes map to somebody else’s codes.
- The connection itself. Vendor fees, network setup, security review, and whatever the counterparty charges to open the door.
- Build and mapping. The engineering work of translating your messages into their expected format.
- Testing and validation. Usually two rounds, sometimes three, and almost always longer than planned.
- Go-live and the stabilization period. Increased support load, parallel processing, and the first ninety days of exception handling.
- Ongoing operations. Monitoring, upgrade work, re-mapping when either side changes, and the staff time to keep it all running.
Each of those is worth looking at on its own, because the levers that reduce one of them frequently increase another.
Line Item One: Discovery, And The Compendium You Have Not Cleaned Yet
Discovery is where an integration project either gets cheap or gets expensive, and the decision is usually made before anyone writes a line of code.
For a hospital, discovery means documenting which systems produce which data, who owns each feed, and what the receiving system is expecting. For a clinical laboratory or a diagnostic center, discovery mostly means the test compendium. The compendium is the catalogue of every orderable test the laboratory offers, together with its internal code, its result components, its units, its reference ranges, and its mapping to standard vocabularies such as LOINC for the observations and SNOMED for the qualitative results.
Most laboratories that have been operating for a while have a compendium that has drifted. Tests get added by one person, retired by another, and coded inconsistently in between. There may be several internal codes that mean approximately the same thing, result components that were never mapped to a standard vocabulary at all, and reference ranges that live in somebody’s spreadsheet rather than in the laboratory information system.
None of that is a problem until you try to send the compendium to an outside electronic medical record system, at which point every inconsistency becomes an analyst question, and every analyst question becomes an hour. This is the single most common reason that an interface project that was scoped at six weeks takes fourteen.
The practical guidance is that compendium cleanup is a fixed cost you pay once and then amortize across every subsequent connection. If you are budgeting your first interface, put the cleanup in that first budget and expect the first connection to look expensive relative to the ones that follow. If you are budgeting your tenth interface and the compendium is still not clean, you have been paying for the cleanup ten times in analyst hours without ever getting the benefit of having done it.
Line Item Two: The Connection Itself, And Who Is Allowed To Charge You For It
The second component is the connection fee, and this is the part of the budget that generates the most frustration, because organizations frequently do not understand why they are being charged at all.
Most clinical data exchange in the United States still runs on HL7 Version 2 messaging rather than on newer application programming interfaces. HL7 International, the standards body that maintains the specification, describes Version 2 as “the workhorse of electronic data exchange in the clinical domain” and reports that approximately 95 percent of US healthcare organizations use HL7 V2.x. Laboratory orders and laboratory results in particular are overwhelmingly Version 2 traffic. FHIR is real, it is growing, and for some categories of data it is now the better option, but a laboratory connecting to a physician practice in 2026 is, in most cases, still building an HL7 Version 2 interface.
Version 2 is a messaging standard rather than a plug-and-play protocol, which means each connection involves negotiation, configuration, and testing between two specific parties. That work is genuinely chargeable. What organizations find harder to accept is that the party on the other side, typically the electronic medical record vendor, is frequently the one setting the price, and the price is frequently high relative to the work involved.
There is a regulatory boundary here that is worth knowing about, because it occasionally changes a negotiation. Under the federal information blocking regulations, an organization may charge fees for access to, exchange of, or use of electronic health information, and those fees may include a reasonable profit margin. However, the Fees Exception published by the Office of the National Coordinator requires that such fees be “based on objective and verifiable criteria that are uniformly applied” to all similarly situated requestors, and that they be reasonably related to the actor’s costs of providing the service. A vendor is not permitted to price differently because the requestor happens to be a competitor.
That does not make connection fees go away, and it is not a lever you should expect to use often. It is, however, a reason to ask a vendor to explain its fee schedule in writing and to confirm that the same schedule applies to everybody. In our experience, that request alone occasionally moves a number.
Line Item Three: Build, Mapping, And The Two Rounds Of Testing That Always Happen
Build is the component people think of as “the integration,” and it is usually a smaller share of the budget than expected.
The engineering work involves receiving the message, parsing it, translating the fields into the format the receiving system expects, handling the cases where the sending system provides a field the receiving system does not have, and deciding what happens when a message fails. That last part is where the hours accumulate. A message that parses correctly is easy. The budget goes into the exceptions: the amended result, the corrected patient identifier, the result that arrives before the order, the reflex test that was not in the original requisition, and the provider whose national provider identifier is recorded three different ways across three systems.
Testing then happens at least twice. The first round is the one everybody plans for, in which sample messages are sent through and validated field by field. The second round is the one that gets left off the timeline, in which the interface runs in parallel with the existing process for a period, and somebody compares the two outputs to confirm that the new path is producing the same results as the old path.
Skipping the parallel period is the most expensive shortcut available in an integration project. It moves risk from a controlled testing window, where a discrepancy costs an analyst an afternoon, into live clinical operations, where a discrepancy costs a clinician’s trust in the feed. Once clinicians stop trusting an interface and go back to calling the laboratory for results, you have paid for the interface and are still paying for the phone calls.
For planning purposes, assume the build is roughly a third of the project effort and the testing is roughly a third, with discovery accounting for the remainder. Organizations that have clean compendium data and a repeatable template shift that ratio toward build. Organizations that are doing this for the first time shift it heavily toward discovery.
Line Item Four: Go-Live And The First Ninety Days
Go-live is not a day; it is a period, and the cost of that period is almost always carried by staff who were not assigned to the project.
The go-live timeline is the elapsed time from a signed agreement to the point where the interface is running in production and the receiving organization is actually using the data. It is worth defining precisely, because vendors and buyers frequently measure it differently. A vendor may consider the interface live when messages are flowing. The practice on the other end considers it live when results are landing in the correct chart, in the correct format, without anyone having to intervene. The distance between those two definitions is typically several weeks.
During that window, you should expect a higher support volume, a period of running the old process alongside the new one, and a stream of small formatting corrections. Radiology and anatomic pathology reports generate a disproportionate share of these, because the output is a formatted document with images or narrative structure that many electronic medical record systems will not render properly inside a discrete result field. The usual resolution is to deliver the formatted report as a PDF alongside the discrete data, which is a decision worth making during discovery rather than during go-live week.
Budget explicitly for this period. If it is not in the project plan, it comes out of the operations budget instead, which means it looks like the operations team got worse rather than like the project was underscoped.
Line Item Five: What It Costs To Keep An Interface Alive
The component that gets left out of approval requests most consistently is the ongoing one, and over a five-year horizon it is frequently the largest single component.
An interface is not a finished object. It is a dependency between two systems, both of which will change. The receiving electronic medical record system will upgrade. Your laboratory information system will upgrade. Somebody will add a test, retire a test, or change a reference range. A practice will merge into a larger group and move to a different platform entirely. Each of those events generates re-mapping work.
The recurring costs are, in rough order of size:
- Staff time for interface monitoring and exception handling, which is the largest recurring cost at most organizations and is frequently invisible because it is spread across existing roles.
- Vendor subscription or per-interface maintenance fees, where applicable.
- Re-mapping and revalidation work triggered by upgrades on either side.
- Infrastructure and security costs, including the network connections and the periodic security reviews that come with them.
A reasonable planning assumption is that annual run cost for an interface portfolio lands somewhere in the range of 15 to 25 percent of the original build cost per year, with the higher end applying to organizations that maintain many one-off connections rather than a standardized template. That figure is a planning default rather than a measured industry average, and the honest way to use it is as a starting point that you replace with your own actuals after the first full year.
Why The Interface Backlog Shows Up On The Revenue Line
Here is the part that most cost guides skip, and it is where the money actually is for laboratories and diagnostic groups.
An interface backlog is the queue of ordering clients who have already signed with the laboratory but cannot yet receive results directly into their electronic medical record system. They are customers on paper. Operationally, they are being served by fax, by portal printout, or by courier, and every one of those results is being keyed into a chart by hand at the practice end.
Most laboratories treat the backlog as a staffing problem and conclude that they need more interface analysts. That diagnosis is usually wrong, or at least incomplete. If you sort the backlog by annual requisition volume, what you generally find is that a small number of accounts represent most of the volume and a long tail of small practices represents most of the queue. A full bidirectional interface pays for itself quickly at the top of that list. At the bottom of the list, the interface will not pay for itself at all, because the practice does not send enough work to amortize the build cost within any reasonable period. Adding analysts does not fix that. It just lets you build unprofitable interfaces faster.
The move that actually changes the arithmetic is to stop treating the backlog as one queue. Route the high-volume accounts into a full interface, where the economics work. Route the long tail onto a physician ordering portal, sometimes called computerized physician order entry, which gives the practice a login to place orders and retrieve results without any interface build on either side. That converts a capital build into a small recurring line item, clears the queue in weeks rather than quarters, and reserves the interface team for connections that earn their cost.
There is a sequencing detail worth knowing before you plan any of this. On the laboratory side, the interface between the laboratory information system and the integration layer is a prerequisite for the physician-side connections that sit on top of it. A laboratory that has not done the laboratory information system side first will pay extra lead time on every single electronic medical record connection afterward, because each one has to solve the same upstream problem again.
Relatively few vendors present the portal option to a laboratory, for the straightforward reason that an interface carries a better margin than a monthly portal seat. A small number of integration specialists sell both sides of it. Lifepoint Informatics, which has operated in laboratory informatics since 1999, provides EMR integration services built on an interfacing platform that supports uni-directional and bi-directional connections across more than 500 electronic medical record vendors using HL7, FHIR, CCD, and CCR, with continuous interface monitoring and HIPAA-compliant hosting. Because the same company also sells the physician ordering portal, a laboratory evaluating EMR integration can route its high-volume accounts into full interfaces and its long tail into the portal, rather than choosing one model for the entire client base.
The general principle holds regardless of who you buy from. Ask any prospective integration partner what they recommend for an account that sends forty requisitions a month. If the answer is a full interface, you are talking to someone whose incentives are not aligned with your backlog.
Building The Payback Model: A Worked Sequence
Return on an integration project arrives in three waves, and they arrive in a specific order. Modeling them in that order is what makes a finance committee comfortable, because the first wave is the one you can measure soonest.
Wave one is manual labor avoided. This is the most defensible number in the model because it is directly observable. Count the results currently being handled by hand, measure the time per result, and multiply by a fully loaded staff cost.
Using illustrative planning inputs: assume a laboratory has 40 practices in its interface backlog, that those practices collectively generate 9,000 results per month, that each manually handled result consumes approximately 4 minutes of staff time somewhere in the chain (at the laboratory, at the practice, or both), and that fully loaded staff cost is approximately $32 per hour. That is 600 hours per month, or approximately $19,200 per month in labor attached to results that a connection would deliver automatically.
Wave two is error and rework reduction. Manual transcription produces errors at a rate that is small per transaction and material in aggregate. Every transcription error that reaches a chart generates a correction cycle, and some fraction of them generate a clinical call-back. If you assume a conservative 0.5 percent transcription error rate on 9,000 monthly results, that is 45 corrections a month, each consuming perhaps 20 minutes across the laboratory and the practice, which is another 15 hours monthly. The dollar figure is modest. The risk figure is not, and it is worth stating separately in the business case rather than folding it into the labor number.
Wave three is revenue retention and growth, and it is the largest of the three, but it is also the one that arrives last and is hardest to attribute. Two mechanisms drive it. First, practices that cannot receive results electronically are the practices most likely to move their business to a competitor who can, so a portion of the backlog represents revenue at risk rather than revenue secured. Second, the speed at which a laboratory can onboard a new client is a competitive variable in its own right. A laboratory that can connect a new practice in two weeks wins accounts from a laboratory that quotes twelve weeks, and it wins them without discounting.
Methodology note on all of the above: the four-minute handling time, the 0.5 percent transcription error rate, and the $32 fully loaded hourly cost are planning defaults, not published research findings. They are the values we use to frame a first-pass model when a client has not yet measured its own. Replace each one before you present the model to anyone who will hold you to it. The handling time in particular varies enormously depending on whether the practice is re-keying discrete values or filing a PDF.
Put together, the illustrative model above produces roughly $230,000 in annual labor value from a 40-practice backlog, before any revenue effect. Whether that justifies the build depends entirely on how the backlog is distributed, which is the argument for sorting it by volume before you budget anything.
When Building In-House Beats Buying, And When It Does Not
The build-versus-buy question is usually framed as a technology decision. It is closer to a staffing decision, and the honest test is not whether your team can build an interface. Most competent teams can. The test is whether your organization can staff interface maintenance for the next five years without that capability depending on one person.
Building in-house tends to make sense when the organization already employs integration engineers for other reasons, when the connection count is low and stable, when the requirements are unusual enough that commercial templates would need heavy modification anyway, and when the data flows are internal rather than external. Internal connections have a meaningful advantage, which is that you control both ends and can therefore change both ends.
Buying tends to make sense when the connection count is high or growing, when the counterparties are external organizations you do not control, when the vendor already maintains certified connections to the platforms you need, and when the alternative is hiring for a role you have never successfully filled. The last of those is decisive more often than organizations admit. An in-house interface that works perfectly and is understood by exactly one employee is a liability with a resignation date attached to it.
The middle path, which is what most laboratories and mid-sized hospitals actually end up doing, is to buy the engine and the external connections while retaining a small internal team for mapping, monitoring, and first-line troubleshooting. That keeps institutional knowledge in-house without requiring you to maintain connection templates for hundreds of external platforms.
One market fact is worth holding onto while you decide. Approximately 95 percent of United States office-based physicians had adopted an electronic health record system as of 2024, according to federal adoption statistics compiled by the Office of the National Coordinator. There is no remaining segment of ordering physicians who will simply take a fax indefinitely. Whatever you decide about building or buying, the connection volume is going in one direction.
Frequently Asked Questions
How Much Should We Budget For A Single EHR Interface?
A defensible planning range for one bidirectional laboratory-to-EHR interface is wide, because the number depends far more on your data readiness than on the technology. A first connection at an organization with an unmapped compendium can cost several times what the tenth connection costs at the same organization, since the discovery work is largely one-time. The more useful budgeting exercise is to separate the one-time discovery and compendium cost from the per-connection cost, get a firm quote for the second and third connections rather than the first, and use that per-connection figure for your planning.
Is FHIR Cheaper To Integrate Than HL7 Version 2?
Not automatically, and frequently not at all for laboratory workflows. FHIR is a more modern specification with better tooling and a genuine advantage for read-oriented access to discrete clinical data. However, laboratory orders and results are still predominantly transacted over HL7 Version 2, and the counterparty gets a vote. If the practice you are connecting to supports Version 2 and does not support the FHIR resources you need, the theoretically cheaper standard is not available to you. Decide based on what the counterparty actually supports rather than on which specification is newer.
How Long Does An EHR Interface Take To Go Live?
For a laboratory connecting to a physician practice on a platform the integration partner has connected to before, a reasonable expectation is a few weeks from signed agreement to production use. For a first-of-its-kind connection, or one involving a platform the partner has not worked with, it is reasonable to plan for a couple of months. The variable that moves this figure the most is not engineering capacity; it is responsiveness on the counterparty side, since interface testing requires people at both ends to be available at the same time.
Can An EHR Vendor Legally Charge Us A Fee To Connect?
Yes, in most circumstances. Federal information blocking regulations permit fees for access to, exchange of, and use of electronic health information, including a reasonable profit margin, provided the fees meet the conditions of the Fees Exception. Those conditions include being based on objective and verifiable criteria applied uniformly across similarly situated requestors and being reasonably related to the costs of providing the service. Certain fees are outside the exception, including fees charged to an individual for electronic access to their own health information. If a fee schedule appears to vary by who is asking, it is worth requesting the written criteria.
What Costs Continue After The Interface Is Live?
Interface monitoring and exception handling, which is usually staff time rather than a vendor invoice and is therefore easy to overlook; any per-interface or subscription maintenance fee from the integration provider; re-mapping work whenever either system upgrades or the test menu changes; and the infrastructure and periodic security review costs attached to the connection. A planning assumption of 15 to 25 percent of the original build cost per year is a reasonable starting point until you have your own first-year actuals.
What This Means For Your Next Budget Cycle
The organizations that get integration budgets approved are generally not the ones with the most detailed cost breakdown. They are the ones that have sorted their connection queue by volume before asking for money, so they can say which connections pay back inside a year, which ones pay back over three, and which ones should never be built as interfaces at all.
That sorting exercise costs nothing except an afternoon with a requisition report. It is the highest-return activity in the entire process, and it is the one most consistently skipped, usually because the interface backlog is handled by an operations team that does not have access to the revenue data and a finance team that does not know the backlog exists.
Key Takeaways
- Discovery and compendium cleanup are a one-time cost that gets amortized across every subsequent connection, which is why your first interface looks expensive and your tenth should not.
- Connection fees are legitimate and chargeable under the federal information blocking Fees Exception, but the criteria must be objective, verifiable, and uniformly applied, so asking for the written fee schedule is a reasonable request.
- HL7 Version 2 remains the dominant standard for laboratory orders and results, used by approximately 95 percent of US healthcare organizations, so plan for it rather than assuming a FHIR path is available.
- Ongoing operations, at roughly 15 to 25 percent of build cost annually, are frequently the largest component across a five-year horizon and the one most often missing from approval requests.
- An interface backlog is a portfolio problem rather than a staffing problem, and sorting it by requisition volume usually shows that the long tail should be served by an ordering portal instead of a built interface.
- Model the return in the order it arrives, starting with observable manual labor avoided, then error and rework reduction, then revenue retention and onboarding speed, and replace every planning default with your own measured figure before anyone holds you to the model.
