Physician Portal & Mobile App Workflows

This document defines eight core workflows for the Physician Portal & Mobile App module. Each workflow includes process steps, actors, decision points, integration hooks, exception handling, and the paperless transformation achieved by the HIS.

Regulatory context (UAE): All workflows must comply with UAE PDPL (Federal Decree-Law No. 45/2021) for personal health data processing, DOH ADHICS / DHA security standards for mobile access, and MOH/DOH/DHA requirements for clinical documentation and result acknowledgment. Where applicable, data exchanged with external systems (e.g., LIS/RIS, NABIDH/Malaffi) must follow HL7/FHIR profiles defined by the respective authorities.

WF-PHY-001: Mobile Patient Lookup & Chart Review

Process Flow

Actor: Physician, Nurse Practitioner
Trigger: Physician needs patient information while mobile (rounding, on-call, remote)
Pre-conditions:

• Valid physician_portal_accounts record linked to providers and users
• Device registered and at least one MFA method configured (biometric/PIN)
• Patient exists in patients and has at least one active or historical encounter in encounters
• User has permission view_patient_charts and is authorised for the facility/department (per DOH/DHA/MOH rules)

1. Physician launches mobile app or web portal.
2. System displays login screen and prompts for biometric (Face ID/Touch ID) or PIN based on physician_preferences and device capabilities.
3. System validates credentials and MFA: - If biometric fails 3 times, system falls back to username/password + OTP.
4. On successful authentication: - System creates a new physician_portal_sessions record (login time, device type, IP, auth_method). - System loads dashboard (SCR-PHY-001) with today’s schedule, patient lists, and inbox summary.
5. Physician taps the patient search bar and selects search mode: - MRN, Emirates ID (e.g., 784-1990-1234567-1), name, bed/room, or recent patients.
6. System queries patients, encounters, and facility/department context to filter results to authorised patients only (per UAE PDPL data minimisation).
7. Physician selects a patient from the result list.
8. System loads SCR-PHY-002 (Patient Chart) and: - Displays patient banner (name, age, sex, Emirates ID, allergies). - Retrieves allergies from patient_allergies, problems from patient_problems, medications from PIS via internal API, recent vitals and results from EHR/LIS/RIS.
9. System caches a minimal offline snapshot (demographics, allergies, active problems, last 24h vitals, last key results) on the device with encryption-at-rest, respecting PDPL and ADHICS.
10. Physician navigates between chart sections (swipe/tabs):
    • Medications (current list, recent administrations from eMAR).
    • Lab results (trend graphs, abnormal highlighting).
    • Radiology reports (with thumbnail links to PACS if available).
    • Clinical notes (clinical_notes).
    • Active orders (via CPOE).
    • Care team (from providers, encounters).
11. If physician attempts to open restricted data (e.g., psychiatric notes flagged as sensitive), system checks role-based permissions and either displays data or shows an access denied message with audit logging.
12. When physician leaves the chart or app goes to background, system:
    • Updates physician_portal_sessions last activity timestamp.
    • Optionally auto-locks after configurable inactivity timeout (per ADHICS).
13. On logout or session timeout, system updates physician_portal_sessions.logout_datetime and clears any decrypted cached data beyond allowed offline set.

Data Modified:

• physician_portal_sessions — INSERT (on login), UPDATE (last activity, logout)
• physician_portal_accounts — UPDATE (last_login, possibly device_tokens)
• physician_preferences — UPDATE (optional: last_patient_list, last_viewed_section)
• No clinical data (patients, notes, results) is modified in this read-only workflow.

Mermaid Flowchart

Decision Points

1. Authentication success
   - If biometric/PIN succeeds → proceed to dashboard.
   - If fails → require username/password + OTP; if still fails → deny access and log security event.

2. Patient search results
   - If no patients match criteria or are outside physician’s authorised scope → show “No results” and allow new search.
   - If matches found → show list with key demographics and encounter context.

3. Section access control
   - If physician has permission for requested section (e.g., mental health notes) → display data.
   - If not → show access denied, log in security/audit log for PDPL compliance.

Integration Points

• EHR & Patient Management (ehr-patient-mgmt)
• Read: patients, patient_demographics, patient_identifiers, patient_allergies, patient_problems, clinical_notes, facilities, departments, encounters.

