CPIA Module 3, Section 1: HL7 v2, FHIR and CDA Essentials
MODULE 3: STANDARDS & INTEROPERABILITY

Section 3.1: HL7 v2, FHIR, and CDA Essentials

The Foundational “Languages” of Health Data Exchange.

SECTION 3.1

HL7 v2, FHIR, and CDA Essentials

Deconstructing the grammar and syntax of healthcare’s most important communication standards.

3.1.1 The “Why”: Deconstructing the Digital Prescription

Before we dive into the technical details of any standard, we must first agree on the fundamental problem they are all trying to solve. Consider the most basic unit of your professional life: the prescription. What is it, really? A prescription is not a piece of paper or a fax; it is a structured, unambiguous set of data points required to safely and effectively dispense a medication. Whether it arrives scrawled on a notepad, transmitted electronically, or dictated over the phone, every valid prescription contains the same core components:

  • A unique patient identifier (Who is this for?)
  • A unique prescriber identifier (Who wrote this?)
  • A specific medication (What is the drug?)
  • A dose, route, and frequency (How should it be taken?)
  • A date of issuance (When was this written?)
  • A quantity and number of refills (How much and for how long?)

In your daily work, you are a master at extracting this structured data from a variety of unstructured or semi-structured “containers”—the fax, the phone call, the patient’s verbal request. The world of health informatics is dedicated to solving this same problem, but for computer systems. The central challenge of interoperability is this: How can one computer system (like an EHR) package these core data points into a container that another, completely different computer system (like a Pharmacy Management System) can receive, open, and understand perfectly every time, without any human intervention?

This is where standards come in. Imagine a world without them. Epic, Cerner, Meditech, and every other vendor would create their own proprietary “language” for a prescription. The “Patient Name” field in one system might be called pt_name, while in another it’s PatientFullName. One might send the dose and units in a single field like 5mg, while another uses two separate fields, dose_value: 5 and dose_unit: mg. Connecting these two systems would require a custom-built, expensive, and brittle translator. Now imagine doing that for hundreds of different data types (labs, allergies, problems) across thousands of hospitals. The system would collapse under its own complexity. This was the reality of early healthcare IT.

Health Level Seven (HL7), the organization, was created to solve this “digital dialect” problem by creating a shared language—a lingua franca—for health data. The standards they produce (HL7 v2, CDA, FHIR) are essentially detailed grammar and vocabulary guides. They provide a universally agreed-upon way to structure and transmit health information so that any system that “speaks the language” can understand the data. As an informatics pharmacist, you must become fluent in these languages. You won’t just be verifying the clinical content of a prescription; you’ll be troubleshooting why the digital container it arrived in was corrupted, incomplete, or sent to the wrong destination.

Retail Pharmacist Analogy: The Evolution of the Prescription “Container”

Think of the three standards we are about to discuss not as abstract technical concepts, but as different types of prescription forms, each designed in a different era with different technology in mind.

1. HL7 v2: The Highly Structured, Cryptic Fax Form

Imagine a government-mandated, multi-part carbon copy form for all prescriptions. There are no clear labels like “Patient Name” or “Drug.” Instead, there are only numbered boxes. You and every other pharmacist in the country have a master key that says “Box 5.1 is the Patient’s Last Name,” “Box 5.2 is the First Name,” “Box 27.2 is the Drug Name,” and so on.

This is HL7 version 2. It’s not designed to be read by a human. It’s a dense, character-based format that uses delimiters like pipes `|` and carets `^` to separate the “boxes.” It’s incredibly efficient for computers that have the “master key” to parse, and because it’s been around since the 1980s, virtually every system in the hospital knows how to use it. However, it’s very rigid. If you suddenly needed to add a new box for “Patient’s Preferred Language,” you’d have to get the entire government to agree on a new form version, which is a massive undertaking.

2. CDA: The Comprehensive, Narrated Patient Chart

Now imagine a patient is being discharged from a hospital and they hand you a complete, multi-page, neatly typed summary of their entire stay. It has a cover page with their demographics, and then clearly labeled sections: “History of Present Illness,” “Hospital Course,” “Allergies,” “Problem List,” and “Discharge Medications.”

