Epic Prelude and Grand Central: Patient Registration

Epic Prelude and Grand Central are where every patient encounter begins – and where the data quality problems that cascade through clinical documentation, billing, and downstream systems originate. Most Epic implementation teams underinvest in registration and ADT build because it looks simpler than clinical modules. This article gives analysts, build specialists, and project leads the depth they need to configure Epic Prelude and Grand Central correctly across patient registration, EMPI management, ADT workflows, insurance verification, and bed management.

What Are Epic Prelude and Grand Central?

Epic Prelude is Epic’s patient registration and identity management module. It manages the creation and maintenance of patient records – demographics, insurance coverage, guarantor information, consent documentation, and patient identity matching. Every Epic encounter begins with a Prelude registration event, whether the patient is checking in for an outpatient appointment, presenting to the emergency department, or being admitted to an inpatient unit.

Grand Central is Epic’s bed management and patient placement module. It manages the inpatient bed lifecycle – bed requests, bed assignments, patient transport, environmental services (housekeeping), and the capacity dashboard that hospital administrators use to monitor census and throughput. Grand Central integrates directly with Prelude: when a patient is admitted from the ED or through a direct admission workflow, Grand Central manages the bed assignment that Prelude initiated.

The two modules are operationally distinct but technically coupled. Prelude owns the patient identity and the encounter record. Grand Central owns the physical bed assignment and the capacity workflow. ADT (Admit-Discharge-Transfer) events originate in Prelude and are reflected in Grand Central. When a patient transfers between units, Grand Central manages the physical placement and Prelude updates the encounter record. Together they are the foundation that every other Epic module – clinical documentation, pharmacy, laboratory, billing – depends on for correct patient identity and location data. The full Epic module context is in the Epic EHR Learning Hub.

Enterprise Master Patient Index (EMPI) and Identity Management in Epic Prelude

The Enterprise Master Patient Index (EMPI) is the patient identity matching system embedded in Prelude. Every time a patient registers, Prelude searches the EMPI for an existing record using a probabilistic or deterministic matching algorithm. The goal is to link every encounter for the same person to a single, definitive patient record – preventing duplicate records, fragmented medical histories, and the downstream errors that cascades through clinical and billing systems.

Matching Algorithm Configuration

Epic’s EMPI uses a weighted scoring algorithm across demographic fields. The matching score is the sum of weighted field matches across name (first, last, middle), date of birth, gender, address, phone number, Social Security Number (SSN), and medical record number (MRN). Field weights are configurable – SSN and date of birth typically carry the highest weight because they are the most stable and unique identifiers.

Build analysts configure matching thresholds – a score above the high threshold auto-links to an existing record, a score below the low threshold creates a new record, and a score in the middle range presents the registrar with potential matches for manual review. Getting the thresholds wrong has direct consequences: too strict produces false negatives (duplicate records for the same person), too loose produces false positives (different patients merged into the same record). A false positive is the more dangerous error – a merged record can result in a clinician seeing another patient’s allergies, medications, or lab results.

Duplicate Record Management and Overlay Prevention

Duplicate patient records are inevitable even with well-configured EMPI matching. Patients give different phone numbers, move, change names, or present without identification. Prelude includes a duplicate review workflow where an overlay team (patient identity management specialists or HIM staff) reviews flagged potential duplicates and merges or keeps separate records based on investigation.

Patient record overlay – incorrectly merging two different patients into one record – is a healthcare patient safety event recognized by The Joint Commission and ECRI. Build analysts must configure the overlay prevention controls in Prelude that require a supervisory approval step before any record merge is finalized. Auto-merge based on algorithm score alone, without human review for high-risk matches, is a patient safety risk that Prelude’s configuration must explicitly prevent.

Patient Registration Workflow and Build in Epic Prelude

Patient registration in Prelude follows a configurable workflow that collects demographic, insurance, and consent information. The registration workflow is built as a series of screens (activities) that the registrar completes in a defined sequence. Build analysts configure which fields are required versus optional, which fields trigger downstream workflows, and which screens apply to which encounter type.

Registration Activity Configuration

Prelude registration activities are the individual data collection screens in the registration workflow. Common activities include demographic information (name, DOB, address, phone, gender, race, ethnicity), insurance coverage entry, guarantor setup, emergency contact, consent documentation, and financial counseling flags. Each activity is configured with required fields, default values, field validation rules, and role-based visibility.

