Healthcare Interoperability Standards Explained: FHIR, HL7, X12, and DICOM for Developers and Architects

Part of our complete guide to agentic AI in RCM.

If you're building healthcare software, you'll encounter at least four interoperability standards — FHIR, HL7 v2, X12, and DICOM — and each one exists because it solves a different problem. This guide explains what each standard does, when to use which, how they interact, and what a developer actually needs to implement each one. This is a technical guide for developers and architects, not a regulatory compliance guide.

This guide provides a comprehensive reference to every major healthcare interoperability standard. For each standard, we cover what it does, when to use it, a sample message, and which systems rely on it.

HL7 Version 2 (HL7v2): The Workhorse

HL7v2 is the most widely deployed healthcare messaging standard in the world. First released in 1987, it is used by 95%+ of U.S. hospitals for real-time clinical data exchange. Despite being replaced by FHIR for new applications, HL7v2 will run in production for decades to come.

What It Does

HL7v2 handles event-driven messaging between clinical systems. When a patient is admitted, a lab result is finalized, or a medication is ordered, an HL7v2 message is generated and sent to downstream systems. In FHIR, the lab results carried by ORU messages arrive as Observation resources; see our FHIR Observation resource guide for vitals, labs and LOINC coding.

Key Message Types

Sample HL7v2 ADT Message

MSH|^~\&|ADT|HOSPITAL|INTEGRATION|ENGINE|20260317103000||ADT^A01|MSG00001|P|2.5.1
EVN|A01|20260317103000
PID|1||MRN12345^^^HOSPITAL^MR||DOE^JOHN^A||19800315|M|||123 MAIN ST^^ANYTOWN^CA^90210||555-555-1234
PV1|1|I|ICU^101^A|E|||1234^SMITH^JANE^M^MD|||MED||||1|||1234^SMITH^JANE^M^MD|IP||||||||||||||||||HOSPITAL|||20260317103000
NK1|1|DOE^MARY|SPOUSE|555-555-5678
IN1|1|1|BCBS123|BLUE CROSS|PO BOX 1234^^CHICAGO^IL^60601||555-555-9999|GROUP001

FHIR R4 and R5: The Modern Standard

FHIR (Fast Healthcare Interoperability Resources) is the modern standard for healthcare data exchange. FHIR R4 achieved normative status in 2019, and FHIR R4 is now mandated by ONC for certified health IT in the U.S.

What It Does

FHIR provides a RESTful API framework for accessing and exchanging healthcare data. Unlike HL7v2's message-based approach, FHIR treats clinical data as resources that can be created, read, updated, and searched through standard HTTP methods. Search results come back wrapped in a searchset Bundle, and multi-resource writes use transaction or batch Bundles, all covered in our FHIR Bundle resource guide.

Key FHIR Resources

Sample FHIR Patient Resource

{
  "resourceType": "Patient",
  "id": "patient-john-doe",
  "identifier": [{
    "system": "http://hospital.example.org/mrn",
    "value": "MRN12345"
  }],
  "name": [{
    "family": "Doe",
    "given": ["John", "A"]
  }],
  "gender": "male",
  "birthDate": "1980-03-15",
  "address": [{
    "line": ["123 Main St"],
    "city": "Anytown",
    "state": "CA",
    "postalCode": "90210"
  }],
  "telecom": [{
    "system": "phone",
    "value": "555-555-1234",
    "use": "home"
  }]
}

FHIR R4 vs R5

X12 EDI: Claims and Administrative Transactions

X12 EDI (Electronic Data Interchange) is the mandated standard for healthcare administrative transactions in the U.S. under HIPAA. Every insurance claim, eligibility check, and payment remittance uses X12 formats.

Key Transaction Sets

NCPDP SCRIPT: Prescription Messaging

NCPDP SCRIPT is the standard for electronic prescribing between prescribers, pharmacies, and pharmacy benefit managers. Required by the CMS e-prescribing mandate.

Key Message Types