• Protocol: Internal API / FHIR (e.g., Patient, AllergyIntolerance, Condition, Encounter, DocumentReference).

• LIS (lis)

• Read: Lab results (lab_results), trends.

• Protocol: Internal API / FHIR DiagnosticReport/Observation (INT-PHY-003).

• RIS (ris)

• Read: Radiology reports (radiology_reports), PACS viewer links.

• Protocol: Internal API / FHIR DiagnosticReport (INT-PHY-004).

• PIS (pis)

• Read: Medication list, eMAR administrations, pharmacist interventions.

• Protocol: Internal API (INT-PHY-005).

• Scheduling (scheduling)

• Read: Today’s schedule, inpatient census, on-call lists.
• Protocol: Internal API (INT-PHY-006).

Exception Handling

• Authentication failures:

• After configurable number of failed attempts (e.g., 5), temporarily lock physician_portal_accounts and require admin reset; log per ADHICS and PDPL security requirements.

• Network connectivity loss:

• If connection lost after login, allow read-only access to previously cached offline snapshot; display banner “Offline — data may be outdated” and block access to non-cached sections.

• Authorisation failure for patient/section:

• Show “Access not permitted for this patient/section” and log event with user, patient_id, timestamp for PDPL accountability.

• Backend API timeout:

• Show non-blocking error (“Unable to load labs, pull to retry”) while still showing other sections; retry with exponential backoff.

Paperless Transformation

Remaining Paper Touchpoints: Optional printed summaries for multidisciplinary meetings if required by local policy.

Inputs and Outputs

Inputs:

Outputs:

Post-conditions:

• Active session exists in physician_portal_sessions with valid auth method recorded
• Patient chart data displayed is current as of query time
• Minimal offline snapshot cached with encryption-at-rest on device
• All access events logged for UAE PDPL audit compliance

SLA and Timing

WF-PHY-002: Mobile Order Entry

Process Flow

Actor: Physician
Trigger: Physician needs to enter or modify orders while mobile
Pre-conditions:

• Active encounter in encounters (inpatient, ED, or outpatient)
• Physician authenticated with active physician_portal_sessions record
• Physician has enter_orders permission and ordering privileges for the facility
• Patient chart open in mobile app (WF-PHY-001 completed)

1. From the open patient chart, physician taps “Orders” then “New Order” (SCR-PHY-003).
2. System prompts to select order type: medication, lab, imaging, consult, diet, nursing, etc.
3. System displays: - Provider’s physician_favorites (orders and order sets) at top. - Departmental order sets (from master data). - Search bar for full order catalog.
4. Physician selects a favorite/order set or searches and selects an orderable item.
5. System pre-populates order details based on: - Order set defaults. - Patient parameters (age, weight, renal function) from EHR. - Provider preferences (e.g., default priority).
6. System invokes CDS via CPOE module: - Drug–allergy and drug–drug interactions (using patient_allergies and active meds from PIS). - Duplicate orders, dose range, and contraindications.
7. Decision: If any CDS alert is hard-stop (e.g., severe allergy), system displays blocking alert: - Physician may cancel or modify order; order cannot be signed until resolved.
8. For non-blocking alerts, system displays warnings with options to override and capture justification.
9. Physician reviews and edits order details (dose, route, frequency, priority, duration, instructions) using mobile-optimised controls and optional voice input.
10. System validates completeness and shows order summary for confirmation.
11. Physician signs order using mobile e-signature (PIN/biometric) compliant with UAE electronic transactions law; system records signature metadata.
12. System sends order payload to CPOE module via internal API (INT-PHY-002) for persistence and downstream routing:
    • Medication orders → PIS / MAR.
    • Lab orders → LIS.
    • Imaging orders → RIS.
    • Others → relevant modules.
13. CPOE returns success/acknowledgment or error.
14. On success:
    • Patient’s active orders list is refreshed.
    • A confirmation banner is shown.
    • Any resulting tasks (e.g., “Collect specimen”) are created in clinical_task_items.
15. On error (e.g., downstream system unavailable), order is queued in a retry buffer and physician is notified of pending transmission status.

Data Modified:

• physician_favorites — INSERT/UPDATE (if physician marks/unmarks favorite during process)
• clinical_task_items — INSERT (auto-generated tasks from new orders)
• CPOE-owned tables (not defined here) — INSERT/UPDATE for actual orders
• physician_inbox_items — INSERT (optional: alerts for unsigned orders or order failures)
• physician_portal_sessions — UPDATE (last activity)

Mermaid Flowchart

Decision Points

1. CDS hard-stop alerts
   - If present → physician must modify or cancel order; cannot proceed to signing.
   - If absent → proceed with soft alerts or directly to order details.

2. Soft alerts (warnings)
   - If present → physician may override with justification (stored in CPOE audit log).
   - If none → smoother flow to signing.

3. Order signing
   - If physician signs → order transmitted to CPOE.
   - If physician cancels or saves as draft → no transmission; draft stored in CPOE (if supported).

4. Transmission success
   - If success → tasks created, active orders updated.
   - If failure → order queued with retry; physician informed of pending status.

Integration Points

• CPOE (cpoe)
• Direction: Outbound (orders), inbound (status/errors).
• Data: Order details, CDS alerts, order status.

• Protocol: Internal API (INT-PHY-002).

• PIS (pis) via CPOE

• Direction: Indirect outbound.

• Data: Medication orders, dispensing status, interventions (INT-PHY-005).

• LIS (lis) via CPOE

• Direction: Indirect outbound.

• Data: Lab orders and order-result linking.

• RIS (ris) via CPOE

• Direction: Indirect outbound.

• Data: Imaging orders.

• Task Management (this module)

• Direction: Internal.
• Data: clinical_task_items for specimen collection, consent, etc.

Exception Handling

• CDS engine unavailable:

• System displays banner “Decision support temporarily unavailable”; allows only low-risk orders or requires confirmation that physician will proceed without CDS, per local policy.

• CPOE API timeout:

• Order stored in local mobile queue with status “Pending submission”; background job retries; physician inbox item created in physician_inbox_items if not sent within defined SLA.

• Partial downstream failure (e.g., PIS down):

• CPOE returns specific error; portal shows which subsystem failed; order may be held in CPOE pending manual pharmacy follow-up.

• Loss of connectivity mid-order:

• Draft order stored locally (encrypted) and synced when connection resumes; physician informed that order is not yet active.

Paperless Transformation

Remaining Paper Touchpoints: Paper consent forms for certain procedures where electronic consent is not yet implemented.

Inputs and Outputs

Inputs:

Outputs:

Post-conditions:

• Order transmitted to CPOE and routed to downstream systems (PIS, LIS, RIS)
• E-signature metadata recorded with PIN/biometric method
• Active orders list refreshed in portal with confirmation
• Any resulting clinical tasks created and assigned

SLA and Timing

WF-PHY-003: Result Review & Acknowledgment

Process Flow

Actor: Physician
Trigger: New result available, critical value alert, or pending result notification
Pre-conditions:

• Physician authenticated with active physician_portal_sessions
• Physician has review_results and (for critical) acknowledge_critical_results permissions
• Results available in LIS/RIS and linked to patient’s encounter
• Notification rules configured in physician_preferences and system Notification Rules master data

1. LIS/RIS finalises a result and sends it to the EHR; EHR flags result as new and, if critical, per DOH/DHA/MOH thresholds.
2. Notification engine evaluates physician_preferences and Notification Rules: - If configured, sends push notification via APNS/FCM (INT-PHY-008) and creates physician_inbox_items entry for the responsible physician.
3. Physician opens Unified Inbox (SCR-PHY-005) or taps push notification.
4. System filters inbox to “Results” tab, showing: - Critical results at top with badges. - New abnormal and normal results below.
5. Physician selects a result item.
6. System opens Results Review screen (SCR-PHY-004) and: - Displays current value, reference range, abnormal flags. - Shows trend chart using previous lab_results/radiology_reports. - Shows related orders from CPOE for context.
7. Decision: If result is marked critical: - System requires explicit acknowledgment (e.g., “Call patient”, “Adjust medication”, “No immediate action”) and optional note.
8. Physician enters acknowledgment action and note (for critical) or simply reviews (for non-critical).
9. System records acknowledgment: - Updates physician_inbox_items.status to “completed” and sets read_datetime and actioned_datetime. - For critical results, logs acknowledgment in LIS/EHR audit trail (outside this module) and updates any linked clinical_task_items.
10. Decision: Physician may forward result to another provider for consultation:
    • Selects provider, adds comment, and optionally creates a new clinical_task_items for follow-up.
