HL7 ADT integration is the process of receiving, validating, and routing Admit, Discharge, and Transfer messages so that every downstream system (EMR, lab, pharmacy, billing) reflects the same patient state in real time. Three priorities determine whether an implementation survives its first month in production:

Support the core A-codes first, not the full event catalog
Parse MSH, PID, and PV1 fields reliably before touching anything else
Build acknowledgment handling and durable queueing before go-live, not after the first outage

ADT is the backbone feed for nearly every downstream clinical and financial system a facility runs. Get the plumbing wrong and you don’t get a bad report, you get patients who look admitted in one system and discharged in another.

Key Takeaways

Reliable HL7 ADT integration depends on prioritizing high-frequency events, validating identifier fields before anything else, and building durable, replayable transport rather than treating ACKs as sufficient error handling.

Point	Details
Prioritize the right events	Build A01, A04, A03, and A08 first since they cover most production volume, then A40 with extra validation.
Validate PID-3 rigorously	Missing assigning authority in PID-3 is a leading cause of patient-matching failures and mis-merges.
Treat A08 and A40 as high risk	These update and merge events break more production systems than admit or discharge messages ever do.
Build retry logic beyond ACKs	Differentiate connectivity failures (auto-retry) from data failures (manual review) to avoid retry loops.
Use ADT-ready automation	Smartadmissions gives post-acute facilities built-in EMR and ADT-aware referral integration without an in-house build.

ADT Fundamentals: Message Structure and Core Segments to Validate
Which ADT Trigger Events Should You Build First?
How Should Transport and Acknowledgments Work?
What Integration Architecture Actually Works in Production?
What Should Your Onboarding and Testing Checklist Include?
What Smart Admissions Has Learned Building ADT-Aware Intake
How Do You Handle Errors Beyond ACK/NACK?
What Security and Privacy Controls Does ADT Integration Require?
How Do You Manage HL7 Version Differences?
How Do You Scale ADT Processing for High Volume?
What Logging and Audit Trail Standards Should You Follow?
The Uncomfortable Truth About ADT Integration Projects
Get ADT-Ready Referral Automation Without Building the Pipeline Yourself
Sources

ADT Fundamentals: Message Structure and Core Segments to Validate

An ADT message carries patient demographic and encounter data using HL7’s Patient Administration standard, the message family responsible for admits, transfers, discharges, and the identity updates that ripple through every connected system. Each message is a pipe-delimited string of segments, and five of them determine whether your integration actually works.

MSH (Message Header): MSH-9 identifies the message type and trigger event, MSH-10 is the unique control ID you’ll use for deduplication, and MSH-11 flags test versus production traffic.
EVN (Event Type): carries the event timestamp, which matters more than the message’s arrival time when you’re reconstructing order later.
PID (Patient Identification): PID-3 holds the patient identifier plus assigning authority, PID-5 is the name, PID-7 is date of birth. PID-3 is the single field most likely to break patient matching.
PV1 (Patient Visit): PV1-2 gives patient class, PV1-19 the visit number, PV1-36 the discharge disposition.
MRG (Merge): only present on A40 events, and it’s where duplicate-record cleanup actually happens.

Expect Z-segments. Almost every source system bolts on site-specific extensions, and your parser needs to tolerate unknown segments without failing the whole message.

Which ADT Trigger Events Should You Build First?

Not all 40-plus ADT events matter equally. A practitioner reference covering the full A01 through A62 catalog found that A01, A04, A03, A08, and A40 appear in most hospital integrations, which means your first build cycle should ignore the long tail entirely.

Build in this order:

A01 (admit) and A04 (register) — highest volume, and the events every downstream system depends on for patient existence.
A03 (discharge) — closes the encounter; get PV1-36 disposition logic right here.
A08 (update patient information) — deceptively simple, and one of the two events that most often breaks production (more on that below).
A11/A12/A13 (cancel admit/transfer/discharge) — low volume but critical for reversing state cleanly.
A02 (transfer) and A05 (pre-admit) — moderate volume, straightforward logic once A01 works.
A28/A31 (add/update person info) — patient master file syncs, not encounter driven.
A40 (merge) — rare, but the single most dangerous event type to get wrong.