• NewRx — New prescription from prescriber to pharmacy
• RxRenewalRequest — Pharmacy requests refill authorization
• CancelRx — Prescriber cancels a prescription
• RxChangeRequest — Pharmacy requests a formulary alternative
• RxFill — Pharmacy notifies prescriber that prescription was dispensed
• PDMP Request/Response — Query the Prescription Drug Monitoring Program for controlled substance history

DICOM: Medical Imaging

DICOM (Digital Imaging and Communications in Medicine) is the universal standard for medical imaging. Every CT scan, MRI, X-ray, ultrasound, and PET scan is stored and transmitted as DICOM objects.

Related Reading

For more insights, explore our guides on DICOM and FHIR Medical Imaging Interoperability Guide and FHIR in Modern Healthcare.

You may also find value in EHR Software Development Guide and Building a Healthtech App.

DICOM Architecture

• DICOM objects — Images with embedded metadata (patient info, study details, series information, acquisition parameters)
• PACS (Picture Archiving and Communication System) — Stores and serves DICOM images
• DICOM services — C-STORE (send image), C-FIND (search), C-MOVE (retrieve), C-GET (fetch), WADO-RS (web access)
• DICOMweb — RESTful API for DICOM operations, increasingly used alongside FHIR ImagingStudy resources

IHE Profiles: Integration Blueprints

IHE (Integrating the Healthcare Enterprise) does not create new standards. Instead, it defines integration profiles — blueprints that specify how to use existing standards (HL7v2, FHIR, DICOM) together to solve specific healthcare integration problems. Patient-centric profiles such as PDQm sit on the FHIR Patient resource, so it helps to understand FHIR Patient identifiers and patient search before implementing them.

Key IHE Profiles

Direct Protocol: Secure Health Information Exchange

Direct is a secure email-like protocol for point-to-point health information exchange. It uses S/MIME encryption over SMTP to send clinical documents (typically CDA or PDF) between healthcare organizations.

• Use case — Referral letters, discharge summaries, transition of care documents sent between providers who are not on the same EHR
• Addressing — Direct addresses look like email (provider@direct.hospital.org) but route through Health Information Service Providers (HISPs)
• Trust model — Trust anchors and certificate chains ensure both sender and receiver are verified healthcare entities
• Decline — Direct is being replaced by FHIR-based exchange (TEFCA, Carequality) for most use cases, but remains required for CMS Meaningful Use attestation

Which Standard to Use: A Decision Framework

The Convergence: USCDI and TEFCA

Two federal initiatives are converging on healthcare standards in the U.S.:

• USCDI (United States Core Data for Interoperability) — Defines the minimum data elements that must be exchangeable. USCDI v3 (2025) includes clinical notes, health insurance information, and social determinants. All expressed through FHIR R4 profiles. Those profiles come from US Core, and our USCDI vs US Core version mapping shows which US Core release carries each USCDI version.
• TEFCA (Trusted Exchange Framework and Common Agreement) — Defines the network for exchanging data. TEFCA establishes rules for how health information networks connect and share data. Comparable to India's ABDM in ambition.

Together, USCDI defines what data must be shared and TEFCA defines how it gets shared. Both are built on FHIR R4, accelerating the standard's dominance.

Navigate Healthcare Standards with Nirmitee

At Nirmitee, we implement all major healthcare interoperability standards — from HL7v2 with Mirth Connect to SMART on FHIR applications to HL7v2-to-FHIR translation. Our integration team has deployed hundreds of interfaces across hospitals, health systems, and healthtech platforms.

Contact us to discuss your interoperability strategy.

Struggling with healthcare data exchange? Our Healthcare Interoperability Solutions practice helps organizations connect clinical systems at scale. We also offer specialized Healthcare Software Product Development services. Talk to our team to get started.

For the regulatory side — what these standards mean for TEFCA compliance and information blocking — see: Healthcare Interoperability in 2026: Regulations, TEFCA, and Your 90-Day Action Plan