Understanding Epic Prelude

What is Epic Prelude?

Epic Prelude is Epic's registration application. UI Health Care's Epic education pages describe it as the application used for registering patients and capturing their account and coverage information. Prelude is where medical record numbers are created, demographics are maintained, and guarantors and insurance coverage are attached before a visit is billed.

Prelude works alongside Cadence, Epic's scheduling application, and Epic's billing applications. Registration staff, schedulers and admitting teams all use Prelude activities, even if they think of their job as scheduling or check in.

Who uses Prelude in a hospital?

Prelude is used by anyone who creates or updates a patient's registration, which is a much wider group than the registration desk. Each group touches different fields, and each can introduce errors that travel downstream.

• Front desk and check in: Confirm demographics, coverage and the care team at each visit, often from the appointment desk.
• Admitting and bed management: Register inpatients and record admission details that start inpatient ADT events.
• Emergency and transfer intake: Register patients quickly, sometimes as anonymous patients when details are not yet known.
• Patient financial services: Maintain guarantor accounts, hospital accounts and complex coverage.
• Identity teams: Review records marked for merge and combine duplicates.

UI Health Care's material shows how detailed this gets in practice. The registration checklist can be personalized per user, staff can request access to a record another user has locked, and identity theft flags can be added when a patient asks for extra precautions.

What information does Prelude capture?

Prelude captures who the patient is, who pays for their care and the details of each encounter. Some of that information stays true across visits, and some belongs only to one encounter.

• Patient-level data: Contact information, emergency contacts, preferred language, interpreter needs and the patient care team, which apply across encounters.
• Identity: The medical record number, legal name, date of birth and patient photo.
• Guarantor accounts: The person or entity responsible for the bill, with notes such as financial counseling or self-pay status.
• Coverage: Insurance plans with member, subscriber and policy details, added to the right guarantor account.
• Hospital account: The billing record for an encounter, which every encounter must have at least one of.
• Special cases: Accident-related claim information, the Medicare Secondary Payer questionnaire and private encounter flags.

Every one of these can reach a downstream system. A wrong guarantor affects billing partners, a wrong preferred language affects patient messaging vendors, and a wrong primary care provider affects who receives event notifications.

How does Prelude handle patient identity and duplicates?

Prelude guards identity at the moment of registration. When a user creates a new medical record number, a potential duplicate records window shows existing patients with similar details, and the user should use the existing record if there is a match.

• New MRNs: Created only when the patient does not already exist in Epic.
• Mark for merge: If a likely duplicate is found after the fact, front-end staff mark it for merge so an identity team can review it.
• Restricted edits: At UI Health Care most users cannot change date of birth, and staff are told to create a new MRN and mark for merge when a birth date looks wrong.
• Name changes: Updated through a name edit window with a reason recorded.
• Audit trail: A registration audit report lists each change, who made it and when.

For integration teams, this means merges are a normal event, not an exception. Every system that stores Epic patient identifiers must be ready to receive a merge and move its own data to the surviving record, without losing anything that was attached to the retired one.

How does Prelude drive ADT feeds?

Prelude drives ADT feeds because registration events in Epic trigger outbound patient administration messages. Epic's open.epic catalog describes the Outgoing Patient Administration interface as informing external systems of new patients, demographic changes, visit events, registration details such as guarantors and coverage, allergies and bed status.

The catalog also notes the interface can be triggered from many applications, not only registration, and that it does not send final coded diagnoses or DRGs. Systems that need coded billing data must get it from a different feed.

• A04 register: An outpatient registration or check in creates a new visit.
• A01 admit: An inpatient admission.
• A02 transfer: A move between units or beds.
• A03 discharge: The end of a visit.
• A08 update: Changes to patient or visit information, the most frequent message in most feeds.
• A40 merge: Two patient records combined, with the surviving and retired identifiers.