A40 requires special handling. The message carries both a surviving and a “merged from” patient ID in the MRG segment, and your system has to reassign every historical record tied to the retired ID without creating orphaned encounters. Never process an A40 asynchronously from your main identity table; race conditions here cause the ugliest data corruption in ADT pipelines.

Pro Tip: Build a dedicated validation rule that rejects any A40 missing MRG-1 (prior patient identifier) rather than silently merging on partial data. A bad merge is far harder to unwind than a rejected message.

For every event, validate PID-3’s assigning authority before anything else. Research on patient matching points to missing or inconsistent identifier qualifiers as a recurring driver of interoperability failures.

How Should Transport and Acknowledgments Work?

MLLP over TCP is still the standard transport for HL7 v2 ADT feeds, and most interface engines default to it. Keep production and test traffic on separate ports or separate MLLP listeners entirely; mixing them is how test data ends up in a live patient chart.

ACK handling has three outcomes:

AA (Application Accept) — message processed successfully; log and move on.
AE (Application Error) — message was malformed or failed a business rule; log the full payload and alert if the error rate spikes.
AR (Application Reject) — the receiver refuses the message outright; treat this as a connectivity or contract issue, not a data issue.

MSH-11 (processing ID) should drive routing logic so test messages never reach production listeners. For ordering, don’t trust arrival time. Use the EVN timestamp and a persistent queue keyed by visit number, since network retries and interface engine hiccups routinely deliver A03 before A01 for the same encounter.

What Integration Architecture Actually Works in Production?

A production-grade ADT pipeline follows a consistent shape regardless of vendor: inbound listener, validation, transformation, fan-out, and durable storage. The specifics matter more than the diagram.

Inbound listener — an MLLP listener (Mirth Connect and similar engines are common choices) accepts the raw message, sends the ACK immediately, then hands the payload to a validation stage. Don’t couple ACK timing to downstream processing success; a slow fan-out destination shouldn’t block your ACK to the source system.
Validation and transformation — check required segments and fields (MSH, PID-3, PV1-19 at minimum) before transformation. Reject early and reject loudly.
Fan-out routing — each destination (EMR, ancillary systems, an analytics platform) gets its own delivery thread and its own ACK tracking, so one slow or down destination never stalls the others.
FHIR bridging — most organizations don’t replace v2 ADT feeds, they layer FHIR on top. Mapping PID and PV1 into FHIR Patient and Encounter resources lets modern apps consume the same event stream without disrupting existing HL7 v2 flows.
Durable queueing and archival — persist every raw message before transformation. Replay capability and an audit trail aren’t optional extras; they’re what let you recover from a downstream outage without re-requesting data from the source.

A robust ADT pipeline needs per-destination ACK aggregation and a single dashboard that surfaces non-AA acknowledgments and queue-depth spikes. That visibility is what turns a multi-hour outage into a two-minute triage.

Open-source frameworks like intu illustrate this pattern well: listener, transform, route, archive, all as discrete, independently testable stages.

What Should Your Onboarding and Testing Checklist Include?

Testing an ADT feed properly means testing more than the happy path. MiHIN’s ADT Notifications onboarding process offers a useful model, covering legal agreements, transport setup, sample messages, mapping tables, and a defined data quality assurance (DQA) period before go-live.

Your checklist should include:

Signed data-sharing or connection agreements before any test traffic flows
Sample messages covering every event you plan to support, not just A01/A04/A03
A field-level mapping table reviewed by both sides of the interface
A DQA window (commonly two to four weeks) where production-volume test data is monitored before flipping to live

Test cases must go beyond basic admits. Run A08 updates against records already merged, A40 merges with historical encounters attached, out-of-order delivery, and duplicate message control IDs. The A08 and A40 event types cause a disproportionate share of production incidents precisely because teams test them last, if at all.

For ongoing operations, track latency against an SLA, alert on queue-depth growth, and keep replay capability live at all times.

The most common pitfall isn’t a missing feature. It’s treating every ADT event with the same validation logic and letting PID-3’s assigning authority go unchecked, which is how two different patients end up sharing one chart.

What Smart Admissions Has Learned Building ADT-Aware Intake