This is a Clinical Document Architecture (CDA) document, specifically its most common form, the Continuity of Care Document (CCD). It’s a complete, self-contained story of a clinical encounter. As a human, you can read it from top to bottom and get a fantastic clinical picture. You can find the medication list under its proper heading. However, it’s not designed for quick, transactional data retrieval. If your computer system needs to automatically know the patient’s current dose of lisinopril, it can’t just look in “Box 27.4.” It has to receive the entire document, parse through the narrative, find the “Medications” section, and then extract the data. It tells a story, but it’s not a quick command.

3. FHIR: The Modern Smartphone App

Finally, imagine a modern mobile app connected directly to the clinic’s EHR. You don’t get a fax or a long document. You just tap buttons on your screen. You tap “Patient Demographics” and just the patient’s name, DOB, and address appear. You tap “Active Medications” and a clean list of only their current meds appears. You need to see their last A1c? You tap “Lab Results” and query for that specific test.

This is Fast Healthcare Interoperability Resources (FHIR). It’s not about sending messages or documents. It’s about data as a service. It breaks healthcare information down into small, logical “Resources” (a Patient is a resource, a Medication is a resource, an Observation is a resource). Using modern web technologies (APIs), a system can ask for exactly the resource it needs, and only that resource. It’s fast, flexible, and designed for the internet and mobile era. It is the future of health data exchange.

3.1.2 The Workhorse: A Deep Dive into HL7 v2

Despite being decades old, HL7 version 2 (commonly written as HL7v2) is the single most widely implemented healthcare messaging standard in the world. It is the invisible engine running in the background of almost every hospital. When a patient is admitted in the registration system (ADT), when a lab result is sent from the LIS to the EHR, and when a medication order is sent from the CPOE to the pharmacy system, it is almost certainly happening via an HL7v2 message. Understanding its structure is not optional for an informatics pharmacist; it is a core competency.

HL7v2 was created in the late 1980s, a time of mainframe computers and serial port connections. It was designed to be compact and efficient. The core principle is a character-delimited format. It uses specific punctuation marks to act as signposts, telling a computer where one piece of data ends and the next begins. This makes the messages look like cryptic nonsense to the human eye, but they are perfectly logical to a computer program called an “interface engine” or a “parser.”

The “Pipe and Hat” Syntax: The Grammar of HL7v2

The entire structure of HL7v2 is built on a hierarchy of delimiters. You must memorize these:

Delimiter Name Purpose Example
Segment Terminator A carriage return (like hitting ‘Enter’) separates one line, or Segment, from the next. PID|...PV1|...
| Field Separator (Pipe) Separates the Fields within a segment. ...|SMITH^JOHN^J|...
^ Component Separator (Caret/Hat) Separates the Components within a field. (e.g., Last Name, First Name). SMITH^JOHN^J
& Sub-component Separator Separates Sub-components within a component. (Rarely used). Component1&Sub1
~ Repetition Separator Separates repeating instances of the same field. (e.g., multiple phone numbers). (555)123-4567~(555)765-4321

Think of it like a mailing address: The entire address block is the Segment. The pipe `|` separates the fields for Name, Street, and City/State. The caret `^` separates the components of the City/State field into “New York” and “NY”.

Deconstructing a Pharmacy Order Message (RDE^O11)

Let’s analyze a real-world example. A physician enters an order for Lisinopril 10mg. The CPOE generates the following HL7v2 message and sends it to the Pharmacy system. This message type is called an `RDE^O11` – Pharmacy/Treatment Encoded Order.

MSH|^~\&|EPIC_CPOE|MAIN_HOSP|PHARMACY_SYS|MAIN_HOSP|20251017230935||RDE^O11|MSG00123|P|2.3
PID|1||1234567^^^MRN|...|SMITH^JOHN^J||19650401|M|...
PV1|1|I|MEDSURG^201^1||||112233^DOE^JANE^M^DR|||...
ORC|NW|ORDER1234|||||...||20251017230900|445566^PROVIDER^BILL^T^DR|...
RXE|1^TAKE^1|216215^LISINOPRIL TAB^RXNORM^10^MG|10|MG||PO^BY MOUTH^HL70162|||QD^ONCE A DAY^HL70335|...
RXR|PO^BY MOUTH^HL70162|...
Segment-by-Segment Analysis

