Patient Registration in Healthcare: Process Steps, EMPI Matching, HL7 v2 ADT Messaging, X12 270/271 Eligibility, and EMTALA Rules

Patient registration (also referred to as patient access or hospital admissions registration) is the foundational front-end clinical and administrative workflow through which a healthcare facility identifies a patient, resolves their enterprise medical record number (MRN), verifies health plan coverage, collects mandatory regulatory notices, and broadcasts an encounter notification across clinical information systems. Whereas a patient intake form captures self-reported clinical history and symptom questionnaires, the patient registration process establishes the legal identity, encounter context, and financial clearance record that anchor all downstream orders, laboratory specimens, radiology studies, and billing claims.

In hospital informatics and healthcare revenue cycle management (RCM), registration errors—such as duplicate MRN creation, transposed subscriber IDs, or missing coordination-of-benefits screening—are the single largest source of downstream patient safety near-misses (wrong-chart orders) and initial claim denials.

What Is Patient Registration in Healthcare? The 6-Step Patient Registration Workflow

Whether executed via pre-arrival online patient registration portals, self-service check-in kiosks, or bedside registration in acute care, the standard patient registration workflow follows six sequential steps:

1. Step 1 — Enterprise Master Patient Index (EMPI) Identity Search & Resolution: Before creating a new record, the registrar or digital check-in engine queries the Master Patient Index (MPI / EMPI) using deterministic and probabilistic matching algorithms (or the HL7 FHIR $match operation) across USCDI v3/v4 demographic traits (legal name, date of birth, sex, current/historical address, phone number, and government photo ID). This prevents both duplicate records (one patient assigned two MRNs) and overlay records (two patients merged under a single MRN).
2. Step 2 — USCDI Demographic & Guarantor Data Collection: Captures or updates standardized patient demographics—including OMB race and ethnicity categories, preferred spoken and written language, interpreter need, emergency contact (next of kin), and financial guarantor relationship.
3. Step 3 — Real-Time Insurance Eligibility & Benefits Verification (ASC X12 270/271): Transmits an automated HIPAA ASC X12N 270 (Eligibility, Coverage, or Benefit Inquiry) transaction to the clearinghouse or payer and parses the real-time X12N 271 response to confirm active coverage dates, plan network status, copayment, coinsurance, remaining deductible, and prior authorization requirements.
4. Step 4 — Coordination of Benefits & Medicare Secondary Payer (MSP) Screening: For Medicare beneficiaries, federal regulations (42 CFR § 411.20 and the CMS Medicare Secondary Payer Manual, Chapter 3) require hospitals to complete the Medicare Secondary Payer Questionnaire (MSPQ) at every inpatient admission and outpatient encounter (or within 90 days for recurring series encounters) to determine whether Working Aged group health coverage, End-Stage Renal Disease (ESRD), Disability, Workers’ Compensation, Black Lung, or No-Fault/Liability insurance is primary to Medicare.
5. Step 5 — Regulatory Consents & Financial Disclosures: Obtains the General Consent for Medical Treatment, Assignment of Benefits, HIPAA Notice of Privacy Practices (NPP) written acknowledgment (45 CFR § 164.520), Good Faith Estimate (GFE) for uninsured/self-pay patients under the No Surprises Act (45 CFR § 149.610), and—when a specific Medicare service is expected to be denied as not medically necessary—an Advance Beneficiary Notice of Noncoverage (ABN, Form CMS-R-131).
6. Step 6 — Encounter Creation & HL7 ADT Broadcast: Assigns an encounter/visit number (Characterized as Inpatient, Observation, Emergency, or Outpatient/Recurring) and transmits real-time HL7 Version 2 ADT messages to downstream clinical modules.

HL7 Version 2 ADT Messaging and FHIR R4 Mapping in Hospital Registration

