Interoperability in Health Informatics: A Practitioner's How-To

Ninety-six percent of U.S. non-federal acute care hospitals had adopted certified health IT by 2021 (ONC / HHS (Report to Congress)). That's the good news. The bad news? Adoption doesn't equal interoperability. We've built a nationwide network of digital silos. As a working practitioner, I've spent years wrestling with HL7 v2 interfaces, FHIR APIs, and the occasional fax machine. This is how we actually make interoperability happen.

This guide is for the health informaticists, integration engineers, and clinical IT leads who are tired of point-to-point interfaces and want to build something that scales. We're going to walk through a practical, step-by-step approach to achieving real interoperability, grounded in what's actually working in the field today.

Who This Is For

If you're responsible for connecting systems in a hospital, clinic, or health information exchange, this is for you. We're not talking about theoretical standards; we're talking about the messy, real-world work of getting EHRs, labs, imaging, and registries to talk to each other. You likely already know the pain: HL7 v2 is ubiquitous but arcane, and FHIR promises a better way but has its own learning curve. We'll cut through the noise.

Step 1: Inventory Your Data and Standards

Before you can interoperate, you need to know what you have. Start by cataloging every system that touches patient data: EHR, lab, radiology, pharmacy, billing. For each, note what standards it supports. HL7 v2 is still the workhorse, used by more than 95% of US healthcare organizations (HL7 International), but you'll also encounter CDA documents, DICOM for imaging, and increasingly, FHIR. Don't forget terminology: SNOMED CT for clinical terms, LOINC for lab codes, and RxNorm for drugs. These aren't optional; they're the vocabulary that makes data meaningful.

Create a matrix: system, data type, standard, version, and terminologies. This will be your roadmap. You'll likely find that your lab system speaks HL7 v2.4, your EHR has a FHIR R4 endpoint, and your imaging system speaks DICOM. That's normal. The goal is to bridge them.

Step 2: Choose Your Interoperability Strategy

Now, decide how you'll exchange data. You have two main options: point-to-point interfaces or a common framework. Point-to-point is how we've done it for decades, but it's brittle and doesn't scale. A better approach is to adopt a common standard, and FHIR is the future. HL7's FHIR uses RESTful APIs and discrete resources like Patient, Encounter, and Observation (HL7 International). It's developer-friendly and designed for the modern web. However, FHIR isn't a silver bullet. HL7 v2 remains the standard for high-throughput legacy workflows (HL7 International). So, you'll likely need both.

Here's a comparison to help you decide:

For new interfaces, I recommend FHIR. For existing high-volume transactions like ADT feeds, keep HL7 v2. Build a bridge if needed. And don't forget the US Core Implementation Guide, which defines the minimum constraints for FHIR resources in the US (US Core Implementation Guide). It's your practical starting point.

Step 3: Implement with USCDI in Mind

The US Core Data for Interoperability (USCDI) is your data dictionary. Version 3, released in 2022, expanded to 94 data elements in 19 classes, up from 52 elements in 16 classes in v1 (ONC Standards Bulletin 2022-2). As of January 1, 2026, USCDI v3 becomes the baseline data standard in the ONC Health IT Certification Program (ONC / HHS (HTI-1 Final Rule)). That means your certified EHR must support it. So, when you're mapping your data, align with USCDI v3. It's not just about compliance; it's about ensuring you're capturing the data that matters for patient care and exchange.

For example, when you design your FHIR API, make sure your Patient resource includes all the USCDI v3 elements: demographics, smoking status, and so on. This will save you headaches later.

Step 4: Secure Your Data and Stay HIPAA-Compliant

Interoperability without security is a breach waiting to happen. The HIPAA Security Rule requires administrative, physical, and technical safeguards (ONC / HHS (Health IT)). Technical safeguards include access control, audit controls, integrity, and person or entity authentication (45 CFR 164.312). You need unique user IDs, automatic logoff, and encryption, which is addressable (45 CFR 164.312(a)). Don't skimp here. The penalties are real: for 2026, the annual cap is $2,190,294, and a single violation can cost up to $73,011 for lower tiers (Federal Register (2026 HIPAA CMP Adjustment)).

What can go wrong? You implement a FHIR API without proper authentication, and a third-party app exposes patient data. That's an information blocking complaint and a HIPAA violation. The ONC's information blocking rule makes it illegal to interfere with the access, exchange, or use of electronic health information (ONC / HHS (Information Blocking)). So, you must balance openness with security. Use OAuth 2.0, require signed certificates, and log everything.

Step 5: Test, Monitor, and Iterate

Once your interfaces are live, don't walk away. Set up monitoring for API latency, error rates, and data quality. Use synthetic patients to test end-to-end flows. And remember, interoperability is an ongoing process. Standards evolve: FHIR R5 was published in 2023 with 157 resources (HL7 FHIR (Resource Index)), and LOINC is updated regularly (version 2.82 has 109,325 concepts) (LOINC). Plan for upgrades.

Also, consider joining TEFCA, the national framework for health information sharing. It's a network-of-networks that enables exchange across health information networks (ONC / HHS (TEFCA)). If you're a large organization, becoming a QHIN might be overkill, but participating through a QHIN can simplify exchange with partners.

What Can Go Wrong

Here's a real scenario: You build a FHIR API to share lab results. You forget to include the LOINC codes for the lab tests. The data comes through, but it's just a text string. The receiving system can't interpret it, so it's useless. That's interoperability failure. Always include standardized terminology. Another pitfall: you think HL7 v2 is dead, so you don't invest in it. But your legacy systems still rely on it, and you've created a gap. Keep both.

Bottom Line

The single best move is to adopt FHIR for new interfaces, align with USCDI v3, and maintain HL7 v2 for legacy workflows. That's the pragmatic path to interoperability.

Sources

• ONC / HHS (Report to Congress) - https://healthit.gov/news/onc-outlines-health-it-interoperability-progress-report-congress/
• HL7 International - https://www.hl7.org/fhir/
• ONC Standards Bulletin 2022-2 - https://healthit.gov/standards-onc-technology/onc-standards-bulletin/onc-standards-bulletin-2022-2/
• ONC / HHS (HTI-1 Final Rule) - https://healthit.gov/regulations/hti-rules/hti-1-final-rule/
• Federal Register (2026 HIPAA CMP Adjustment) - https://www.federalregister.gov/documents/2026/01/28/2026-01688/annual-civil-monetary-penalties-inflation-adjustment
• LOINC - https://loinc.org/