The HL7 A03message is a discharge or end-visit notification used in HL7 Version 2 healthcare interfaces to inform connected applications that a patient's encounter has ended. Also known as ADT A03, it helps EHRs, laboratory systems, pharmacy applications, billing platforms, and other healthcare systems maintain consistent encounter information. The message carries patient identifiers, visit details, and discharge information, including disposition and discharge time when available. This guide explains the HL7 ADT A03 message structure, MSH, EVN, PID, and PV1 segments, a complete sample message, field mappings, Mirth Connect JavaScript examples, acknowledgment handling, and troubleshooting.
What Is an HL7 ADT A03 Message?
An HL7 ADT A03 message communicates the discharge of a patient or the completion of a visit. It belongs to the Admit, Discharge, Transfer message family defined by HL7 Version 2. Hospitals typically generate this event after discharge information is recorded in the patient administration system or EHR. Receiving applications use the notification to locate an existing encounter and update its status. Unlike A01 admission and A02 transfer events, A03 represents the end of a visit. The wider HL7 ADT messaging guide explains how these events support patient administration.
Purpose of the A03 Discharge Event
The A03 event communicates that an existing encounter has ended. Receiving applications use the notification to update visit status, synchronize discharge information, and support appropriate downstream administrative and clinical workflows.
When Is an ADT A03 Message Generated?
An A03 notification is commonly generated when a hospital records a patient discharge or completes an encounter. The sending application distributes the event to connected systems requiring updated visit information.
Which Healthcare Systems Receive A03 Messages?
EHRs, laboratory systems, pharmacy platforms, revenue cycle applications, and care coordination tools may receive A03 messages. Each destination processes the notification according to its encounter management and operational requirements.
How A03 Messages Support Encounter Closure
A03 notifications help connected applications identify encounters that should no longer remain active. Consistent processing reduces discrepancies between systems and supports accurate discharge reporting and administrative workflows.
Why Discharge Message Accuracy Matters
Incorrect or missing A03 notifications can leave completed encounters open or update the wrong visit. Reliable processing depends on patient identification, encounter matching, discharge field validation, and dependable message delivery.
HL7 ADT A03 Message Structure and Segments
An HL7 ADT A03 message uses a segment-based format with fields separated by delimiters. The message header identifies the sender, receiver, HL7 version, and trigger event. Event metadata, patient identifiers, and encounter information appear in subsequent segments. Common segments include MSH, EVN, PID, and PV1. The PV1 segment is particularly important because it can contain discharge disposition and discharge date or time. Optional segments depend on the interface profile. Understanding the structure is essential for developers implementing HL7 v2 integration between hospital systems.
MSH Segment: Message Header
MSH identifies the sending application, receiving application, message timestamp, control identifier, and HL7 version. MSH-9 contains the A03 trigger event, allowing integration engines to apply discharge-specific processing rules.
EVN Segment: Event Information
EVN contains event metadata, including the recorded event timestamp. Receiving systems can use this information to support auditing, investigate delayed messages, and reconcile event processing sequences.
PID Segment: Patient Identification
PID contains patient identifiers and demographic information. Receiving applications use these values, particularly PID-3 and its assigning authority, to identify the correct patient before updating encounter information.
PV1 Segment: Patient Visit Information
PV1 communicates encounter details, including patient class, location, visit number, discharge disposition, and discharge timestamp. Correct field mapping helps receiving applications update the intended visit without creating another encounter.
Optional Segments in A03 Messages
Additional segments may communicate diagnoses, supplementary visit information, or other data required by receiving applications. Their presence depends on the HL7 version, implementation profile, and agreed interface requirements.
HL7 ADT A03 Message Example With Field Explanation
The following HL7 ADT A03 example represents a fictional inpatient discharge using HL7 v2.5 conventions. The message identifies the patient, encounter, discharge disposition, and discharge timestamp. Pipe characters separate fields, while carets separate components within composite values. MSH-9 identifies the discharge event, PID-3 contains the patient identifier, and PV1-19 identifies the encounter. PV1-36 and PV1-45 provide discharge-related information. This example is intended for learning and interface testing, not for direct production use without validation against the receiving application's implementation guide.
Complete HL7 ADT A03 Sample Message
MSH|^~\&|ADT_SYSTEM|HOSPITAL|EHR|MAIN|20261012160000||ADT^A03^ADT_A03|MSG30001|P|2.5
EVN|A03|20261012155500
PID|1||P123456^^^HOSPITAL^MR||DOE^JANE||19850415|F
PV1|1|I|WARD2^310^A||||1234^SMITH^JOHN||||||||||||V10001|||||||||||||||||01||||||||20261010100000|20261012155000The PV1 segment is position-sensitive. The discharge-related fields should be checked with a version-aware HL7 parser before importing this illustrative message into a live interface.
Explore each segment and its key fields:
Illustrative ADT^A03 — HL7 v2.5 (fictional data)
Select a segment to see what it carries
MSH — Message Header
RequiredThe MSH segment identifies ADT_SYSTEM as the sender and EHR as the receiver. ADT^A03^ADT_A03 specifies the discharge event, while MSG30001 provides a unique message control identifier.
| Field | Meaning | Value in this message |
|---|---|---|
| MSH-3 | Sending application | ADT_SYSTEM |
| MSH-5 | Receiving application | EHR |
| MSH-7 | Message creation time | 20261012160000 |
| MSH-9 | Message type | ADT^A03^ADT_A03 |
| MSH-10 | Message control ID | MSG30001 |
| MSH-12 | HL7 version | 2.5 |
MSH Segment Explained
The MSH segment identifies ADT_SYSTEM as the sender and EHR as the receiver. ADT^A03^ADT_A03 specifies the discharge event, while MSG30001 provides a unique message control identifier.
PID Segment Explained
The PID segment identifies fictional patient Jane Doe through patient identifier P123456. Receiving applications should use the identifier and assigning authority to locate the correct patient record.
PV1-19: Visit Number Explained
PV1-19 identifies the encounter associated with the discharge. Accurate visit matching is necessary because a patient may have multiple historical encounters, and the message must update the correct one.
PV1-36 and PV1-45 Explained
PV1-36 contains discharge disposition, while PV1-45 contains discharge date or time when populated. Receiving systems use these values for encounter closure and related reporting workflows.
Important HL7 ADT A03 Fields and Mapping
Reliable HL7 A03 integration requires accurate field mapping between the sending and receiving applications. Patient identifiers, encounter numbers, discharge disposition codes, and timestamps must retain their intended meaning during transformation. Different healthcare applications may use different identifier namespaces or discharge code sets, making mapping specifications essential. Developers should document mandatory fields, accepted values, and validation rules before implementation. The following table identifies commonly used A03 fields and their purpose. Additional requirements may apply depending on the HL7 version and destination interface profile.
| Field | HL7 Description | Example | Integration Purpose |
|---|---|---|---|
| MSH-3 | Sending Application | ADT_SYSTEM | Identifies source |
| MSH-5 | Receiving Application | EHR | Identifies destination |
| MSH-9 | Message Type | ADT^A03^ADT_A03 | Identifies discharge event |
| MSH-10 | Message Control ID | MSG30001 | Message tracking |
| MSH-12 | Version ID | 2.5 | Parsing and validation |
| EVN-2 | Recorded Date/Time | 20261012155500 | Event timestamp |
| PID-3 | Patient Identifier List | P123456 | Patient matching |
| PID-5 | Patient Name | DOE^JANE | Demographic identification |
| PV1-2 | Patient Class | I | Encounter classification |
| PV1-3 | Assigned Patient Location | WARD2^310^A | Last assigned location |
| PV1-19 | Visit Number | V10001 | Encounter matching |
| PV1-36 | Discharge Disposition | 01 | Discharge outcome |
| PV1-44 | Admit Date/Time | 20261010100000 | Admission timestamp |
| PV1-45 | Discharge Date/Time | 20261012155000 | Discharge timestamp |
MSH-9: Identifying the Discharge Event
MSH-9 identifies the ADT A03 message type. Integration engines inspect this field to distinguish discharge notifications from admissions, transfers, registrations, and patient information updates before applying event-specific processing.
PID-3: Patient Identifier Matching
PID-3 contains patient identifiers and assigning authorities. Receiving applications should match the complete identifier context rather than relying only on a local identifier that may overlap across facilities.
PV1-19: Encounter Identification
PV1-19 identifies the encounter being discharged. Receiving applications should validate this value against existing visit records and investigate ambiguous or missing identifiers before changing encounter status.
PV1-36: Discharge Disposition Mapping
PV1-36 contains a coded discharge disposition value. Integration teams should map source codes to destination-supported terminology and validate their meaning against the applicable interface specifications.
PV1-45: Discharge Timestamp Mapping
PV1-45 communicates the discharge timestamp when provided. Receiving systems should preserve the intended date and time, including applicable timezone conventions, to avoid incorrect encounter closure or reporting.
How HL7 ADT A03 Messages Work in Healthcare Integration
An HL7 A03 workflow begins when a hospital records a discharge or completes a patient visit. The source application generates an HL7 message containing patient identifiers, encounter details, and discharge information. An integration engine receives the notification, validates its structure, applies any required transformations, and routes it to connected applications. Receiving systems locate the existing encounter and update its status. Reliable processing requires acknowledgments, duplicate prevention, and recovery procedures. These safeguards help maintain consistent encounter information across EHRs, laboratories, pharmacy applications, and administrative systems.
Step 1: Discharge Event Generation
The patient administration system generates an A03 notification after a discharge is recorded. The message includes patient and visit information needed by downstream applications to identify the affected encounter.
Step 2: Message Validation
The integration engine validates the HL7 structure, event type, patient identifiers, and required visit information. Invalid messages should enter a controlled exception workflow rather than being processed automatically.
Step 3: Field Transformation
The integration engine maps patient identifiers, encounter numbers, disposition codes, and timestamps into destination-supported formats. Transformations should preserve the meaning of source data and follow documented interface requirements.
Step 4: Encounter Status Update
Receiving applications identify the existing encounter and apply the discharge event. They should not create a new encounter or close another visit when identifiers are missing or ambiguous.
Step 5: Acknowledgment and Monitoring
The receiving application returns an acknowledgment according to the agreed HL7 mode. Integration teams monitor failures, message delays, and reconciliation exceptions to maintain reliable discharge processing.
How to Implement HL7 ADT A03 Messages Using Mirth Connect
Mirth Connect can receive, validate, transform, and route HL7 ADT A03 messages using configurable channels and connectors. A typical implementation receives messages through an MLLP listener, identifies the A03 event, extracts patient and visit information, and forwards the data to a destination system. Developers can use JavaScript transformers to implement field validation and mapping. Production interfaces also need acknowledgment handling, logging, retries, and duplicate prevention. Organizations with complex requirements can use Mirth Connect development services to support implementation and maintenance.
Configure an HL7 Source Connector
Create a Mirth Connect channel using an MLLP listener or another supported connector. Configure the expected HL7 version, endpoint settings, security requirements, and message data type.
Filter ADT A03 Messages
Configure a source filter to identify the A03 trigger event in MSH-9. This prevents admission, transfer, and registration notifications from entering discharge-specific processing workflows.
Mirth Connect JavaScript filter example:
var messageType = msg['MSH']['MSH.9']['MSH.9.1'].toString();
var triggerEvent = msg['MSH']['MSH.9']['MSH.9.2'].toString();
return messageType === 'ADT' && triggerEvent === 'A03';Extract Patient and Discharge Fields
Use a JavaScript transformer to extract patient identifiers, visit numbers, discharge disposition, and discharge timestamps. Validate required values before routing messages to the destination application.
var patientId = msg['PID']['PID.3']['PID.3.1'].toString();
var visitNumber = msg['PV1']['PV1.19']['PV1.19.1'].toString();
var dischargeDisposition = msg['PV1']['PV1.36']['PV1.36.1'].toString();
var dischargeDateTime = msg['PV1']['PV1.45']['PV1.45.1'].toString();
if (!patientId || !visitNumber) {
throw new Error('Missing patient ID or visit number');
}
channelMap.put('patientId', patientId);
channelMap.put('visitNumber', visitNumber);
channelMap.put('dischargeDisposition', dischargeDisposition);
channelMap.put('dischargeDateTime', dischargeDateTime);These examples assume an HL7 v2 message parsed into Mirth Connect's XML representation. Production logic should also validate assigning authorities, repeating identifiers, timestamps, and destination-specific requirements.
Configure Destination Mapping
Map extracted fields into the destination application's supported format. Preserve patient and encounter identifiers, validate disposition codes, and ensure the destination updates the intended existing encounter.
Example of a destination-ready JSON object:
var dischargeData = {
patientId: channelMap.get('patientId'),
visitNumber: channelMap.get('visitNumber'),
dischargeDisposition: channelMap.get('dischargeDisposition'),
dischargeDateTime: channelMap.get('dischargeDateTime'),
eventType: 'A03'
};
var jsonPayload = JSON.stringify(dischargeData);
channelMap.put('jsonPayload', jsonPayload);Test and Monitor Discharge Processing
Test successful discharges, missing identifiers, invalid timestamps, duplicate notifications, and destination failures. Monitor acknowledgment responses and processing errors to identify discharge synchronization problems before they affect downstream applications.
HL7 ADT A03 ACK Message Examples and Error Handling
HL7 acknowledgment messages help sending applications determine whether an A03 notification was accepted or rejected according to the agreed acknowledgment mode. The ACK message includes an acknowledgment code and the original message control identifier. Common application acknowledgment codes include AA for acceptance, AE for error, and AR for rejection. These responses support message tracking and recovery workflows. However, an acknowledgment does not always guarantee that every downstream business process has completed. Interface teams should define acknowledgment semantics, retry behavior, and reconciliation procedures in their integration specifications.
Successful ACK Response: AA
An AA acknowledgment indicates application-level acceptance under the configured acknowledgment mode. The response includes the original message control identifier, allowing the sending system to correlate it with the discharge notification.
MSH|^~\&|EHR|MAIN|ADT_SYSTEM|HOSPITAL|20261012160001||ACK^A03^ACK|ACK30001|P|2.5
MSA|AA|MSG30001Application Error Response: AE
An AE acknowledgment indicates an application error during message processing. The response may include additional error details that help integration teams identify validation or encounter matching problems.
MSH|^~\&|EHR|MAIN|ADT_SYSTEM|HOSPITAL|20261012160002||ACK^A03^ACK|ACK30002|P|2.5
MSA|AE|MSG30001
ERR|||204^Unknown Key Identifier^HL70357|EApplication Rejection Response: AR
An AR acknowledgment indicates that the receiving application rejected the message. Rejections may involve unsupported events, interface restrictions, or other conditions requiring investigation before retransmission.
MSH|^~\&|EHR|MAIN|ADT_SYSTEM|HOSPITAL|20261012160003||ACK^A03^ACK|ACK30003|P|2.5
MSA|AR|MSG30001How to Correlate ACK Responses
The MSA-2 field contains the original message control identifier. Sending systems can use this value to associate an acknowledgment with the correct discharge notification and support reliable message tracking.
How to Handle Failed Acknowledgments
Failed acknowledgments require controlled error handling. Integration teams should distinguish temporary delivery failures from permanent validation errors and apply retries only when they will not create duplicate or incorrect updates.
Common HL7 ADT A03 Integration Errors and Troubleshooting
HL7 A03 integration failures often involve missing encounter identifiers, incorrect discharge timestamps, unsupported disposition codes, or mismatched patient records. These problems can prevent downstream applications from closing visits or cause incorrect encounter updates. Network interruptions and duplicate messages may introduce additional risks. Troubleshooting should examine the original message, acknowledgment response, interface mappings, and receiving application behavior. A documented HL7 parsing and data mapping process helps teams identify field-level inconsistencies and improve discharge reliability.
Missing or Incorrect Visit Number
A missing PV1-19 value can prevent reliable encounter matching. Establish documented handling rules and investigate ambiguous visits before allowing the receiving application to close an encounter.
Invalid Discharge Disposition Codes
Receiving applications may reject unsupported PV1-36 values. Maintain approved code mappings and validate source values against the destination system's accepted discharge disposition terminology.
Incorrect Discharge Date and Time
Malformed or inconsistent PV1-45 values can affect encounter status and reporting. Validate timestamp formats and apply agreed timezone handling rules before forwarding discharge information.
Duplicate Discharge Notifications
Retries may cause the same discharge event to arrive multiple times. Implement idempotent processing so repeated notifications do not trigger unnecessary downstream actions or duplicate updates.
Failed ACK and Message Delivery
Network interruptions and destination failures can prevent successful discharge processing. Review acknowledgment codes, transport logs, and retry behavior before correcting or safely replaying the message.
HL7 ADT A03 vs A01, A02, A04, and A08
HL7 ADT trigger events represent different patient administration activities. An A03 message communicates discharge or visit completion, while A01 indicates admission and A02 represents transfer. A04 commonly handles patient registration, and A08 communicates updates to existing patient information. These events share several message segments but have different effects on encounter status. Receiving applications must distinguish them to prevent incorrect visit creation, closure, or modification. Accurate event mapping is particularly important when multiple systems independently maintain encounter information and depend on timely patient administration notifications.
| Event | Meaning | Primary Action |
|---|---|---|
| A01 | Admit/Visit Notification | Start admitted encounter |
| A02 | Transfer a Patient | Update assigned location |
| A03 | Discharge/End Visit | End encounter |
| A04 | Register a Patient | Register patient encounter |
| A08 | Update Patient Information | Update existing information |
A03 vs A01: Discharge and Admission
A01 communicates an admission, while A03 communicates discharge or visit completion. Receiving systems should apply different encounter state transitions and avoid treating discharge notifications as new admissions.
A03 vs A02: Discharge and Transfer
A02 updates the patient's assigned location during an existing encounter. A03 indicates the encounter has ended. Confusing these events can leave patient visits open or close them incorrectly.
A03 vs A04: Discharge and Registration
A04 commonly represents patient registration, while A03 indicates discharge or visit completion. The events affect different stages of encounter management and require distinct downstream processing rules.
A03 vs A08: Discharge and Information Updates
A08 communicates patient information updates without necessarily changing encounter status. A03 represents an encounter-ending event and should be processed according to discharge-specific workflow requirements.
Best Practices for Reliable HL7 A03 Integration
Reliable HL7 A03 integration depends on correct encounter identification, consistent discharge timestamps, and dependable downstream processing. Healthcare organizations should define how receiving applications interpret discharge disposition, handle duplicate notifications, and recover from delivery failures. Interface specifications must also document which system owns encounter status and how conflicting updates are resolved. Security controls are essential because discharge messages may contain protected health information. Combining field validation, event sequencing, monitoring, and documented recovery procedures helps integration teams maintain accurate visit information across healthcare applications.
Validate Patient and Encounter Identifiers
Confirm that every discharge notification identifies the intended patient and encounter. Route ambiguous or missing identifiers for investigation instead of automatically closing potentially unrelated visits.
Standardize Discharge Disposition Mapping
Document source discharge disposition codes and their destination equivalents. Validate mappings whenever a healthcare application or vendor interface changes its supported terminology.
Handle Timestamps Consistently
Define how admission and discharge timestamps are represented, including applicable timezone conventions. Test date and time transformations to prevent incorrect encounter duration or reporting calculations.
Implement Reliable Recovery Procedures
Configure message persistence, acknowledgment handling, retries, and duplicate detection. Establish safe replay procedures so failed discharge events can be recovered without creating inconsistent encounter states.
Protect Patient Information and Monitor Interfaces
Secure message transmission, restrict endpoint access, and minimize sensitive data in operational logs. Monitor failed acknowledgments, processing latency, and reconciliation exceptions to maintain reliable discharge synchronization.
Frequently Asked Questions About HL7 ADT A03 Messages
HL7 A03 integration involves discharge events, encounter closure, patient matching, and downstream application updates. Healthcare developers and IT teams frequently need to understand which fields communicate discharge information, how A03 differs from related ADT events, and how to troubleshoot failed messages. The following questions address common implementation concerns using general HL7 v2 conventions. Actual processing requirements may vary by healthcare organization, vendor, HL7 version, and interface implementation guide.
What does A03 mean in HL7?
A03 is the HL7 v2 trigger event for Discharge/End Visit. It notifies connected applications that a patient's encounter has ended. The message includes patient identification and visit information so receiving systems can update encounter status and perform appropriate discharge-related workflows according to their interface specifications.
What is the difference between HL7 A01 and A03?
A01 communicates an admission event, while A03 communicates discharge or visit completion. An A01 notification typically establishes an admitted encounter, whereas A03 updates an existing encounter to reflect its completion. Receiving applications should distinguish these events to avoid incorrect visit creation or closure.
Which HL7 fields contain discharge information?
PV1-36 can contain discharge disposition, while PV1-45 identifies discharge date and time when populated. PV1-19 commonly identifies the affected encounter. Receiving applications should validate these values against the applicable HL7 version and vendor-specific interface specifications before applying discharge updates.
Can Mirth Connect process HL7 A03 messages?
Yes. Mirth Connect can receive, validate, transform, and route HL7 ADT A03 notifications. Developers can configure event filters, extract patient and visit identifiers, map discharge fields, and deliver messages to downstream systems. Production implementations should include acknowledgment handling, duplicate prevention, monitoring, and recovery procedures.
Does an A03 message delete a patient record?
No. An A03 message communicates discharge or visit completion rather than deletion of the patient's record. Receiving systems should update the appropriate encounter status while preserving patient information according to their data retention policies, application requirements, and applicable healthcare regulations.
How do you troubleshoot a failed HL7 A03 message?
Check MSH-9 for the correct discharge event, PID-3 for patient identification, PV1-19 for encounter matching, and PV1-36 and PV1-45 for discharge information. Review acknowledgment responses, mapping rules, and destination errors. Investigate missing identifiers, unsupported codes, duplicate messages, and timestamp inconsistencies.
Need Help With HL7 ADT A03 Integration?
Reliable discharge messaging helps healthcare organizations maintain accurate encounter information across EHRs, billing systems, laboratory applications, and care coordination platforms. Taction Software supports HL7 interface development, Mirth Connect configuration, discharge field mapping, and production troubleshooting. Our team can help investigate rejected discharge messages, improve encounter matching, and implement reliable acknowledgment and recovery procedures. Whether an organization is building new discharge interfaces or modernizing existing integrations, careful validation and operational monitoring help reduce data inconsistencies and support dependable healthcare workflows.
Custom HL7 Discharge Interface Development
We design and implement HL7 A03 interfaces based on source and destination requirements. Development includes message validation, discharge field mapping, encounter identification, and acknowledgment processing.
Mirth Connect Channel Development
Our engineers configure Mirth Connect channels for discharge message reception, filtering, transformation, and delivery. Implementations account for destination requirements, error handling, and production monitoring.
Discharge Message Troubleshooting
We investigate failed discharge notifications, incorrect encounter closure, unsupported disposition values, and timestamp mapping problems. Our approach focuses on identifying root causes and improving processing reliability.
Ongoing Integration Support
We help healthcare organizations maintain HL7 interfaces through monitoring, error alerts, mapping updates, and recovery procedures. These services support dependable discharge messaging as connected systems evolve.
Need help improving discharge message processing? Explore our HL7 interface messaging services.