Patient Access Workflows

This document defines six core workflows for the Patient Access module. Each workflow includes process steps, actors, decision points, integration hooks, exception handling, and the paperless transformation achieved by the HIS.

Regulatory context: UAE Federal Decree-Law No. 45/2021 on Personal Data Protection (UAE PDPL), MOH licensing requirements, DHA eClaimLink and DOH eClaims (Shafafiya) standards for eligibility and authorisation, and alignment with NABIDH (Dubai) / Malaffi (Abu Dhabi) interoperability policies. All workflows must ensure minimum necessary use of patient data, explicit consent where required, and secure transmission per ADHICS / TDRA cybersecurity guidance.

WF-PAC-001: Insurance Eligibility Verification

Process Flow

Actor: Registration Clerk, System (automated)
Trigger: Patient registration, appointment booking, check-in, or scheduled batch re-verification (e.g., 72 hours before service)
Pre-conditions:

• Patient exists in patients (from ehr-patient-mgmt)
• Appointment and/or encounter exists in appointments / encounters (from scheduling)
• Payer and plan configured in payers, insurance_plans (from policy-contract-mgmt)
• Patient’s insurance details captured or available from prior visit
• Patient consent for electronic eligibility checks recorded per UAE PDPL (in EHR/consent module)

1. Registration Clerk opens the Eligibility Verification screen (SCR-PAC-001) from the patient context (MRN / Emirates ID 784-1990-1234567-1).
2. System pre-populates payer, plan, member ID, group ID, and Emirates ID from latest insurance record; clerk updates or adds new insurance if needed.
3. System validates mandatory fields (payer, plan, member ID, patient DOB, Emirates ID) and displays any validation errors inline.
4. Clerk selects check type (real-time / batch / day-of-service recheck) and request source (registration, scheduling, portal, automated).
5. System creates an eligibility_checks row (status = pending, request_source, check_type, check_datetime, linked patient_id, payer_id, plan_id, and optionally encounter_id / appointment_id).
6. System determines correct integration endpoint based on facility emirate and payer:
   - Dubai → DHA eClaimLink (INT-PAC-001)
   - Abu Dhabi → DOH eClaims / Shafafiya (INT-PAC-002)
   - Other / self-pay / direct payer → configured endpoint from Payer Eligibility Endpoints master data.
7. System sends real-time eligibility request to the selected endpoint with required payload (member ID, Emirates ID, payer/plan, service date, facility, provider).
8. Decision: Did the payer respond within timeout (e.g., 20 seconds)? - Yes → proceed to step 9.
   - No → go to step 12.
9. System receives eligibility response (raw XML/JSON) and stores it in eligibility_responses.response_raw linked to check_id.
10. System parses key benefits: active/inactive, effective/termination dates, co-pay amount/percentage, deductible total and met, coinsurance, annual max and remaining, plan limitations; populates structured fields in eligibility_responses (e.g., is_eligible, copay_amount, deductible_met).
11. System updates eligibility_checks.status to success and associates the latest successful check to the encounter/appointment (e.g., encounter_details.financial_clearance_status = 'eligibility_verified' via internal API to billing-claims and scheduling).
12. Decision: If timeout or error from payer:
    • If retry allowed (e.g., up to 3 attempts) → system retries with exponential backoff and logs attempts.
    • If retries exhausted → set eligibility_checks.status = 'error' and store error code/message.
13. System displays coverage summary to clerk: eligibility status, co-pay, deductible remaining, coinsurance, key limitations (e.g., network-only, pre-auth required).
14. Decision: Is patient ineligible or coverage expired for date of service?
    • No (eligible) → proceed to step 16.
    • Yes (ineligible) → step 15.
15. Clerk informs patient that coverage is inactive/invalid, offers alternatives (other insurance, self-pay, financial counseling referral) and records outcome; system flags encounter as not financially cleared and may create a task for Financial Counselor.
16. For eligible patients, system calculates preliminary patient responsibility indicators (not a full estimate) and sends summary to billing-claims (INT-PAC-005) for downstream use.
17. System schedules an automatic re-verification job for the day of service if the latest successful check is older than 72 hours; job will create new eligibility_checks entries with request_source = 'auto_reverify'.

Data Modified:

• eligibility_checks — INSERT (new check), UPDATE (status, error info, linkage to encounter/appointment)
• eligibility_responses — INSERT (parsed response per check)
• encounter_details (in scheduling module) — UPDATE (financial clearance flags via internal API)
• billing_pre_claim / equivalent (in billing-claims) — UPDATE/INSERT (eligibility summary, if such table exists in that module)

Mermaid Flowchart

Decision Points

1. Mandatory fields complete?
   - If not, user cannot proceed; system highlights missing fields (e.g., missing Emirates ID, member ID).
2. Payer response within timeout?
   - If no, system retries up to configured limit; after that, marks check as error and prompts for manual follow-up or provisional self-pay.
3. Is coverage active for date of service?
   - If yes, mark encounter as eligibility-verified.
   - If no, flag encounter as not cleared and prompt for alternate insurance or financial counseling.
4. Check older than 72 hours before DOS?
   - If yes, auto re-verification scheduled.
   - If no, existing verification considered valid.

Integration Points

Exception Handling

• Validation failures:
• Missing or invalid Emirates ID, member ID, or DOB → inline error messages; no external call made.
• Payer timeout / connectivity error:
• Automatic retries with increasing intervals; if all fail, status set to error, visible banner “Eligibility system unavailable – treat as self-pay or retry later”; audit log entry created.
• Payer returns technical error (invalid format, unknown member):
• Store error code in eligibility_responses.payer_response_code; display human-readable message; allow clerk to correct data and resubmit.
• Data privacy / consent:
• If consent for electronic eligibility not present, system prompts clerk to obtain verbal/written consent and record it before sending; if patient refuses, eligibility check is skipped and encounter flagged as self-pay per facility policy.
• Auto re-verification failure on day of service:
• System flags encounter in a “Financial Clearance Exception” work queue; supervisor can override hold based on facility policy.

Paperless Transformation

Remaining Paper Touchpoints: Printed eligibility summary may be given to patient on request; otherwise fully digital.

Inputs and Outputs

Inputs:

Outputs:

Post-conditions:

• eligibility_checks row exists with status success, error, or pending
• If successful, encounter is flagged as financially cleared in scheduling
• If unsuccessful, encounter flagged as not financially cleared; task may be created for Financial Counselor
• Auto re-verification job scheduled if check is >72 hours before date of service

SLA and Timing

State Transition Diagram

The eligibility check manages a distinct lifecycle from creation through resolution.

WF-PAC-002: Prior Authorization Management

Process Flow

Actor: Authorization Specialist, Physician
Trigger: Service ordered that requires prior authorization per payer rules (e.g., high-cost imaging, elective surgery)
Pre-conditions:

• Order exists in CPOE / clinical module with CPT and ICD-10-AM codes
• Eligibility verification completed or attempted
• Coverage rules available from coverage_rules (policy-contract-mgmt) indicating auth requirement
• Patient consent for sharing clinical documentation with payer recorded per UAE PDPL

1. System receives new order from CPOE or scheduling and checks coverage_rules via INT-PAC-006 to determine if prior auth is required for the payer/plan, service, and diagnosis.
2. Decision: Does the service require prior auth? - No → system records “no auth required” and ends workflow.
   - Yes → proceed to step 3.
3. System creates a draft prior_authorizations record with auth_status = 'pending_submission', linking patient_id, encounter_id, payer_id, service_codes (CPT), icd10_codes, and requesting_provider_id.
4. Authorization Specialist opens the Prior Authorization Worklist (SCR-PAC-002) and selects the new case.
5. System pre-populates the Authorization Request Form (SCR-PAC-003) with patient info, service codes, diagnosis, and referring/requesting provider details.
6. Specialist reviews and attaches required clinical documentation (lab results, imaging reports, clinical notes) from EHR; system stores references or documents in prior_auth_requests.clinical_documentation (e.g., document IDs).
7. Specialist selects submission channel (DHA eClaimLink, DOH eClaims, direct payer portal, or manual upload) based on payer configuration.
8. System validates that all mandatory fields and documents required by payer policy are present (e.g., recent MRI report, conservative therapy notes).
9. System creates a new prior_auth_requests row with submission_datetime, submission_channel, and links it to auth_id.
10. For electronic channels (eClaimLink / DOH eClaims), system submits structured auth request payload including clinical justification; for portal-only payers, system may generate a PDF or summary for manual upload but still tracks status.
11. Decision: Did the payer respond synchronously (immediate approval/denial) or is it pending review?
    • Immediate response → step 12.
    • Pending → step 13.