11. System sends provider-to-provider message (via Secure Messaging workflow) and creates a new physician_inbox_items for the recipient.
12. Result is removed from “outstanding” list and appears in “completed” or “acknowledged” views.
13. Cumulative result dashboard is updated to reflect reduced count of outstanding results for the physician’s panel.

Data Modified:

• physician_inbox_items — INSERT (on result notification), UPDATE (status, read_datetime, actioned_datetime, action_taken)
• clinical_task_items — INSERT (optional follow-up tasks), UPDATE (if existing task is completed by acknowledgment)
• LIS/EHR audit tables (external) — INSERT/UPDATE for critical acknowledgment
• physician_portal_sessions — UPDATE (last activity)

Mermaid Flowchart

Decision Points

1. Critical vs non-critical result
   - If critical → mandatory acknowledgment with action and note; tracked for compliance.
   - If non-critical → optional acknowledgment; may simply be marked as reviewed.

2. Forwarding result
   - If physician forwards → new inbox item and optional task for recipient; original remains acknowledged but linked to consultation.
   - If not forwarded → workflow ends after acknowledgment.

3. Notification delivery
   - If push notifications enabled in physician_preferences → send to device; otherwise, rely on in-app inbox only.

Integration Points

• LIS (lis)
• Direction: Inbound.
• Data: Lab results, critical flags (INT-PHY-003).

• Protocol: FHIR DiagnosticReport/Observation or HL7 ORU^R01 into EHR, then internal API to portal.

• RIS (ris)

• Direction: Inbound.

• Data: Radiology reports, critical findings (INT-PHY-004).

• CPOE (cpoe)

• Direction: Read-only.

• Data: Linked orders for context and order-result correlation.

• Push Notification Service (APNS/FCM)

• Direction: Outbound.
• Data: Notification payloads for new/critical results (INT-PHY-008).

Exception Handling

• Missed critical acknowledgment within SLA:

• Escalation logic triggers: re-notify primary physician, then escalate to on-call or department head; create high-priority clinical_task_items.

• Push notification failure:

• Logged but inbox item still created; physician sees result when next opening app.

• Result data inconsistency (e.g., missing reference range):

• Display result with warning banner; allow acknowledgment but log data quality issue for LIS/EHR team.

• Network loss during acknowledgment:

• Acknowledgment stored locally and synced when connection returns; until then, result remains “unacknowledged” in central system.

Paperless Transformation

Remaining Paper Touchpoints: Optional printed result copies for external referrals where electronic exchange is not available.

Inputs and Outputs

Inputs:

Outputs:

Post-conditions:

• Result reviewed and inbox item status updated to "completed" or "acknowledged"
• Critical results have mandatory acknowledgement with action taken and note recorded
• Acknowledgement logged in LIS/EHR audit trail for DOH/DHA compliance
• Outstanding result count decremented on cumulative dashboard

SLA and Timing

WF-PHY-004: Secure Messaging (Provider-to-Provider & Patient)

Process Flow

Actor: Physician, Nurse Practitioner, Nurse, Clinical Staff
Trigger: Clinical communication needed or patient message received
Pre-conditions:

• Authenticated session with appropriate messaging permissions (message_patients, message_providers, receive_delegated_messages)
• Patient Portal active for patient (for patient messages)
• Provider directory up to date in providers and physician_portal_accounts

