Learn

Interoperability foundations

Healthcare interoperability is the ability of different systems to exchange data and use it with the intended meaning. A working interface needs more than transport: both sides must agree on structure, identifiers, terminology, workflow, and how to handle missing or unexpected data.

HL7 v2

Message types

An HL7 v2 message starts with MSH. MSH-9 usually carries a message type and trigger event (for example ADT^A01). Common families on this site include ADT (patient administration), ORM (orders), ORU (results), and SIU (scheduling).

Trigger events

Triggers describe why a message was produced: admit, discharge, update, register, and similar workflow events. Always read both the type and the trigger; an A08 is not an A01.

Common segments

MSH is the header. PID identifies a patient record in the message. PV1 describes the visit. ORC/OBR/OBX carry orders and observations. NK1 and GT1 appear when next-of-kin or guarantor data is sent. Field numbers are 1-based; MSH numbering is special because MSH-1 is the field separator character itself.

Common data types

Composite values use the component separator from MSH-2. Names, coded values, and identifiers are typically composites. Repeating values use the repetition separator. Empty components still occupy a slot.

Explore messages with the HL7 Message Analyzer.

FHIR

FHIR stands for Fast Healthcare Interoperability Resources. It represents healthcare concepts as reusable resources such as Patient, Encounter, Observation, Medication, and DiagnosticReport. Resources can reference one another and are commonly exchanged as JSON or XML through APIs.

Resources and profiles

A base resource defines a general shape. Profiles add constraints for a particular country, program, or workflow. Implementation guides bring profiles, terminology, examples, and conformance expectations together for a use case.

REST is common, not mandatory

Many FHIR implementations use RESTful read, search, create, and update interactions. FHIR resources can also be exchanged in documents, messages, batches, subscriptions, and other patterns.

CDA, C-CDA, and CCD

Clinical Document Architecture (CDA) defines the structure and meaning of clinical documents exchanged as a complete, persistent record. A CDA document has a header describing its context and participants, plus a body containing human-readable narrative and, when available, structured entries.

How the names relate

• CDA is the underlying HL7 document architecture.
• C-CDA is a US implementation guide that constrains CDA with reusable templates.
• CCD is a Continuity of Care Document and is one document type defined within C-CDA.

Health information exchange (HIE)

HIE is the electronic sharing of health information among authorized participants. It is not one message format or product: an exchange may use HL7 v2, C-CDA, FHIR, Direct messaging, document-query standards, or several approaches together.

Common exchange patterns

Directed exchange sends information to a known recipient. Query-based exchange lets an authorized participant search for available patient information. Consumer-mediated exchange gives patients a role in accessing or directing their information.

Identifiers

An NPI is a 10-digit identifier. Format and checksum can be checked locally. Registry search uses the official CMS NPPES API. An NPI is not proof of current licensure.

NPI Lookup