In hospital health IT architecture, the Patient Administration System (PAS) or core EHR registration module acts as the authoritative source of patient and visit context. Every registration action triggers a standardized HL7 Version 2.x ADT (Admit, Discharge, Transfer) message over MLLP or REST interfaces to synchronize the Laboratory Information System (LIS), Radiology Information System (RIS / PACS), pharmacy system, and dietary/bed-management boards:

HL7 v2 Trigger Event	Event Name	Key HL7 v2 Segments	Equivalent HL7 FHIR R4 Resources	Clinical & Operational Trigger
ADT^A04	Register a Patient	MSH, EVN, PID, PD1, NK1, PV1, GT1, IN1, IN2, DG1	Patient, Encounter (class = AMB or EMER), Coverage, RelatedPerson	Fired when an outpatient, ambulatory surgery, or Emergency Department patient arrives and is registered without an inpatient bed admission.
ADT^A05	Pre-Admit a Patient	MSH, EVN, PID, PV1, GT1, IN1	Encounter (status = planned), Appointment	Fired during scheduled pre-registration (e.g., 3–7 days before elective surgery) to initiate financial clearance and pre-admission testing.
ADT^A01	Admit / Visit Notification	MSH, EVN, PID, NK1, PV1, PV2, IN1, DG1	Encounter (class = IMP, status = in-progress)	Fired when a patient is formally admitted to an inpatient hospital bed under an attending physician’s admission order.
ADT^A08	Update Patient Information	MSH, EVN, PID, PV1, GT1, IN1	PUT /Patient/[id], PUT /Encounter/[id], PUT /Coverage/[id]	Fired whenever a registrar updates address, name spelling, insurance subscriber ID, or attending provider on an active encounter.
ADT^A28 / ADT^A31	Add / Update Person Information	MSH, EVN, PID, PD1, NK1	POST or PUT /Patient	Updates enterprise person-level demographics in the EMPI independent of a specific visit or encounter.
ADT^A40	Merge Patient Identifier List	MSH, EVN, PID, MRG	Patient.link (type = replaced-by)	Fired by Health Information Management (HIM) when merging a duplicate MRN (`MRG` segment) into the surviving enterprise MRN.

Emergency Department Patient Registration and EMTALA Compliance Rules

In hospital emergency departments (EDs), patient registration is strictly constrained by the federal Emergency Medical Treatment and Labor Act (EMTALA, 42 U.S.C. § 1395dd) and CMS Conditions of Participation at 42 CFR § 489.24(d)(4) and § 489.20(r)(3):

• Quick-Reg (Mini-Registration) at Triage: When an individual presents to the emergency department requesting examination or treatment, registration staff perform a rapid Quick Registration (Quick-Reg) capturing only the patient’s name (or a standardized trauma alias if unresponsive), age/DOB, sex, chief complaint, and arrival timestamp for the mandatory EMTALA Central Log (42 CFR § 489.20(r)(3)) so clinical triage and diagnostic ordering can begin immediately.
• Prohibition on Delaying the Medical Screening Examination (MSE): Under 42 CFR § 489.24(d)(4)(i)–(iv), a hospital may not delay providing an appropriate Medical Screening Examination or necessary stabilizing treatment in order to inquire about the individual’s method of payment or insurance status, nor may ED staff seek prior authorization from a health plan before the MSE is completed and stabilization is underway.
• Bedside Financial Registration Post-MSE: Full insurance card scanning, X12 270/271 eligibility verification, MSPQ administration, and copayment/financial counseling are conducted at the bedside only after the qualified medical person (QMP) has completed the Medical Screening Examination and confirmed that the patient is clinically stable.

Patient Registration in Clinical Research Trials (EHR Research Flags & Billing Routing)

In academic medical centers conducting interventional clinical trials, patient registration directly controls research billing compliance (preventing the routine billing of sponsor-paid items to Medicare or commercial payers). When a registered patient is enrolled in a clinical study, the Clinical Trial Management System (CTMS) sends an HL7/FHIR research subject message to the EHR registration module, attaching a study-level Research Encounter Flag and routing professional and technical charges through the research billing review workqueue prior to X12 837 claim generation.