Different encounter types require different registration workflows. An ED walk-in registration at 2 AM needs to be as fast as possible – collecting only the minimum information needed to create the encounter, with additional data collected later. A pre-admission registration for a scheduled surgery the following week needs complete insurance verification, consent documentation, and financial clearance. Build analysts configure encounter-type-specific registration workflows that balance data completeness with operational speed.

Pre-Registration and MyChart Integration

Pre-registration allows patients to complete or update their demographic and insurance information before arriving at the health system – through MyChart or a patient-facing pre-registration questionnaire. When a patient completes pre-registration, their responses flow into Prelude and pre-populate the registration workflow for the registrar’s review and confirmation. Pre-registration reduces registration time at check-in and improves data accuracy because patients self-report their own information rather than having a registrar transcribe it.

Build analysts configure the pre-registration questionnaire content, the field mapping from pre-registration responses to Prelude fields, and the workflow that alerts registrars when a patient has completed pre-registration. The pre-registration data must be reviewed – not blindly accepted – because patients sometimes update information incorrectly (wrong insurance card number, outdated address). A pre-registration workflow that auto-updates Prelude without registrar review creates a data quality risk.

Race, Ethnicity, and Language (REL) Data Collection

CMS and the Office of Minority Health mandate the collection of standardized race, ethnicity, and preferred language data using OMB standards for race/ethnicity and ISO 639 for language codes. Prelude’s REL configuration must use the correct standard code sets. Health systems that submit quality data to CMS programs (IQR, OQR, MIPS) must report demographic data using these standards. Using free-text fields or non-standard codes creates data quality gaps that affect both population health reporting and regulatory compliance.

The preferred language field drives language interpretation service workflows. If a patient’s preferred language is Spanish, Prelude’s configuration should trigger interpreter availability alerts in the patient’s encounters and in the clinical documentation workflow. Build analysts must map the language code to the interpretation service workflow – not just collect the data field.

Insurance Verification and Real-Time Eligibility in Prelude

Insurance verification is one of the highest-value functions in registration. A patient whose insurance is not verified at the point of registration may receive services that are not covered, creating bad debt that is difficult to recover. Prelude integrates real-time eligibility verification through the HIPAA 270/271 transaction set – a 270 inquiry goes to the payer’s clearinghouse, and a 271 response returns the patient’s coverage details within seconds.

Real-Time Eligibility (RTE) Configuration

Real-time eligibility in Prelude is triggered automatically when a registrar adds or updates a patient’s insurance coverage. Prelude submits a 270 inquiry to the payer via the configured clearinghouse connection, receives the 271 response, and parses the benefit information into the patient’s coverage record. Build analysts configure the clearinghouse connection, the payer-specific eligibility trigger rules, and the 271 parsing logic.

271 response parsing is payer-specific. Different payers structure their benefit information in different loops and segments within the X12 271 format. A 271 from Medicare structures its benefit information differently than a 271 from a commercial plan. Build analysts must configure payer-specific parsing rules for each major payer relationship. An incorrectly parsed 271 may populate the wrong coverage dates, the wrong plan name, or miss deductible information entirely – creating downstream billing errors that are difficult to trace back to registration.

Coverage Verification Workflow and Financial Clearance

Coverage verification beyond RTE includes prior authorization checking, referral verification, and financial clearance for high-cost services. Prelude’s coverage verification workflow surfaces these requirements to the registrar and financial counselor at the time of registration. Build analysts configure which service types require prior authorization flags, which payer plans require referral documentation, and when the financial counseling workflow should be triggered (high estimated patient liability, uninsured, underinsured).

Financial assistance screening is a Prelude function that identifies patients who may qualify for charity care, Medicaid, or hospital financial assistance programs. Build analysts configure the screening questionnaire, the program eligibility logic, and the workflow that routes qualified patients to financial counseling. For federally qualified health centers and safety-net hospitals, this workflow is operationally central to their mission – getting it right matters as much as clinical workflows.

ADT Workflows: Admit, Discharge, Transfer in Epic Prelude

ADT (Admit-Discharge-Transfer) events are the lifecycle milestones of an inpatient encounter. In Epic, ADT events are initiated in Prelude and reflected across Grand Central, the clinical modules, and all downstream systems via HL7 ADT messages. Every ADT event changes the patient’s encounter status, location, and care team assignments – and triggers downstream system updates that clinical staff depend on for real-time information.

Admit Workflow Types