12. System updates prior_authorizations.auth_status to approved or denied, sets auth_number, approved_date/denied_date, valid_from, valid_to, and approved_units; notifies ordering physician and updates billing-claims with auth number.
13. If pending, system sets auth_status = 'under_review' and populates prior_auth_requests.payer_response with acknowledgement; case remains on worklist with “days pending” counter.
14. Decision: Payer requests peer-to-peer review or additional information?
    • If yes → Specialist coordinates with Physician to schedule call, records peer_review_scheduled = true and notes in payer_response.
    • If no → wait for final decision.
15. When final decision received (via electronic response or manual update), Specialist updates prior_authorizations with status, dates, units, and any conditions; system automatically links auth to relevant scheduled procedures and claims.
16. If denied, system notifies Physician and allows documentation of appeal plan or alternative treatment; subsequent appeal submissions are tracked as additional prior_auth_requests rows linked to same auth_id.

Data Modified:

• prior_authorizations — INSERT (initial record), UPDATE (status, auth number, dates, units)
• prior_auth_requests — INSERT (each submission/response cycle), UPDATE (payer_response, response_datetime, peer_review_scheduled)
• encounter_details (scheduling) — UPDATE (auth status flags)
• billing_claims / equivalent (billing-claims) — UPDATE (auth number, auth status)

Mermaid Flowchart

Decision Points

1. Auth required?
   - Based on payer, plan, CPT, ICD-10-AM, and facility rules from coverage_rules.
2. All payer-required fields/docs present?
   - If not, system blocks submission and lists missing items (e.g., “Upload last 3 months physiotherapy notes”).
3. Immediate response vs under review?
   - Some payers auto-approve low-risk services; others always pend.
4. Peer review or additional information requested?
   - If yes, additional tasks and documentation steps are triggered.

Integration Points

Exception Handling

• Missing clinical documentation:
• System prevents submission and lists required documents; Specialist can save draft but not submit.
• Payer system downtime:
• System queues auth request; status queued_for_submission; retries periodically; visible in worklist with “Payer offline” indicator.
• Mismatch between order and auth (e.g., CPT changed):
• System detects change and prompts Specialist to update auth or request amendment; logs in prior_auth_requests.
• Data privacy:
• If patient has restricted sharing of certain sensitive diagnoses (per UAE PDPL and facility policy), system masks those details and may require explicit consent override before submission.

Paperless Transformation

Remaining Paper Touchpoints: Some payers may still issue paper letters; these can be scanned and attached, but core process is digital.

Inputs and Outputs

Inputs:

Outputs:

Post-conditions:

• prior_authorizations record exists with final status (approved, denied, or under_review)
• If approved, auth number linked to encounter and available for claims
• If denied, physician notified and appeal workflow available
• All submissions and responses stored for audit

SLA and Timing

State Transition Diagram

The prior authorization manages a distinct lifecycle from identification through resolution.

WF-PAC-003: Referral Management

Process Flow

Actor: Registration Clerk, Referring Physician, Specialist
Trigger: Patient needs referral for specialist consultation or facility-to-facility service, and payer requires referral per plan rules
Pre-conditions:

• Patient and referring provider exist in patients and providers
• Specialist provider exists or is created as external provider record
• Payer and plan known; coverage rules indicate whether referral is required
• Relevant clinical indication (ICD-10-AM) available from EHR

1. Referring Physician creates a referral order in CPOE or provides an external referral letter; system captures key details (reason, target specialty, urgency).
2. System checks coverage_rules for the patient’s payer/plan to determine if a referral is required for the requested specialist/service.
3. Decision: Is referral required by payer? - No → system records “referral not required” and may still create an internal referral for coordination; workflow ends.
   - Yes → proceed to step 4.
4. Registration Clerk or Physician opens the Referral Management screen (SCR-PAC-004) and initiates a new referral.
5. System pre-populates patient, referring provider, suspected specialist provider (or specialty), payer, and ICD-10-AM code; user selects specific specialist provider if not already specified.
6. Clerk enters service_type (from Referral Type Codes master data), authorized_visits requested, and proposed valid_from / valid_to dates.
7. System creates a referrals record with status = 'pending_submission', authorized_visits, used_visits = 0.
8. If payer requires referral submission (often embedded in prior auth), system either:
   - Submits referral details as part of prior auth (integration with WF-PAC-002), or
   - Sends a standalone referral notification via payer portal/API if supported.
