HL7 ADT A28 Message: Add Person or Patient Information, Structure, Segments & Examples

The HL7 A28 message is an Admit, Discharge, Transfer (ADT) event used to add person or patient information to a healthcare application without necessarily creating an encounter. Known as ADT A28 or Add Person Information, it allows registration systems, enterprise master patient indexes, EHRs, and other connected applications to establish a patient identity record. Unlike an A01 admission notification or A04 registration event, A28 primarily concerns the creation of person-level information. Correct processing is important because duplicate or incorrectly matched patient records can affect clinical workflows and data integrity. This guide explains A28 structure, segments, examples, field mapping, Mirth Connect implementation, acknowledgments, and troubleshooting.

What Is an HL7 ADT A28 Message?

An HL7 ADT A28 message communicates the addition of person information to a receiving healthcare system. It belongs to the HL7 Version 2 patient administration event family and is commonly used in patient identity management and registration interfaces. The event can establish a person record without implying that the individual has been admitted, transferred, discharged, or assigned to an active encounter. Receiving applications typically use patient identifiers and demographic information to create the corresponding record. Understanding A28 alongside other HL7 ADT messages helps integration teams distinguish person-level registration from encounter-related events.

Purpose of the HL7 A28 Event

A28 communicates that a person record should be added to a receiving application. The event supports identity creation without requiring a corresponding admission or active patient visit.

When Is an ADT A28 Message Generated?

An A28 notification may be generated when a registration application or master patient index creates a new person record that must be shared with connected systems.

Which Healthcare Systems Receive A28 Messages?

EHRs, enterprise master patient indexes, patient registration platforms, and other healthcare applications may receive A28 messages to establish patient identity information.

How A28 Differs From Encounter Registration

A28 adds person information, while encounter-related events such as A01 and A04 communicate additional visit context. Receiving systems should not automatically create an inpatient admission from A28.

Why Accurate A28 Processing Matters

Incorrect A28 processing can create duplicate patient records, overwrite existing identities, or introduce inaccurate demographics. Reliable integration requires identifier validation, duplicate detection, and consistent mapping.

HL7 ADT A28 Message Structure and Segments

An HL7 ADT A28 message uses the segment-based format defined by HL7 Version 2. In HL7 v2.5, A28 uses the ADT_A05 message structure. Important segments include MSH, EVN, PID, and optionally demographic or administrative segments such as PD1, NK1, and PV1, depending on the implementation profile. MSH identifies the event and source, EVN records event information, and PID carries the primary person identifiers and demographics. Because A28 is a person-level event, visit information should not be assumed to represent an active admission. Receiving applications must follow the agreed interface specification.

MSH Segment: Message Header

MSH identifies the sending and receiving applications, message timestamp, control identifier, processing mode, and HL7 version. MSH-9 identifies A28 as the person information addition event.

EVN Segment: Event Information

EVN provides event metadata, including the recorded timestamp. Receiving applications may use it for audit tracking and determining when the person information was created.

PID Segment: Patient Identification

PID carries identifiers and demographics, including patient identifier, name, date of birth, sex, address, and contact details. Accurate PID mapping is central to A28 processing.

PD1 Segment: Additional Demographics

PD1 may carry additional patient demographic information supported by the interface profile. Receiving applications should map these fields only when relevant and appropriately defined.

NK1 and Other Optional Segments

NK1 may provide next-of-kin or associated-party information. Optional segments should be processed according to the implementation guide and should not trigger unrelated encounter workflows.

HL7 ADT A28 Message Example With Field Explanation

The following HL7 ADT A28 example illustrates a fictional person record being added to a receiving healthcare application. The message uses HL7 v2.5 conventions and identifies ADT^A28^ADT_A05 in MSH-9. PID-3 contains the person identifier, while PID-5, PID-7, and PID-8 provide demographic information. The example does not include an active encounter because A28 can communicate person-level information independently of admission or visit activity. Production systems should validate identifiers and check for existing records before creating a new person entry.

Complete HL7 ADT A28 Sample Message

