HL7/FHIR Integrations Are Important, But Are They Slowing Down Your Product Roadmap?

Most medtech engineering leaders can tell you what an EHR integration costs to build. Far fewer can tell you what it costs to own. That gap is where product roadmaps quietly go missing. A connection to a hospital’s EHR doesn’t end at go-live: it carries validation evidence, documentation, version compatibility, and support obligations that follow it for as long as the interface exists. Stack a few of those together and integration work stops being a project and starts being a standing tax on engineering capacity. This piece looks at the full life of a single integration, which parts of it are genuinely your product, and which parts are worth handing to a configurable platform.

Should Engineering Teams Build Every HL7/FHIR Integration?

No. Building every connection in-house makes sense only when the integration itself is part of what makes the product valuable. For most medical device and health tech companies, choosing the right EHR integration strategy means treating transport and translation layers as commodity work that a configurable, standards-based HL7 and FHIR platform handles more cheaply than an engineering team can. What’s worth building is what the product does with the data once it arrives.

Key Takeaways

• The build cost of an integration is the smallest part of its total cost.
• For regulated devices, each interface carries design, validation, and labeling considerations that persist long after launch.
• Integration work rarely blocks a roadmap outright. It erodes it, a sprint at a time.
• Not all integration work is equal. Some layers are commodity, one layer is genuinely your product.
• The goal isn’t fewer integrations. It’s spending engineering time only where it differentiates you.

Why Healthcare Interoperability Became a Product Requirement

A decade ago, EHR connectivity was something a medical device company added after the product proved itself. Now it shows up in the first procurement conversation. Clinicians expect device data where they already work, and a product that can’t get it there struggles to get adopted regardless of how good the underlying technology is.

Federal data shows how normal this has become. In 2024, roughly 9 in 10 hospitals integrated data from third-party technology into their EHR for at least one clinical purpose, and 83% sent data from the EHR back out to third-party systems (healthit.gov). The clinical categories ONC tracked were remote patient monitoring, telehealth, clinical decision support, and population health. Those are the categories most connected devices live in.

One number in that same brief deserves more attention than it usually gets. About half of hospitals used standards-based APIs when integrating clinical data from third-party technology, and only 39% when sending data back out. The rest runs on proprietary EHR APIs and non-API methods, including HL7 v2 interfaces.

So the practical picture isn’t a clean migration to FHIR. It’s a mixed environment where FHIR, HL7 v2, and vendor-specific APIs all coexist, and will keep coexisting for years. Any roadmap built on “we’ll standardize on FHIR and this gets simpler” is planning for a world that isn’t arriving soon.

And connectivity itself won’t differentiate you. Every serious competitor in your category is expected to connect to Epic, Oracle Health, and MEDITECH. What separates products is what happens after the connection exists.

What One Integration Actually Costs, Start to Finish

Engineering estimates almost always cover the second stage on that list. The build. It’s the visible part, the part with a ticket attached, and it’s the number that gets quoted when someone asks how long a new hospital will take.

The trouble is that the build is rarely the expensive part.

Discovery comes first, and it’s unpredictable by nature. You’re learning how one hospital implements a standard, what their workflow actually expects, and which fields matter clinically rather than just technically. Two hospitals on the same EHR can still need meaningfully different work.

Validation comes after the build, and for a medical device company it isn’t optional paperwork. More on that below.

Then comes the part nobody budgets: steady state. The interface exists now, so it generates support tickets. A mapping needs correcting. An edge case appears that testing didn’t catch. Someone at the hospital changes a workflow and something downstream breaks quietly.

And then the EHR gets upgraded, and a connection that worked fine for eight months needs attention again.

Here’s the part that matters for planning. Every one of those stages except the build recurs. Add a customer and you don’t add one project, you add one more permanent obligation to a list that only grows. The tenth integration doesn’t just cost what the first one cost. It costs that, plus a share of maintaining the nine before it.

The Layer Medtech Teams Underestimate: Validation and Design Evidence

For a medical device company, an interface isn’t only software. It’s part of the device’s design surface, and that brings obligations teams from unregulated software backgrounds often don’t anticipate.

FDA’s guidance on interoperable medical devices asks manufacturers to think through the purpose of each electronic data interface, who the anticipated users are, what happens when exchanged data arrives incomplete or delayed, and how the interface gets verified, validated, and described in labeling. It also sets out what FDA expects to see about those interfaces in premarket submissions (fda.gov).

Read that next to a build-everything-in-house strategy and the arithmetic shifts. A custom interface isn’t a two-week task that disappears from the backlog. It’s a design decision with testing evidence and documentation attached, and that attachment lasts as long as the interface does.

Now multiply it. Fifteen hospital customers across four EHR platforms, each with its own interface, its own validation record, and its own documentation to keep current. The overhead stops being linear well before you notice it happening.

This is why experienced medtech engineering leaders treat integration architecture as a product decision rather than a delivery detail. A standardized integration layer means one validated approach applied repeatedly. Fifteen bespoke interfaces means fifteen things to verify, document, and defend.

Where the Roadmap Actually Goes

Integration work rarely blocks a roadmap outright. If it did, someone would escalate it. What it does instead is erode the roadmap gradually, which is much harder to see and much harder to argue about.

The mechanism is simple. Integration work arrives with a customer name attached, and roadmap work doesn’t. When a hospital’s interface breaks or a signed deal needs a connection built, that request feels urgent in a way a planned feature never does, even when the planned feature is worth more to the business. So it wins the sprint. Then it wins the next one.