9. System updates referrals.status based on payer response: approved, denied, or under_review; stores referral_number if provided.
10. System notifies patient and specialist (via SMS/email/portal) of referral approval and shares key details (visits authorized, expiry date) in line with NABIDH/Malaffi policies.
11. At each specialist visit check-in, system checks for active referral: status = 'approved', within validity dates, and used_visits < authorized_visits.
12. Decision: Is there an active referral with remaining visits?
    • Yes → increment used_visits and allow visit; update referral record.
    • No → flag “referral missing/expired” and prompt for new referral or payer exception.
13. System generates alerts when valid_to is approaching or used_visits is close to authorized_visits to allow proactive renewal.

Data Modified:

• referrals — INSERT (new referral), UPDATE (status, referral_number, used_visits, validity dates)
• appointments / encounters (scheduling) — UPDATE (referral linkage, referral status flags)

Mermaid Flowchart

Decision Points

1. Referral required by payer?
   - Based on payer rules; some plans require referrals only for out-of-network or certain specialties.
2. Active referral with remaining visits?
   - If not, system blocks or warns at check-in depending on facility policy.
3. Referral handled standalone vs embedded in prior auth?
   - Some payers treat referral as part of auth; system must follow payer-specific configuration.

Integration Points

Exception Handling

• Specialist not yet in provider master:
• System allows creation of external provider record with minimal required data; flags for credentialing follow-up.
• Payer denies referral:
• System records denial reason; notifies Physician; allows documentation of appeal or alternative plan.
• Referral expired mid-treatment:
• System alerts specialist office and patient; new referral workflow can be initiated.
• Data privacy:
• For sensitive referrals (e.g., mental health), system may restrict visibility to authorised roles only per UAE PDPL and facility policy.

Paperless Transformation

Remaining Paper Touchpoints: External referring providers may still send paper letters; these can be scanned and attached.

Inputs and Outputs

Inputs:

Outputs:

Post-conditions:

• referrals record exists with status (approved, denied, or under_review)
• If approved, referral linked to relevant appointments and available for claims
• Visit counter (used_visits) initialized and tracked at each specialist check-in
• Expiry alerts configured for proactive renewal

SLA and Timing

WF-PAC-004: Patient Cost Estimation

Process Flow

Actor: Financial Counselor, Registration Clerk
Trigger: Patient requests cost estimate or is scheduled for high-cost procedure (e.g., surgery, MRI)
Pre-conditions:

• Patient and planned services known (from scheduling or CPOE orders)
• Payer and plan identified; recent eligibility check available or in progress
• Contracted fee schedules and coverage rules available from policy-contract-mgmt
• Patient informed that estimate is not a guarantee of payment (per payer and facility policy)

1. Financial Counselor opens the Cost Estimator screen (SCR-PAC-005) for a specific patient and upcoming encounter.
2. System retrieves planned services (CPT codes) from scheduling/CPOE and displays them in the estimator.
3. System fetches contracted rates for each CPT from policy-contract-mgmt (fee schedules) based on payer, plan, and facility.
4. System retrieves latest eligibility_responses for the patient’s payer/plan to determine deductible remaining, co-pay, coinsurance, and annual max remaining.
5. Counselor can add or remove planned services (e.g., additional anaesthesia, implants) and adjust quantities.
6. System calculates estimated_charges (sum of contracted rates) and applies coverage logic to compute:
   - estimated_payer_payment
   - estimated_patient_responsibility
   - Breakdown: deductible applied, co-pay, coinsurance.
7. System creates or updates a cost_estimates record with all calculated fields, estimate_datetime, valid_until (e.g., 30 days), and links to patient_id, encounter_id, payer_id.
8. Counselor reviews the estimate with the patient, using bilingual EN/AR display; system can generate a patient-friendly PDF or portal view.
9. Patient acknowledges the estimate verbally or electronically; system records acknowledged_by_patient (boolean) and user/time of acknowledgment.
10. Decision: Does patient request a payment plan or financial assistance?
    • No → workflow ends with estimate stored.
    • Yes → system creates a task or direct link to Financial Counseling workflow (WF-PAC-005).
11. If services change before procedure (e.g., additional CPTs added), system detects changes and recalculates the estimate, creating a new version in cost_estimates or updating existing record with versioning.

