Why every healthtech acquisition eventually becomes an interoperability project

You didn't buy a product. You bought a dataset, a set of integrations, and a promise that they'll talk to everything you already own.

The term sheet talks about users, revenue, and product. The diligence deck has a roadmap, a churn curve, and a slide on "synergies." Everyone shakes hands, the press release goes out, and for about a week, the acquisition looks like exactly what you paid for.

Three weeks in, someone on your team is staring at a spreadsheet named mapping_v3_FINAL_USE_THIS.xlsx, trying to figure out why patient IDs don't line up between the two systems. The integrations to hospitals, labs, and payers were built by an engineer who left two years ago. Nobody wrote down why half the field mappings exist. The roadmap your board signed off on is now waiting behind a migration nobody priced into the deal.

I've sat in enough of these post-close meetings to say it flat out: in healthtech, every acquisition turns into an interoperability project. The only question is whether you plan for it before close or find out at the next board meeting.

Table of Contents

1. The deal closes. Then the real work begins.
2. What you actually bought: the data and its connections
3. Why healthcare makes this inevitable and worse than other industries
4. The four places interoperability quietly breaks a deal
5. Garbage in, dangerous out: the data pipeline your AI inherits
6. What good looks like: from migration panic to harmonization discipline
7. A pre-acquisition interoperability diligence checklist
8. Treat interoperability as a thesis, not a surprise

The deal closes. Then the real work begins.

It's tempting to think of an acquisition as buying a product but in healthcare that framing is a trap. Interfaces are disposable. The moat is what sits underneath: clinical records, claims and eligibility flows, device telemetry, and the EHR and lab integrations built and certified over years. None of that transfers cleanly.

A user table migrates in an afternoon. A decade of clinical data (encoded against one vendor's assumptions, one team's shortcuts, one era's version of a standard) does not. And here's the part that matters for everything downstream: that same data is what any future AI capability will be built on. The pipeline you inherit carries a migration cost, but that's the smaller number. Every "AI-powered" feature on the roadmap, the one that justified the purchase price, runs on it.

Why healthcare makes this inevitable and worse than other industries

Plenty of industries deal with integration after an acquisition. Healthcare is in a category of its own, for structural reasons that aren't going away.

Start with the standards themselves. We have FHIR for modern APIs, HL7v2 still running the majority of real-world hospital messaging, X12 governing claims and eligibility on the payer side, and C-CDA documents moving clinical summaries around. Most serious health systems run all of these at once. An acquired company almost certainly runs its own version too. What looks like adopting one standard turns into inheriting a portfolio of them.

Then there's the dirty secret of the word "compliant." Two systems can both be genuinely FHIR-compliant and still fail to agree on what a given field means, which code system populates it, or whether a value is required. The standard tells you the envelope; it does not guarantee the letter inside says the same thing. Real interoperability is semantic, not just syntactic, and that's where the work actually lives.

Layer on EHR vendor variability, custom extensions, local code mappings, and undocumented assumptions baked in by the original engineers, and you get the core truth: every system you acquire carries its own private dialect. Post-close, you own the job of reconciling all of those dialects into something coherent. Nobody put that on a slide.

The four places interoperability quietly breaks a deal

When this work gets underestimated, the damage shows up in four predictable places. It's worth holding these in mind before you sign, not after.

Timeline. Integration and harmonization debt pushes synergies out by quarters. The cross-sell, the unified platform, the "one record" story, all of it waits on plumbing that was scoped as an afterthought.

Valuation. Undiscovered data-quality and mapping debt is a real liability, the same way deferred maintenance is on a building. If you didn't price it, you overpaid and you'll fund the difference out of post-close engineering capacity.

Compliance. Every time you move PHI between systems, you expand your HIPAA and security surface area. Migration is precisely the moment when data is most exposed and least governed, and regulators don't grade on a curve for newly acquired entities.

Product velocity. This is the quiet killer. Your best engineers get pulled off features and onto pipes. And the first casualty is almost always the AI roadmap because you can't ship a trustworthy model on top of data you haven't even finished reconciling.

Garbage in, dangerous out: the data pipeline your AI inherits

I want to dwell on that last point, because it's where the stakes have changed the most.

It's now standard for the acquired product (or your combined platform)  to promise something AI-powered: a risk score, a documentation assistant, a triage suggestion, a coding helper. Those features are only as good as the data underneath them, and acquisitions are exactly when that data is at its messiest.

Consider what comes out of a typical EHR. Free-text notes with no structure. Lab values where the units aren't normalized. Fields that one system treats as required and another leaves null.

Local codes that were never mapped to a standard vocabulary. Feed that into a clinical model and you get an AI tool that underperforms  and one that is confidently, invisibly wrong. In healthcare, "wrong" is a safety event.

This is why I keep telling acquirers that interoperability is the unsung hero of clinical AI. Nobody puts the harmonization layer in the pitch deck. But there is no credible AI product without it. The mapping work is what makes a model trustworthy enough to put in front of a clinician. Skip it, and your AI roadmap is built on sand precisely when you've told the board it's the reason for the deal.

Clean, semantically-aligned data carries the AI story on its back. Without it, there's no story to tell.

What good looks like: from migration panic to harmonization discipline

The good news is that this is a solved problem when it's treated as a discipline rather than a fire drill. The teams that handle acquisitions well share a few habits:.

• They run interoperability diligence before signing, not after, treating the data and its integrations as a first-class part of the assessment. 
• They define a canonical data model and a deliberate mapping strategy, so they're harmonizing toward something rather than translating every system into every other system. 
• They know "FHIR-compliant" doesn't mean "correct," so they push past format conversion and insist on semantic alignment.
• And they treat harmonization as an ongoing capability, staffed, owned, and maintained, rather than a one-time port that's declared done and forgotten.

What sets these teams apart: they named the interoperability project early and resourced it on purpose, instead of letting it ambush the roadmap.

A pre-acquisition interoperability diligence checklist

If you take one practical thing from this piece, make it this. Before you sign, get clear answers to these questions:

1. Which standards and versions are actually in use — not on the marketing page, but in production? FHIR, HL7v2, X12, C-CDA, proprietary APIs?
2. How many custom integrations exist, and who maintains them? What happens to that knowledge if the original team leaves?
3. What is the data-quality and field-mapping debt? How much is structured, how much is free text, and how much has never been mapped to a standard vocabulary?
4. Is the data AI-ready? Could you train or deploy a clinical model on it today without a major cleanup, and if not, what's the gap?
5. Where does PHI move, and how is it governed during and after migration? What's the compliance exposure the moment you start combining systems?
6. What's the realistic harmonization timeline and cost , and is it reflected in the valuation and the post-close roadmap?

If the answers are vague, that vagueness is the finding. It's the size of the interoperability project you're about to inherit.

Treat interoperability as a thesis, not a surprise

Every health tech acquisition becomes an interoperability project. Call it physics, not pessimism. An industry built on fragmented standards, private data dialects, and the rising stakes of clinical AI works this way by default. A signed contract doesn't merge two systems. Someone has to do the slow, unglamorous work of making their data mean the same thing.

Winning the next wave of acquisitions comes down to data clean enough to build an AI roadmap on. The teams that get there treated interoperability as part of the deal thesis from day one, instead of meeting it as a surprise in quarter three.

If you're evaluating an acquisition, or already living inside the integration that followed one, the most valuable move you can make is to bring that expertise in early. The plumbing is invisible right up until it's the only thing anyone's talking about.

You don't acquire a product, you acquire its integrations.