Case Management Workflows

This document defines six core workflows for the Case Management module, covering utilization management (UM), discharge planning, care coordination, readmission risk assessment, and payer communication.

Regulatory context (UAE): All workflows must comply with UAE PDPL (Federal Decree-Law No. 45/2021) for patient data protection and consent; MOH, DOH (Abu Dhabi), and DHA (Dubai) requirements for utilization management and discharge planning; and HIE policies for NABIDH (Dubai) and Malaffi (Abu Dhabi) where case management summaries may be shared. Access to case management data is role-based and logged for audit per ADHICS/DHA security standards.

WF-CSM-001: Admission Review (Concurrent UM)

Process Flow

Actor: Case Manager / UM Nurse
Trigger: Inpatient admission message received (ADT A01) from Scheduling/ADT
Pre-conditions:

• Patient and encounter exist in shared entities (patients, encounters)
• Admission type = Inpatient or Observation
• Payer and plan known or marked as “self-pay / pending”
• UM clinical criteria master data configured (InterQual-equivalent or local)

1. System receives ADT A01 from Scheduling module and creates/updates census.
2. System auto-runs case assignment rules (from case_management_assignments) based on department, service line, and current caseload.
3. System creates a new case header in case_reviews (INSERT) linked to patient_id, encounter_id, assigned case_manager_id, sets: - case_status = 'OPEN' - case_type = 'ADMISSION_REVIEW' - priority based on payer and diagnosis (e.g., high for high-cost DRGs).
4. Case Manager opens Case Management Worklist (SCR-CSM-001) and selects the new case.
5. System retrieves clinical summary from EHR (diagnosis list, vitals, labs, imaging, progress notes) via internal API (INT-CSM-002).
6. Case Manager selects appropriate UM criteria set (e.g., “Adult Medical Inpatient”) and review type = “Admission”.
7. Case Manager evaluates criteria item-by-item: - For each criterion, records met/not met and evidence in um_criteria_evaluations (INSERT multiple rows).
8. System calculates criteria_met flag for the review and inserts a row into utilization_reviews: - review_type = 'ADMISSION' - criteria_tool, criteria_met, clinical_justification, level_of_care (e.g., Inpatient vs Observation).
9. Decision: Are admission criteria met? - If Yes:
   1. System sets recommended_action = 'CONTINUE_INPATIENT' in utilization_reviews.
   2. System sets initial expected_discharge_date in case_reviews based on DRG/LOS norms from master data (UPDATE). - If No:
   3. System sets recommended_action = 'DOWNGRADE_OR_DISCHARGE'.
   4. System flags case as “Requires Physician Advisor Review”.
10. Decision: Is payer authorization required at admission?
    • System queries payer rules from Policy & Contract Management (INT-CSM-005).
    • If Yes, system notifies Patient Access/Prior Auth module (INT-CSM-003) with admission details and recommended LOS.
11. If criteria not met, Case Manager escalates to Physician Advisor:
    • Physician Advisor reviews clinical data and UM criteria.
    • May override to approve inpatient level of care; system updates utilization_reviews with override_by and override_reason (UPDATE).
12. Case Manager initiates early discharge planning:
    • Creates a discharge_plans record (INSERT) with plan_status = 'IN_PROGRESS', target_discharge_date aligned with expected LOS.
13. System records review due date for next concurrent review in utilization_reviews.next_review_date based on payer schedule.
14. All actions are logged in audit tables (module-wide audit, not detailed here) for PDPL and DOH/DHA compliance.

Data Modified:

• case_reviews — INSERT (new case), UPDATE (expected_discharge_date, case_status, readmission_risk_score later)
• utilization_reviews — INSERT (admission review), UPDATE (override fields, next_review_date)
• um_criteria_evaluations — INSERT (criteria checklist)
• discharge_plans — INSERT (initial plan)
• case_management_assignments — UPDATE (current_caseload increment)

Mermaid Flowchart

Decision Points