Data Modified:

• cost_estimates — INSERT (new estimate), UPDATE (recalculation, acknowledgment, validity)
• financial_counseling_records — INSERT (if counseling triggered)

Mermaid Flowchart

Decision Points

1. Use existing eligibility vs require new check?
   - If last eligibility is older than facility threshold (e.g., 30 days), system may prompt to re-verify before estimating.
2. Patient requests payment plan/assistance?
   - If yes, triggers WF-PAC-005.
3. Services changed after estimate?
   - If yes, system recalculates and flags prior estimate as superseded.

Integration Points

Exception Handling

• Missing fee schedule for CPT:
• System flags missing configuration; Counselor can enter a manual estimate with reason; record flagged for finance follow-up.
• Outdated eligibility data:
• System warns user and suggests running eligibility verification; user can proceed with disclaimer.
• Patient disputes estimate:
• Counselor can add notes in cost_estimates and adjust assumptions (e.g., out-of-network vs in-network) with clear documentation.

Paperless Transformation

Remaining Paper Touchpoints: Patient may request printed estimate; otherwise digital via portal or email.

Inputs and Outputs

Inputs:

Outputs:

Post-conditions:

• cost_estimates record exists with all calculated fields and validity period
• Patient acknowledgment recorded (if obtained)
• If services change, estimate is recalculated and versioned
• If patient requests assistance, financial counseling task created

SLA and Timing

WF-PAC-005: Financial Counseling

Process Flow

Actor: Financial Counselor
Trigger: Patient identified as self-pay, high estimated out-of-pocket (OOP), uninsured, underinsured, or referred from eligibility/cost estimation workflows
Pre-conditions:

• Patient account and outstanding balances available from billing-claims
• Cost estimate or existing high balance identified
• Facility financial assistance policies and Financial Assistance Programs master data configured
• Patient consent to discuss financial details recorded per UAE PDPL

1. Financial Counselor opens the Financial Counseling screen (SCR-PAC-006) for a specific patient.
2. System retrieves patient’s financial history: outstanding balances, previous payment plans, prior charity applications from billing-claims and financial_counseling_records.
3. System displays recent cost_estimates and upcoming high-cost procedures, if any.
4. Counselor reviews patient’s situation with them (employment status, income range, dependents, residency status) and records summary in patient_situation.
5. System suggests applicable options based on Financial Assistance Programs and Payment Plan Templates (e.g., 6-month instalment, 12-month instalment).
6. Counselor presents options: payment plan, upfront discount per facility policy, charity care application, government assistance (e.g., local emirate support schemes).
7. Decision: Which option(s) does the patient choose? - Payment plan → step 8.
   - Charity care → step 9.
   - Immediate full payment or no arrangement → step 10.
8. For payment plan: Counselor configures payment_plan_setup (amount, instalments, due dates) using template; system creates or references a payment_plan_id in billing system and links it in financial_counseling_records.
9. For charity care: Counselor initiates charity_application_id (in billing/finance module), uploads required documents, and records status; system links it in financial_counseling_records.
10. Counselor documents options_presented and patient_decision (e.g., “Accepted 12-month plan”, “Declined assistance”).
11. System creates a financial_counseling_records entry with session_datetime, counseling_type, notes, and links to any payment plan or charity application.
12. If electronic signature is supported, patient signs digitally on tablet; system stores signature reference and marks agreement as accepted.
13. System notifies billing-claims of new arrangements for account handling and collections strategy.

Data Modified:

• financial_counseling_records — INSERT (each counseling session)
• Payment plan / charity tables (in billing-claims) — INSERT/UPDATE (via integration)

Mermaid Flowchart

Decision Points

1. Eligibility for assistance programs?
   - System can pre-screen based on income/residency criteria; Counselor confirms.
2. Patient chooses payment plan vs charity vs no arrangement?
   - Determines downstream billing strategy.
3. Digital signature available?
   - If not, Counselor may record verbal agreement and follow facility policy.

Integration Points

Exception Handling

• Incomplete financial information:
• Counselor can proceed with partial data but must record limitations; system flags record as “provisional”.
• Patient declines to share financial details:
• Counselor records refusal; system marks as “no counseling” and informs billing to follow standard collections.
• Assistance program rules change:
• Master data update required; system should not allow use of expired templates.

Paperless Transformation

