Healthcare runs on a patchwork of data standards developed over four decades. A single hospital might use HL7v2 for ADT messages, FHIR R4 for patient portals, X12 EDI for claims, NCPDP SCRIPT for prescriptions, and DICOM for radiology — all simultaneously. Understanding when and how to use each standard is essential for anyone building healthcare software.
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.
Key Message Types
| Message Type | Trigger | Content | Common Use |
|---|---|---|---|
| ADT (Admit/Discharge/Transfer) | A01, A02, A03, A04, A08 | Patient demographics, visit info, bed assignment | Patient registration, census management |
| ORM (Order Message) | O01 | Lab/radiology orders, order details | Order entry to ancillary systems |
| ORU (Observation Result) | R01 | Lab results, vital signs, pathology reports | Result delivery to EHR |
| RDE (Pharmacy Order) | O11 | Medication orders, dosage, route | E-prescribing within hospital |
| MDM (Document Management) | T02 | Clinical document notifications | Transcription, document routing |
| SIU (Scheduling) | S12, S14, S15 | Appointment creation/modification | Scheduling system integration |
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|GROUP001FHIR 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.
Key FHIR Resources
| Resource | Description | HL7v2 Equivalent | Common Operations |
|---|---|---|---|
| Patient | Demographics, identifiers, contacts | PID segment | GET, POST, PUT, SEARCH |
| Encounter | Visit/admission details | PV1 segment | GET, SEARCH, _include |
| Observation | Lab results, vital signs, assessments | OBX segment | GET, SEARCH by category/code |
| Condition | Diagnoses, problem list | DG1 segment | GET, POST, SEARCH |
| MedicationRequest | Prescriptions, medication orders | RXE segment | GET, POST, SEARCH |
| DiagnosticReport | Lab/radiology report packages | ORC/OBR segments | GET, SEARCH, _include Observation |
| DocumentReference | Clinical documents (CDA, PDF) | MDM messages | GET, POST, SEARCH |
| AllergyIntolerance | Patient allergies | AL1 segment | GET, POST, SEARCH |
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
| Feature | FHIR R4 | FHIR R5 |
|---|---|---|
| Status | Normative (production) | Standard for Trial Use |
| Adoption | 95%+ of certified EHRs | Early adopters only |
| Subscriptions | Basic (polling-based) | Topic-based (WebSocket/webhook) |
| New resources | — | SubscriptionTopic, NutritionIntake, Permission |
| Recommendation | Use for all production apps | Wait for broader adoption |
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
| Transaction | Code | Direction | Use Case |
|---|---|---|---|
| Professional Claim | 837P | Provider -> Payer | Physician office visit claims |
| Institutional Claim | 837I | Provider -> Payer | Hospital inpatient/outpatient claims |
| Eligibility Inquiry | 270 | Provider -> Payer | Check patient insurance eligibility |
| Eligibility Response | 271 | Payer -> Provider | Return eligibility and benefit details |
| Claim Status Inquiry | 276 | Provider -> Payer | Check claim processing status |
| Claim Status Response | 277 | Payer -> Provider | Return claim status |
| Payment/Remittance | 835 | Payer -> Provider | Electronic payment advice |
| Prior Authorization | 278 | Provider -> Payer | Request service authorization |
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.
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.
Key IHE Profiles
| Profile | Standards Used | Problem Solved |
|---|---|---|
| PIX/PDQ (Patient Identity) | HL7v2 or FHIR | Patient identity matching across systems |
| XDS.b (Cross-Enterprise Document Sharing) | HL7v2, CDA, SOAP | Document sharing across organizations |
| MHD (Mobile Access to Health Documents) | FHIR | Lightweight document sharing for mobile apps |
| PDQm (Patient Demographics Query for Mobile) | FHIR | Patient search from mobile applications |
| IUA (Internet User Authorization) | OAuth 2.0, SMART on FHIR | Secure authorization for health IT |
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
| Scenario | Recommended Standard | Why |
|---|---|---|
| New patient-facing app | FHIR R4 | RESTful API, JSON format, SMART on FHIR auth, mandated by ONC |
| Connecting to legacy hospital systems | HL7v2 (with FHIR bridge) | 95%+ of hospitals already speak HL7v2. Build a bridge rather than replacing. |
| Submitting insurance claims | X12 837 | Mandated by HIPAA. No alternative for payer transactions. |
| E-prescribing | NCPDP SCRIPT | CMS mandate. Required for pharmacy system integration. |
| Medical imaging | DICOM + DICOMweb | Universal imaging standard. Use DICOMweb for modern access. |
| Cross-organization document exchange | FHIR (via TEFCA/Carequality) | Replacing Direct and XDS.b. Future-proof choice. |
| Real-time clinical events | HL7v2 (existing) or FHIR Subscriptions (new) | HL7v2 for existing interfaces; FHIR R5 Subscriptions for new builds. |
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.
- 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.