1. Admission criteria met? - If Yes: Maintain inpatient level of care; set expected LOS and proceed with concurrent review schedule. - If No: Escalate to Physician Advisor; consider observation status or alternative care setting.
2. Payer authorization required at admission? - If Yes: Trigger Prior Auth workflow; admission may be “pending auth”. - If No: Proceed without auth but still document UM review.
3. Physician Advisor override? - If Yes: criteria_met may remain false but recommended_action updated to continue inpatient with documented override. - If No: Proceed with downgrade/discharge planning.

Integration Points

• Scheduling (ADT) — inbound (INT-CSM-001): ADT A01 admission details (encounter, location, attending).
• EHR & Patient Management — bidirectional (INT-CSM-002):
• Inbound: diagnoses, vitals, labs, notes.
• Outbound: UM review summary, level of care decisions.
• Policy & Contract Management — inbound (INT-CSM-005):
• Payer UM rules, review schedules, auth requirements.
• Patient Access (Prior Auth) — bidirectional (INT-CSM-003):
• Outbound: initial auth request with LOS and level of care.
• Inbound: auth number, approved days, conditions.

Exception Handling

• Missing clinical data (e.g., no diagnosis yet):
• System flags review as “Provisional”; allows saving with mandatory note; prompts re-review once data available.
• No matching case assignment rule:
• System assigns to default pool; notifies Case Management Director to update case_management_assignments.
• Integration failure with Policy & Contract Management:
• System uses last cached payer rules; flags case as “UM rules not verified” and alerts UM team.
• Physician Advisor not available:
• System escalates to backup advisor list; if none, marks case as “Pending Advisor” and sends alert to Case Management Director.

Paperless Transformation

Remaining Paper Touchpoints: None — fully digital.

Inputs and Outputs

Inputs:

Outputs:

Post-conditions:

• Case record exists with case_status = 'OPEN' and assigned Case Manager
• Admission UM review completed with criteria met/not met determination
• Expected discharge date set based on DRG/LOS norms
• Initial discharge plan created with plan_status = 'IN_PROGRESS'
• Next concurrent review date scheduled per payer rules
• Authorization request initiated if payer requires pre-certification

SLA and Timing

State Transition Diagram

WF-CSM-002: Continued Stay Review

Process Flow

Actor: Case Manager / UM Nurse
Trigger: Scheduled review date reached or approaching authorized LOS limit
Pre-conditions:

• Existing open case_reviews record for encounter
• At least one prior utilization_reviews record
• Payer rules loaded (review frequency, auth requirements)
• Latest clinical data available from EHR

1. System runs a daily job to identify cases where: - next_review_date <= today OR - approved_days in continued_stay_authorizations nearing expiry.
2. System generates alerts on Case Management Worklist (SCR-CSM-001) for due reviews.
3. Case Manager opens the case and selects Continued Stay Review.
4. System retrieves updated clinical data from EHR (labs, vitals, imaging, progress notes, procedures) via INT-CSM-002.
5. Case Manager selects UM criteria set and review type = “CONTINUED_STAY”.
6. Case Manager evaluates criteria and records each item in um_criteria_evaluations (INSERT).
7. System inserts a new utilization_reviews record with: - review_type = 'CONTINUED_STAY' - criteria_met, clinical_justification, level_of_care, payer_notification_required (based on rules).
8. Decision: Continued stay criteria met? - If Yes:
   1. Set recommended_action = 'CONTINUE_INPATIENT'.
   2. Calculate and update next_review_date (UPDATE utilization_reviews). - If No:
   3. Set recommended_action = 'DOWNGRADE_OR_DISCHARGE'.
   4. Notify attending physician via EHR messaging.
9. Decision: Payer continued-stay authorization required? - If Yes:
   1. Case Manager prepares clinical summary (auto-populated, editable).
   2. System creates/updates continued_stay_authorizations (INSERT or UPDATE) with:
      • requested_days, request_date, status = 'PENDING'.
   3. System sends auth request to Patient Access or directly to payer via eClaimLink/DOH eClaims (INT-CSM-003 / external).