MSH|^~\&|REGISTRATION|HOSPITAL|MPI|MAIN|20261013113000||ADT^A28^ADT_A05|MSG28001|P|2.5
EVN|A28|20261013112500
PID|1||P280001^^^HOSPITAL^MR||WILSON^JENNIFER||19910418|F|||123 OAK STREET^^CHICAGO^IL^60601^USA||^PRN^PH^^1^312^5550182

All patient information is fictional. The sample represents creation of person information, not a completed admission or patient transfer.

Explore each segment and its key fields:

MSH Segment Explained

MSH identifies REGISTRATION as the sender and MPI as the receiving application. ADT^A28^ADT_A05 identifies the trigger event and message structure, while MSG28001 supports tracking.

EVN Segment Explained

EVN identifies A28 as the event and records its timestamp. Integration teams can use this information to investigate when the person record notification was generated.

PID-3: Patient Identifier Explained

PID-3 identifies fictional patient Jennifer Wilson using identifier P280001. The assigning authority helps receiving applications distinguish this identifier from values issued by other systems.

PID-5, PID-7, and PID-8: Demographic Information

PID-5 contains the patient's name, PID-7 contains date of birth, and PID-8 contains administrative sex. These fields support person record creation and identity matching.

PID-11 and PID-13: Contact Information

PID-11 contains address information, while PID-13 contains telephone contact details. Receiving systems should validate and map these fields according to the destination's data model.

Important HL7 ADT A28 Fields and Mapping

Reliable HL7 A28 integration depends on accurate patient identifier and demographic mapping. MSH-9 identifies the person addition event, MSH-10 supports message tracking, and PID-3 identifies the person record. PID-5, PID-7, and PID-8 commonly provide name, date of birth, and administrative sex. Other PID fields may carry address, telephone, and additional identity information. Receiving applications should define which source system is authoritative for each field and how duplicates are handled. Clear HL7 v2 integration specifications help avoid inconsistent identity records.

MSH-9: Identifying the A28 Event

MSH-9 identifies A28 as the trigger event. Integration engines should route it through person creation processing rather than admission, discharge, or transfer workflows.

PID-3: Establishing a Unique Identity

PID-3 contains patient identifiers and assigning authorities. Receiving applications should use the complete identifier context to prevent duplicate records or collisions between identifier domains.

PID-5: Mapping Patient Names

PID-5 contains patient name components, including family and given names. Receiving applications should preserve name structure and handle repetitions according to the interface profile.

PID-7 and PID-8: Demographic Validation

PID-7 and PID-8 provide birth date and administrative sex information. These fields may support identity matching but should not replace reliable identifier-based validation.

PID-11 and PID-13: Address and Contact Mapping

PID-11 and PID-13 contain address and telephone information. Receiving applications should map them according to destination field definitions and data quality requirements.

How HL7 ADT A28 Messages Work in Healthcare Integration

An HL7 ADT A28 workflow begins when an authorized registration or identity management application creates a person record. The source system generates an A28 message containing identifiers and demographic information. An integration engine receives the message, validates its structure, and routes it to connected healthcare applications. Receiving systems determine whether the identifier already exists, apply duplicate detection rules, and create the person record when appropriate. The event does not automatically establish an inpatient admission or active encounter. Reliable processing requires consistent identifier mapping, acknowledgment handling, and audit records.

Step 1: A New Person Record Is Created

An authorized application creates a person record and assigns an identifier. The source system generates an A28 notification containing the relevant identity information.

Step 2: Validate the HL7 Message

The integration engine validates the A28 event, patient identifier, demographics, and message metadata. Invalid or incomplete notifications should enter an exception workflow.

Step 3: Check for Existing Patient Records

The receiving application checks whether the identifier already exists and applies approved identity matching rules. Ambiguous matches should not automatically create or overwrite records.

Step 4: Create the Person Record

If the identity is valid and does not conflict with an existing record, the destination creates the person entry using the mapped demographic fields.

Step 5: Acknowledge and Audit the Result

The receiving application returns an acknowledgment according to its HL7 configuration. Audit records document the source event, identity matching outcome, and record creation result.