Let’s break this down line by line. Each three-letter code (MSH, PID, etc.) identifies a Segment, which is a logical grouping of data.

MSH: The Message Header

The MSH segment is the envelope. It contains metadata about the message itself, not the patient. It is always the first segment.

MSH|^~\&|EPIC_CPOE|MAIN_HOSP|PHARMACY_SYS|MAIN_HOSP|20251017230935||RDE^O11|MSG00123|P|2.3
Field (Position) Value Meaning
MSH.1 | Field Separator (defines the character used for the rest of the message).
MSH.2 ^~\& Encoding Characters (defines the other delimiters).
MSH.3 EPIC_CPOE Sending Application: What system sent this?
MSH.4 MAIN_HOSP Sending Facility: What organization sent this?
MSH.5 PHARMACY_SYS Receiving Application: What system is this intended for?
MSH.7 20251017230935 Message Date/Time: When was this sent? (Format: YYYYMMDDHHMMSS)
MSH.9 RDE^O11 Message Type: What kind of message is this? RDE = encoded pharmacy order. O11 = event type.
MSH.10 MSG00123 Message Control ID: A unique serial number for this specific message.
MSH.12 2.3 Version ID: What version of the HL7 standard is being used?
PID: Patient Identification

The PID segment contains patient demographics. This is the “who.”

PID|1||1234567^^^MRN|...|SMITH^JOHN^J||19650401|M|...
Field (Position) Value Meaning
PID.3 1234567^^^MRN Patient Identifier List: The most important field. This contains the Medical Record Number. The components are ID Number, Check Digit, Code, and Assigning Authority. Here, it’s MRN # 1234567.
PID.5 SMITH^JOHN^J Patient Name: Separated into components: Family Name^Given Name^Middle Initial.
PID.7 19650401 Date of Birth: Format YYYYMMDD.
PID.8 M Administrative Sex.
PV1: Patient Visit

The PV1 segment contains information about the patient’s current encounter or visit, such as their location in the hospital.

PV1|1|I|MEDSURG^201^1||||112233^DOE^JANE^M^DR|||...
Field (Position) Value Meaning
PV1.2 I Patient Class: I = Inpatient.
PV1.3 MEDSURG^201^1 Assigned Patient Location: Nursing Unit^Room^Bed. Here, the patient is in the MedSurg unit, room 201, bed 1.
PV1.7 112233^DOE^JANE^M^DR Attending Doctor: ID Number^Last Name^First Name…
ORC: Common Order

The ORC segment contains information common to all orders, regardless of type. It specifies what action is being taken (new order, cancel order, etc.) and who placed the order.

ORC|NW|ORDER1234|||||...||20251017230900|445566^PROVIDER^BILL^T^DR|...
Field (Position) Value Meaning
ORC.1 NW Order Control: This is a critical field. NW = New Order. Other values include CA (Cancel), XO (Change), etc.
ORC.2 ORDER1234 Placer Order Number: The unique ID for this order from the CPOE system.
ORC.9 20251017230900 Date/Time of Transaction: When the provider signed the order.
ORC.12 445566^PROVIDER^BILL^T^DR Ordering Provider: The person who placed the order.
RXE: Pharmacy/Treatment Encoded Order

This is the heart of the pharmacy message. It contains all the details of the actual medication order. Its structure is complex, but this is where an informatics pharmacist spends most of their time.