10. System tracks payer response:
    • On approval: update continued_stay_authorizations with approved_days, response_date, status = 'APPROVED'.
    • On denial: set status = 'DENIED', denial_reason, and flag for appeal.
11. Decision: Denied with appeal option?
    • If Yes: Case Manager initiates appeal; updates appeal_status (e.g., 'FILED', 'IN_REVIEW').
    • If No: Case Manager coordinates discharge or level-of-care change.
12. Case Manager updates case_reviews.expected_discharge_date based on clinical trajectory and auth outcome (UPDATE).
13. System sends UM review summary and auth status to Billing & Claims (INT-CSM-004) to support compliant billing and avoid denials.

Data Modified:

• utilization_reviews — INSERT (continued stay review), UPDATE (next_review_date, recommended_action)
• um_criteria_evaluations — INSERT
• continued_stay_authorizations — INSERT/UPDATE
• case_reviews — UPDATE (expected_discharge_date, case_status if nearing discharge)

Mermaid Flowchart

Decision Points

1. Review due or auth expiring? - If No: Case remains in background; no action. - If Yes: Review is queued and alerted.
2. Continued stay criteria met? - If Yes: Continue inpatient; set next review date. - If No: Initiate downgrade/discharge discussion.
3. Payer continued-stay authorization required? - If Yes: Create/Update continued_stay_authorizations and send request. - If No: Document review only; no payer communication.
4. Appeal possible? - If Yes: Start appeal, track appeal_status. - If No: Plan discharge or alternative level of care.

Integration Points

• EHR & Patient Management — inbound (INT-CSM-002): updated clinical data for review.
• Policy & Contract Management — inbound (INT-CSM-005): review frequency, auth rules.
• Patient Access (Prior Auth) — bidirectional (INT-CSM-003): continued-stay auth requests and responses.
• Billing & Claims — outbound (INT-CSM-004): UM review results, auth numbers, approved days.
• eClaimLink / DOH eClaims — outbound (via Billing/Patient Access): payer communication for UM.

Exception Handling

• Payer portal or eClaimLink downtime:
• System queues auth requests; marks status = 'PENDING_TRANSMISSION'; retries periodically; alerts UM team if beyond threshold (e.g., 4 hours).
• Clinical data not updated (e.g., no recent notes):
• System warns Case Manager; allows review with mandatory comment; flags review as “Limited Data”.
• Auth response not received within payer SLA:
• System escalates with alerts to Case Manager and Patient Access; may trigger phone-based follow-up.
• Billing integration failure:
• UM summary stored; system flags affected encounters for manual billing review to prevent non-compliant claims.

Paperless Transformation

Remaining Paper Touchpoints: Some payers may still require faxed documents; system should allow uploading scanned copies for reference.

Inputs and Outputs

Inputs:

Outputs:

Post-conditions:

• New continued stay review recorded with criteria determination
• Next review date scheduled per payer rules
• Authorization status updated (if payer auth required)
• Billing notified of UM review outcome and auth numbers
• Expected discharge date adjusted based on clinical trajectory

SLA and Timing

State Transition Diagram

WF-CSM-003: Discharge Planning

Process Flow

Actor: Case Manager, Discharge Planner, Social Worker
Trigger: Within 24 hours of admission, significant clinical status change, or approaching expected discharge date
Pre-conditions:

• Open case_reviews record
• Patient has an active inpatient encounter
• Basic demographic and social data available in EHR
• Post-acute service master data configured