How to Implement HL7 ADT A28 Messages Using Mirth Connect

Mirth Connect can receive, validate, transform, and route HL7 ADT A28 messages between registration systems, enterprise master patient indexes, EHRs, and other healthcare applications. A typical implementation receives an A28 message through an MLLP listener, checks the event type, extracts patient identifiers and demographics, and sends a person creation request to the destination. Unlike an admission interface, A28 processing should focus on person-level information. Production channels must also handle duplicate identifiers, repeating PID fields, incomplete demographic data, and conflicting identity records. Mirth Connect development services can support these requirements.

Configure the HL7 Source Connector

Create a Mirth Connect channel with an MLLP Listener or another supported transport. Configure the HL7 v2.x data type, secure connectivity, source authentication, acknowledgment settings, and message retention policies.

Filter HL7 ADT A28 Messages

Use a source filter to identify A28 notifications. Keep person creation events separate from demographic updates, patient merges, and encounter registration workflows.

Mirth Connect JavaScript filter:

var messageType =
    msg['MSH']['MSH.9']['MSH.9.1'].toString();

var triggerEvent =
    msg['MSH']['MSH.9']['MSH.9.2'].toString();

return messageType === 'ADT' &&
       triggerEvent === 'A28';

This filter identifies the message type. Production interfaces should also validate the sender, expected HL7 version, and supported message profile.

Extract Patient Identifiers and Demographics

Use a JavaScript transformer to extract patient identifiers, name components, date of birth, administrative sex, and message metadata. Validate mandatory fields before attempting record creation.

Mirth Connect JavaScript transformer:

function getValue(segment, field, component) {
    var fieldName = segment + '.' + field;
    var componentName = fieldName + '.' + component;

    return msg[segment][fieldName][componentName]
        .toString()
        .trim();
}

var patientId = getValue('PID', 3, 1);
var assigningAuthority = getValue('PID', 3, 4);
var identifierType = getValue('PID', 3, 5);

var familyName = getValue('PID', 5, 1);
var givenName = getValue('PID', 5, 2);
var dateOfBirth = getValue('PID', 7, 1);
var administrativeSex = getValue('PID', 8, 1);

var messageControlId = getValue('MSH', 10, 1);
var eventTimestamp = getValue('EVN', 2, 1);

if (!patientId || !assigningAuthority) {
    throw new Error(
        'A28 missing patient identifier or authority'
    );
}

if (!messageControlId) {
    throw new Error(
        'A28 missing message control identifier'
    );
}

var person = {
    identifier: patientId,
    assigningAuthority: assigningAuthority,
    identifierType: identifierType,
    familyName: familyName,
    givenName: givenName,
    dateOfBirth: dateOfBirth,
    administrativeSex: administrativeSex,
    eventTimestamp: eventTimestamp,
    messageControlId: messageControlId
};

channelMap.put(
    'personData',
    JSON.stringify(person)
);

This example reads the first PID-3 identifier and PID-5 name. Production implementations should support repeating identifiers, complete assigning-authority components, optional demographics, and the destination's validation rules.

Transform A28 Into a Person Creation Request

Create a destination-specific JSON payload containing patient identifiers and demographics. The destination should perform an identity lookup before creating a new record.

Example JSON transformation:

var person = JSON.parse(
    channelMap.get('personData')
);

var createPersonRequest = {
    eventType: 'A28',
    action: 'createPersonIfNotExists',

    patient: {
        identifier: person.identifier,
        assigningAuthority:
            person.assigningAuthority,
        identifierType:
            person.identifierType,

        name: {
            family: person.familyName,
            given: person.givenName
        },

        dateOfBirth: person.dateOfBirth,
        administrativeSex:
            person.administrativeSex
    },

    sourceEvent: {
        messageControlId:
            person.messageControlId,
        timestamp:
            person.eventTimestamp
    }
};

channelMap.put(
    'jsonPayload',
    JSON.stringify(createPersonRequest)
);

The JSON payload is illustrative and is not a standardized HL7 API. A destination must implement identity matching and duplicate prevention before creating the person record.