These event types come from the HL7 v2 standard, and each organization configures which events it sends and to whom. Ask for the sending specification for your feed rather than assuming every event is included, and ask which segments carry guarantor, coverage and allergy details, since those vary between sites.

Can external systems send registration data into Epic?

Yes. Epic's catalog also lists an Incoming Patient Administration interface, which lets an external system create or update patient and visit information in Epic. It is used when another system is the source of registration, such as during a phased migration or for a service that registers its own patients.

Incoming registration needs careful ownership rules. If two systems can change the same address or coverage, they will eventually overwrite each other. Decide field by field which system is the source of truth, and keep the other one read-only for those fields.

Patient matching is the other half of inbound work. An incoming message must find the right existing patient or create a new one, and a weak match rule creates exactly the duplicates the potential duplicate window is meant to stop at the front desk. Agree the matching fields and the handling of near matches with the Epic identity team before go-live.

How do guarantors and coverage affect downstream systems?

Guarantors and coverage decide who is billed, so they matter to every revenue cycle partner. UI Health Care's material notes that every encounter must have a guarantor account and that coverage must sit on the appropriate guarantor account with member, subscriber and policy details.

• Eligibility tools: Need accurate payer and member identifiers to check coverage before the visit.
• Prior authorization: Depends on the plan attached to the encounter, not just the patient.
• Claims and statements: Go to the guarantor, who may not be the patient, such as a parent or a workers' compensation carrier.
• Terminated coverage: Must be ended in Prelude, not deleted, when it was once correct, so history stays accurate.

Many denials trace back to registration. A coverage entered with the wrong subscriber, or an accident visit registered without its claim information, causes rework that no billing system can fix later.

How do registration errors show up in other systems?

Registration errors show up as mismatched results, duplicate patients, misdirected messages and denied claims in systems far from the front desk. Because Prelude data flows out within moments, a single mistake can reach many systems before anyone notices it.

• Lab and imaging: A result that cannot be matched to an order because the patient was registered twice.
• Patient messaging: Reminders sent in the wrong language or to an old phone number.
• Care coordination: Event notifications sent to a primary care provider who no longer looks after the patient.
• Analytics: Duplicate patients that inflate counts and split one person's history across two records.
• Billing partners: Claims sent to a payer that no longer covers the patient.

Downstream teams can help by reporting these patterns back. A monthly list of unmatched messages and likely duplicates, shared with the patient access team, often fixes the root cause faster than any amount of interface logic.

What should integration teams plan for with Prelude data?

Plan for merges, updates, locked records and identifier choices. Most ADT integration bugs come from assuming that a patient's identity and details never change after the first message.

• Identifiers: Agree which identifier you store, such as the enterprise MRN, and which assigning authority it belongs to.
• Merges: Handle merge messages by moving data from the retired record to the surviving record, and test it with real cases.
• Update volume: Expect frequent update messages, and process them idempotently.
• Anonymous patients: Trauma or transfer patients may be registered with placeholder details and later updated or merged.
• Privacy flags: Respect private encounter and similar flags when your system shows patient lists or directories.
• Event notifications: Honour patient preferences recorded at registration, such as opting out of primary care notifications.

Build a test set from real registration scenarios with the Epic team: a new patient, a name change, a coverage change, a transfer, a merge and a correction. Run it every time either side changes its interface.

How Agnotic can help

Agnotic Technologies builds integrations that consume Epic patient administration feeds. We design patient matching and merge handling, map registration and coverage fields to your data model, and build test sets that cover the real-world events Prelude produces.

For revenue cycle and patient access products, we help connect to Epic in ways that keep registration data accurate on both sides, including field ownership rules for inbound updates. We also build the monitoring that flags unmatched messages and suspected duplicates, so problems reach the patient access team while they are still easy to fix.

Sources

• UI Health Care Epic Education: Prelude
• open.epic: HL7 v2 interfaces (Outgoing and Incoming Patient Administration)