HL7 Standards Family

Overview of HL7

Health Level Seven International (HL7) is the most widely used set of healthcare data exchange standards. The “Level Seven” refers to the seventh layer (application layer) of the OSI networking model.

HL7 Version 2.x (HL7 V2)

Status: Most widely implemented healthcare standard globally First Released: 1987 Current Versions: 2.3, 2.4, 2.5, 2.5.1, 2.6, 2.7, 2.8, 2.9

When and Where HL7 V2 is Used

Primary Use Cases:

• Admissions, Discharge, Transfer (ADT) messages
• Laboratory orders and results (ORU, ORM)
• Pharmacy orders and dispenses
• Billing and financial transactions
• Scheduling and appointment management
• Patient registration

Typical Settings:

• Hospitals and hospital systems
• Laboratory information systems (LIS)
• Pharmacy systems
• Radiology information systems (RIS)
• Electronic Medical Records (EMR/EHR)

HL7 V2 Message Structure

MSH|^~\&|SendingApp|SendingFacility|ReceivingApp|ReceivingFac|202311190900||ADT^A01|MSG00001|P|2.5
EVN|A01|202311190900
PID|1||123456789^^^Hospital^MR||Doe^John^A||19800115|M|||123 Main St^^Anytown^CA^12345||(555)555-1234|||S||999-88-7777
PV1|1|I|2000^2012^01||||004777^ATTEND^AARON^A|||SUR||||ADM|A0

Message Components:

Segment Structure:

• Segments start with a 3-letter code (MSH, PID, PV1, etc.)
• Fields separated by | (pipe)
• Components within fields separated by ^ (caret)
• Subcomponents separated by & (ampersand)
• Repetitions separated by ~ (tilde)

Common Segments:

• MSH (Message Header): Required in all messages, contains metadata
• EVN (Event Type): Describes the trigger event
• PID (Patient Identification): Patient demographics and identifiers
• PV1 (Patient Visit): Visit information (admission, location, attending doctor)
• OBR (Observation Request): Order information
• OBX (Observation Result): Result data
• DG1 (Diagnosis): Diagnosis information
• AL1 (Allergy): Allergy information

Common Message Types:

• ADT^A01: Admit patient
• ADT^A03: Discharge patient
• ADT^A04: Register patient
• ADT^A08: Update patient information
• ORU^R01: Unsolicited observation/result
• ORM^O01: General order message
• SIU^S12: Schedule notification

Implementation Considerations

Advantages:

• Extremely flexible and extensible
• Well-established with broad vendor support
• Can handle complex scenarios
• Backward compatible across versions

Challenges:

• Flexibility leads to implementation variability
• Requires extensive interface specifications
• Testing can be complex
• Z-segments (custom segments) reduce interoperability

Best Practices:

• Document all implementation choices
• Use conformance profiles
• Implement comprehensive error handling
• Validate against message profiles
• Use acknowledgment messages (ACK)

HL7 Version 3 (HL7 V3)

Status: Mature standard, limited adoption Key Feature: Reference Information Model (RIM)

When and Where HL7 V3 is Used

Primary Use Cases:

• Clinical Document Architecture (CDA) - most successful V3 artifact
• Public health reporting
• Immunization registries
• Electronic lab reporting
• Some national health systems (UK, Netherlands)

Typical Settings:

• Public health agencies
• National health information exchanges
• Clinical document repositories

HL7 V3 Architecture

Reference Information Model (RIM): The RIM is the cornerstone of HL7 V3, providing a single, coherent data model.

Core RIM Classes:

• Act: Any action in healthcare (procedures, observations, encounters)
• Entity: Physical things (persons, organizations, materials)
• Role: The role an entity plays (patient, provider, employee)
• Participation: The relationship between roles and acts
• ActRelationship: Relationships between acts
• RoleLink: Relationships between roles

XML Structure Example:

<ClinicalDocument xmlns="urn:hl7-org:v3">
  <typeId root="2.16.840.1.113883.1.3" extension="POCD_HD000040"/>
  <id root="2.16.840.1.113883.19.5" extension="c266"/>
  <code code="34133-9" codeSystem="2.16.840.1.113883.6.1"/>
  <title>Summarization of Episode Note</title>
  <effectiveTime value="20050329"/>
  <confidentialityCode code="N" codeSystem="2.16.840.1.113883.5.25"/>
  <recordTarget>
    <patientRole>
      <id extension="12345" root="2.16.840.1.113883.19.5"/>
      <patient>
        <name>
          <given>John</given>
          <family>Doe</family>
        </name>
      </patient>
    </patientRole>
  </recordTarget>
</ClinicalDocument>

Implementation Considerations

Advantages:

• Rigorous methodology
• Consistent semantic model
• XML-based (widely supported)
• Better semantic interoperability than V2

Challenges:

• Complex to implement
• Steep learning curve
• Limited vendor adoption (except CDA)
• Verbose message structure

HL7 FHIR (Fast Healthcare Interoperability Resources)

Status: Actively developed, rapidly growing adoption First Released: 2014 (DSTU1) Current Version: R5 (2023) Most Widely Used: R4 (2019)

When and Where FHIR is Used

Primary Use Cases:

• Patient access APIs (patient portals, mobile apps)
• Provider-to-provider data exchange
• Population health queries
• Clinical decision support integration
• Research data collection
• Public health reporting
• IoT and wearable device integration

Typical Settings:

• Modern EHR systems
• Health information exchanges
• Patient-facing applications
• Research platforms
• Government health IT initiatives (ONC, CMS mandates)
• Telehealth platforms

Regulatory Drivers:

• 21st Century Cures Act: Mandates FHIR APIs for patient access
• CMS Interoperability Rules: Require FHIR implementation
• ONC Certification: FHIR API support required for EHR certification

FHIR Core Concepts

Resources: FHIR is based on “resources” - modular components representing healthcare concepts.

Common Resource Types:

• Patient: Patient demographics and identifiers
• Practitioner: Healthcare provider information
• Observation: Clinical measurements and lab results
• Condition: Diagnoses and health concerns
• Procedure: Procedures performed
• Medication: Medication information
• MedicationRequest: Medication orders/prescriptions
• Encounter: Healthcare visit or episode
• AllergyIntolerance: Allergy and adverse reaction information
• DiagnosticReport: Diagnostic test results

Resource Structure Example (JSON):

{
  "resourceType": "Patient",
  "id": "example",
  "meta": {
    "versionId": "1",
    "lastUpdated": "2023-11-19T09:00:00Z"
  },
  "identifier": [
    {
      "use": "official",
      "type": {
        "coding": [
          {
            "system": "http://terminology.hl7.org/CodeSystem/v2-0203",
            "code": "MR"
          }
        ]
      },
      "system": "http://hospital.example.org",
      "value": "123456"
    }
  ],
  "active": true,
  "name": [
    {
      "use": "official",
      "family": "Doe",
      "given": ["John", "A"]
    }
  ],
  "gender": "male",
  "birthDate": "1980-01-15",
  "address": [
    {
      "use": "home",
      "line": ["123 Main Street"],
      "city": "Anytown",
      "state": "CA",
      "postalCode": "12345"
    }
  ],
  "telecom": [
    {
      "system": "phone",
      "value": "555-555-1234",
      "use": "home"
    }
  ]
}

FHIR RESTful API

FHIR uses standard HTTP methods for CRUD operations:

Operations:

• GET: Read resources or search
• POST: Create new resources
• PUT: Update existing resources
• DELETE: Remove resources
• PATCH: Partial updates

Example API Calls:

Read a specific patient:

GET /fhir/Patient/example
Accept: application/fhir+json

Search for patients by name:

GET /fhir/Patient?name=Doe

Search for observations for a patient:

GET /fhir/Observation?patient=Patient/example&category=vital-signs

Create a new observation:

POST /fhir/Observation
Content-Type: application/fhir+json

{
  "resourceType": "Observation",
  "status": "final",
  "category": [
    {
      "coding": [
        {
          "system": "http://terminology.hl7.org/CodeSystem/observation-category",
          "code": "vital-signs"
        }
      ]
    }
  ],
  "code": {
    "coding": [
      {
        "system": "http://loinc.org",
        "code": "29463-7",
        "display": "Body Weight"
      }
    ]
  },
  "subject": {
    "reference": "Patient/example"
  },
  "effectiveDateTime": "2023-11-19",
  "valueQuantity": {
    "value": 75,
    "unit": "kg",
    "system": "http://unitsofmeasure.org",
    "code": "kg"
  }
}