Building referral-to-admission automation across dozens of skilled nursing and post-acute EMR connections means encountering nearly every ADT quirk described above: inconsistent Z-segments, missing assigning authorities, mismatched processing IDs. Reusable mapping templates and a structured DQA phase for each new facility connection are what shorten go-live time and get referrals turning into occupied beds faster.

How Do You Handle Errors Beyond ACK/NACK?

An AE or AR response tells you a message failed. It doesn’t tell you what to do next, and that gap is where most homegrown interfaces fall apart.

Build a dead-letter queue for every rejected message, tagged with the specific validation failure, not just “error.” A message rejected for a missing PID-3 assigning authority needs different remediation than one rejected for a malformed timestamp, and lumping them into one error bucket makes triage slower than it needs to be.

Retry logic needs limits and backoff. A connectivity failure (AR from a down destination) warrants exponential backoff and automatic retry. A data failure (AE from bad PID formatting) should never auto-retry unchanged. Retrying malformed data just repeats the failure and clutters your logs.

Set a maximum retry count, then route to manual review. Three to five attempts over a defined window is typical; beyond that, an engineer needs to look at the message. Auto-retrying indefinitely is how a single malformed feed from one source system quietly fills a queue for days.

Track error rates by source system and by event type, not just in aggregate. A spike in A08 failures from one specific feed is a different problem than a general uptick, and a single dashboard view hides that distinction.

Finally, build a manual replay tool that lets an on-call engineer resubmit a corrected message without touching the original transaction log. Losing the ability to reconstruct exactly what was sent and when is the single most common reason ADT incidents take hours to resolve instead of minutes.

What Security and Privacy Controls Does ADT Integration Require?

ADT messages carry protected health information on every line: name, date of birth, diagnosis-adjacent visit data, insurance identifiers. HIPAA compliance isn’t a checkbox at the end of the build, it’s a design constraint from the first listener you stand up.

Encrypt in transit and at rest. MLLP over plain TCP has no built-in encryption, so most production deployments wrap it in a VPN tunnel or TLS-terminated proxy rather than exposing raw MLLP ports to any network beyond a tightly controlled segment. Message archives used for replay and audit need encryption at rest, not just access controls.

Authenticate every connection, not just every message. IP allowlisting alone isn’t sufficient for a feed carrying PHI; mutual TLS or a certificate-based handshake between interface engine and source system closes off a class of spoofing risk that IP filtering misses.

Limit access on a need-to-know basis. Not every downstream system needs the full ADT payload. A billing system consuming ADT data for census purposes doesn’t need clinical notes fields even if your source system happens to include them, and trimming payloads at the routing layer reduces your exposure surface.

Log access, not just message content. A HIPAA audit needs to show who touched a given patient’s ADT record and when, separate from the clinical audit trail your EMR maintains. Build that access log into your interface engine from day one; retrofitting it later means gaps in your compliance history you can’t fill in retroactively.

How Do You Manage HL7 Version Differences?

HL7 v2.x has shipped multiple versions since the 1980s, and v2.3, v2.5, and v2.5.1 are all still common in active production feeds. The core ADT structure holds steady across versions, but field optionality and segment cardinality shift enough to break naive parsers.

The most frequent compatibility issue is a field that’s optional in one version and required in another, or a segment that repeats in a newer version but appears once in an older one. NK1 (next of kin) is a common offender. Some source systems send one NK1 segment per message; others send several, and a parser built assuming a single instance will silently drop data.

Negotiate and document the version per connection, not per project. Every source system should have its version pinned in your mapping documentation, and your parser should branch logic by version rather than assuming a single schema across all feeds.

Build tolerance for unexpected segments and fields rather than strict schema rejection. A parser that fails hard on any unrecognized field will break the moment a source system upgrades its EMR and adds a field you didn’t anticipate. Log unknown segments for review instead of rejecting the whole message.

When bridging to FHIR, version differences compound. Mapping v2 ADT data into FHIR Patient and Encounter resources requires your mapping layer to normalize version-specific quirks before the FHIR transformation runs, not during it, or you’ll end up debugging two problems at once.

How Do You Scale ADT Processing for High Volume?