1. System automatically creates an initial discharge_plans record at admission (from WF-CSM-001) or when manually initiated: - plan_status = 'IN_PROGRESS' - planned_disposition initially null or default (e.g., “Home”).
2. Discharge Planner opens Discharge Planning Screen (SCR-CSM-003) for the patient.
3. System retrieves: - Patient demographics, address, caregiver info. - Insurance coverage, payer network. - Clinical summary and functional status from EHR.
4. Discharge Planner performs barriers assessment (social, financial, clinical, caregiver availability) and updates discharge_plans.barriers_identified (UPDATE).
5. Decision: Are significant barriers present? - If Yes: System suggests Social Worker involvement; assigns tasks accordingly. - If No: Proceed with standard planning.
6. Planner identifies services needed (home care, rehab, DME, transport) and updates discharge_plans.services_needed (UPDATE).
7. System creates discharge_plan_tasks (INSERT multiple rows) for: - Arranging post-acute services. - Scheduling follow-up appointments (via Scheduling integration). - Patient education and medication counseling.
8. Discharge Planner coordinates with interdisciplinary team (physician, nurses, therapists, Social Worker) and documents notes in discharge_plans and/or care_coordination_notes (INSERT).
9. Decision: Transfer to another facility required? - If Yes: Planner coordinates with receiving facility; tasks created for transfer documentation and transport. - If No: Focus on home/community-based services.
10. Planner educates patient and family on discharge plan; records patient_family_agreed flag and timestamp in discharge_plans (UPDATE).
11. As tasks are completed, responsible users update discharge_plan_tasks.status and completed_datetime (UPDATE).
12. Decision: All critical tasks completed and discharge order placed? - If Yes: Set discharge_plans.plan_status = 'COMPLETED' and update case_reviews.disposition and actual_discharge_date (UPDATE). - If No: System highlights outstanding tasks and may delay discharge if critical items pending.
13. System sends discharge plan summary to Patient Portal (INT-CSM-006) and, where applicable, to NABIDH/Malaffi via EHR integration.

Data Modified:

• discharge_plans — INSERT (if not already), UPDATE (barriers, services_needed, plan_status, patient_family_agreed)
• discharge_plan_tasks — INSERT/UPDATE
• care_coordination_notes — INSERT (for interdisciplinary coordination)
• case_reviews — UPDATE (disposition, actual_discharge_date, case_status='CLOSED' when fully complete)

Mermaid Flowchart

Decision Points

1. Significant barriers present? - If Yes: Involve Social Worker; may trigger financial counseling, community resource referrals. - If No: Standard discharge planning.
2. Transfer to another facility required? - If Yes: Additional tasks for bed acceptance, transfer forms, transport. - If No: Focus on home-based services.
3. All critical tasks completed and discharge order placed? - If Yes: Finalize plan and close case. - If No: Keep plan open; system alerts team to pending items.

Integration Points

• Scheduling — outbound: follow-up appointments creation (post-discharge clinic, rehab).
• EHR & Patient Management — bidirectional (INT-CSM-002):
• Inbound: clinical status, therapy notes, nursing assessments.
• Outbound: discharge plan summary.
• Patient Portal — outbound (INT-CSM-006): discharge instructions, appointments, services.
• Pharmacy / PIS — via EHR: discharge medications for patient education.
• NABIDH/Malaffi — via EHR: discharge summary and plan where required by DOH/DHA.

Exception Handling

• Patient or family declines proposed plan:
• System requires documentation of reasons; patient_family_agreed = false; triggers escalation to physician and possibly ethics/administration.
• Post-acute provider cannot accept patient (capacity or network issue):
• Task marked as “Failed”; system prompts selection of alternative provider; logs attempts.
• Transport delays:
• Task due date breached; system alerts Discharge Planner and nursing; may adjust discharge time.
• Portal access declined:
• System records preference; allows printing of discharge plan while still storing digital copy.

Paperless Transformation

Remaining Paper Touchpoints: Printed discharge instructions for patients who opt out of portal or require physical copies.

Inputs and Outputs

Inputs:

Outputs:

Post-conditions:

• Discharge plan finalized with all critical tasks completed
• Patient and family educated and agreement documented
• Follow-up appointments scheduled
• Post-acute services arranged (home care, rehab, DME)
• Discharge summary shared to Patient Portal and HIE
• Case status updated to CLOSED

