2.2 Information Systems, EHR/EDI & Downtime Procedures

Patient Access as the Front Door to the EHR

Every field a patient access associate keys into the registration screen becomes clinical, financial, and legal data the moment it is saved. Registration is not a form-filling task that happens "before" the real healthcare information systems work begins — it is the first write to the Electronic Health Record (EHR) for that encounter. Timely, accurate data entry at registration determines whether a lab result routes to the correct chart, whether an allergy alert fires for the right patient, and whether a claim bills correctly weeks later. A CHAA-certified associate is trained to understand that a rushed or careless registration doesn't just create paperwork problems downstream — it can delay care or contribute to a clinical error.

Consider a concrete chain of impact: a wrong date of birth entered at registration can cause an age-based clinical decision-support alert (a pediatric dosing check, for example) to fail silently, because the system is now calculating age against the wrong birth date. The clinician never sees a warning that should have fired. That single keystroke error, invisible at the registration desk, becomes a patient-safety gap two departments away. This is the core reason "timely input of data" is tested as its own blueprint sub-topic rather than folded into general accuracy — speed and correctness both matter, because a correct-but-late entry can miss the clinical window just as badly as a fast-but-wrong one.

Own Role in EHR, ADT & Ancillary Systems

Patient access typically works inside, or directly feeds, several connected systems:

• EHR (Electronic Health Record) — the longitudinal clinical chart clinicians document into
• ADT (Admission, Discharge, Transfer) system — tracks patient location, status, and movement in real time; often the same platform registration uses to create the encounter
• Ancillary systems — lab, radiology, pharmacy, and scheduling systems that receive patient and order data originating from registration

These systems don't share one database by magic — they are connected by an electronic data interface (EDI), a defined messaging standard (commonly HL7) that automatically pushes registration data such as demographics, insurance, and encounter type out to every downstream system the moment it is saved. This is why a single accurate registration populates the lab system, the pharmacy system, and the billing system simultaneously — and why a single inaccurate registration propagates that same error to every one of them at the same speed.

Downtime Procedures: Scheduled vs. Unscheduled

Systems fail. CHAA candidates are expected to know both categories of downtime and how registration keeps functioning through each:

During any downtime, registration switches to paper-based (manual) downtime forms — pre-printed face sheets, armband labels, and encounter forms kept on hand at every registration point specifically for this purpose. A well-stocked downtime kit typically includes a supply of pre-numbered downtime MRNs (so no two patients registered on paper accidentally share a number), blank consent and ABN forms, a manual insurance-card imprinter or photocopier, and a paper log for recording every temporary identifier issued. Patients are still registered, given a temporary or downtime-specific identifier, and cared for without interruption; the data simply isn't in the live EHR yet.

Post-Event Reconciliation

Once systems are restored, every paper downtime record must be entered or scanned back into the EHR and matched to the correct patient and encounter — this reconciliation step is just as procedurally important as the downtime response itself. Unreconciled downtime charts create the same duplicate-record and orphaned-data risks discussed in patient identification: a patient registered on paper during an outage who is never matched back to their permanent MRN effectively becomes a second, incomplete record. Reconciliation is typically owned jointly by patient access leadership and HIM, working from a downtime log that tracks every temporary identifier issued during the event until each one is closed out.

Mass-Casualty Registration

A mass-casualty incident (MCI) — a multi-victim event that overwhelms normal intake — requires an accelerated version of the same downtime discipline. Under a hospital's incident command structure, registration shifts to rapid, minimal-data intake: patients may arrive with only a triage tag and a temporary identifier (a "Doe" name plus a unique tracking number), full demographic and insurance collection is deferred, and the priority is getting every patient a trackable identifier fast enough to keep pace with triage. As in routine downtime, full reconciliation — matching every temporary MCI identifier to a verified permanent record — happens after the event, coordinated with HIM to prevent the same duplicate and overlay risks at a much larger scale.

Why These Two Sub-Topics Sit Together

Downtime response and mass-casualty registration are tested as one theme because they share the same underlying skill: keeping every patient trackable, and every record reconcilable, when the normal single-step "search EMPI, create or match one chart" workflow isn't available. A CHAA candidate who understands routine downtime procedures — issue a temporary identifier, keep a log, reconcile later — already understands the mass-casualty version at a larger, faster scale. The exam rewards recognizing that pattern rather than memorizing two unrelated procedures.