Healthcare Data Interoperability: A U.S. Standards Guide
Healthcare Data Interoperability: A U. S.
Healthcare data interoperability means clinical information can be accessed, exchanged, and used across different systems without custom workarounds or manual re-entry. ONC defines it as giving authorized parties timely, secure access to electronic health information so clinicians can deliver safe, patient-centered care. The regulatory framework driving this in the U.S. runs through the 21st Century Cures Act, ONC rulemaking, the Trusted Exchange Framework and Common Agreement (TEFCA), and the United States Core Data for Interoperability (USCDI) standard. If your organization is starting from scratch or re-evaluating an existing approach, the single most effective first move is to adopt a staged, standards-first roadmap that prioritizes FHIR APIs and USCDI-aligned core data elements before anything else.
Where to start:
- Audit your current EHR and device interfaces for standards compliance (FHIR R4, HL7 v2, USCDI coverage)
- Identify your TEFCA participation path: direct QHIN connection or sub-participant via a Health Information Exchange (HIE)
- Require FHIR API support and USCDI data coverage in every new vendor contract
- Engage an engineering partner like Bitrupt early if internal capacity for standards-based integration is limited
Key Takeaways
A staged, standards-first approach to healthcare data interoperability, anchored in FHIR R4, USCDI alignment, and TEFCA participation, is the most reliable path to clinical and operational value without overcommitting resources up front.
Table of Contents
- What does healthcare data interoperability actually mean?
- Who benefits from interoperable health systems, and how?
- What U.S. policy shapes your interoperability obligations?
- Which standards and technologies actually power interoperability?
- What does a solid interoperability architecture look like?
- What are the hardest barriers to overcome?
- How do you build a staged interoperability roadmap?
- How do you measure interoperability success?
- What have U.S. organizations actually accomplished?
- Engineering checklist for FHIR-based integrations
- Authoritative resources to bookmark
- Where organizations go wrong, and what actually works
- Bitrupt builds the interoperability infrastructure your clinical systems need
- Sources
What does healthcare data interoperability actually mean?
Interoperability is not a single capability. It is a spectrum, and most organizations sit somewhere in the middle. ONC and the broader health IT community commonly describe four levels:
- Foundational: Systems can send and receive data. No guarantee the receiving system can interpret it. Think of it as getting a fax you can’t read.
- Structural: Data is formatted consistently (HL7 v2, C-CDA, FHIR resources) so the receiving system knows where each field lives, even if it doesn’t fully understand the meaning.
- Semantic: Systems share a common vocabulary. A lab result coded in LOINC means the same thing in Boston as it does in Phoenix. This is where most organizations struggle.
- Organizational: Governance, policy, legal agreements, and workflows align so that data actually flows when it should. TEFCA is largely an organizational-layer solution.
Types of data exchanged and how they move
The data types in scope for interoperability are broader than most teams initially plan for: clinical notes, lab results, imaging reports, medication lists, immunization records, claims data, public health reporting data, and patient-generated data from wearables and remote monitoring devices. Each category has different standards maturity and different governance requirements.
Exchange happens through four main mechanisms. Directed exchange sends data point-to-point, typically via Direct Secure Messaging. Query-based exchange lets a provider pull records from another organization on demand. API-based exchange uses FHIR RESTful APIs to give applications programmatic access to patient data. Patient-mediated exchange puts the patient in control, allowing them to share or restrict data through apps authorized under the ONC Patient Access Rule.
Statistic: A 2023 HealthIT Data Brief found that hospital participation in interoperable exchange has grown across multiple domains, yet gaps remain specifically in API adoption and standardized semantic exchange, the two layers that deliver the most clinical value.
Who benefits from interoperable health systems, and how?
The business case for interoperability is strongest when you can point to concrete, measurable outcomes. Here are the use cases that consistently deliver value.
Clinical and care coordination
When a patient moves from an emergency department to a skilled nursing facility, a complete medication list and discharge summary that arrives automatically prevents adverse drug events and readmissions. Medication reconciliation at transitions of care is one of the highest-ROI use cases for clinical data exchange. Real-time clinical decision support, such as allergy alerts or duplicate-order warnings, depends on semantic interoperability: the system must understand what the incoming data means, not just receive it.
Operational and financial value
Duplicate laboratory and imaging orders are a direct cost of poor interoperability. When a referring physician’s system can query prior results, the ordering clinician can make a more informed decision before ordering a repeat test. For value-based care contracts, payers and providers both need longitudinal patient data to calculate quality metrics accurately. Administrative workflows, including prior authorization and eligibility verification, also benefit from structured, machine-readable data exchange.
Public health and research
The COVID-19 pandemic exposed how fragile manual public health reporting was. States and federal agencies that had invested in electronic case reporting and immunization information systems were faster to identify outbreak clusters and allocate resources. The same infrastructure supports cancer registries, syndromic surveillance, and population health analytics. For research, AI tools in clinical settings increasingly depend on structured, interoperable data as their input layer.
Statistic: Federal data briefs confirm that hospital engagement in interoperable exchange has increased across treatment, payment, and public health domains, though semantic and API-based exchange still lags behind basic document sharing.
What U.S. policy shapes your interoperability obligations?
The regulatory landscape is not optional background reading. It directly determines what your vendors must support, what you can be penalized for, and what your patients have a legal right to access.
Key legal and policy anchors
- 21st Century Cures Act (2016): Required ONC to develop TEFCA, prohibited information blocking, and mandated patient access to electronic health information without special effort or cost.
- ONC Interoperability and Patient Access Final Rule (2020): Required certified EHRs to support FHIR R4 APIs for patient and provider access, aligned with USCDI v1 as the minimum data set.
- Information Blocking Rule: Providers, health IT developers, and HIEs face penalties for practices that unreasonably interfere with access, exchange, or use of electronic health information. The Health IT Playbook outlines what constitutes a violation and available exceptions.
- TEFCA Common Agreement: Establishes governance, privacy, and security baselines for nationwide exchange through Qualified Health Information Networks (QHINs). As of 2024, ONC has designated multiple QHINs, including eHealth Exchange, CommonWell, Carequality, KONZA, and others, marking a significant milestone in national network infrastructure.
- USCDI: The standard set of data classes and elements required for certified health IT. Versions are updated through a public process; draft USCDI v7 materials are currently under development.
- Interoperability Standards Advisory (ISA): ONC’s annual reference that maps recommended standards to specific interoperability needs, from imaging to EMS to functional status.
Pro Tip: Before signing any EHR or integration vendor contract, require written confirmation of which USCDI version the product supports, whether it has passed ONC certification for FHIR APIs, and whether it participates in or connects to a TEFCA QHIN. These three questions eliminate most compliance surprises.
Compliance checklist for your legal and GRC teams
Which standards and technologies actually power interoperability?
Standards are the grammar of health data exchange. Without shared grammar, two systems can connect but still not communicate.
Core standards and when to use them
The Interoperability Standards Advisory maps these standards to specific clinical domains, so you can identify which combination applies to your use case rather than guessing.
Security and privacy for API-based exchange
FHIR APIs introduce security requirements that document-based exchange did not. OAuth 2.0 and OpenID Connect are the authentication and authorization protocols required by ONC for SMART on FHIR applications. Every API call should carry a scoped access token, and the server must enforce those scopes at the resource level. Audit trails must capture who accessed what data, when, and from which application. Cloud security controls for FHIR server deployments, including encryption at rest and in transit, network segmentation, and access logging, are not optional additions; they are baseline requirements for HIPAA compliance and TEFCA participation.
Pro Tip: Implement SMART on FHIR scopes at the resource and operation level from day one. Retrofitting fine-grained authorization onto a FHIR server after launch is significantly more expensive than building it in during initial development.
What does a solid interoperability architecture look like?
Think of interoperability architecture the way you’d think about plumbing in a hospital building. The pipes, valves, and pressure regulators all have to work together before water flows reliably to every room. The components below are your pipes and valves.
Core architectural components
- Patient identity resolution: A Master Patient Index (MPI) or probabilistic matching service that links records for the same patient across systems. Without this, you are exchanging data about the wrong person.
- Authentication and authorization: OAuth 2.0 / SMART on FHIR for API access; role-based access control for internal systems; federation for cross-organization identity.
- Consent management: A consent engine that tracks patient preferences, enforces them at the data layer, and logs consent decisions for audit purposes.
- Terminology services: A hosted value set authority (VSAC, NLM’s FHIR terminology server) that translates between local codes and standard terminologies like LOINC and SNOMED CT.
- FHIR server or registry: The data layer that exposes patient data as FHIR resources. Can be a native FHIR store or a facade over a legacy database.
- Audit and logging: Immutable logs of every data access event, queryable for compliance reporting and incident response.
How TEFCA and QHINs fit in
TEFCA creates a network-of-networks model. Instead of building point-to-point connections with every trading partner, your organization connects to a QHIN, and the QHIN handles routing to other QHINs and their participants. This dramatically reduces the number of bilateral agreements and technical integrations you need to maintain. Sub-participants connect through an existing QHIN participant, which lowers the barrier for smaller organizations. The QHIN Technical Framework (QTF) specifies the transport, identity, and performance requirements each QHIN must meet.
Pro Tip: Test your patient identity resolution logic against synthetic datasets that include common real-world noise: name variations, date-of-birth typos, address changes, and merged records. Identity mismatches at scale are the leading cause of data quality failures in production HIE environments.
What are the hardest barriers to overcome?
Interoperability projects fail more often from organizational and procurement mistakes than from purely technical ones. Knowing the failure modes in advance is half the battle.
Technical and semantic barriers
Legacy EHRs often use proprietary data models and HL7 v2 interfaces that require custom translation layers. Medical devices are worse: many use manufacturer-specific protocols that have no standard mapping to FHIR resources. Device integration costs have been estimated at $6,500–$10,000 per bed in one-time costs, plus up to 15% annual maintenance, according to prior analyses. Semantic gaps are subtler but equally damaging. Two systems may both claim LOINC support but use different local codes internally, requiring a terminology mapping service to reconcile them.
Organizational and governance barriers
Misaligned incentives are common. A department that benefits from data access is rarely the one that bears the cost of building the integration. Procurement processes that do not require standards compliance create vendor lock-in that costs multiples of the original contract to unwind. Data stewardship gaps, where no one owns data quality, consent records, or terminology mappings, cause silent failures that only surface when a clinician acts on bad data.
This is the hidden cost that most procurement teams miss. Requiring a vendor to demonstrate a working reference implementation, not just claim standards support, is one of the most effective risk-reduction moves available to a buyer. Standards-first procurement materially reduces long-term total cost of ownership, particularly for organizations operating at thin margins.
How do you build a staged interoperability roadmap?
There is no single roadmap that works for every organization. McKinsey’s health systems analysis is explicit on this point: a one-size-fits-all approach fails in practice. What works is a staged progression that matches investment to readiness.
Staged implementation plan
- Stage 0: Foundations. Establish a Master Patient Index, deploy a provider and facility registry, and document your current interface inventory. Identify which systems hold which data classes and whether they use standard formats.
- Stage A: Connectivity. Stand up a FHIR server or facade, connect to your state HIE or a TEFCA QHIN sub-participant, and implement directed exchange via Direct Secure Messaging for transitions of care.
- Stage B: API adoption. Implement SMART on FHIR patient-facing APIs to meet ONC Patient Access Rule requirements. Enable provider-facing query APIs for care coordination. Begin USCDI data element coverage audits.
- Stage C: Semantic quality. Deploy a terminology service. Map local codes to LOINC, SNOMED CT, and USCDI value sets. Implement automated data quality checks and conformance testing against FHIR profiles.
- Stage D: Real-time clinical use. Integrate CDS Hooks for decision support at the point of care. Enable real-time medication reconciliation, allergy checking, and patient-generated data ingestion from remote monitoring devices.
Procurement language to require in RFPs
- Mandatory FHIR R4 API support with ONC certification documentation
- USCDI version coverage (specify minimum version and upgrade path)
- A working test harness and sandbox environment for integration testing
- Documented QHIN or TEFCA sub-participant status or a clear roadmap to achieve it
- Reference implementation availability for all claimed standards
Timeline and cost drivers vary significantly by stage. Stages 0 and A typically take 3–9 months and are dominated by governance setup and legacy interface documentation. Stages B and C add API development and terminology service costs. Stage D introduces clinical workflow change management, which is often the longest and most expensive phase.
How do you measure interoperability success?
You cannot manage what you do not measure. The KPIs below give you a starting point for a business case and ongoing program governance.
Cost drivers to include in your business case: FHIR server licensing or hosting, terminology service subscription (NLM’s free VSAC is an option), MPI software or cloud service, QHIN participation fees, and engineering time for interface development and ongoing maintenance. Device integration, as noted above, carries its own per-bed cost line that should be budgeted separately.
What have U.S. organizations actually accomplished?
Progress is real, but uneven. These milestones and examples illustrate where the field stands.
TEFCA QHIN milestones
- ONC designated the first QHINs in late 2023, including eHealth Exchange, CommonWell Health Alliance, Carequality, KONZA National Network, MedAllies, and Kno2. This marked the first time a national network-of-networks governance structure was operational in the U.S.
- Early QHIN data flows demonstrated treatment-purpose queries across previously siloed networks, a capability that previously required bilateral agreements between each network.
- The TEFCA Common Agreement continues to evolve; ONC has signaled expansion of exchange purposes and technical requirements in subsequent versions.
HIE and state-level examples
- Indiana Health Information Exchange (IHIE): One of the longest-running HIEs in the U.S., IHIE demonstrated that query-based exchange at scale reduces duplicate testing and improves care coordination, particularly for patients who frequently use emergency departments.
- CommonWell and Carequality linkage: The decision by these two major networks to link their participant bases created one of the largest interoperable patient record exchange networks in the country, covering a significant portion of U.S. hospital beds.
- Electronic case reporting during COVID-19: States with mature electronic case reporting infrastructure were able to report confirmed cases to CDC within hours rather than days, demonstrating the public health value of semantic interoperability at the foundational level.
Engineering checklist for FHIR-based integrations
If you are building or procuring a FHIR integration, this checklist covers the decisions that most commonly cause rework.
Developer implementation checklist
- Choose a FHIR server that supports R4 natively (HAPI FHIR, Azure Health Data Services, Google Cloud Healthcare API, AWS HealthLake). Evaluate conformance statement coverage before committing.
- Define supported resources and profiles. Map your use case to specific FHIR resources (Patient, Observation, MedicationRequest, Condition, DiagnosticReport) and identify which US Core profiles apply.
- Set a versioning strategy. Decide how you will handle FHIR version upgrades and profile changes without breaking existing integrations. Semantic versioning of your API surface is the minimum.
- Bind terminology. Map every coded element to LOINC, SNOMED CT, or RxNorm as required by the relevant US Core profile. Use the NLM FHIR terminology server or VSAC for value set resolution.
- Implement a test harness. Use the Inferno testing tool (ONC’s official FHIR certification test suite) and the HL7 FHIR validator for conformance testing. Run tests against synthetic data before connecting to production.
- Automate conformance testing in CI/CD. Every pull request should run FHIR validation and US Core profile checks automatically. Catching a terminology binding error in CI is orders of magnitude cheaper than catching it in a live patient encounter.
- Implement SMART on FHIR. Configure OAuth 2.0 scopes at the resource and operation level. Test launch sequences for both standalone and EHR-launch contexts.
- Plan for partial and noisy data. Real-world FHIR resources often arrive with missing required fields, incorrect codes, or duplicate entries. Build validation and normalization layers before data reaches clinical workflows.
Recommended tools and environments
- Inferno: ONC’s official test suite for FHIR certification and US Core conformance
- HAPI FHIR: Open-source Java FHIR server widely used for development and testing
- Synthea: Synthetic patient data generator for realistic integration testing without PHI
- SMART App Launcher: Reference implementation for testing SMART on FHIR launch sequences
- NLM FHIR Terminology Server: Free, hosted value set resolution for LOINC, SNOMED CT, and RxNorm
For practical implementation patterns, Bitrupt’s FHIR API integration playbook covers common integration architectures and the engineering decisions that most frequently cause delays.
Pro Tip: Run your FHIR server’s conformance statement through the Inferno test suite before you write a single line of integration code. Discovering that your server does not support a required search parameter after you have built a query layer around it is an expensive lesson.
Authoritative resources to bookmark
- ONC Interoperability Hub: The central policy and program page for U.S. health IT interoperability, including TEFCA, USCDI, and certification program links.
- TEFCA Common Agreement and QHIN information: Primary source for governance documents, QHIN designations, and the QHIN Technical Framework.
- USCDI documentation on the ISP: Current and draft USCDI versions, data class definitions, and the ONDEC submission process for new data elements.
- ISA Reference Edition (2024): ONC’s annual catalog of recommended standards by clinical domain, useful for procurement and architecture decisions.
- Sequoia Project: The recognized coordinating entity for TEFCA; publishes QHIN Technical Framework updates and implementation guidance.
- HL7 International: Source for FHIR specifications, US Core implementation guide, and CDA standards.
- Health IT Playbook: Practical guidance on HIE participation, information blocking, and API adoption.
- NCBI: Procuring Interoperability: Academic review of procurement strategies and cost estimates for standards-based integration.
Where organizations go wrong, and what actually works
Most organizations that struggle with interoperability share a common pattern: they start with the technology and work backward to governance. The sequence should be reversed. Before you evaluate FHIR servers or QHIN participation options, you need to know who owns patient identity in your organization, who is accountable for data quality, and what your legal team’s position is on information blocking exceptions.
The second most common mistake is treating interoperability as a one-time project rather than an ongoing program. Standards evolve. USCDI versions change. TEFCA adds exchange purposes. A system that is compliant today may need updates within 18 months. Organizations that build for maintainability, with automated conformance testing, modular terminology services, and documented interface inventories, spend far less on remediation than those that treat each integration as a bespoke build.
Bitrupt’s healthcare engineering practice works with clinical organizations on exactly this pattern: staged delivery, senior-engineer staffing on every integration, and test-driven development from the first sprint. When the question is whether to build internally or engage an external partner, the honest answer depends on whether your internal team has FHIR profile expertise and TEFCA governance experience. If either is missing, the cost of building that expertise from scratch typically exceeds the cost of a well-scoped external engagement.
Bitrupt builds the interoperability infrastructure your clinical systems need
Healthcare organizations that need to connect EHRs, devices, HIEs, and patient-facing apps to a standards-compliant data layer face a specific engineering challenge: the work requires FHIR expertise, USCDI knowledge, and HIPAA-grade security practices, all at the same time. That combination is rare in a single internal team.
Bitrupt’s clinical-grade engineering services are built for exactly this. Every engagement is staffed with senior engineers who have hands-on FHIR R4 implementation experience, not mid-level generalists learning on your project timeline. Bitrupt delivers end-to-end: FHIR server setup, US Core profile conformance, SMART on FHIR authorization, terminology service integration, and TEFCA/QHIN connectivity planning. Flexible engagement models, including development pods and staff augmentation, mean you can scale the team to match your roadmap stage without a long-term staffing commitment.
If your organization is at Stage 0 or A and needs to move fast, the right next step is a scoped technical assessment. Contact Bitrupt’s enterprise integration team to scope your FHIR readiness and get a staged delivery plan within 24 hours.
Sources
- Interoperability - ONC - Office of the National Coordinator for Health Information Technology
- TEFCA - ONC - Office of the National Coordinator for Health Information Technology
- United States Core Data for Interoperability (USCDI) | Interoperability Standards Platform (ISP)
- Procuring Interoperability: Achieving High-Quality, Connected, and Person-Centered Care - NCBI Bookshelf
