Interoperability Debt: The Hidden Liability in Digital Health Acquisitions

← Back to All Insights

Every digital health company integrates with electronic health records, insurance claims systems, lab data feeds, and patient-facing applications. The quality of those integrations—the technical and business debt they accumulate—is one of the most consistently underestimated factors in digital health valuations. Companies that look healthy from a revenue and growth perspective can carry years of integration debt that surfaces as integration costs in an acquirer's first year post-close.

Interoperability debt is structurally different from technical debt. Technical debt slows internal development. Interoperability debt slows partner integration—every new customer takes longer than the last to onboard, and existing customers periodically break in expensive ways.

What Counts as Interoperability Debt

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

Why FHIR Adoption Does Not Eliminate the Debt

FHIR is a standard. Implementation is not. Each EHR vendor's FHIR API exposes different resources, different search parameters, different authentication patterns, and different rate limits. A company that claims FHIR-compliant integration often means "we integrate with the largest three EHRs' particular FHIR implementations"—not that they have a generic FHIR engine. The distinction matters at scale.

Signs of Interoperability Debt in Diligence

Engineering team headcount allocated to "integration" or "partner engineering" growing faster than the customer base; a rising ratio of post-onboarding support tickets per customer; documented exceptions for individual customers ("Customer X has their own data format"); long onboarding timelines for new customers (90+ days for an EHR integration suggests architectural fragility); customer churn correlated with engineering-heavy migration projects.

The 21st Century Cures Act Compliance Layer

Information blocking rules under 21st Century Cures Act add a regulatory dimension to interoperability obligations. Digital health companies that build closed integrations may inadvertently create information blocking liability if they restrict access to required data classes. The rule applies broadly and enforcement has expanded steadily since 2022.

CMS Interoperability Mandates

CMS Payer-to-Payer Data Exchange rules (effective 2027) require certain payers to share clinical data with each other on patient request. Digital health vendors who serve those payers will inherit data-format and exchange-protocol obligations that may not match their current integration pattern. Diligence should examine whether the target has a roadmap for compliance or is treating it as a future-year problem.

Remediation Cost Models

Interoperability debt remediation typically requires 18-30 months and 20-40% of engineering capacity. Companies that build a generic integration layer (a FHIR engine, a normalized clinical data model, a generic claim transformer) reduce per-customer onboarding cost dramatically. Companies that defer this work see their customer acquisition cost rise as they scale—the opposite of healthy SaaS economics.

Interoperability debt is not an exotic concept—it is the digital health equivalent of any acquired company's technical debt, but with regulatory and customer-relationship dimensions traditional technical-debt assessment misses. For acquirers, the cost of remediation often exceeds the headline integration synergy projections. For investors evaluating a Series B or later digital health company, the depth and architecture of the integration layer is a primary signal of unit-economic sustainability.