HIPAA compliance is a legal floor, not an architecture. Real interoperability requires engineering decisions that a compliance checklist never surfaces.
Almost every healthcare technology leader we speak with describes their organization as "HIPAA compliant," and almost none of them describe their systems as genuinely interoperable. This is not a contradiction — it is the predictable result of treating HIPAA as the finish line rather than the starting point. HIPAA's Security and Privacy Rules set a legal floor for how protected health information must be safeguarded. They say very little about whether a cardiology practice's system can actually exchange a structured, computable patient record with the hospital across town, or whether a referral from a primary care physician arrives as usable data rather than a scanned PDF that a staff member has to re-key by hand.
We work with providers across our healthcare industry practice who have passed every compliance audit on paper and still cannot move a patient's medication list electronically between two systems that are, in principle, both certified EHR technology. Closing that gap requires architecture decisions that go well beyond what any compliance checklist asks for.
HIPAA's technical safeguards — access controls, audit controls, integrity controls, and transmission security — are necessary conditions for handling health data responsibly, but they are silent on data structure, terminology standardization, and API design. Two systems can each independently satisfy every HIPAA technical safeguard and still be completely unable to exchange meaningful clinical data, because compliance says nothing about whether both systems represent a diagnosis using the same coding system, structure a medication order the same way, or expose an API at all.
Real interoperability is a deliberate design choice layered on top of compliance, built around three concrete commitments: adopting HL7 FHIR as the standard for structured clinical data exchange rather than proprietary formats, adopting standard terminologies such as SNOMED CT, LOINC, and RxNorm so that a diagnosis or lab result means the same thing to every system that receives it, and exposing that data through documented, versioned APIs rather than one-off point-to-point integrations that break every time a source system is upgraded. None of this is mandated by HIPAA directly, though U.S. regulations under the 21st Century Cures Act now push in this direction through information-blocking rules that penalize organizations for making data artificially hard to exchange.
The part of interoperability that gets underestimated is that when data moves between organizations, the governance obligations attached to it have to move with it. A patient's consent preferences, the minimum-necessary access principle, and the audit trail of who has touched a given record cannot stop at the boundary of the system that originated the data. If Hospital A shares a patient record with Clinic B through a health information exchange, Clinic B inherits the obligation to enforce the same access discipline on that data that Hospital A was required to apply, and both organizations need an audit trail that can reconstruct the full chain of access across the exchange, not just within their own walls.
This is where a lot of interoperability initiatives quietly fail security review: the clinical data flows correctly, but the consent and access-control metadata that should travel alongside it gets dropped somewhere in the integration layer, because the integration was built to move records, not to move the governance context those records carry. Building this correctly typically means investing in a proper API gateway and consent management layer as core infrastructure, not a downstream nice-to-have, before opening exchange with any new external partner. This is precisely the discipline our platform integration engagements are built around — treating consent and access metadata as first-class data that moves with every clinical record, not an afterthought bolted onto the pipe.
Healthcare IT leaders sometimes plan interoperability as a project with an endpoint — get every system onto FHIR, declare victory, move on. In practice, the ecosystem a provider organization exchanges data with is permanently heterogeneous: some partners will be on modern FHIR-native platforms, others will still be running HL7v2 interfaces from systems installed a decade ago, and referral partners will range from large hospital systems with dedicated integration teams to small independent practices with no IT staff at all. An interoperability architecture that assumes everyone will eventually catch up to the same standard is planning for a future that will not arrive on any predictable timeline.
The more durable approach is to build an integration engine or interoperability platform designed explicitly to translate between standards — ingesting HL7v2, CDA, and FHIR alike, and normalizing all of it into a single internal canonical model that the rest of the organization's systems and analytics can rely on. This shields internal systems from the version and standard a given external partner happens to support, and it means each new partner integration is a mapping exercise against a stable internal model rather than a bespoke point-to-point build. Combined with strong governance and standards-based data exchange, this is what turns interoperability from a perpetual integration burden into durable infrastructure.
HIPAA-ready architecture and interoperable architecture are related but distinct achievements, and conflating them is why so many technically compliant healthcare organizations still struggle to move data where it needs to go. The organizations that get this right treat compliance as the non-negotiable floor and interoperability as the deliberate architecture built on top of it — standardized data, governance that travels with the data, and infrastructure designed for permanent heterogeneity.