RXE|1^TAKE^1|216215^LISINOPRIL TAB^RXNORM^10^MG|10|MG||PO^BY MOUTH^HL70162|||QD^ONCE A DAY^HL70335|...
Field (Position) Value Meaning
RXE.1 1^TAKE^1 Quantity/Timing: A complex field. Here it indicates Take 1 tablet.
RXE.2 216215^LISINOPRIL TAB^RXNORM^10^MG Give Code (The Drug): This is the most important field. It identifies the medication. It’s composed of sub-components: Identifier^Text^Name of Coding System. Here, it’s RxNorm code 216215, which corresponds to Lisinopril 10 MG Oral Tablet. Using a standard coding system like RxNorm is critical for interoperability.
RXE.3 10 Give Amount: The dose number.
RXE.4 MG Give Units: The dose unit.
RXE.6 PO^BY MOUTH^HL70162 Give Administration Method: A code for the method of administration.
RXE.7 PO^BY MOUTH^HL70162 Give Route: A code for the route.
RXE.10 QD^ONCE A DAY^HL70335 Give Frequency: A code for the frequency. Using standardized codes is key.
Informatics in Action: Troubleshooting an HL7v2 Dosing Error

Scenario: The CPOE order was for Vancomycin 1000 MG. It arrives in the pharmacy system as Vancomycin 1 MG. The nurse calls you, confused. Where do you, the informatics pharmacist, look?

  1. Capture the Message: You go into your interface engine (e.g., Corepoint, Mirth Connect) and find the exact `RDE^O11` message for that order.
  2. Examine the RXE Segment: You look at the raw text of the `RXE` segment.
    ...|...|190547^VANCOMYCIN INJ^RXNORM|1000|MG|...
  3. Analyze the Fields: You check `RXE.3` (Give Amount) and `RXE.4` (Give Units). In the message from the CPOE, they are correct: `1000` and `MG`. This tells you the CPOE sent the data correctly.
  4. Hypothesize the Problem: The problem is not in the sending system; it’s in the receiving system (the Pharmacy application) or in the interface engine’s translation map. The pharmacy system is likely misinterpreting the message. Perhaps it has a bug where it only reads the first digit of the dose. Or maybe the interface engine has a faulty script that is stripping characters from the dose field before sending it to the pharmacy system.
  5. Resolution: You have now isolated the problem. You can confidently report to the pharmacy system vendor or the interface team: “The CPOE is correctly sending a dose of 1000 in RXE.3. The pharmacy system is incorrectly processing this value. Please investigate your system’s HL7 parser for this field.” You have used your knowledge of HL7v2 to solve a critical patient safety issue.

3.1.3 The Storyteller: Understanding Clinical Document Architecture (CDA)

While HL7v2 excels at discrete, real-time transactions (“A new order has been placed!”), it’s not well-suited for conveying a comprehensive clinical narrative. You can’t easily send an entire discharge summary or a consultant’s full report in a series of HL7v2 messages. To solve this problem, HL7 developed the Clinical Document Architecture (CDA). A CDA is exactly what it sounds like: a standard for creating electronic clinical documents.

The core principle of a CDA is that it is a complete, self-contained package of information. It’s designed to be both human-readable (with the help of a stylesheet) and machine-processable. Unlike the cryptic pipe-and-hat format of HL7v2, CDA uses XML (eXtensible Markup Language). XML uses descriptive tags to label data, making it much easier to understand the structure of the information.

The Continuity of Care Document (CCD)

The single most important and common implementation of CDA is the Continuity of Care Document (CCD or C-CDA). The CCD is a standardized summary of a patient’s clinical information, designed to be shared when a patient is transferred from one care setting to another (e.g., hospital to a skilled nursing facility, or from one hospital to another). Its purpose is to ensure the receiving provider has a comprehensive snapshot of the patient’s condition. A standard CCD contains defined sections for:

  • Allergies and Intolerances
  • Medications
  • Problem List (Diagnoses)
  • Procedures
  • Results (Labs, Radiology)
  • Vital Signs
  • Social History
  • Plan of Care

Deconstructing a CDA Medication Section

Let’s look at a simplified XML snippet from the “Medications” section of a CCD. Notice how the tags describe the data they contain.