SLA and Timing

State Transition Diagram

WF-CSM-004: Care Coordination

Process Flow

Actor: Care Coordinator, Case Manager
Trigger: Complex patient identified (risk algorithm, frequent readmissions, or physician referral)
Pre-conditions:

• Patient has active or recent encounter
• Readmission risk or complexity criteria defined in master data
• Care coordination program types configured

1. System identifies eligible patients using: - Readmission risk scores from readmission_risk_assessments. - Rules (e.g., ≥2 admissions in 6 months, multiple chronic conditions).
2. Eligible patients appear on Care Coordination Dashboard (SCR-CSM-004) with risk flags.
3. Care Manager or Coordinator selects a patient and confirms enrollment into a care coordination program type (e.g., heart failure, diabetes).
4. System creates a care_coordination_notes entry (INSERT) documenting program enrollment and initial assessment.
5. Coordinator defines care coordination plan: - Goals, interventions, responsible parties, and timelines (stored in structured fields and/or JSON within care_coordination_notes).
6. Decision: Is a dedicated Care Coordinator available? - If Yes: Assign coordinator_id and update workload. - If No: Assign to Case Manager or shared pool.
7. Coordinator schedules follow-up touchpoints: - Clinic visits via Scheduling. - Phone calls and portal messages. - Home visits where applicable.
8. Each interaction (call, visit, portal message) is documented as a new care_coordination_notes record (INSERT) with: - activity_type (e.g., “Phone Call”, “Portal Message”). - contact_made_with, outcome, note_datetime.
9. Decision: Patient adherent to care plan? - If Yes: Continue current plan; update risk level if improving. - If No: Escalate interventions (e.g., more frequent contacts, involve Social Worker or physician).
10. Coordinator periodically reassesses patient status and updates plan; may adjust risk level and goals.
11. Outcomes (readmissions, ED visits, patient satisfaction) are tracked via integration with EHR and analytics; summary metrics feed into case_reviews.readmission_risk_score or analytics layer.
12. When goals achieved or patient stabilized, Coordinator documents program completion in care_coordination_notes and flags patient as “Program Completed” or “Graduated”.

Data Modified:

• care_coordination_notes — INSERT (enrollment, interactions, updates, completion)
• case_reviews — UPDATE (readmission_risk_score, case_status notes if used for inpatient cases)
• case_management_assignments — UPDATE (current_caseload for coordinators)

Mermaid Flowchart

Decision Points

1. Dedicated Care Coordinator available? - If Yes: Assign named coordinator; improves accountability. - If No: Assign to Case Manager or shared pool; may impact caseload.
2. Patient adherent to care plan? - If Yes: Maintain or reduce intensity of follow-up. - If No: Increase contact frequency, involve Social Worker, or physician.
3. Goals achieved or patient stable? - If Yes: Close program; document outcomes. - If No: Continue or intensify coordination.

Integration Points

• EHR & Patient Management — inbound:
• Diagnoses, medications, lab trends, ED visits, admissions.
• Scheduling — outbound:
• Follow-up appointments, telehealth sessions.
• Patient Portal — outbound/inbound:
• Care plan summaries, secure messages, patient-reported outcomes.
• Physician Portal — outbound:
• Coordination notes and action items for physicians.

Exception Handling

• Unable to reach patient:
• Coordinator records attempts in care_coordination_notes; system prompts alternative contact methods; after threshold attempts, flags as “Unable to Contact”.
• Patient withdraws consent (PDPL requirement):
• System records withdrawal; stops proactive outreach; retains historical notes but restricts further processing for coordination purposes.
• Coordinator overload:
• case_management_assignments.current_caseload exceeds max_caseload; system alerts Case Management Director to rebalance assignments.

Paperless Transformation

Remaining Paper Touchpoints: Printed care plans for patients without digital access.

Inputs and Outputs

Inputs:

Outputs:

Post-conditions:

• Patient enrolled in appropriate care coordination program
• Named coordinator assigned with manageable caseload
• Follow-up touchpoints scheduled (clinic, phone, portal)
• All interactions documented in care_coordination_notes
• Patient risk level reassessed and updated periodically

SLA and Timing

WF-CSM-005: Readmission Risk Assessment

Process Flow

Actor: System (automated scoring), Case Manager
Trigger: Patient approaching discharge or presenting with potential readmission (within 30 days)
Pre-conditions:

• Risk scoring algorithm and weights configured (LACE or local)
• Access to required data elements (LOS, ED visits, comorbidities, acuity)
• Patient has an active or recent encounter

1. When a patient reaches a configurable LOS threshold (e.g., ≥2 days) or is flagged for discharge, system triggers risk calculation.
2. System gathers required inputs from EHR and encounters: - Length of stay (current encounter). - Acuity of admission (e.g., via ED). - Comorbidities (ICD-10-AM codes). - ED visits in last 6 months.
3. System calculates a numeric risk score using configured weights and creates a readmission_risk_assessments record (INSERT) with: - risk_score, risk_level (e.g., Low/Medium/High), score_components_json, assessment_datetime, assessed_by (system or user).
4. Risk score and level are displayed on: - Case Management Worklist (SCR-CSM-001). - Readmission Risk Dashboard (SCR-CSM-006).
5. Decision: Risk level high or very high? - If Yes: System recommends enhanced discharge planning and care coordination; flags case as high priority. - If No: Standard discharge planning.
6. Case Manager reviews risk assessment and may adjust risk_level manually with justification (UPDATE readmission_risk_assessments).
7. For high-risk patients, system automatically: - Creates additional discharge_plan_tasks (INSERT) for post-discharge follow-up calls within 48 hours. - Suggests enrollment into care coordination program (link to WF-CSM-004).
8. If patient is readmitted within 30 days: - System detects prior discharge and flags encounter as potential readmission. - Case Manager performs root cause analysis and documents in a new readmission_risk_assessments or care_coordination_notes entry (INSERT).
9. Aggregate risk and outcome data feed into analytics for monitoring 30-day readmission rates and program effectiveness.

Data Modified:

• readmission_risk_assessments — INSERT, UPDATE (manual adjustments)
• discharge_plan_tasks — INSERT (extra tasks for high-risk patients)
• case_reviews — UPDATE (readmission_risk_score, priority)

Mermaid Flowchart

Decision Points

1. Risk level high/very high? - If Yes: Trigger enhanced interventions. - If No: Standard pathway.
2. Manual adjustment of risk level? - Case Manager may override algorithm based on clinical judgment; justification required.
3. Readmitted within 30 days? - If Yes: Flag as readmission; root cause analysis. - If No: Count as successful outcome.

Integration Points

• EHR & Patient Management — inbound:
• Diagnoses, ED visits, prior admissions, LOS.
• Scheduling — outbound:
• Follow-up appointments for high-risk patients.
• Analytics / BI — outbound:
• Risk scores and outcomes for KPI tracking.

Exception Handling

• Missing data for risk calculation:
• System uses available data; flags assessment as “Incomplete”; prompts Case Manager to review.
• Algorithm configuration error:
• System falls back to default weights; logs error for informatics team.
• Multiple overlapping assessments:
• System marks latest as “Active”; older ones as “Superseded”.

Paperless Transformation

Remaining Paper Touchpoints: None — fully digital.

Inputs and Outputs

Inputs:

Outputs:

Post-conditions:

• Risk score calculated and recorded with component breakdown
• Risk level (Low/Medium/High) displayed on worklist and dashboard
• High-risk patients flagged for enhanced discharge planning and care coordination
• Additional post-discharge follow-up tasks created for high-risk patients

SLA and Timing

WF-CSM-006: Payer Communication & Authorization Follow-Up

Process Flow