FHIR Search Parameters

FHIR provides powerful search capabilities:

Common Search Parameters:

• _id: Search by resource ID
• _lastUpdated: Search by last modification time
• _tag: Search by tag
• _profile: Search by profile
• _text: Full-text search
• _content: Search in narrative content

Resource-Specific Parameters:

• Patient: name, identifier, birthdate, gender
• Observation: patient, code, date, category
• Condition: patient, code, onset-date

Search Modifiers:

• :exact: Exact match
• :contains: Partial match
• :missing: Check if parameter is missing
• :not: Negation

Example Searches:

# Find patients born after 1980
GET /fhir/Patient?birthdate=gt1980-01-01

# Find observations with specific LOINC code
GET /fhir/Observation?code=http://loinc.org|29463-7

# Find conditions for a patient
GET /fhir/Condition?patient=Patient/example&clinical-status=active

# Search with multiple parameters
GET /fhir/Observation?patient=Patient/example&date=ge2023-01-01&date=le2023-12-31

FHIR Profiles and Implementation Guides

Profiles constrain base FHIR resources for specific use cases.

US Core Profiles: US Core is a set of profiles required for US implementations:

• US Core Patient: Adds race, ethnicity, birth sex
• US Core Condition: Specifies required terminologies
• US Core Observation: Defines vital signs profiles
• US Core MedicationRequest: Standardizes prescriptions

Example Profile Constraint:

{
  "resourceType": "StructureDefinition",
  "url": "http://hl7.org/fhir/us/core/StructureDefinition/us-core-patient",
  "name": "USCorePatientProfile",
  "status": "active",
  "kind": "resource",
  "abstract": false,
  "type": "Patient",
  "baseDefinition": "http://hl7.org/fhir/StructureDefinition/Patient",
  "differential": {
    "element": [
      {
        "id": "Patient.identifier",
        "path": "Patient.identifier",
        "min": 1,
        "mustSupport": true
      },
      {
        "id": "Patient.name",
        "path": "Patient.name",
        "min": 1,
        "mustSupport": true
      }
    ]
  }
}

Major Implementation Guides:

• US Core: Foundation for US implementations
• International Patient Summary (IPS): Global summary document
• Argonaut: Industry-driven implementation guides
• CARIN: Consumer access to insurance data
• Da Vinci: Value-based care use cases
• Bulk Data: Large-scale data export
• SMART on FHIR: App authorization framework

FHIR Advantages

For Developers:

• RESTful architecture (familiar to web developers)
• JSON support (easier than XML for many developers)
• Extensive tooling and libraries
• Active developer community
• Modern authentication (OAuth 2.0)

For Healthcare:

• Granular, resource-based approach
• Mobile and web app friendly
• Supports real-time queries
• Enables patient access
• Facilitates innovation

For Organizations:

• Lower implementation costs than V2/V3
• Faster time to market
• Better support for emerging use cases
• Regulatory alignment

FHIR Implementation Considerations

Authentication and Authorization: FHIR uses OAuth 2.0 and SMART on FHIR for security.

SMART on FHIR Authorization Flow:

1. App registration with EHR
2. User launches app (standalone or EHR launch)
3. App redirects to authorization endpoint
4. User authenticates and grants permission
5. EHR returns authorization code
6. App exchanges code for access token
7. App uses token to access FHIR API

Required Scopes:

• patient/*.read: Read all patient resources
• patient/Observation.read: Read observations only
• patient/Condition.rs: Read and search conditions
• user/.: Clinician context access

Versioning:

• FHIR versions are not fully backward compatible
• R4 is the current widely adopted version
• Plan migration strategy when upgrading
• Test thoroughly across versions

Performance Optimization:

• Use _summary parameter for lighter responses
• Implement pagination for large result sets
• Use _elements to retrieve only needed fields
• Consider GraphQL endpoint for complex queries
• Implement caching where appropriate

Testing:

• Use public test servers (test.fhir.org)
• Validate against profiles
• Test search parameters thoroughly
• Check error handling
• Test authorization flows