Interoperability in Health Informatics: A Practical How-To

Who This Is For

Imagine you’re a health informatics lead at a mid-sized clinic. You’ve got an EHR that works, but your lab results come in as PDFs, your patients can’t see their records in your patient portal, and you just got a letter from a health plan asking for claims data in a format you don’t support. You’re not alone. The industry has spent decades layering on standards, but true interoperability—the ability of different systems to exchange and use health information—still feels out of reach.

This guide is for you if you’re responsible for making systems talk to each other, whether you’re a clinician, an IT admin, or a compliance officer. You’ll get a practical, opinionated walkthrough: choose the right standards, secure your data, and avoid the legal landmines. I’m going to tell you what to do first, what to skip, and what can go wrong.

1. Start with the Right Standards, Not the Shiny Ones

You have two main choices for exchanging health data: HL7 Version 2 (v2) and FHIR. HL7 v2 has been around since 1987 and is still used by more than 95% of US healthcare organizations (HL7 International). It’s a workhorse—great for high-volume, legacy workflows like lab orders and results. FHIR, on the other hand, is the modern standard, using RESTful APIs and resources like Patient and Observation, and it’s designed for developers, mobile apps, and cloud-native systems (HL7 International).

My recommendation: don’t rip out v2. It’s not going away. Instead, build a bridge. Use v2 for your internal, high-throughput messaging, and expose FHIR APIs for anything patient-facing or new. That’s what the US Core Implementation Guide is built for—it defines the minimum constraints on FHIR R4 resources to support patient data access (US Core Implementation Guide). If you’re starting fresh, go FHIR, but know that you’ll still need to handle v2 from partners.

2. Map Your Data to Standard Terminologies

Standards alone won’t make your data useful. You need to encode your clinical concepts using standard terminologies. The big three are SNOMED CT for clinical terms, LOINC for lab identifiers, and ICD-10 for diagnoses (HL7 International). SNOMED CT is designated for use in US federal systems, and the National Library of Medicine is the US National Release Center (NLM). LOINC is the international standard for identifying health observations and measurements—it’s stewarded by the Regenstrief Institute and, as of version 2.82, contains over 109,000 concepts (LOINC).

Here’s the thing: you can’t just say “we use SNOMED.” You have to map your local codes to the standard ones, and that’s real work. For example, if your EHR uses a local code for “Type 2 diabetes,” you need to map it to the SNOMED CT concept. If you’re sending lab results, you need LOINC codes for each test. RxNorm is your friend for medications—it provides normalized names and links to drug vocabularies, so you can send a prescription that another system will understand (NLM).

Don’t try to do this manually. Invest in a terminology server and tools that help you map. It’s tedious, but it’s the foundation of interoperability.

3. Secure the Exchange: HIPAA Is Not Optional

You can’t have interoperability without security. The HIPAA Security Rule requires you to protect electronic protected health information (ePHI) with administrative, physical, and technical safeguards (ONC/HHS). That means you need policies, training, facility security, and technical controls like encryption and access controls (ONC/HHS). NIST SP 800-66 Rev. 2, published in February 2024, is the go-to resource for implementing the Security Rule—use it (NIST).

Here’s where many organizations trip up: the Security Rule’s Access Control standard requires you to implement unique user IDs, emergency access procedures, automatic logoff, and encryption/decryption (45 CFR 164.312(a)). Encryption is addressable, not required, but if you don’t encrypt, you’d better have a good reason. And the Breach Notification Rule: if you have a breach of unsecured PHI, you must notify individuals within 60 days of discovery (45 CFR 164.404). That’s a hard deadline.

Penalties are real. The civil monetary penalty cap for 2026 is $2,190,294, and the maximum per violation for willful neglect not corrected is $2,190,294 (Federal Register). Don’t be that organization.

4. Implement the Patient Access API—You Have No Choice

If you’re a Medicare Advantage plan, Medicaid managed care, or a Qualified Health Plan on the Federally-facilitated Exchange, you’re required to implement a Patient Access API using FHIR R4 as of January 1, 2021 (CMS Interoperability and Patient Access Final Rule). That’s not optional. The API must let patients retrieve their data, with a date of service on or after January 1, 2016, via third-party apps of their choice.

But even if you’re not a payer, you should build this. Why? Because the 21st Century Cures Act made sharing electronic health information the expected norm, and information blocking—practices that interfere with access, exchange, or use of EHI—is illegal (ONC/HHS). Providers, health IT developers, and HIEs are all “actors” under the rule. The information blocking applicability date was April 5, 2021, and before October 6, 2022, the definition of EHI was limited to USCDI data elements (ONC/HHS). Now it’s the full EHI. So if you’re blocking patient access, you could face penalties.

5. Plan for the Future: USCDI v3 and TEFCA

Interoperability is moving fast. The ONC HTI-1 final rule made USCDI v3 the baseline data standard for certified health IT as of January 1, 2026 (ONC/HHS). USCDI v3 has 94 data elements in 19 classes, up from 52 in v1 (ONC Standards Bulletin). If you’re building new systems, target USCDI v3 now.

And then there’s TEFCA—the Trusted Exchange Framework and Common Agreement. It’s a network-of-networks that lets you share data across different health information networks. The first QHINs were designated in December 2023, and data is flowing (ONC/HHS). If you’re not part of a QHIN yet, you’ll likely need to be soon, because payers and providers are starting to require it.

What Can Go Wrong: The Hidden Costs

Here’s the warning: interoperability is not a set-and-forget project. You’ll run into version mismatches—your partner uses FHIR R4, you use R5. You’ll encounter terminology gaps—your lab sends LOINC codes for tests you don’t recognize. And you’ll face the “minimum necessary” standard under HIPAA, which means you have to limit data sharing to what’s needed for the purpose (45 CFR 164.502(b)). That can slow you down.

But the biggest risk is doing nothing. The MIPS performance threshold for 2026 is 75 points, and the Promoting Interoperability category is 25% of your score (Federal Register). If you’re not interoperable, you’re leaving money on the table. And with HIPAA penalties climbing, you can’t afford to ignore security.

Sources

• ONC / HHS (Health IT) - https://www.healthit.gov/topic/health-it-basics
• HL7 International - https://www.hl7.org/fhir/
• eCFR 45 CFR Part 164 Subpart C - https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C
• Federal Register (CMS Interoperability and Patient Access Final Rule) - https://www.federalregister.gov/documents/2020/05/01/2020-05050/medicare-and-medicaid-programs-patient-protection-and-affordable-care-act-interoperability-and
• ONC / HHS (HTI-1 Final Rule) - https://healthit.gov/regulations/hti-rules/hti-1-final-rule/
• Federal Register (CY 2026 Physician Fee Schedule) - https://www.federalregister.gov/documents/2025/11/05/2025-19787