Actor: UM Nurse, Case Manager
Trigger: Authorization deadline approaching, payer request for information, or denial received
Pre-conditions:

• Existing continued_stay_authorizations record or auth requirement identified
• Payer contact methods and rules available from Policy & Contract Management
• Patient encounter and UM reviews up to date

1. System continuously monitors continued_stay_authorizations for: - Upcoming expiry (e.g., within 48 hours). - Pending status without response beyond SLA.
2. Cases with approaching deadlines appear on Authorization Tracking Screen (SCR-CSM-005) with countdown timers.
3. UM Nurse selects an authorization and reviews: - Payer, approved days, remaining days. - Last UM review and clinical summary.
4. Nurse prepares updated clinical summary (auto-populated from EHR and UM module) and edits as needed.
5. Decision: Submission channel? - Payer portal, phone, eClaimLink, or DOH eClaims based on payer rules.
6. System records a new event in continued_stay_authorizations (UPDATE): - request_date, status = 'PENDING', requested_days.
7. Nurse submits clinical information via selected channel: - If via integrated electronic channel, system sends data through Patient Access/Billing (INT-CSM-003/004). - If via phone, nurse documents call details in continued_stay_authorizations and/or care_coordination_notes.
8. Decision: Payer requests additional information? - If Yes: System flags case; Nurse coordinates with clinical team to obtain missing data and resubmits. - If No: Await decision.
9. On receiving payer decision: - Approval: update approved_days, response_date, status = 'APPROVED', auth_number (UPDATE). - Denial: set status = 'DENIED', denial_reason.
10. Decision: Peer-to-peer review required?
    • If Yes: Nurse schedules peer review between Physician Advisor and payer physician; records details and outcome.
11. Final determination is recorded; system updates:
    • case_reviews.expected_discharge_date and priority.
    • Billing & Claims notified with final auth status and numbers (INT-CSM-004).
12. If denial upheld, Case Manager coordinates discharge or alternative plan and documents in discharge_plans and care_coordination_notes.

Data Modified:

• continued_stay_authorizations — UPDATE (request_date, requested_days, status, approved_days, response_date, denial_reason, appeal_status)
• care_coordination_notes — INSERT (payer communication details, peer review notes)
• case_reviews — UPDATE (expected_discharge_date, priority)

Mermaid Flowchart

Decision Points

1. Deadline approaching or SLA breached? - If Yes: Case prioritized for follow-up. - If No: No immediate action.
2. Submission channel selection: - Based on payer rules; may affect data format and integration.
3. Payer requests additional information? - If Yes: Additional clinical data gathered and resubmitted. - If No: Await final decision.
4. Peer-to-peer review required? - If Yes: Schedule and document; may overturn denial. - If No: Determination stands.

Integration Points

• Patient Access (Prior Auth) — bidirectional (INT-CSM-003):
• Shared tracking of auth requests and numbers.
• Billing & Claims — outbound (INT-CSM-004):
• Final auth numbers, approved days, denial reasons for claim submission and appeals.
• eClaimLink / DOH eClaims — outbound:
• Electronic submission of UM data where supported.
• EHR & Patient Management — inbound:
• Clinical data for summaries.

Exception Handling

• Payer system outage:
• System marks submission as “Pending Transmission”; retries; logs manual phone submissions if used.
• Incorrect payer rules:
• If mismatch detected (e.g., payer rejects due to wrong schedule), system logs incident and notifies Policy & Contract Management to update rules.
• Missed deadline:
• System flags as “Late Submission”; requires root cause documentation; may impact denial analytics.

Paperless Transformation

Remaining Paper Touchpoints: Some payers may still require fax; scanned copies can be attached or referenced in notes.

Inputs and Outputs

Inputs:

Outputs:

Post-conditions:

• Authorization status updated with payer decision (approved/denied)
• Approved days and auth numbers recorded and communicated to Billing
• If denied, appeal initiated or discharge/alternative care planned
• All payer communications documented for audit trail

SLA and Timing