The HL7 Protocol: Managing Patient and Clinical Data
While DICOM handles the massive binary payloads of the images themselves, Health Level 7 (HL7) serves as the primary communication protocol for the exchange, integration, sharing, and retrieval of clinical and administrative text-based data across the broader healthcare enterprise.
Traditional monolithic hospital IT environments heavily rely on older iterations of the standard, specifically HL7 version 2.x. HL7 v2.x utilizes a rigid, structured, pipe-delimited textual format to encode information. These messages are organized into distinct segments that define the event that has occurred within the hospital.
HL7 Version Evolution
Understanding the evolution of HL7 standards provides context for why many Australian healthcare systems still operate on HL7 v2.x while transitioning toward FHIR for modern interoperability initiatives.
HL7 standard version history
| Version | Year | Description |
|---|---|---|
| HL7 v2.1 | 1989 | First widely adopted version with pipe-delimited format |
| HL7 v2.3 | 1995 | Added support for XML and improved data types |
| HL7 v2.5 | 2003 | Most widely deployed version in healthcare systems |
| HL7 v2.8 | 2014 | Current stable v2.x version with enhanced capabilities |
| HL7 v3 | 2005 | XML-based, model-driven architecture (limited adoption) |
| FHIR R4 | 2019 | RESTful API standard using JSON/XML, modern web-friendly |
Australian Context
The Australian Digital Health Agency's My Health Record system increasingly relies on FHIR R4 for modern integrations, while legacy hospital systems continue operating on HL7 v2.5. Integration engines like Mirth Connect bridge this gap.
HL7 v2.x Message Structure and Encoding
HL7 v2.x messages follow a strict hierarchical structure composed of segments, fields, components, and sub-components. Each message begins with an MSH (Message Header) segment that defines the message type and encoding characters.
Encoding Characters
HL7 uses special characters to delimit different levels of the message hierarchy. Understanding these is essential for parsing and constructing valid HL7 messages.
HL7 encoding characters
| Character | Name | Purpose |
|---|---|---|
| | | Field Separator | Separates fields within a segment |
| ^ | Component Separator | Separates components within a field |
| ~ | Repetition Separator | Separates repeated fields |
| \ | Escape Character | Introduces escape sequences |
| Segment Terminator | Ends each segment (CR character) |
Message Segments
Each segment serves a specific purpose within the message. Segments are identified by a three-letter code and are terminated by a carriage return character.
Common HL7 v2.x message segments
| Segment | Description |
|---|---|
| MSH (Message Header) | Defines message type, sending/receiving applications, timestamp |
| EVN (Event Type) | Specifies the triggering event for the message |
| PID (Patient Identification) | Contains patient demographics and identifiers |
| PV1 (Patient Visit) | Encodes patient visit information and status |
| OBR (Observation Request) | Describes the diagnostic order or request |
| OBX (Observation Result) | Contains the actual observation or result data |
| NK1 (Next of Kin) | Emergency contact and next of kin information |
| DG1 (Diagnosis) | Patient diagnosis codes and descriptions |
MLLP Transport Protocol
HL7 messages are typically transmitted using MLLP (Minimum Lower Layer Protocol), which wraps each message with start block (0x0B (Vertical Tab)), end block (0x1C (File Separator)), and commit confirmation (0x0D (Carriage Return)) characters for reliable delivery over TCP/IP.
MLLP Technical Implementation
MLLP provides a simple framing mechanism that ensures complete HL7 messages are transmitted over streaming TCP connections. The protocol uses three control characters to delimit message boundaries and confirm successful receipt.
- Start Block (SB): 0x0B (Vertical Tab) marks the beginning of each HL7 message
- End Block (EB): 0x1C (File Separator) indicates the message content is complete
- Commit Acknowledgment: 0x0D (Carriage Return) confirms successful processing by receiver
The typical MLLP connection flow: sender opens TCP connection → wraps HL7 message with SB/EB → receiver parses complete message → sends CR acknowledgment → connection persists for next message or times out after inactivity.
HL7 International Standards
Official HL7 standards organization - HL7 v2.x, v3, and FHIR specifications
Read moreHL7 v2.x Message Structure
HL7 version 2.x messaging standard documentation and implementation guides
Read moreHL7 Message Types for Imaging Workflow
Common HL7 message types critical to the imaging workflow include:
Core HL7 message types for PACS integration
| Type | Name | Purpose |
|---|---|---|
| ADT | Admission, Discharge, Transfer | Update patient demographics across systems |
| ORM | Order Message | Transmit diagnostic scan orders from EHR to RIS |
| ORU | Observation Result | Transmit radiology report from RIS to EHR |
Radiology-Specific Message Types
Beyond the core ADT/ORM/ORU messages, radiology workflows utilize additional specialized message types for comprehensive departmental management.
Radiology-specific HL7 message types
| Message Type | Name | Trigger | Usage |
|---|---|---|---|
| ADT^A01 | Admit/Visit Notification | Patient admitted to hospital | Update all systems with new patient |
| ADT^A03 | Discharge | Patient discharged | Close patient encounter, update billing |
| ADT^A04 | Register | Patient registered as outpatient | Create outpatient record |
| ADT^A08 | Update Patient Info | Patient demographics changed | Sync updated info across systems |
| ORM^O01 | Order Message | New diagnostic order placed | Send order to RIS/modality |
| ORU^R01 | Observation Result | Result available | Transmit radiology report to EHR |
| SIU^S12 | Notification of Appointment | Imaging appointment scheduled | Notify patient and departments |
| MDM^T02 | Medical Document | Report finalized | Transmit completed radiology report |
Australian Medicare Integration
For Australian practices, ORU^R01 messages must include specific Medicare item numbers in the OBX segments to support billing reconciliation through practice management systems.
ADHA My Health Record
Australian Digital Health Agency - national EHR system and integration standards
Read moreHL7 Australia
HL7 Australia implementation guides and local profiling for Australian healthcare
Read moreAWS B2B Data Interchange
AWS managed service for transforming EDI and HL7 data without custom code
Read moreIHE Integration Profiles for Radiology
The Integrating the Healthcare Enterprise (IHE) initiative defines technical frameworks that specify how DICOM and HL7 should be combined to support specific clinical workflows. IHE profiles ensure multi-vendor interoperability.
Australian healthcare organizations should prioritize IHE profile conformance when procuring new imaging systems to ensure compatibility with national interoperability initiatives and state-wide PACS deployments.
IHE Radiology integration profiles
| Profile | Description | Components |
|---|---|---|
| Scheduled Workflow (SWF) | Coordinates patient scheduling, image acquisition, and report distribution | Order Placer, Order Filler, Acquisition Modality, Image Manager |
| Scheduled Workflow Harmonized (SWF-H) | Enhanced SWF with improved status tracking and error handling | Extended status notifications, improved exception handling |
| Post-Processing Workflow (PPW) | Manages 3D reconstruction and advanced visualization workflows | Image Manager, Post-Processing Manager, Display System |
| Import Reconciliation Workflow (IRWF) | Handles external studies and prior image reconciliation | Import Repository, Reconciliation Workstation |
| Radiation Dose SR (RAD) | Captures and manages radiation dose structured reports | Dose SR Creator, Dose SR Repository |
| Report Distribution (RD) | Distributes finalized reports to ordering physicians | Report Creator, Report Distribution Manager |
Scheduled Workflow (SWF) Deep Dive
The Scheduled Workflow profile is the foundational IHE profile for radiology, coordinating the entire imaging encounter from order to report distribution. It defines four primary actors:
- Order Placer (typically EHR/HIS): Initiates the imaging order
- Order Filler (typically RIS): Manages scheduling and workflow
- Acquisition Modality (CT, MR, etc.): Acquires images and updates status
- Image Manager/Archive (PACS): Stores and manages images for retrieval
This source diagram is worth keeping next to the authored flowcharts because it shows the canonical actor boundaries that vendors are supposed to implement. The local Mermaid diagrams explain behavior step by step; the IHE figure shows the formal interoperability contract underneath.
ADT → MWL → MPPS Patient Journey Flowchart
The following flowchart traces the patient journey from hospital admission through imaging completion, showing HL7 ADT, DICOM MWL, and MPPS message flow:
ADT → MWL → MPPS Patient Journey
Loading diagram...
Message Flow Analysis
HL7 ADT messages broadcast patient admission to all downstream systems. HL7 ORM carries the imaging order to RIS. DICOM C-FIND retrieves patient data from MWL to eliminate manual entry. DICOM MPPS provides real-time status updates. HL7 ORU closes the loop by returning the final report to the EHR.
RIS-PACS Integration Sequence Diagram
The following sequence diagram shows the detailed message exchange between RIS, PACS, Modality, and Workstation during a complete imaging encounter:
RIS-PACS Integration Sequence
Loading diagram...
Critical Integration Points
The Storage Commitment handshake (messages 8-9) is critical for data integrity—modalities have limited local storage and cannot safely delete images without PACS confirmation. MPPS notifications (messages 10-11) enable real-time workflow visibility, allowing RIS to track exam progress and notify radiologists when studies are ready.
IHE Radiology Technical Framework
Complete IHE Radiology technical framework with all integration profiles
Read moreRadiology Workflow and Information Systems Review
Peer-reviewed review of radiology workflow integration, RIS/PACS coordination, and imaging informatics patterns.
Read moreThe Integrated Clinical Workflow: IHE Scheduled Workflow
To ensure seamless patient care, DICOM and HL7 must operate in a highly synchronized manner. This interoperability is typically architected according to the guidelines set forth by the Integrating the Healthcare Enterprise (IHE) initiative, specifically the Scheduled Workflow (SWF) profile.
8-Step IHE Scheduled Workflow
IHE Scheduled Workflow profile steps
| Step | Action |
|---|---|
| 1 | Clinician enters scan request into HIS/EHR |
| 2 | HIS translates to HL7 ORM, transmits to RIS |
| 3 | RIS populates DICOM Modality Worklist (MWL) |
| 4 | Modality C-FIND queries MWL for patient demographics |
| 5 | Technician performs scan; modality creates DICOM Part 10 file |
| 6 | Modality C-STORE pushes images to PACS; sends MPPS to RIS |
| 7 | Radiologist C-MOVE retrieves images, reviews, dictates findings |
| 8 | RIS formats report as HL7 ORU, transmits to EHR |
Integrated DICOM+HL7 Message Flow
Sequence diagram showing the complete 8-step IHE Scheduled Workflow with protocol annotations:
Integrated DICOM+HL7 8-Step Workflow
Loading diagram...
Eliminating Manual Errors
By querying the Modality Worklist via C-FIND, the modality retrieves accurate patient demographics without requiring manual data entry by the technician, thereby eliminating dangerous typographical errors.
IHE Scheduled Workflow Profile
IHE Radiology Scheduled Workflow technical framework specification
Read moreDICOM Modality Worklist
DICOM Part 4 - Modality Worklist Management service class specification
Read moreMirth Connect Integration Engine on AWS
Mirth Connect (now NextGen Connect) is a widely adopted open-source healthcare integration engine that serves as a universal translator between disparate healthcare systems. On AWS, Mirth Connect bridges legacy HL7 v2 systems with modern cloud-native architectures.
Mirth Connect operates as middleware that listens on designated TCP ports for incoming HL7 v2 messages, applies JavaScript-based transformations, and routes the processed data to downstream systems including FHIR endpoints, databases, or cloud services.
AWS Deployment Patterns
Mirth Connect deployment architectures on AWS
| Pattern | Description | Use Case |
|---|---|---|
| ECS/Fargate | Serverless container deployment with auto-scaling | Variable message volumes, cost-optimized operations |
| EC2 Auto Scaling | Traditional VM-based deployment with load balancer | Legacy channel compatibility, persistent storage requirements |
| EKS Kubernetes | Container orchestration with advanced scheduling | Multi-tenant deployments, complex routing logic |
| Lambda + API Gateway | Event-driven serverless processing | Low-volume batch transformations, FHIR conversion |
Typical Mirth Connect Architecture on AWS
A production-ready Mirth Connect deployment on AWS typically includes the following components:
- Application Load Balancer: Distributes MLLP traffic across multiple Mirth Connect instances
- ECS/Fargate Tasks: Containerized Mirth Connect instances with auto-scaling based on message volume
- Amazon RDS (PostgreSQL): Persistent storage for channel configurations, message logs, and queued data
- Amazon S3: Archive storage for processed HL7 messages and audit trails
- AWS Secrets Manager: Secure storage for database credentials and API keys
- CloudWatch Logs: Centralized logging and monitoring of message processing
High-level architecture showing Mirth Connect integration engine deployed on AWS ECS/Fargate:
Mirth Connect Integration Engine on AWS
Loading diagram...
High Availability Configuration
For critical radiology workflows, deploy Mirth Connect across multiple Availability Zones with database read replicas and S3 cross-region replication to ensure continuous operation during infrastructure failures.
Healthcare Integration with Mirth Connect and AWS
AWS blog post on building healthcare data hubs with Mirth Connect
Read moreCreate Healthcare Data Hub with AWS and Mirth Connect
Step-by-step guide for deploying Mirth Connect on AWS infrastructure
Read moreHL7 v2 to FHIR Conversion Workflow
The global healthcare industry is transitioning from legacy HL7 v2.x pipe-delimited messaging to Fast Healthcare Interoperability Resources (FHIR) R4, a RESTful API standard using JSON/XML formats. This conversion is critical for Australian healthcare organizations preparing for My Health Record integration mandates.
FHIR represents healthcare data as discrete "resources" (Patient, DiagnosticReport, Observation) that can be easily queried, shared, and integrated with modern applications including mobile health apps and AI/ML platforms.
HL7 v2 → FHIR Transformation Steps
HL7 v2 to FHIR R4 conversion workflow
| Step | Action | Component |
|---|---|---|
| 1 | HL7 v2 message received via MLLP on port 2575 | Mirth Connect Channel |
| 2 | JavaScript transformer parses pipe-delimited segments | Mirth JavaScript Engine |
| 3 | Field mapping: PID-3 → Patient.identifier, PID-5 → Patient.name | FHIR Resource Builder |
| 4 | Validation against FHIR R4 profiles | FHIR Validator |
| 5 | FHIR JSON resource transmitted to AWS HealthLake | FHIR Endpoint |
| 6 | ACK returned to sending system | Mirth Response |
Data transformation flow showing field-level mapping from HL7 segments to FHIR resources:
HL7 v2 to FHIR R4 Transformation
Loading diagram...
Diagram Interpretation
This diagram illustrates the transformation pipeline, demonstrating field-level mapping between HL7 v2 segments and FHIR R4 resources.
Common Field Mappings
Key HL7 v2 segments map to FHIR R4 resources as follows:
- PID (Patient Identification) → FHIR Patient resource (PID-3 → Patient.identifier, PID-5 → Patient.name, PID-7 → Patient.birthDate)
- PV1 (Patient Visit) → FHIR Encounter resource (PV1-2 → Encounter.status, PV1-3 → Encounter.location)
- OBR (Observation Request) → FHIR ServiceRequest resource (OBR-4 → ServiceRequest.code, OBR-7 → ServiceRequest.occurrenceDateTime)
- OBX (Observation Result) → FHIR DiagnosticReport/Observation resource (OBX-3 → Observation.code, OBX-5 → Observation.value)
- MSH (Message Header) → FHIR MessageHeader resource (MSH-9 → MessageHeader.event, MSH-10 → MessageHeader.id)
AWS HealthLake Integration
Once converted to FHIR R4, healthcare data can be ingested into AWS HealthLake, a fully managed HIPAA-eligible service for storing, indexing, and querying health data. HealthLake enables complex queries across patient records, clinical trials, and research datasets.
HL7 v2 to FHIR Conversion Guide
Technical guide for converting HL7 v2 messages to FHIR resources
Read moreMulti-Modal Data Analysis with AWS Health
AWS solution for integrating HealthLake, HealthImaging, and HealthOmics
Read moreAustralian Healthcare Context: 2026 Mandates
The Australian Digital Health Agency's My Health Record system is undergoing significant modernization with new legislative mandates that fundamentally impact radiology workflow and HL7/FHIR integration requirements.
2026 Share by Default Legislative Mandate
The Health Legislation Amendment (Modernising My Health Record: Sharing by Default) Act 2025 initiates a fundamental paradigm shift in diagnostic data handling. Commencing 1 July 2026, all healthcare providers delivering diagnostic imaging services must upload clinical reports to My Health Record by default.
Technical Compliance Requirements
- Clinical software must conform to ADHA B2B MHR gateway standards
- Systems must support automated report upload within mandated timeframes
- Exception handling required for patient opt-outs and technical outages
- Medicare benefits contingent on MHR conformance certification
Reporting Timeline Changes
The new legislation progressively shrinks the patient access delay window:
- Basic X-ray reports (limbs): Immediate consumer access upon upload
- Advanced imaging (CT, MRI, PET): 5-day delay (reduced from 7 days)
- Radiologists must adapt reporting language for direct patient consumption
Workflow Impact
Radiologists must acknowledge that patients will read highly technical clinical text almost immediately, without a clinical intermediary. Reporting language should be clear, concise, and patient-friendly while maintaining clinical accuracy.
State Health System Variations
Australian state health departments operate distinct PACS/RIS systems with varying levels of My Health Record integration:
Australian state health imaging systems
| State | System | Coverage | Integration |
|---|---|---|---|
| NSW | eHealth NSW RIS-PACS EIR | 100+ public hospitals, 1 billion+ images | State-wide PACS consolidation |
| QLD | Queensland Health Imaging | All public health facilities | Integrated with Hospital Information System |
| VIC | VicHealth PACS | Metropolitan and regional hospitals | Connected to My Health Record |
| SA | SA Health Imaging | State-wide public system | FHIR-based interoperability pilot |
NSW Health EIR
The NSW Health RIS-PACS Enterprise Imaging Repository aggregates data from 100+ clinical facilities, providing a centralized state-wide view of over 1 billion imaging records. This serves as a model for other states' consolidation efforts.
ADHA My Health Record
Australian Digital Health Agency - national EHR system and integration standards
Read moreExternal References
Knowledge Check
Test your understanding with this quiz. You need to answer all questions correctly to mark this section as complete.