Admission Discharge Transfer (ADT) in Healthcare
About Admission Discharge Transfer (ADT)
When an ADT (Admission, Discharge and Transfer) event takes place, healthcare information systems generate an HL7 message known as an ADT message. Admission, discharge, and transfer is referred to as ADT. An ADT event, in its simplest form, is a significant occurrence that occurs whenever a patient is admitted, discharged, transported from one clinic/hospital to another, or to their home. ADT communications typically comprise patient demographic, diagnostic, and insurance information and are initiated via an EMR/EHR.
Securely sending sensitive data in long-term care can be difficult, largely because so much information is exchanged between healthcare professionals and carers. Data exchange has been improved by recent technological developments, such as ADT message systems, as data is now saved and delivered electronically rather than on paper.
Emergence of ADT in Healthcare
What is HL7?
For the interchange, integration, sharing, and retrieval of electronic health information, there is a set of standards, formats, and specifications known as HL7 (Health Level Seven). The organization that develops worldwide standards, HL7 worldwide, is responsible for creating the HL7 standards. Other standard-issuing organizations including the American National Standards Institute and the International Organisation for Standardisation have adopted these standards. A set of communication formats and associated clinical standards put together by HL7 specify the optimum way to present clinical data. Additionally, HL7 encourages international interoperability in healthcare IT by offering instructions on how to put its standards into practice.
Message in HL7
Electronic data is transferred across various healthcare systems using HL7 Messages. The segments of linked information that make up an HL7 message are always separated by carriage returns. Each HL7 message transmits details on a specific event, such the admission of a patient.
Benefits of ADT in Healthcare
The majority of clinical applications can receive important ADT messages, making it the most widely utilized HL7 communications type.
The Hospital Information Systems (HIS) or a registration application typically initiates ADT messages under the HL7 standard to notify ancillary systems that a patient has been admitted, discharged, transferred, or merged, that other demographic information about the patient has changed (name, insurance, next of kin, etc.), or that certain visit details have changed (patient location, attending physician, etc.).
When long-term care facilities use software systems with integrated ADT message systems, the HL7 standards are significantly easier to follow. Data exchange, integration, sharing, and information retrieval efficiency have all significantly increased in these organizations. This is because a reliable ADT nursing system classifies resident data into five clearly visible categories and provides a glimpse of a resident’s ADT records. The records are as follows –
- Census: Location, dates, quality of care, bed type, and bed hold information.
- Reimbursement information: About the insurance payers for each residence.
- Clinical data: Includes diagnosis, prescriptions, and allergies of residents/individuals.
- Contacts information: Point of contact of the guarantor, power of attorney, and next of kin.
- Additional details: This enables carers to include custom fields including referral source, veteran status, and interests. This makes it possible for carers to give residents more individualized care and to plan unique projects or activities for them.
PID (patient identity), PV1 (patient visit), and an additional IN1 (insurance) segment are some of the most crucial segments of an ADT message.There are 51 different types of ADT messages, which can be augmented with additional data to speed up and manage activities within a health system and help providers be prepared and provide high-quality treatment. These messages reflect diverse events including admission, discharge, transfer, registration, etc.
For instance, the insurance information included in the ADT messages can give providers useful information such as referrals, billing information, the location of medicine orders, and prescription validity.
Making ADT feeds useful for managing care
ADT feeds have become increasingly important in enhancing healthcare outcomes in the age of technology evolution as both patients and doctors have started to rely on electronic communication channels. ADT feeds include significant data that can unite departments, make information accessible, and store massive amounts of data in a safe, organized manner. ADT feeds can also be utilized for the following things besides what was mentioned above:
Improved care coordination
ADT communications give care teams the ability to monitor patients’ health and get in touch with them proactively because they offer organized information about a patient’s health.
Real-time notification
Enables clinicians and health coaches be informed about care encounters including hospitalisations, ED visits, and follow-up with discharge instructions by utilizing ADT messaging at the point of care in combination with machine learning.
Analysis of care quality
ADT messages from their databases can be taken out for different time periods and attributes, processed using scripting logic, and after that analyzed to create aggregated information regarding different factors like inpatient encounters, ED visits within 72 hours, readmissions within 30 days, etc.
Receiving a notification from ADT
Imagine that a patient arrives at the local hospital’s emergency room, where they fill out intake paperwork and identify their Primary Care Provider (PCP). An Admission Notification is triggered in the ER’s Electronic Health Record (EHR) while the patient is being roomed, and it is automatically forwarded to the patient’s PCP. The ER’s EHR receives the Admission Notification in real-time from the PCP’s EHR, which generates and sends back a clinical summary of the patient that includes their diagnoses, medications, allergies, most recent diagnostic test results, and other pertinent information. Within seconds, an ER Encounter is created in the patient’s chart. The PCP also receives notification of the admission in their EHR in-basket.
This transaction happened quickly—in less time than it took to room the patient—but it isn’t yet finished.
The clinician and other members of the ER care team have access to the patient’s EHR summary document before the patient is seen. The PCP considers the notice in the in-basket and decides to call the ER to give additional pertinent information about this patient. Before the patient is seen, the PCP intercepts the ER doctor and gives them the extra details. The ER practitioner is no longer starting from scratch when they enter the patient’s room since they have a breadth and depth of knowledge that will help them quickly choose the appropriate course of action and care for that specific patient.
Simply said, this ADT exchange prevents wastage of time and resources and enables the ER physician to immediately start offering knowledgeable care.
ADT Trigger Situations
The underlying cause of sending a message, such as “Patient has been admitted to the hospital,” “Patient address has changed,” or “Patient has moved from room 11 to room 20,” is known as a trigger event. A message is delivered to all systems with an interest in that specific sort of information as soon as a trigger occurs, enabling the receiving application to synchronize its database with the data as known by the message sender.
Examples of ADT trigger events include:
- A01: Admit notification – A visit with an inpatient has begun. The patient has been admitted and has been given a space (a room or a bed) to call home.
- A02: Transfer notification – From one place to another, a patient has been moved.
- A03: Discharge notification –The encounter has ended. The space that was previously allotted to the patient may now be used by another patient.
Data quality requirements
The following Data Quality Standards should be followed when sending ADT messages:
- Completeness – The data must be accessible for more than 90% of the records and must be sufficiently broad and deep to meet the business use cases of UnitedHealthcare.
- Consistency – The data should remain constant throughout time in terms of representation, substance, and formatting.
- Timeliness – The complete set of data should be accessible almost immediately after the event.
- Validity, Accuracy, and Correctness – These attributes should adhere to HL7 criteria and will be evaluated against them.
The list of HL7 message types most frequently used
ACK – General acknowledgement
ADT – Admit, Discharge, Transfer
BAR – Add/change billing account
DFT – Detailed financial transaction
MDM – Medical document management
MFN – Master files notification
ORM – Order (Pharmacy/treatment)
ORU – Observation result (unsolicited)
QRY – Query, original mode
RAS – Pharmacy/treatment administration
RDE – Pharmacy/treatment encoded order
RGV – Pharmacy/treatment give
SIU – Scheduling information unsolicited
An ADT Message Sample
Depending on the type of ADT event and the HL7 version, an ADT message’s segment composition varies. A typical HL7 version 2.4 ADT-A04, Patient Registration message is shown in the sample message below.
| Segment | Description |
|---|---|
| MH | Each message must contain a message header, also known as an MSH segment in an ADT, even if not every segment in an ADT message is required. The message's header includes details on the message's creation date and time, the trigger event type being transmitted, the sending system and location, the receiving system and location, and the HL7 message version. |
| EVN | Event type explains the incident that took place so that the message could be generated. This section, which determines where and when a message is sent based on the type of event, is an essential component of the data flow. |
| PID | Patient Identification gives demographic information on the patient is crucial for identification. |
| [{NK1}] | Next of Kin gives information on how to get in touch with the patient's nearest living relatives if necessary. |
| PV1 | This section contains facts regarding a patient's account or any visit-specific information, such as the servicing facility, treating physician, and visit ID. |
| [PV2] | This section, which conveys the admission reason, is a continuation of information relevant to the patient's visit. If a DG1 segment is present in the message, this segment is optional. The PV2 segment is necessary if the DG1 segment is absent. |
| [{OBX}] | Observation/Result gives Information regarding a single medical observation or outcome is contained in each OBX segment. More frequently, ORU (Observational Report) messages use this part. |
| [{AL1}] | This contains details on a patient's allergies, including the kind, reaction, and severity of the allergen. |
| [{DG1}] | In order to transmit specific diseases, signs, symptoms, anomalies, patient complaints, etc., this segment uses ICD coding standards and contains information regarding a patient's diagnosis. |
| [{PR1}] | This holds details about the several treatments that can be given to a patient, and it can be used again to convey details about multiple treatments. |
| [{ROL}] | The information required to add, update, correct, and delete from the patient record about staff and event engagement. |
| [{GT1}] | This portion contains information about the guarantor, or the individual who is financially in charge of the patient's account. When interacting with applications for insurance billing, this area is especially helpful. |
| [{IN1..2..3}] | This section contains the insurance policy coverage details required to generate patient and insurance bills, such as plan and provider identification. |
| *[ ] = optional, { } = repeating | |
Parsing ADT (Admit, Discharge, Transfer) Messages
The Electronic Health Record (EHR) system of a healthcare organization must include the ADT message system. Consequently, having a thorough understanding of ADT data signals and being able to interpret them will help healthcare professionals manage patient data throughout their organizations more effectively.
Reviewing a sample message will help us get started.
Step 1
The initial step involves recognizing the data format of the message. In this instance, the message is in the ER7 format, which is a specific HL7 message format utilizing delimiters for messages, segments, fields, components, and sub-components. This encoding method is commonly known as a “pipe delimited” message.
Step 2
Moving on to the subsequent step, it is crucial to identify the Header segment, which is located at the beginning of the message. Pay close attention to this segment as we proceed with the following steps.
Step 3
Next, we need to retrieve the Field Separator. The Field Separator can be found at the 4th character position from the left side of the first line. It can be represented as MSH.1.
Step 4
The field separator plays a crucial role in separating the segments within the message. To identify the separators, we look at the second field from the left, denoted as MSH.2. The retrieved values from the MSH segment are as follows:
MSH.2 gives the individual separators, the Component separator, the Repetition Separator, the Escaping Character, and the Sub-component Separator.
Step 5
Following that, we have the Message Type, Trigger Event ID, and HL7 version. These values can be obtained by utilizing the MSH segment.
Now, using the Component Separator after splitting the retrieved values –
Step 6
With the HL7 version information at hand, we can now proceed with message structure mapping. To accomplish this, we require the message structure codes for each ADT event. The table below provides the message structure codes for HL7 v2.4.
Abstract Message Structure Code
Trigger Events
ACK
Varies
ADR_A19
A19
ADT_A01
A01, A04, A08, A13
ADT_A02
A02
ADT_A03
A03
ADT_A05
A05, A14, A28, A31
ADT_A06
A06, A07
ADT_A09
A09, A10, A11, A12
ADT_A15
A15
ADT_A16
A16
ADT_A17
A17
ADT_A18
A18
ADT_A20
A20
ADT_A21
A21, A22, A23, A25, A26, A27, A29, A32, A33
ADT_A24
A24
ADT_A30
A30, A34, A35, A36, A46, A47, A48, A49
ADT_A37
A37
ADT_A38
A38
ADT_A39
A39, A40, A41, A42
ADT_A43
A43, A44
ADT_A45
A45
ADT_A50
A50, A51
ADT_A52
A52, A53, A55
ADT_A54
A54
ADT_A60
A60
ADT_A61
A61, A62
QRY_A19
A19
MESSAGE LOOKUP
This is the starting point from which you begin to examine groups and segments for a specific message.
For instance, when it comes to the ADT^A04 message, the trigger event is A04, and by referring to the message structure mapping table, you can observe that ADT_A01 is the message structure for A04.
The message structure comprises groups (PROCEDURE, INSURANCE, and ADT_A01). Each group contains segments within its elements. Additionally, each segment indicates its repeatability as minOccurs and maxOccurs. In our scenario, the PID segment within ADT_A01 is required to occur only once.
SEGMENT LOOKUP
Once you have completed the Message Lookup process, you will require additional information to determine the available fields within a segment row. For instance, the PID segment contains a field with the ID PID.5. However, in practice, there can be multiple instances of this field, but in our specific example, there is only one.
DATA FIELD LOOKUP
By examining the Field ID, you can obtain information about the description and datatype associated with it. The description is indicated as longName.
DATA TYPE LOOKUP
After acquiring the datatype for a specific field, you can proceed to split the field data using the Component separator and Sub-Component separator. By doing so, you can obtain the description corresponding to that particular datatype.
Step 7
Get the Grouping of the messages. By using the information from Step 6, the message segments are grouped like this –
A. PROCEDURE GROUP
B. INSURANCE GROUP
C. ADT_A01 GROUP or we can say the default group
Step 8
In the final step, we will demonstrate how to parse the PID.5 field, which appears as follows:
As you can observe, there are multiple component separators (^) at the end of the field and before the repetition separator (~), and there is no data within them. Therefore, the field can be represented in the following valid format:
Next, let’s refer to the DATA FIELD LOOKUP to determine the description of PID.5, which is “Patient Name,” and its datatype is XPN. This indicates that PID.5 contains information about the patient’s name. However, following the DATA TYPE LOOKUP, the XPN datatype can be further broken down.
Hence, XPN.1 data type is FN
According to the lookup, the datatype of each of these FN components (e.g., FN.1, FN.2, etc.) is ST, which means they are of the String datatype. In conclusion, we have successfully parsed the PID.5 field.
This process can be applied to any data field using Step 8, enabling us to parse the entire message.
HL7 ORM Message: What Is It?
In response to a trigger event, such as the placement of a new order, the cancellation of an existing order, modifications to an order, discontinuation, etc., information about a patient-specific order is transmitted using the HL7 Order Entry (ORM) message, a general order message. The ORM message only has one type, ORM001, unlike the majority of HL7 messages that have multiple. The MSH, PID (in the case of a new order), a notes and comments segment (NTE2), an observation (OBX), information about the patient visit (PV1 and PV2), the diagnosis (DG1), insurance information, clinical trial information (CTI), and billing information (BLG) are just a few of the segments and groups of repeating and non-repeating segments that make up each ORM message. ORM messages are one of the most frequently used message types in HL7 message formats.
An order is a “request for service” that is exchanged between apps, or possibly even within a single app (an app can send orders to itself). In HL7 messages, each segment and group of segments that make up an ORM message may be required, optional, repeated, or any combination of these in HL7 format.
Radiology and laboratory departments frequently employ HL7 ORM (Order entry) messages to enable orders. The communication includes details about a request for a good or service. These messages can be utilized as a teaching tool or in medical settings like emergency rooms.
Segments and groups of segments make up an ORM message, just like the HL7 message structure.
Figure showing contents Of An HL7 ORM Message ORM^001
- [ ] – Optional
- { } – Repeating
- [{ }] – Optional repeating
- No brackets – Required
The road ahead
Today, we find that providers may acquire a complete perspective on their patients with useful and actionable real-time information, such as with ADT messages, from health systems to accountable care organizations to integrated delivery networks. ADT feeds have the potential to make all of the stakeholders in a health system work together, going beyond admit, discharge, and transfer notifications and correct data interchange. As with any new data sharing initiative, there is a certain amount of fatigue and skepticism surrounding ADTs, but if they are fully implemented, we can expect lower readmission rates, better outcomes for high-risk populations, improved patient experiences, and perhaps a workable way to achieve 100% interoperability.