1. Physician opens Unified Inbox (SCR-PHY-005).
2. System displays tabs: Patient Messages, Provider Messages, System Alerts, Result Notifications.
3. For incoming messages: - System lists messages with priority badges (urgent, routine), unread counts, and patient context where applicable.
4. Physician selects a message: - System displays full thread, including previous replies and attachments (e.g., lab result link).
5. Decision: If message is from a patient: - System checks if physician has message_patients and is part of patient’s care team; otherwise, offers to reassign or escalate.
6. Physician composes a reply: - May attach clinical context (patient link, specific result, note). - May mark reply as “clinical advice” to ensure it is stored in the patient chart.
7. System sends message: - For patient messages → to Patient Portal module (INT-PHY-007) and creates/updates portal_messages. - For provider messages → creates physician_inbox_items for recipient(s).
8. If message is patient-related and marked as clinical advice: - System creates a corresponding entry in clinical_notes or communication log (in EHR) via internal API.
9. Decision: Physician may delegate message handling: - Selects another provider or nurse, adds instructions, and sets priority.
10. System updates original physician_inbox_items status (e.g., “delegated”) and creates a new physician_inbox_items for the delegate with linkage to original.
11. When message thread is resolved, physician marks it as “completed” or “no further action”.
12. System updates physician_inbox_items.status and removes it from active queue, retaining full thread for audit.

Data Modified:

• physician_inbox_items — INSERT (new provider messages, delegated items, system alerts), UPDATE (status, read_datetime, actioned_datetime, action_taken)
• portal_messages (from Patient Portal module) — INSERT/UPDATE via integration
• clinical_task_items — INSERT (if message generates a follow-up task)
• EHR communication/notes tables — INSERT (for patient-related clinical advice)
• physician_portal_sessions — UPDATE (last activity)

Mermaid Flowchart

Decision Points

1. Patient message routing
   - If physician is not authorised or not on care team → must reassign or escalate; cannot reply directly.

2. Clinical advice vs administrative reply
   - If marked as clinical advice → stored in EHR as part of medical record.
   - If not → remains as portal communication only.

3. Delegation
   - If delegated → new inbox item for delegate; original marked as delegated.
   - If not → physician remains responsible until completion.

Integration Points

• Patient Portal (patient-portal)
• Direction: Bidirectional.
• Data: Patient messages, replies, read status (INT-PHY-007).

• Protocol: Internal API.

• EHR (ehr-patient-mgmt)

• Direction: Outbound.

• Data: Clinical communication entries linked to patient chart.

• Provider Directory (ehr-patient-mgmt)

• Direction: Read-only.
• Data: providers, roles, specialties for routing and delegation.

Exception Handling

• Message delivery failure to Patient Portal:

• System retries; if persistent failure, flags message with error status and creates system alert in sender’s inbox.

• Attachment not accessible (e.g., result deleted):

• Show message with placeholder and note “Linked item no longer available”; maintain message text.

• Unauthorized reply attempt:

• If physician tries to reply to a patient they are not authorised to manage, system blocks and suggests reassigning to appropriate provider.

Paperless Transformation

Remaining Paper Touchpoints: None — fully digital for in-scope communications.

Inputs and Outputs

Inputs:

Outputs:

Post-conditions:

• Message thread updated with reply and status change
• Patient messages marked as clinical advice are persisted in EHR communication log
• Delegated messages have clear ownership transfer with linked items
• All message actions logged for audit compliance

SLA and Timing

WF-PHY-005: Schedule Management & On-Call

Process Flow

Actor: Physician
Trigger: Physician needs to view or manage schedule, patient lists, or on-call assignments
Pre-conditions:

• Authenticated session with manage_schedule permission
• Provider schedule and appointments maintained in scheduling module
• On-call rosters configured by department

1. Physician opens “Schedule & Patient List” screen (SCR-PHY-006).
2. System retrieves: - Daily/weekly schedule from appointments and provider schedule APIs. - Clinic patient lists and inpatient census from encounters. - On-call schedule from scheduling master data.
3. Screen displays: - Day/week calendar view. - List of upcoming appointments with patient summary cards. - Inpatient census for assigned wards. - Current on-call status and upcoming on-call shifts.
4. Physician taps an appointment or inpatient to open quick summary or full chart.
5. Decision: Physician wants to request a schedule swap (e.g., on-call or clinic session). - Selects slot and initiates “Swap Request”.
6. System prompts for: - Target provider (same specialty group). - Reason for swap. - Optional notes.
7. System sends swap request to Scheduling module: - Creates a pending swap record. - Sends physician_inbox_items to target provider and optionally to department head.
8. Target provider receives notification and views swap request details.
9. Decision (target provider): Accept or decline swap. - If accept → system updates schedule in scheduling and marks swap as approved. - If decline → system marks swap as declined and notifies requester.
10. If department approval is required (per policy), department head (CMO/Department Head role) receives an approval request and must approve before schedule is finalised.
11. Physician can set availability status (available, busy, in procedure, off-duty) which is stored in physician_preferences or scheduling profile and used by messaging/on-call routing.
12. System updates views and notifies relevant stakeholders of schedule changes.