Transfer Workflow

Patient transfer between units generates an ADT A02 message and updates the patient’s location in every connected system – ADC cabinets, radiology, laboratory, the ED tracking board, and the Grand Central capacity dashboard. The transfer workflow in Prelude must be completed before the patient physically moves. If the ADT A02 is delayed because the nurse or unit secretary forgot to complete the transfer in Epic, downstream systems show the patient in the wrong location until the event is processed.

Build analysts configure the transfer workflow’s required fields – accepting unit, accepting bed, reason for transfer, care team handoff documentation. They also configure transfer notification rules – who receives an in-basket notification when a patient is transferred to their unit, and what information is included. Clinical documentation flows connect to transfer events – the EpicCare Inpatient ClinDoc guide covers how nursing handoff documentation integrates with the transfer workflow.

Discharge Workflow and Encounter Closing

Patient discharge generates an ADT A03 message that closes the inpatient encounter, releases the bed in Grand Central, and triggers billing to begin the claim generation process. The discharge workflow in Prelude includes discharge disposition documentation (home, skilled nursing facility, hospice, expired), condition at discharge, and follow-up instructions. Build analysts configure the discharge disposition code set – the standardized codes required by CMS for inpatient claims must be mapped to Prelude’s disposition options.

Discharge against medical advice (AMA) requires a specific documentation workflow. The patient must sign an AMA form, and the physician must document the discussion. Prelude’s AMA discharge workflow should require a physician attestation before the AMA discharge is processed – without this control, an AMA discharge can occur without the required documentation, creating a liability gap for the health system.

Grand Central: Bed Management and Patient Placement

Grand Central manages the inpatient bed lifecycle from the time a bed is requested through patient discharge and room cleaning. Its primary users are bed management coordinators, nursing supervisors, and hospital administrators who need a real-time view of bed availability, patient placement queue, and housekeeping status. Grand Central integrates with Prelude’s ADT workflow – when a patient is admitted or transferred, Grand Central manages the bed assignment.

Bed Request and Assignment Workflow

When an admit order is placed – from the ED, from a direct admit registration, or from a surgical case – Grand Central receives a bed request. The bed request includes the required bed type (telemetry, ICU, isolation, standard), the requesting unit or physician, and any clinical constraints (gender-specific unit, isolation precautions, fall risk bed near nursing station). Grand Central’s bed management coordinator reviews the request and assigns an available bed that meets the clinical requirements.

Build analysts configure the bed request form’s clinical constraint fields, the bed attribute data (bed type, isolation capability, telemetry availability) for every physical bed in the facility, and the routing rules that send bed requests to the correct bed management coordinator. A 500-bed hospital may have several bed coordinators managing different units or time-of-day shifts. Routing rules must match the operational model exactly.

Environmental Services (Housekeeping) Integration

Grand Central integrates with the housekeeping workflow to track room cleaning status. When a patient is discharged, Grand Central automatically flags the vacated bed as dirty and notifies environmental services. Housekeeping staff use Grand Central (or an integrated housekeeping mobile application) to accept cleaning assignments, document cleaning completion, and return the bed to available status. Build analysts configure the housekeeping notification workflow, the bed status lifecycle (occupied, vacating, dirty, cleaning, clean, available), and the integration with housekeeping mobile tools if used.

The time from patient discharge to bed available status is a key operational metric called bed turnaround time. Grand Central’s capacity dashboard tracks this metric in real time. Build analysts must ensure that the workflow transitions – dirty to cleaning to clean – require housekeeping staff to take an action in the system, not just be automatically time-stamped. Auto-stamping bed transitions produces inaccurate turnaround time data and undermines the capacity dashboard’s value.

HIPAA Privacy Configuration in Epic Prelude Registration

Registration collects Protected Health Information (PHI) at every encounter. HIPAA’s Privacy Rule governs how that information is collected, stored, used, and disclosed. Prelude’s privacy configuration controls which staff can access which patient records, which patients can restrict information sharing, and how patient directory information is managed. Build analysts configure these controls in coordination with the organization’s HIPAA privacy officer.

Facility Directory and Patient Visibility

The HIPAA facility directory allows hospitals to confirm a patient’s presence, general condition, and room location to callers who ask by name – unless the patient has opted out. Prelude’s facility directory configuration defines what information can be shared, under what circumstances, and who can access the directory inquiry workflow. Build analysts configure the opt-out process, the directory inquiry workflow, and the role-based access controls that prevent unauthorized staff from querying patient location information.