A mid-size hospital system can generate tens of thousands of ADT messages daily across all its feeds, and a multi-facility post-acute network isn’t far behind once you count every registration, transfer, and status update. Throughput planning has to happen before go-live, not after the queue backs up.

Horizontal scaling of your listener tier handles volume spikes better than a single beefy server. Multiple MLLP listener instances behind a load balancer, each writing to the same durable queue, let you add capacity without redesigning your pipeline.

Decouple ACK timing from downstream processing. The source system needs its ACK within seconds; your fan-out to five downstream destinations can take longer without anyone noticing, as long as the queue between ingestion and fan-out is durable. Conflating the two is the most common performance mistake in homegrown interfaces.

Batch where you can, stream where you must. Analytics and reporting destinations can often tolerate batched delivery every few minutes. Clinical systems that drive point-of-care decisions need near-real-time delivery, and treating both the same way either slows your clinical feeds or overwhelms your analytics pipeline with unnecessary immediacy.

Monitor queue depth as your primary early-warning signal, not error rate alone. A queue that’s growing but not yet erroring is the clearest sign that your consumer throughput has fallen behind your producer volume, and catching that trend early beats discovering it during a multi-hour backlog.

What Logging and Audit Trail Standards Should You Follow?

Every ADT message needs a permanent, unaltered record of what was received, when, and what happened to it. This isn’t optional infrastructure. It’s what makes a HIPAA audit, a patient-safety investigation, or a simple “why did this record change” question answerable in minutes instead of days.

Log the raw message before any transformation touches it. Store the original pipe-delimited payload alongside your parsed and transformed version, so you can always reconstruct exactly what the source system sent.

Capture a timeline per message: received timestamp, validation result, transformation output, each fan-out destination’s ACK status, and any retry attempts. A single message ID should let an engineer trace its entire lifecycle without cross-referencing five different systems.

Retain logs long enough to satisfy both operational and compliance needs. Operational debugging usually only needs 30 to 90 days, but compliance and audit requirements often call for longer retention. Check your organization’s specific policy rather than assuming a default window covers both purposes.

Separate access logs from processing logs. Who viewed a patient’s ADT record is a different audit question than how that record was processed, and conflating them makes both harder to query when a compliance officer or auditor asks a specific question.

The Uncomfortable Truth About ADT Integration Projects

Most ADT implementation guides spend their energy on the happy path: how A01 and A04 flow, how PID and PV1 map cleanly to a receiving system. That’s not where projects fail. They fail on the events nobody wants to prioritize, A08 updates and A40 merges, because those are the ones that touch existing data instead of creating new records.

The conventional advice to “start with admit and discharge, add complexity later” is backwards for exactly this reason. Every week you run production traffic without A08 and A40 handling built and tested is a week where identity drift and duplicate records accumulate silently, and by the time someone notices, the cleanup is a data remediation project, not a code fix.

If you take one thing from this guide, make it this: build your validation and merge logic before you build your dashboards. A pipeline that handles every A01 perfectly but corrupts one merge a month isn’t a working integration. It’s a liability with good uptime numbers. Prioritize PID-3 assigning authority checks and A40 handling in your first sprint, not your third.

— Harry

Get ADT-Ready Referral Automation Without Building the Pipeline Yourself

Smartadmissions gives skilled nursing and post-acute facilities a faster path to ADT-connected intake than building or maintaining a custom interface engine in-house. Facilities that need referral and admissions workflows synced to real ADT feeds, without staffing a dedicated integration team, get that connectivity built into the platform rather than assembled from scratch.

The platform’s EMR integration approach handles mapping templates and eligibility verification alongside referral intake, so admissions staff see accurate patient and encounter data the moment a referral arrives rather than waiting on a manual chart pull. For facilities evaluating what that integration actually improves in day-to-day census management, the bed occupancy strategies page breaks down the operational side in plain terms. If your admissions team is still bridging referral data and ADT updates by hand, request a demo to see how Smartadmissions handles that connection for you.

Sources

Consult HL7’s Patient Administration product section for formal ADT message definitions, MiHIN’s ADT Notifications guide for onboarding standards, and the NCBI interoperability chapter on HL7 v2 to FHIR bridging.

HL7 ADT Integration: 8 Rules That Prevent Production Failures