<!-- Medications Section -->
<component>
  <section>
    <!-- Section Template ID for 'Medications' -->
    <templateId root="2.16.840.1.113883.10.20.22.2.1.1"/>
    <code code="10160-0" codeSystem="2.16.840.1.113883.6.1" displayName="History of medication use"/>
    <title>Medications</title>
    <text>
      <table border="1" width="100%">
        <thead><tr><th>Medication</th><th>Instructions</th></tr></thead>
        <tbody>
          <tr>
            <td>Lisinopril 10 MG Oral Tablet</td>
            <td>1 tablet by mouth once daily</td>
          </tr>
        </tbody>
      </table>
    </text>
    <!-- This is the discrete, machine-readable entry -->
    <entry typeCode="DRIV">
      <substanceAdministration classCode="SBADM" moodCode="EVN">
        <consumable>
          <manufacturedProduct>
            <manufacturedMaterial>
              <code code="216215" codeSystem="2.16.840.1.113883.6.88" displayName="Lisinopril 10 MG Oral Tablet">
                <originalText>Lisinopril 10 MG Oral Tablet</originalText>
              </code>
            </manufacturedMaterial>
          </manufacturedProduct>
        </consumable>
        <doseQuantity value="1"/>
        <routeCode code="C38288" codeSystem="2.16.840.1.113883.3.26.1.1" displayName="ORAL"/>
        <effectiveTime xsi:type="PIVL_TS" institutionSpecified="true" operator="A">
          <period value="1" unit="d"/>
        </effectiveTime>
      </substanceAdministration>
    </entry>
  </section>
</component>
Analysis of the CDA Structure

Notice the two key parts within the `

` tag:

  1. The Narrative Block (<text>): This part contains simple HTML (like a ``) that is designed to be displayed to a human. This ensures that any system, even one that doesn’t understand the complex CDA structure, can at least show the document to a clinician for manual review. This is the CDA’s safety net.
  2. The Structured Entry (<entry>): This part contains the rich, discrete, machine-readable data. Here you can see the ``, ``, and the medication `` which uses the RxNorm code system, just like our HL7v2 example. A sophisticated system can parse this structured data and use it for things like medication reconciliation.
    3. Masterclass Table: HL7v2 vs. CDA
    Attribute HL7 v2 CDA (CCD)
    Core Paradigm Transactional Messaging: Short, discrete messages representing a single event (e.g., "new order," "patient discharged"). Document-Oriented: A complete, persistent, self-contained clinical document representing a summary of care.
    Format Pipe-and-Hat (ASCII text, character-delimited). XML (eXtensible Markup Language).
    Primary Use Case Real-time data feeds within the walls of a hospital (e.g., ADT, Orders, Labs). Exchanging summary-of-care records between organizations (e.g., hospital discharge to SNF).
    Human Readability Not human-readable without a specification guide. Purely for machine processing. Human-readable (via the narrative block) and machine-processable (via the structured entries).
    Data Model Implicit. The meaning of a field is based on its position in the message (e.g., PID.5 is always Patient Name). Explicit and semantic. Data is labeled with descriptive XML tags and coded with terminologies like LOINC and SNOMED.
    Analogy The cryptic, efficient fax form. The comprehensive, narrative patient chart summary.

3.1.4 The Future: Fast Healthcare Interoperability Resources (FHIR)

The creators of HL7v2 and CDA built the best possible standards for the technology of their time. But the world has changed. The internet, smartphones, and cloud computing have created a new set of expectations for how data should be accessed. We don't want to receive a 20-page document (CDA) just to find out a patient's allergies, nor do we want to set up a complex, point-to-point message interface (HL7v2) for a simple query. We want to ask a specific question and get a specific answer, instantly. This is the world of APIs (Application Programming Interfaces), and it's the paradigm that powers the modern internet.

Fast Healthcare Interoperability Resources (FHIR®, pronounced "Fire") is HL7's answer to this modern need. It is a complete reimagining of how to exchange health data, built from the ground up using the same web standards that power sites like Google, Amazon, and Facebook. It is not an update to v2 or v3; it is a brand new standard designed for the internet age.

The Core Concept: "Resources"

The fundamental departure of FHIR is that it doesn't think in terms of "messages" or "documents." Instead, it breaks all healthcare information down into modular components called Resources. A Resource is a single, discrete clinical or administrative concept. Examples include:

  • Patient
  • Practitioner
  • Organization
  • AllergyIntolerance
  • Condition (Problem)
  • Observation (Lab, Vital)
  • Medication
  • MedicationRequest (Order)
  • MedicationDispense
  • MedicationAdministration
  • Encounter
  • Coverage

