• Data lifecycle management for seamless source-to-destination data movement, next-gen analytics and AI integration.

          Advanced Data ETL, Reporting and Gen AI

          No-code data engineering
          Automated data transformation
          Enterprise-grade LLM

          An automated data orchestration and pipeline management platform.

          An AI-powered, enterprise-ready Gen AI platform for internal teams.

          Healthcare Data Management

          Parsing engine and interactive mapper.

          Precision parsing, mapping, transformation & health data analytics.

        • Data lifecycle management for seamless source-to-destination data movement, next-gen analytics and AI integration.

          Advanced Data ETL, Reporting and Gen AI

          No-code data engineering
          Automated data transformation
          Enterprise-grade LLM

          Custom, integrated predictive layer.

          Automated data movement for faster time-to-insights.

          Consolidated data for improved accessibility.

          Structured data for reporting, analytics and model training.

        • Data lifecycle management for seamless source-to-destination data movement, next-gen analytics and AI integration.

          Advanced Data ETL, Reporting and Gen AI

          No-code data engineering
          Automated data transformation
          Enterprise-grade LLM

          Visual insights to help you optimize your data for analytics.

          Insider knowledge into proven methodologies and best data practices.

          Explore how businesses leveraged our data solutions to their advantage.

          Keep up with the latest trends to scale faster and outwit competition.

        • Data lifecycle management for seamless source-to-destination data movement, next-gen analytics and AI integration.

          Advanced Data ETL, Reporting and Gen AI

          No-code data engineering
          Automated data transformation
          Enterprise-grade LLM

          We are a bold team supporting bold leaders like you ready to adopt and migrate to new technologies.

          Discover the essence of our tech beliefs and explore the possibilities they offer your business.

          Unlock your business potential by leveraging Gen AI and capitalizing on rich datasets.

          Lead your business to new heights and scale effortlessly with expert guidance along the entire customer journey.

  • Join the team

Admission Discharge Transfer (ADT) in Healthcare

About Admission Discharge Transfer (ADT)

ADT Feature Image

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

Years of information transmission delays and erroneous data entry by healthcare professionals resulted in a poor continuity of care, disorganized data records, ineffective data gathering procedures, and subpar patient care.  Then, in 1987, a non-profit organization called Health Level Seven International (HL7) created a thorough framework to direct healthcare practitioners with a global set of standards so that electronic health information can better assist clinical activities.  The main goal of HL7 is for carers to securely access and use resident health data whenever and wherever they are required, ultimately creating standards that enable data interoperability for healthcare providers.  Utilizing patient demographic and administrative data across various healthcare systems is made possible through ADT data messages. It is a method for keeping track of patients’ travels inside hospitals and other healthcare facilities.  But does following a patient’s whereabouts really manage the treatment given?  Yes, it is the answer. Effective care coordination is essential in the healthcare industry to guarantee that every patient receives the highest quality treatment. This entails keeping account of every stage of the scenario that the healthcare provider handles, including admission, discharge, and transfer.

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 –

  1. Census: Location, dates, quality of care, bed type, and bed hold information.
  2. Reimbursement information: About the insurance payers for each residence.
  3. Clinical data: Includes diagnosis, prescriptions, and allergies of residents/individuals. 
  4. Contacts information: Point of contact of  the guarantor, power of attorney, and next of kin. 
  5. 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.

The EHR automatically sends a Discharge Notification message to the PCP when the patient is released from the ER. The PCP’s nurse receives the message since it is concerning a discharge.  The nurse notices the patient requires a follow-up visit and some extra services to prevent the patient from going back to the ER when they receive the Discharge Notification in their EHR mailbox.  A follow-up visit is arranged with the nurse’s assistance. The admission notification that their shared patient was admitted to the ER and the discharge notification that they were released home both immediately contacted the home health agency that has been providing care for this patient.  To make sure the patient is doing well, they make plans for a nurse to check on them the next day.

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.
ADT Trigger Situations

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.

An ADT Message sample
MHEach 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.
EVNEvent 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.
PIDPatient 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.
PV1This 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.

Parsing ADT Message

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.

Parsing ADT Step 2

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.

Parsing ADT Step 3

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:

Parsing ADT Step 4

MSH.2 gives the individual separators, the Component separator, the Repetition Separator, the Escaping Character, and the Sub-component Separator.

Individual 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.

Parsing ADT Step 5

Now, using the Component Separator after splitting the retrieved values –

Parsing ADT Step 5(2)

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






A01, A04, A08, A13






A05, A14, A28, A31


A06, A07


A09, A10, A11, A12












A21, A22, A23, A25, A26, A27, A29, A32, A33




A30, A34, A35, A36, A46, A47, A48, A49






A39, A40, A41, A42


A43, A44




A50, A51


A52, A53, A55






A61, A62




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.

Message 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.

Segment 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 Field 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.

Data Type Lookup

Step 7

Get the Grouping of the messages. By using the information from Step 6, the message segments are grouped like this –


Procedure Group


Insurance Group

C. ADT_A01 GROUP or we can say the default group

ADT_A01 Group

Step 8

In the final step, we will demonstrate how to parse the PID.5 field, which appears as follows:

Step 8 (1)

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:

Step 8 (2)

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.

Step 8 (3)

Hence, XPN.1 data type is FN

Step 8 (4)

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.

Still, facing difficulty in parsing your ADT messages? Let our experts guide you.

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.

Related blogs and articles