Configure Duplicate Detection and Error Routing

Check whether the patient identifier already exists before creating a new record. Route ambiguous matches, missing identifiers, and validation failures to an exception queue for investigation.

HL7 ADT A28 ACK Message Examples and Error Handling

HL7 acknowledgment messages allow sending applications to determine whether an A28 notification was accepted or rejected. A typical acknowledgment contains MSH and MSA segments, with ERR providing additional error details when necessary. In original acknowledgment mode, AA indicates application acceptance, AE indicates an application error, and AR indicates rejection. For person creation interfaces, the acknowledgment agreement should define whether acceptance means the message was validated, the patient record was created, or the event was queued for further processing. Reliable correlation helps prevent duplicate person records during retries.

Successful ACK Response: AA

An AA acknowledgment indicates application-level acceptance under the configured acknowledgment mode. MSA-2 references the original A28 message control identifier.

MSH|^~\&|MPI|MAIN|REGISTRATION|HOSPITAL|20261013113001||ACK^A28^ACK|ACK28001|P|2.5
MSA|AA|MSG28001

Application Error Response: AE

An AE acknowledgment indicates an application processing error. Missing identifiers, invalid demographic fields, or identity matching failures may prevent successful processing.

MSH|^~\&|MPI|MAIN|REGISTRATION|HOSPITAL|20261013113002||ACK^A28^ACK|ACK28002|P|2.5
MSA|AE|MSG28001
ERR|||101^Required field missing^HL70357|E

Application Rejection Response: AR

An AR acknowledgment indicates that the receiving application rejected the message. Unsupported event types, unauthorized sources, or invalid message profiles may cause rejection.

MSH|^~\&|MPI|MAIN|REGISTRATION|HOSPITAL|20261013113003||ACK^A28^ACK|ACK28003|P|2.5
MSA|AR|MSG28001

Correlate Acknowledgments With Person Creation

MSA-2 references the original message control identifier. Integration teams use it to associate acknowledgment responses, retry attempts, and destination processing outcomes with the corresponding A28 notification.

Prevent Duplicate Creation During Retries

A missing acknowledgment does not necessarily mean record creation failed. Before retrying, check the destination's processing status and apply idempotency controls to prevent duplicate patient records.

Common HL7 ADT A28 Integration Errors and Troubleshooting

HL7 A28 integration problems commonly involve duplicate patient identifiers, incorrect assigning authorities, incomplete demographics, and confusion between person creation and encounter registration. A receiving application may reject an A28 message because the identifier already exists or because required fields do not satisfy its validation rules. Other failures occur when patient identifiers are mapped without their issuing authorities or when destinations automatically create encounters. Troubleshooting should examine the original HL7 message, PID field mappings, identity matching results, acknowledgment responses, and destination processing rules. Accurate HL7 parsing and data mapping helps reduce these issues.

Duplicate Patient Identifier

The destination may already contain the identifier supplied in PID-3. Verify whether the message is a retransmission, an existing record, or a genuine identifier conflict.

Missing or Incorrect Assigning Authority

A patient identifier may be unique only within its issuing organization. Validate PID-3 assigning-authority components before creating or matching person records.

Incomplete Demographic Information

Missing names, birth dates, or other required fields may cause destination validation failures. Define mandatory data requirements in the interface specification rather than assuming every demographic field is populated.

A28 Incorrectly Creates an Encounter

A28 concerns person information and does not automatically imply admission or active visit registration. Remove mappings that create encounters unless the destination's approved workflow explicitly requires them.

Out-of-Sequence A28 and A31 Messages

An update event may arrive before the corresponding person creation notification. Receiving applications should reconcile the identity history rather than silently overwriting or duplicating records.

HL7 ADT A28 vs A31, A04, A01, and A40

HL7 patient administration events distinguish person creation, person information updates, visit registration, admission, and patient identifier merging. A28 adds person information, while A31 updates person information. A04 registers a patient for a visit, and A01 communicates an admission or visit notification. A40 merges patient identifiers. These events may contain similar PID segments, but their purposes differ. Receiving applications should use the event type and agreed implementation profile to determine whether to create a person record, update demographics, establish an encounter, or reconcile identifiers.