Data Modified:

• Scheduling-owned tables — INSERT/UPDATE (swap requests, schedule changes)
• physician_inbox_items — INSERT (swap requests, approvals, notifications), UPDATE (status)
• physician_preferences — UPDATE (availability status, default views)
• physician_portal_sessions — UPDATE (last activity)

Mermaid Flowchart

Decision Points

1. Swap request vs simple availability change
   - If swap requested → workflow involves other providers and possibly department head.
   - If only availability changed → local update affecting routing and visibility.

2. Target provider acceptance
   - If accepted → proceed to schedule update (subject to approval).
   - If declined → requester notified; no schedule change.

3. Department approval requirement
   - If required and granted → schedule updated.
   - If denied → swap cancelled; both parties notified.

Integration Points

• Scheduling (scheduling)
• Direction: Bidirectional.
• Data: Provider schedule, appointments, inpatient census, swap requests (INT-PHY-006).

• Protocol: Internal API.

• EHR (ehr-patient-mgmt)

• Direction: Read-only.
• Data: Patient demographics and encounter details for patient cards.

Exception Handling

• Schedule conflict detected by Scheduling module:

• If swap would create overlapping assignments or violate staffing rules, Scheduling returns error; portal shows message and cancels swap.

• Target provider unavailable (no portal account):

• System prevents selection or suggests alternative providers.

• Network/API failure:

• Schedule view may show last cached schedule with warning; swap requests disabled until connectivity restored.

Paperless Transformation

Remaining Paper Touchpoints: Optional printed daily lists for specific clinics if mandated by local policy.

Inputs and Outputs

Inputs:

Outputs:

Post-conditions:

• Schedule view reflects current assignments and any approved swaps
• Swap requests have clear status (pending, accepted, declined, approved by dept head)
• Availability status is current and used by messaging/on-call routing
• All schedule changes logged with timestamps and actors

SLA and Timing

State Transition Diagram

WF-PHY-006: Mobile Clinical Documentation

Process Flow

Actor: Physician
Trigger: Physician needs to document a note while mobile
Pre-conditions:

• Active encounter in encounters
• Physician authenticated with sign_notes permission
• Note templates configured in Note Templates (Mobile) master data

1. Physician opens patient chart and navigates to “Notes” section (SCR-PHY-009).
2. System displays existing clinical_notes and a “New Note” button.
3. Physician taps “New Note” and selects note type (progress note, brief update, procedure note).
4. System shows list of mobile-optimised templates for selected note type.
5. Physician selects a template: - System auto-populates sections with patient data (vitals, meds, recent labs, problem list) via EHR API.
6. Physician uses voice dictation or typing to fill in subjective/objective/assessment/plan fields.
7. Decision: Physician may save as draft or proceed to sign: - If draft → note saved with status “draft” and visible only to author (or per policy).
8. Before signing, system validates: - Required fields completed (e.g., assessment and plan). - No conflicting documentation rules (e.g., duplicate procedure notes).
9. Physician reviews note preview and taps “Sign”.
10. System captures electronic signature (PIN/biometric) and sends note to EHR (ehr-patient-mgmt) via internal API.
11. EHR persists note in clinical_notes with author, timestamp, and source = “physician_portal”.
12. System updates local view and removes draft version if it existed.
13. If note is a key document (e.g., discharge summary), system may trigger additional workflows (e.g., notify care team, update discharge tasks).

Data Modified:

• clinical_notes (EHR-owned) — INSERT/UPDATE via integration
• physician_portal_sessions — UPDATE (last activity)
• physician_inbox_items — INSERT (optional: notifications for co-signature or review)
• Portal may maintain local metadata (e.g., last used template) in physician_preferences — UPDATE

Mermaid Flowchart

Decision Points