Remaining Paper Touchpoints: Some government assistance programs may still require paper forms; these can be scanned and referenced.

Inputs and Outputs

Inputs:

Outputs:

Post-conditions:

• financial_counseling_records entry exists with session details
• If payment plan accepted, plan created in billing system and linked
• If charity care initiated, application tracked with document references
• Billing notified of new arrangements for account handling

SLA and Timing

WF-PAC-006: Pre-Registration

Process Flow

Actor: Registration Clerk, Patient (via Portal), System
Trigger: Appointment booked, scheduled procedure, or patient-initiated online pre-registration
Pre-conditions:

• Appointment exists in appointments (scheduling) with date/time and visit type
• Patient has contact details (mobile/email) in ehr-patient-mgmt
• Pre-registration question sets configured per visit type
• Patient portal account available or invitation process in place
• Consent and privacy notices aligned with UAE PDPL presented in portal

1. When an appointment is created or updated, system evaluates visit type and lead time to determine if pre-registration is applicable.
2. System creates a pre_registration_records entry with status = 'invited', links to patient_id and appointment_id, and sets invitation_sent_datetime.
3. System sends pre-registration invitation via SMS/email with secure link to Patient Portal (INT-PAC-008) and/or notifies Registration Clerk to perform phone-based pre-registration if patient has no portal access.
4. Patient logs into portal and opens pre-registration; system presents configured Pre-Registration Question Sets (demographics, insurance, consents) in EN/AR.
5. Patient updates demographics (address, phone, emergency contacts) and uploads insurance card images; system writes changes to ehr-patient-mgmt via internal APIs and marks demographics_complete = true when required fields are filled.
6. Patient enters insurance details; system triggers an automatic eligibility check (WF-PAC-001) and, upon success, sets insurance_verified = true in pre_registration_records.
7. System checks coverage rules for scheduled services to identify any prior auth or referral requirements; if all required items are present and valid, sets auth_verified = true.
8. Patient reviews and electronically signs consent forms (treatment, data processing per UAE PDPL, NABIDH/Malaffi data sharing where applicable); system records consent_obtained = true and stores consent artifacts in EHR.
9. Decision: Are all pre-registration components complete (demographics, insurance, auth/referral, consents)? - Yes → system sets status = 'complete' and completed_datetime in pre_registration_records.
   - No → system sets status = 'in_progress' and lists incomplete items.
10. For patients unable to use portal, Registration Clerk uses phone or in-person call to complete the same fields via SCR-PAC-007; system updates pre_registration_records accordingly.
11. On day of service, check-in screen shows pre-registration status; if complete, clerk can perform expedited check-in with minimal verification.
12. System tracks pre-registration completion rate for KPI reporting.

Data Modified:

• pre_registration_records — INSERT (new record), UPDATE (status, flags, timestamps)
• patients / patient_demographics / patient_identifiers (ehr-patient-mgmt) — UPDATE (demographics, insurance)
• eligibility_checks / eligibility_responses — INSERT (auto eligibility)

Mermaid Flowchart

Decision Points

1. Pre-registration applicable?
   - Based on visit type (e.g., elective vs emergency) and time until appointment.
2. Patient uses portal vs clerk-assisted?
   - Determines whether data entry is patient-driven or staff-driven.
3. All components complete?
   - Drives status and check-in workflow.

Integration Points

Exception Handling

• Patient does not respond to invitation:
• System flags appointment in Pre-Registration Dashboard (SCR-PAC-007) for clerk follow-up; reminder SMS/email may be sent.
• Eligibility or auth cannot be completed before visit:
• System flags encounter as not fully financially cleared; supervisor can override or reschedule per policy.
• Data conflicts with existing records (e.g., different Emirates ID):
• System prompts for manual review and may require identity verification at check-in.

Paperless Transformation

Remaining Paper Touchpoints: Patients without digital access may still sign paper consents at check-in; these can be scanned into the system.

Inputs and Outputs

Inputs:

Outputs:

Post-conditions:

• pre_registration_records exists with status (invited, in_progress, or complete)
• If complete, all components verified: demographics, insurance, eligibility, auth/referral, consents
• Day-of-service check-in is expedited for patients with complete pre-registration
• Pre-registration completion rate tracked for KPI reporting

SLA and Timing

State Transition Diagram

The pre-registration record manages a distinct lifecycle from invitation through check-in.