Sensitive patient designations – behavioral health, HIV/AIDS, substance use disorder, domestic violence, VIP – require additional privacy protections. For behavioral health patients, 42 CFR Part 2 (the federal regulation governing substance use disorder records) requires patient-specific consent before any disclosure, even to other treating providers within the same health system. Build analysts must configure 42 CFR Part 2 consent tracking in Prelude for organizations that operate substance use disorder treatment programs – this is a distinct legal requirement from standard HIPAA consent.

ADT Interface Build and Downstream System Integration

The ADT feed from Prelude is the most critical interface in any Epic implementation. Every downstream system that needs to know where a patient is or whether they are currently an active patient depends on ADT messages. Laboratory, pharmacy, radiology, bed management systems, ADC cabinets, external HIE networks, and patient notification platforms all receive ADT feeds. Getting the ADT interface configuration right is not optional – it is the prerequisite for every other integration working correctly.

ADT messages fire from Prelude through Epic Bridges via MLLP/HL7 v2. Each receiving system needs specific event types, specific PID segment content, and specific message timing. Build analysts configure the ADT outbound interface per receiving system – which events fire to which system, what the MSH sending/receiving application codes are, and which PID fields are populated. The most common ADT interface errors are incorrect MSH application codes (causing message rejection), wrong PID.3 MRN assigning authority (causing patient match failure), and missing PID.18 account number (causing billing system failures). Orders and CPOE workflows depend directly on correct ADT patient location data – the Epic EHR Orders and CPOE guide covers how order routing depends on patient location codes from Prelude.

HL7 FHIR Patient and Encounter Resources

Prelude patient and encounter data is also accessible through Epic’s HL7 FHIR R4 API. The Patient resource exposes demographics, identifiers, and contact information. The Encounter resource exposes encounter type, status, period (admit and discharge dates), and location. The Coverage resource exposes insurance plan and eligibility data. External applications – payer portals, HIE networks, population health platforms, and patient-facing apps – access this data through FHIR.

Under the ONC 21st Century Cures Act, health systems must provide patients with access to their encounter and demographic data through FHIR APIs without information blocking. This means Prelude data – patient demographics, encounter history, insurance coverage, care team assignments – must be accessible through Epic’s FHIR Patient Access API. Build analysts implementing Prelude must confirm that FHIR Patient resource configuration exposes the required data elements per the US Core Patient profile.

Testing and Validation Strategy for Prelude and Grand Central

Registration and ADT testing requires a different mindset from clinical module testing. The primary failure modes are data quality failures (wrong demographics, wrong insurance, wrong patient matched), workflow failures (required fields not enforced, wrong screens for encounter type), and interface failures (ADT messages not firing, PID fields wrong). All three categories require dedicated test scenarios.

EMPI matching validation requires test patients designed to exercise the matching algorithm at every score range: a clear match (same DOB, name, SSN), a clear non-match (different person entirely), and multiple middle-range scenarios that should present the registrar with a manual review prompt. Boundary-value matching scenarios – a patient with a slightly different name spelling or a transposed date of birth – are the most important tests because they expose threshold misconfiguration.

ADT interface testing must verify end-to-end that each ADT event in Prelude produces the correct message in every receiving system. Registering a patient must produce an A04 in the lab, the radiology system, and the ADC cabinet. Admitting a patient must produce an A01 with the correct bed assignment in Grand Central. Discharging must produce an A03 that closes the bed in Grand Central, triggers billing, and removes the patient from the ED tracking board. Teams experienced in BAT vs UAT methodology understand that registration BAT must include front-line registrars completing realistic registration workflows – not just IT analysts confirming field population.

Go-Live Planning and Common Registration and ADT Failures

Prelude and Grand Central go-live failures are often dismissed as “registration training issues” when they are almost always build and configuration issues. Registrars who cannot complete a registration workflow correctly are usually encountering a screen that does not match their operational workflow – not forgetting training. The Epic EHR Go-Live Support framework applies here with front-desk operational leadership added to the command center.

Roles, Certifications, and Career Path

Authoritative References

• HHS OCR – HIPAA Guidance on Hospital Facility Directories and Patient Information Disclosure
• HL7 FHIR R4 – Patient Resource and US Core Patient Profile for Registration Data Exchange

Downloads: Prelude and Grand Central Templates and Checklists