Look at any single quarter and nothing seems wrong. A few sprints went to interface work, which was clearly necessary. Look across a year and the picture changes: the capability that would have made the product genuinely hard to replace is still sitting in the backlog, and the team can’t point to the decision that put it there. Because there wasn’t one.

That’s the cost worth measuring, and it isn’t measured in engineering hours. It’s measured in the features that never shipped.

What Changes Around the Fifth Integration

The first EHR integration is usually a good experience. It’s novel, the team learns a lot, and shipping it feels like opening up a market. Nobody regrets building the first one.

The second and third are where the pattern starts. Most of the work looks familiar, but not quite familiar enough to reuse, so the team copies the previous approach and adjusts. It’s faster than starting over. It also quietly creates three slightly different versions of the same thing.

By the fifth, the shape of the problem has changed. Customer-specific exceptions have accumulated: a different mapping here, an unusual message format there, a validation rule that exists because one hospital asked for it eighteen months ago and nobody’s certain it can be removed. Changes get slower because the blast radius is unclear. The team starts routing every integration question to whoever built the last one, because they’re the only person who knows how it all fits together.

None of that comes from bad engineering. It comes from solving the same problem five times under deadline pressure, which is exactly what happens when each new customer is treated as a new project.

The teams that avoid this aren’t smarter. They just made one decision earlier: they standardized the pattern before they had five versions of it, rather than after. That decision is much cheaper at integration two than at integration ten.

Not All Integration Work Is Worth Owning

Most build-versus-outsource conversations treat integration as one indivisible thing. It isn’t, and separating the layers makes the decision much clearer.

Transport and connectivity is the plumbing: establishing the connection, moving messages reliably, handling authentication, retrying what fails. There’s nothing proprietary here. Your version of reliable message delivery isn’t better than anyone else’s, and it’s rarely the reason a hospital selects one device over another..

Translation is where most engineering time disappears. Mapping fields, handling format differences across HL7 v2 and FHIR and whatever vendor-specific API sits in front of a given EHR, validating what comes through. It’s genuinely hard work, which is why teams assume it must be strategic. It usually isn’t. It’s hard and repetitive, which is the exact profile of work worth standardizing rather than rebuilding.

Clinical application is different. What your product infers from the data, how it presents information to a clinician, what the algorithm does, how the workflow fits the care setting: that’s the product. That’s what the hospital is actually buying, and it’s where engineering time compounds into competitive advantage.

The layers also explain why “we built our own integration layer” so often stops feeling like a good decision around year two. The investment went almost entirely into layers one and two, where it can’t differentiate anything, while layer three, the part customers evaluate, waited.

A reasonable rule: own the layer your customers can tell the difference in. Standardize the rest.

Where BridgeFast Comes In

BridgeFast exists to take layers one and two off an engineering team’s plate.

Built on Dash Technologies’ HL7 and FHIR implementation work, it handles connector logic, message mapping, validation, and the EHR-specific behavior that consumes most integration timelines. New hospital connections start from patterns that already work rather than a blank editor, which changes both how long a connection takes and how confidently the team can predict it.

That predictability is worth as much as the speed. When every integration is bespoke, timelines are guesses and sales gets vague answers. When connections follow a standard pattern, the team can tell sales what a new hospital takes, and can hold roadmap commitments without reserving capacity for whatever integration work shows up mid-quarter.

If the staffing side of this question is the more pressing one for your team, meaning who does this work and how you hire for it, that’s covered in How Medical Device Companies Can Scale EHR Integrations Without HL7/FHIR Specialists. This piece is about what the work costs over time. The two questions tend to arrive together.

One thing worth being clear about: none of this makes interoperability expertise unnecessary. Layer three still needs people who understand clinical data and how hospitals actually work. What changes is that their time goes to that layer instead of rebuilding the two beneath it.

Why This Gets More Important, Not Less

It would be reasonable to build all of this in-house if interoperability were about to get simpler. Then the investment would shrink over time and eventually stop mattering.

It’s going the other way. AI-assisted clinical features need more data moving in both directions, not less. Connected care models increase the number of systems a device has to speak to. And as the ONC numbers show, the underlying environment isn’t consolidating onto one standard, so the surface area a device company has to cover keeps widening rather than narrowing.

Which means the gap between companies compounds. Teams that standardized their integration layer spend their engineering time on clinical capability. Teams still rebuilding transport and translation for every customer spend theirs on work no customer will ever notice. Give that two or three years and the difference shows up plainly in the product.

Conclusion

Healthcare interoperability isn’t optional, and nobody serious is arguing it should be. But there’s a real difference between needing integrations and needing to build every one of them yourself.

The full cost of a custom integration is discovery, build, validation, documentation, support, and every EHR upgrade after that, repeated per customer, forever. For regulated devices, that includes design evidence that has to stay current. Set against that, the engineering estimate for the build looks like what it is: the smallest line item.

Spend the engineering time on the layer your customers evaluate. Standardize the layers they never see.

Let Your Engineering Team Build What Makes Your Product Different

BridgeFast combines Dash Technologies’ interoperability expertise with a configurable, standards-based HL7/FHIR platform that helps medtech and health tech companies reduce integration complexity, speed up product delivery, and keep engineering focused on innovation.

Talk to a Healthcare Interoperability Expert