A28 vs A31: Person Creation and Update

A28 adds person information, while A31 updates an existing person record. Receiving applications should distinguish record creation from demographic modification to avoid duplicate identities.

A28 vs A04: Person Creation and Visit Registration

A04 communicates patient registration associated with a visit. A28 focuses on person-level information and does not necessarily establish an active encounter.

A28 vs A01: Identity Creation and Admission

A01 communicates admission or visit information. A28 adds a person record without automatically changing inpatient status, assigning a bed, or creating an admission.

A28 vs A40: Creation and Identifier Merging

A40 communicates the merging of patient identifiers, while A28 introduces person information. Identity creation should not automatically consolidate existing patient records.

Best Practices for Reliable HL7 A28 Integration

Reliable HL7 A28 integration requires consistent identifier management, duplicate prevention, and careful handling of demographic information. Healthcare organizations should document which application is authoritative for person creation and how receiving systems match existing identities. Interfaces should validate patient identifiers, assigning authorities, and mandatory demographic fields before creating records. They should also handle duplicate messages, out-of-sequence updates, and incomplete information without creating unintended encounters. Secure transmission, controlled access, and appropriate audit records are essential because patient registration messages may contain protected health information.

Use Complete Patient Identifier Context

Match patient records using identifiers, assigning authorities, and identifier types. Avoid relying solely on patient names or dates of birth when creating new identities.

Prevent Duplicate Person Records

Check for existing identifiers before record creation. Route ambiguous identity matches to an approved reconciliation workflow rather than automatically creating another record.

Separate Person and Encounter Workflows

Treat A28 as a person information event. Do not automatically create an admission, visit, or bed assignment unless explicitly required by the destination's approved interface specification.

Handle Out-of-Sequence Messages

Account for A31 updates arriving before A28 creation messages. Use authoritative source data and reconciliation rules to prevent stale demographic values from overwriting newer information.

Maintain Security and Auditability

Use authenticated transport, appropriate access controls, and audit logging. Limit exposure of demographic information in operational logs and error notifications.

Frequently Asked Questions About HL7 ADT A28 Messages

HL7 A28 integration raises questions about person creation, patient registration, demographic mapping, and duplicate identity prevention. Healthcare developers often need to distinguish A28 from A01, A04, and A31 and understand which PID fields identify the patient. These distinctions matter when connecting registration systems, EHRs, and enterprise master patient indexes. The following answers address common technical concerns using HL7 Version 2 conventions. Actual message requirements depend on the source system, receiving application, and agreed implementation guide.

Need Help With HL7 ADT A28 Integration?

Reliable person information messaging helps healthcare organizations maintain accurate patient identities across registration systems, EHRs, and enterprise master patient indexes. Taction Software supports HL7 interface development, Mirth Connect configuration, patient identity mapping, and healthcare application integration. Our engineers can help organizations implement A28 processing, validate patient identifiers, prevent duplicate records, and establish dependable acknowledgment and monitoring procedures. Whether you are connecting a new registration platform or modernizing existing HL7 interfaces, accurate person creation workflows support consistent patient information across connected systems.

Custom HL7 Patient Registration Interfaces

We develop HL7 A28 interfaces based on source and destination requirements, including patient identifier mapping, demographic validation, duplicate detection, and acknowledgment handling.

Mirth Connect Channel Development

Our engineers configure Mirth Connect channels for patient identity notifications, including event filters, JavaScript transformations, secure connectivity, and exception management.

Enterprise Master Patient Index Integration

We help organizations connect patient registration systems, EHRs, and enterprise master patient indexes through controlled identity creation and update workflows.

Production Monitoring and Support

We support HL7 interfaces through monitoring, failure alerts, mapping updates, and reconciliation procedures that help maintain dependable patient administration messaging.

Need help with HL7 person information integration? Explore our HL7 interface messaging services to discuss your requirements.