1. Draft vs signed note
   - Draft: stored but not part of official record; can be edited later.
   - Signed: becomes part of legal medical record; further edits require addenda.

2. Validation of required fields
   - If missing critical sections → cannot sign; user must complete.

3. EHR save success
   - If failure → note remains local draft; user informed and can retry later.

Integration Points

• EHR (ehr-patient-mgmt)
• Direction: Outbound.
• Data: clinical_notes with structured content, author, timestamps, source.
• Protocol: Internal API / FHIR DocumentReference or Composition.

Exception Handling

• Speech-to-text failure:

• User can switch to manual typing; error message shown but note creation continues.

• EHR API unavailable:

• Signed note queued locally with status “Pending upload”; user warned that note is not yet in central record; background sync retries.

• Conflict with concurrent documentation:

• If EHR detects conflicting note (e.g., duplicate procedure note), returns error; portal shows message and allows user to adjust note type or content.

Paperless Transformation

Remaining Paper Touchpoints: Paper consent forms or external documents may still be scanned into EHR.

Inputs and Outputs

Inputs:

Outputs:

Post-conditions:

• Signed note persisted in EHR as part of the legal medical record
• Draft notes (if saved) visible only to author per policy
• Note source clearly marked as "physician_portal" for provenance
• Any triggered downstream workflows (e.g., discharge tasks) initiated

SLA and Timing

WF-PHY-007: Clinical Handoff / Sign-Out

Process Flow

Actor: Physician (outgoing and incoming)
Trigger: Shift change or on-call transition
Pre-conditions:

• Authenticated session with clinical_handoff permission
• Handoff templates (I-PASS) configured in master data
• Patient assignments available from encounters and care team data

1. Outgoing physician opens “Clinical Handoff” screen (SCR-PHY-007).
2. System retrieves patient list for handoff: - Assigned inpatients, ED board, or on-call panel from encounters and scheduling.
3. Physician selects which patients to include in handoff.
4. For each patient, system displays I-PASS template fields: - Illness severity, patient summary, action list, situation awareness, contingency plan.
5. Physician fills in or updates handoff fields, optionally using voice dictation.
6. System saves handoff data in handoff_communications as draft with status “in_progress”.
7. Once all patients are updated, physician selects incoming provider (e.g., on-call colleague) and taps “Send Handoff”.
8. System validates: - At least one patient included. - Incoming provider is valid and has appropriate role.
9. System updates handoff_communications.status to “sent” and sets handoff_datetime.
10. System creates physician_inbox_items for incoming provider with link to handoff and patient list.
11. Incoming provider opens handoff item from Unified Inbox or Handoff screen.
12. System displays structured I-PASS handoff for each patient with quick links to charts.
13. Incoming provider reviews and taps “Accept Handoff”.
14. System updates handoff_communications.status to “accepted” and sets acknowledged_datetime.
15. Any critical action items may generate clinical_task_items for the incoming provider.

Data Modified:

• handoff_communications — INSERT (new handoff), UPDATE (status, handoff_datetime, acknowledged_datetime, content)
• physician_inbox_items — INSERT (handoff notifications), UPDATE (status when accepted)
• clinical_task_items — INSERT (action items), UPDATE (when completed)
• physician_portal_sessions — UPDATE (last activity)

Mermaid Flowchart

Decision Points

1. Handoff completeness
   - If no patients selected or mandatory fields missing → cannot send; user prompted to complete.

2. Incoming provider validity
   - If provider not found or lacks appropriate role → error; user must choose another.

3. Incoming provider acceptance
   - If accepted → responsibility formally transferred; tasks created.
   - If not accepted (e.g., provider queries content) → handoff remains pending; may require clarification.

Integration Points

• EHR (ehr-patient-mgmt)
• Direction: Read-only.

• Data: Patient demographics, problems, recent results for context.

• Scheduling (scheduling)

• Direction: Read-only.
• Data: Care team assignments and on-call providers.

Exception Handling

• Handoff not accepted within defined time:

• System escalates via physician_inbox_items to on-call supervisor or department head.

• Network loss during handoff creation:

• Draft stored locally and synced when connection resumes; user notified.

• Data mismatch (patient no longer assigned):

• System flags patient as “no longer under your care” and suggests removing from handoff.