Each Resource is like a Lego block with a standard shape and defined set of properties. You can then combine these blocks to create any clinical scenario you need. A prescription, for instance, isn't a single monolithic message. It's a MedicationRequest resource that has pointers to a Patient resource and a Practitioner resource.

Deconstructing a FHIR Resource: The `MedicationRequest`

FHIR resources can be represented in different formats, but the most common and human-readable is JSON (JavaScript Object Notation). Let's look at the same "Lisinopril 10mg daily" order, but this time as a FHIR MedicationRequest resource in JSON format. Notice how it's structured as readable "key": "value" pairs.

{
  "resourceType": "MedicationRequest",
  "id": "medreq0315",
  "status": "active",
  "intent": "order",
  "medicationCodeableConcept": {
    "coding": [
      {
        "system": "http://www.nlm.nih.gov/research/umls/rxnorm",
        "code": "216215",
        "display": "Lisinopril 10 MG Oral Tablet"
      }
    ],
    "text": "Lisinopril 10 MG Oral Tablet"
  },
  "subject": {
    "reference": "Patient/1234567",
    "display": "John J. Smith"
  },
  "encounter": {
    "reference": "Encounter/98765"
  },
  "authoredOn": "2025-10-17T23:09:00Z",
  "requester": {
    "reference": "Practitioner/445566",
    "display": "Dr. Bill T. Provider"
  },
  "dosageInstruction": [
    {
      "text": "Take 1 tablet by mouth once daily",
      "timing": {
        "repeat": {
          "frequency": 1,
          "period": 1,
          "periodUnit": "d"
        }
      },
      "route": {
        "coding": [
          {
            "system": "http://snomed.info/sct",
            "code": "26643006",
            "display": "Oral route"
          }
        ]
      },
      "doseAndRate": [
        {
          "doseQuantity": {
            "value": 1,
            "unit": "tablet",
            "system": "http://terminology.hl7.org/CodeSystem/v3-orderableDrugForm"
          }
        }
      ]
    }
  ]
}
Analysis of the FHIR JSON Structure

This is far more intuitive than HL7v2. You can immediately see what each piece of data represents:

  • resourceType: Clearly states what this object is: a `MedicationRequest`.
  • medicationCodeableConcept: Identifies the drug using a standard coding system (RxNorm), just like the other standards.
  • subject & requester: These fields don't contain the full patient and provider details. Instead, they simply point to other resources. `Patient/1234567` is a URL that will retrieve the full `Patient` resource for this individual. This is the power of the web-based approach; data is linked, not endlessly duplicated.
  • dosageInstruction: This is a highly structured block that captures the sig in a discrete, computer-readable way. It specifies the timing, route, and dose quantity separately, eliminating the ambiguity of free-text sigs.
The Final Showdown: HL7v2 vs. CDA vs. FHIR

Each standard has its place, but FHIR's modern, web-centric approach is where the industry is headed. This comprehensive table summarizes the key differences every informatics professional must know.

Attribute HL7 v2 CDA FHIR
Paradigm Transactional Messaging Document-Oriented API-based Resource Querying
Format Pipe-and-Hat (ASCII) XML JSON or XML
Data Model Implicit, positional segments and fields. Explicit, narrative sections with structured entries. Small, reusable, linkable "Resources."
Key Use Case High-volume, real-time internal hospital data feeds (Orders, ADT, Labs). Exchanging comprehensive care summaries between organizations. Mobile apps, web portals, modular data queries, patient access.
Learning Curve Very steep. Requires specialized training and tools. Steep. Requires understanding XML and the complex CDA schema. Much gentler. Uses standard web technologies familiar to all modern developers.
Flexibility Very rigid. Extensions are difficult and often proprietary ("Z-segments"). Moderately flexible, but complex to extend properly. Highly flexible. Designed for extension via "Profiles" and "Extensions."
Analogy The cryptic, efficient fax form. The comprehensive, narrative patient chart summary. The modern smartphone app.