Interoperability Debt: The Hidden Liability in Digital Health Acquisitions

← Back to All Insights

Every digital health company integrates with something: electronic health records, insurance claims systems, lab data feeds and patient-facing applications. How those integrations were built, and the technical and business debt they carry, is easy to underestimate in a valuation. A company that looks healthy on revenue and growth can carry integration debt that surfaces as cost and delay after an acquisition closes.

Interoperability debt is different from ordinary technical debt. Technical debt slows internal development. Interoperability debt slows partner integration: each new customer can take longer to onboard than the last, and existing integrations break in expensive ways when something changes on the other side.

What Counts as Interoperability Debt

Interoperability debt accumulates whenever an integration is built as a one-off rather than as a reusable pattern. Common forms include custom HL7 v2 mappings for each Epic, Oracle Health (Cerner) or Veradigm (Allscripts) customer; per-payer 837P and 835 claim mappings without a common normalization layer; bespoke FHIR resource extensions that diverge from the US Core profiles; and lab data pipelines that hand-map LOINC codes source by source. Each saves time at the moment of integration and costs time at every later change.

Why FHIR Adoption Does Not Eliminate the Debt

FHIR is a standard; implementations vary. EHR vendors' FHIR APIs can expose different resources, search parameters, authentication patterns and rate limits. A claim of “FHIR-compliant integration” can mean integration with a few large EHRs' particular FHIR implementations rather than a generic FHIR capability, and the difference matters at scale.

Signs of Interoperability Debt in Diligence

Engineering headcount for “integration” or “partner engineering” growing faster than the customer base; a rising number of post-onboarding support tickets per customer; documented exceptions for individual customers (“Customer X has its own data format”); onboarding timelines that lengthen rather than shorten as the company grows; and customer churn that follows engineering-heavy migration projects.

Information Blocking

The 21st Century Cures Act's information blocking rules (45 CFR Part 171) apply to three kinds of actors: health care providers, developers of certified health IT, and health information networks and exchanges. A digital health company is directly covered if it is one of those actors, for example if it develops certified health IT; if it sells to providers, its customers carry the obligation and may expect data access and contract terms that support their compliance. Enforcement is now real: the HHS Office of Inspector General can impose civil money penalties of up to $1 million per violation on certified health IT developers and on networks and exchanges for conduct since September 1, 2023, a separate rule sets disincentives for health care providers, and in September 2025 HHS announced it was stepping up enforcement.

CMS Interoperability Requirements

CMS's Interoperability and Prior Authorization final rule (CMS-0057-F, January 2024) requires impacted payers, including Medicare Advantage organizations, Medicaid and CHIP programs and managed care plans, and qualified health plan issuers on the federally facilitated exchanges, to implement Provider Access, Payer-to-Payer and Prior Authorization APIs by January 1, 2027. Under the payer-to-payer requirement, with the patient's opt-in permission, payers exchange claims and encounter data, USCDI data elements and prior authorization information for dates of service within five years. Vendors serving those payers may inherit data-format and API obligations that do not match their current integration pattern, so diligence should ask whether the target has a compliance roadmap or is treating 2027 as a future problem.

Remediation

Remediation cost depends on the architecture, and there is no reliable rule of thumb. The useful questions are how much engineering capacity integrations consume today, whether a generic integration layer (a FHIR engine, a normalized clinical data model, a common claims transformer) exists or is planned, and whether per-customer onboarding cost is falling or rising as the company scales. A company whose onboarding cost rises with each customer is moving against healthy software economics.

Interoperability debt is the digital health version of any acquired company's technical debt, with regulatory and customer-relationship dimensions that a conventional technical-debt review can miss. For acquirers, remediation cost belongs in the synergy model. For investors in a later-stage digital health company, the depth and architecture of the integration layer is an important signal of whether unit economics will hold as the company scales.