Paperless Transformation

Remaining Paper Touchpoints: None — handoff content is fully digital.

Inputs and Outputs

Inputs:

Outputs:

Post-conditions:

• Handoff record persisted with full I-PASS content and timestamps
• Incoming provider has received and acknowledged handoff
• Critical action items converted to tracked tasks
• Responsibility formally transferred with audit trail

SLA and Timing

State Transition Diagram

WF-PHY-008: Clinical Task Management

Process Flow

Actor: Physician, Nurse
Trigger: Task created from order, result, message, or manual entry
Pre-conditions:

• Authenticated session with manage_tasks permission
• Task lists configured or auto-created in clinical_task_lists

1. User opens “Task List” screen (SCR-PHY-008).
2. System loads: - Default clinical_task_lists for the user (e.g., “My Tasks”, “Team Tasks”). - Associated clinical_task_items with status, priority, due dates, and patient links.
3. User filters or sorts tasks by priority, due date, patient, or source (orders, results, messages).
4. Decision: User chooses to add a new manual task: - Taps “Add Task”.
5. System prompts for: - Task description, patient (optional), priority, due date/time, list, and notes.
6. System creates new clinical_task_items with status “open”.
7. For system-generated tasks (e.g., unsigned orders, abnormal results): - Tasks are auto-created by other modules and appear in the list with source_module and source_id.
8. User taps a task to view details and related context (e.g., opens patient chart, order, or result).
9. Decision: User may complete, defer, or delegate the task: - Complete → sets status to “completed” and completed_datetime. - Defer → updates due_datetime and possibly priority. - Delegate → selects another provider and adds instructions.
10. If delegated:
    • System updates clinical_task_items.delegated_to and may create a new task in delegate’s list or reassign list_id.
11. Overdue tasks are highlighted; escalation rules may create physician_inbox_items or notify supervisors.
12. Task metrics (completion rate, overdue rate) feed into KPIs.

Data Modified:

• clinical_task_lists — INSERT (if user creates new list), UPDATE (e.g., is_default)
• clinical_task_items — INSERT (manual tasks), UPDATE (status, due_datetime, delegated_to, completed_datetime, notes)
• physician_inbox_items — INSERT (escalation alerts), UPDATE (status)
• physician_portal_sessions — UPDATE (last activity)

Mermaid Flowchart

Decision Points

1. Manual vs system-generated tasks
   - Manual: created by user; flexible fields.
   - System-generated: created by other workflows; may have constraints (e.g., cannot delete until underlying issue resolved).

2. Task action (complete/defer/delegate)
   - Complete: closes task.
   - Defer: keeps task open but changes due date/priority.
   - Delegate: shifts responsibility to another user.

3. Escalation for overdue tasks
   - If overdue beyond threshold → escalation inbox items or notifications created.

Integration Points

• CPOE (cpoe)
• Direction: Inbound.

• Data: Tasks for unsigned orders, pending co-signatures.

• LIS/RIS (lis, ris)

• Direction: Inbound.

• Data: Tasks for pending critical result follow-up.

• Patient Portal (patient-portal)

• Direction: Inbound.
• Data: Tasks from patient messages requiring follow-up.

Exception Handling

• Task linked to deleted or closed context (e.g., cancelled order):

• System marks task as obsolete and suggests completion with note.

• Delegate not found or inactive:

• System prevents delegation and prompts user to choose another.

• Bulk actions errors:

• If user performs bulk complete/defer and some tasks fail (e.g., permission issues), system reports which tasks failed and why.

Paperless Transformation

Remaining Paper Touchpoints: None — task tracking is fully digital.

Inputs and Outputs

Inputs:

Outputs:

Post-conditions:

• All tasks reflect current status (open, completed, deferred, delegated)
• Completed tasks have completed_datetime set and are archived
• Delegated tasks have clear ownership with instructions recorded
• Overdue tasks escalated per configured rules
• Task metrics available for KPI reporting

SLA and Timing

State Transition Diagram

These eight workflows collectively enable mobile, paperless clinical practice for physicians and advanced practice providers in UAE facilities, while aligning with UAE PDPL, DOH/DHA/MOH requirements, and local HIE standards (NABIDH/Malaffi).