Patient Portal & Mobile App Workflows

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

Regulatory context (UAE): All workflows must comply with UAE Federal Decree-Law No. 45/2021 on Personal Data Protection (UAE PDPL), MOH/DHA/DOH policies on patient access to records, and HIE requirements for NABIDH (Dubai) and Malaffi (Abu Dhabi). Identity verification and consent capture must support Emirates ID and UAE Pass. Audit trails and access logs must be retained per local regulator retention policies.

WF-PPT-001: Patient Portal Registration & Activation

Process Flow

Actor(s): Patient, Registration Clerk (optional for in-person)
Trigger: Patient registers at facility or self-registers online/mobile
Pre-conditions:

• Patient demographic record exists in patients (MRN assigned) OR patient is creating a pre-registration record.
• Facility has configured UAE Pass integration and identity verification rules.
• Portal is configured with supported languages and terms of use.

1. Patient opens portal web or mobile app and selects “Register / Create Account”.
2. System asks patient to choose registration path: - a. “Use UAE Pass” (recommended), or
   - b. “Use Emirates ID + mobile OTP”.
3. If UAE Pass selected:
4. System redirects to UAE Pass OAuth 2.0 / OpenID Connect flow.
5. Patient authenticates with UAE Pass and grants consent to share identity attributes.
6. System receives ID token and profile (Emirates ID, full Arabic/English name, mobile, email).
7. If Emirates ID path selected:
8. Patient enters Emirates ID (e.g., 784-1990-1234567-1) and date of birth.
9. System validates format and queries patient_identifiers in ehr-patient-mgmt to find matching patient.
10. System sends OTP to patient’s registered mobile number (from patient_demographics) or to mobile entered if allowed by policy.
11. Patient enters OTP; system verifies within configured time window.
12. System displays matched patient details (masked) and asks patient to confirm identity (e.g., last 4 digits of mobile or PO Box).
13. System checks if a portal_accounts record already exists for this patient: - If active account exists → stop and prompt patient to use “Forgot Password” flow. - If inactive/pending account exists → resume activation.
14. Patient enters/confirm contact details (email, mobile) and sets: - Username (or uses email as username), - Password (meeting complexity rules), - MFA method (SMS OTP, authenticator app, or device biometric if mobile).
15. System creates or updates portal_accounts: - Links patient_id and optionally user_id (if shared auth), - Stores email, phone, activation_status = PENDING_VERIFICATION, language_preference default (English or Arabic).
16. Patient selects preferred language (English/Arabic) and notification channels (email/SMS/push) on a preferences screen.
17. System creates/updates portal_preferences for the account (notification_email, notification_sms, notification_push, language, display_theme).
18. System displays terms of use and UAE PDPL data processing consent (bilingual). Patient must explicitly accept.
19. On acceptance, system:
    • Updates portal_accounts.activation_status = 'ACTIVE', activation_date = NOW(), uae_pass_linked = TRUE/FALSE as applicable.
    • Logs a new row in portal_sessions for first login.
20. System sends welcome notification (email/SMS/push) with basic portal guide via portal_notifications.
21. For dependents (<18 or per facility policy), system offers “Add child / dependent”:
    • Parent enters dependent Emirates ID / MRN.
    • System verifies relationship (from EHR or via manual approval queue).
    • On approval, system inserts proxy_access_grants with access_level and expiry.
22. Patient is redirected to dashboard (SCR-PPT-001).

Data Modified:

• portal_accounts — INSERT/UPDATE
• portal_preferences — INSERT/UPDATE
• portal_sessions — INSERT (initial session)
• portal_notifications — INSERT
• proxy_access_grants — INSERT (if proxy configured)
• audit_logs (module-level, if present) — INSERT for consent and identity verification

Mermaid Flowchart

Decision Points

1. Registration method: - If UAE Pass available and patient chooses it → use OIDC; higher assurance. - If Emirates ID path chosen → rely on OTP + demographic match.
2. Patient match: - If no patient found by Emirates ID → show guidance to contact registration desk; do not create orphan portal account.
3. Existing portal account: - If active account exists → block duplicate registration, direct to account recovery. - If pending/inactive → reuse and complete activation.
4. Consent acceptance: - If patient declines UAE PDPL consent or terms → do not activate account; mark record for follow-up.

Integration Points

• EHR & Patient Management (ehr-patient-mgmt):
• Read: patients, patient_demographics, patient_identifiers for Emirates ID, MRN, mobile, DOB.
• Write: none directly; demographic updates handled in separate workflows.
• UAE Pass (INT-PPT-008):
• OAuth 2.0 / OpenID Connect for identity verification and SSO.
• Data: Emirates ID, name, mobile, email, assurance level.
• Identity / Auth service:
• Shared users table if central auth is used; link portal_accounts.user_id.
• Notification service:
• Uses portal_notifications to send email/SMS/push for welcome and OTP (if internal).

Exception Handling

• No patient match by Emirates ID:
• Do not create portal account.
• Display localized message: “We could not find your record. Please contact Registration or call +971 4 XXX XXXX.”
• Log event for registration team follow-up.
• OTP failures / UAE Pass timeout:
• Allow limited retries (e.g., 3 attempts).
• After threshold, temporarily lock registration for that Emirates ID and log security event.
• Duplicate account attempt:
• Show non-technical message; provide “Forgot Password” link.
• Log as security-relevant event.
• Consent not accepted:
• Do not activate account; keep activation_status = 'PENDING_CONSENT'.
• Display explanation referencing UAE PDPL rights and how to request offline access.
• Integration outage (UAE Pass or SMS gateway):
• Show banner “Online registration temporarily unavailable”.
• Allow in-person registration via Registration Clerk who can complete activation later.

Paperless Transformation

Remaining Paper Touchpoints: Some facilities may still use paper forms for complex guardianship/legal proxy documentation; these can be scanned into patient_documents and referenced by the proxy workflow.

Inputs and Outputs

Inputs:

Outputs:

Post-conditions:

• Patient has an active portal account linked to their MRN and Emirates ID
• UAE PDPL consent recorded with timestamp and audit trail
• MFA method configured for subsequent logins
• Proxy access for dependents established (if applicable)
• Patient can access all portal features

SLA and Timing

State Transition Diagram

WF-PPT-002: Online Appointment Booking

Process Flow

Actor: Patient
Trigger: Patient wants to schedule, reschedule, or cancel an appointment
Pre-conditions:

• Patient has an active portal_accounts record and is authenticated.
• Scheduling module is integrated and exposes provider availability via FHIR (INT-PPT-002).
• Facility booking rules (lead times, telehealth eligibility, referral requirements) are configured.

1. Patient logs into portal/app and navigates to “Book Appointment”.
2. Patient selects: - a. Self or dependent (if proxy access exists), and
   - b. Visit type (e.g., in-person, telehealth, new, follow-up).
3. Patient searches for provider or clinic by: - Provider name, specialty, facility, or preferred emirate.
4. System queries Scheduling module for matching providers and available slots (FHIR Practitioner, Schedule, Slot).
5. System displays provider profiles (photo, specialty, languages, location, next available slot, patient ratings).
6. Patient selects a provider and preferred date range.
7. System retrieves and displays available time slots, applying: - Provider working hours, - Telehealth eligibility, - Gender preference (if configured), - DOH/DHA rules (e.g., referral required for some services).
8. Patient selects a time slot and confirms appointment type (in-person vs telehealth).
9. System checks: - a. Referral/authorization requirement (via policy-contract-mgmt / billing-claims),
   - b. Double-booking conflicts for patient,
   - c. Any pre-visit forms or tests required.
10. If referral/authorization required and missing:
    • System informs patient and may allow provisional booking with “Pending Authorization” status or block booking per policy.
11. If pre-visit questionnaire is required, system prompts patient to complete it immediately or later (creates patient_submitted_forms stub).
12. Patient confirms booking; system creates appointment in Scheduling module (FHIR Appointment) with source = portal.
13. Scheduling module returns confirmation (appointment_id, status, location/telehealth link).
14. System:
    • Stores reference to appointments.appointment_id,
    • Sends confirmation via portal_notifications (email/SMS/push),
    • Offers ICS calendar download / add-to-calendar.
15. Patient can view, reschedule, or cancel existing appointments from “My Appointments”:
    • Reschedule triggers similar slot search and updates appointment.
    • Cancellation updates appointment status and may enforce cancellation rules (e.g., no cancellation within 24 hours).

Data Modified:

• appointments (in Scheduling module) — INSERT/UPDATE (via API)
• telehealth_sessions — INSERT (for telehealth bookings, pre-created stub with scheduled_datetime)
• patient_submitted_forms — INSERT (for pre-visit questionnaires)
• portal_notifications — INSERT
• portal_audit_log (if present) — INSERT for booking/reschedule/cancel actions

Mermaid Flowchart

Decision Points

1. Referral/authorization requirement: - If required and missing:
   • Option A: Block booking and show instructions (upload referral, call center).
   • Option B: Allow provisional booking with “Pending Authorization” and notify billing/authorization team.
2. Pre-visit forms: - If required → create patient_submitted_forms stub and prompt patient. - If optional → allow patient to skip but remind before visit.
3. Reschedule vs cancel: - If within restricted window (e.g., <24 hours) → may block cancellation or show warning and require confirmation.

Integration Points

• Scheduling module (scheduling, INT-PPT-002):
• FHIR Appointment, Schedule, Slot for availability and booking.
• Data: provider_id, patient_id, appointment type, location, telehealth flag.
• Billing & Claims (billing-claims) / Policy & Contract (policy-contract-mgmt):
• Read: referral/authorization status, coverage rules for visit type.
• Telehealth subsystem:
• For telehealth appointments, create telehealth_sessions stub and generate secure join URLs.
• Notification service:
• Confirmation, reminder, and change notifications via portal_notifications.

Exception Handling

• Slot no longer available (race condition):
• Scheduling API returns conflict.
• System informs patient: “This slot has just been taken. Please choose another time.”
• Refresh available slots.
• Referral check service unavailable:
• System may:
  • Allow booking but flag “Authorization status unknown”, or
  • Temporarily disable online booking for affected services.
• Telehealth not supported for selected provider/service:
• Hide telehealth option or show explanatory message.
• Cancellation policy violation:
• If patient attempts to cancel within restricted window, show policy and contact number; optionally allow request for cancellation that staff must approve.

Paperless Transformation

Remaining Paper Touchpoints: Some external referrals may still arrive as paper/fax and be scanned into patient_documents before being recognized by the system.

Inputs and Outputs

Inputs:

Outputs:

Post-conditions:

• Appointment confirmed in Scheduling module with portal as source
• Patient has confirmation with appointment details and any required actions
• Pre-visit forms queued (if applicable)
• Telehealth session stub created (if telehealth appointment)
• Reminders scheduled for upcoming appointment

SLA and Timing

State Transition Diagram

WF-PPT-003: View Health Records

Process Flow

Actor: Patient
Trigger: Patient wants to view clinical information (results, medications, notes)
Pre-conditions:

• Patient has active portal account and is authenticated (password/MFA or biometric).
• Release rules for results and notes are configured (e.g., delay for sensitive results).
• Integrations with EHR, LIS, RIS, and PIS are operational.

1. Patient logs into portal/app and navigates to “My Health Records”.
2. System performs authorization check: - Confirms patient or proxy access rights (via proxy_access_grants).
3. System loads health summary: - Active problems (from patient_problems), - Allergies (patient_allergies), - Active medications (from PIS/EHR), - Upcoming appointments.
4. Patient selects a category: Lab Results, Radiology, Medications, Allergies, Problems, Immunizations, Clinical Notes, Vitals.
5. For Lab Results: - System queries LIS via FHIR DiagnosticReport/Observation or EHR cache. - Applies result release rules (e.g., 3-day delay for certain pathology results). - Displays list with date, test name, status, and flags abnormal values. - Provides trend charts for key LOINC-coded tests (e.g., HbA1c, creatinine).
6. For Radiology: - System queries RIS/EHR for finalized reports (FHIR DiagnosticReport). - Applies release delay if configured. - Displays report text and optionally key images (via DICOM viewer link).
7. For Medications: - System retrieves active and historical medication list (FHIR MedicationRequest/MedicationStatement). - Displays patient-friendly names, instructions, start/stop dates.
8. For Clinical Notes: - System retrieves notes from EHR that are marked “patient-visible”. - Applies any DOH/DHA policies on psychiatric or sensitive notes.
9. Patient can: - Filter by date range, provider, or facility. - Download selected records as bilingual PDF. - Request FHIR export (e.g., for NABIDH/Malaffi or personal health apps).
10. System logs each access event (who, when, what category) for UAE PDPL audit.
11. If patient is proxy viewing dependent records, system enforces access_level (e.g., may hide certain adolescent data per facility policy).

Data Modified:

• portal_sessions — UPDATE (last activity timestamp)
• portal_audit_log / access_logs — INSERT (record view events)
• No clinical data is modified; all reads from EHR/LIS/RIS/PIS.

Mermaid Flowchart

Decision Points

1. Authorization / proxy rights: - If proxy has limited access_level → hide restricted categories (e.g., reproductive health for adolescents).
2. Result release rules: - If result is within delay window or marked “provider review first” → withhold from display and show message “Your doctor is reviewing this result.”
3. Export type: - If patient requests FHIR export → generate time-limited download link or push to external app per consent.

Integration Points

• EHR & Patient Management (ehr-patient-mgmt):
• Read: problems, allergies, immunizations, vitals, clinical notes, documents.
• LIS (lis, INT-PPT-003):
• Read: lab results via FHIR DiagnosticReport/Observation.
• RIS (ris, INT-PPT-004):
• Read: radiology reports via FHIR DiagnosticReport and DICOM viewer.
• PIS (pis, INT-PPT-005):
• Read: medication list and dispensing status.
• NABIDH / Malaffi HIE:
• Optional: cross-facility records if connected, respecting patient consent.

Exception Handling

• Data source unavailable (LIS/RIS/PIS/EHR):
• Show partial data with clear banners: “Some information is temporarily unavailable. Please try again later.”
• Log integration error for IT.
• Result flagged as sensitive:
• Do not display; show generic message and encourage patient to contact provider.
• Export failure:
• If PDF/FHIR export fails, show error and allow retry; log technical details for support.

Paperless Transformation

Remaining Paper Touchpoints: Some patients may still request certified paper copies for legal purposes; these are generated from the EHR but outside the portal workflow.

Inputs and Outputs

Inputs:

Outputs:

Post-conditions:

• Patient has viewed requested health information
• All access events logged for UAE PDPL audit compliance
• Result release rules enforced (withheld results not displayed)
• Proxy access restrictions applied for dependent records

SLA and Timing

WF-PPT-004: Secure Messaging

Process Flow

Actor(s): Patient, Provider
Trigger: Patient has non-urgent clinical question or provider initiates message to patient
Pre-conditions:

• Patient has active portal account.
• Provider has active user account and is enabled for portal messaging.
• Message routing rules (provider inbox, department pools) are configured.

1. Patient navigates to “Messages” and selects “New Message”.
2. Patient chooses: - Recipient provider or department, - Subject, - Message body (free text).
3. System displays warning banner: “Not for emergencies. In case of emergency, call 998/999.”
4. Patient optionally: - Marks message as “Urgent (non-emergency)”, - Attaches files (images, PDFs) within allowed size and type.
5. System validates: - Recipient selection, - Message length, - Attachment size/type, - That message is not empty.
6. System creates a message thread if new, or appends to existing thread: - Inserts into portal_messages with sender_type = PATIENT, recipient_type = PROVIDER or DEPARTMENT, sent_datetime = NOW(), is_urgent flag.
7. System routes message to provider portal / physician portal inbox (INT-PPT-007) and optionally to EHR in-basket.
8. Provider receives notification (internal + optional email/SMS) and opens message in Physician Portal.
9. Provider reviews message and responds: - Types reply, may attach educational documents or instructions. - May link reply to an encounter (existing or new teleconsultation).
10. System inserts provider reply into portal_messages with sender_type = PROVIDER, updates thread, and sets read/unread flags.
11. Patient receives notification via portal_notifications and sees threaded conversation in portal.
12. System may automatically file message thread into EHR as part of the patient record (documentation) with appropriate encounter linkage.
13. SLA monitoring: - Background job checks for messages without provider response beyond configured SLA (e.g., 24 hours) and escalates or sends reminders.

Data Modified:

• portal_messages — INSERT/UPDATE (read_datetime, thread_id)
• portal_notifications — INSERT
• portal_audit_log — INSERT (message sent/received events)
• EHR messaging tables (in Physician Portal module) — INSERT/UPDATE

Mermaid Flowchart

Decision Points

1. Urgent flag: - If patient marks as urgent → system may highlight in provider inbox and enforce shorter SLA, but still show “not for emergencies” warning.
2. Recipient type: - If department selected → route to shared inbox; assignment rules determine responsible provider.
3. Encounter linkage: - If message content indicates clinical decision (e.g., medication change) → provider may be required to link to an encounter for billing and medico-legal reasons.

Integration Points

• Physician Portal (physician-portal, INT-PPT-007):
• Bidirectional messaging API; provider inbox and replies.
• EHR (ehr-patient-mgmt):
• Optional: store message threads as part of patient record or encounter documentation.
• Notification service:
• Outbound notifications for new messages and reminders.

Exception Handling

• Invalid attachments:
• Reject file and show message: “Only images (JPG/PNG) and PDFs up to 10 MB are allowed.”
• Provider inbox unavailable:
• If Physician Portal is down, queue messages and show “Your message has been received; response may be delayed.”
• Misrouted messages:
• Admin tools to reassign threads to correct provider/department; logged in audit trail.

Paperless Transformation

Remaining Paper Touchpoints: None for this workflow — fully digital communication channel.

Inputs and Outputs

Inputs:

Outputs:

Post-conditions:

• Message delivered to provider inbox with appropriate priority
• Patient can track message status and view threaded conversation
• SLA monitoring active for provider response time
• Message optionally linked to encounter for clinical documentation

SLA and Timing

WF-PPT-005: Prescription Refill Request

Process Flow

Actor(s): Patient, Provider
Trigger: Patient needs medication refill for existing prescription
Pre-conditions:

• Patient has active portal account.
• Medication list is synchronized with PIS/EHR.
• Facility policy allows portal-based refill requests for eligible medications.

1. Patient navigates to “Medications / Refills”.
2. System retrieves current and recent medications from PIS/EHR (FHIR MedicationRequest, MedicationDispense).
3. System displays list with: - Medication name, dose, instructions, - Remaining refills (if tracked), - Last dispensed date, - Refill eligibility status (e.g., “Refillable”, “Too early”, “Contact provider”).
4. Patient selects one or more medications and clicks “Request Refill”.
5. System prompts patient to: - Confirm quantity (e.g., 30 days), - Select pharmacy (facility pharmacy or preferred external pharmacy from profile), - Add optional note to provider.
6. System validates: - That each medication is eligible for refill (not expired, not controlled if policy disallows, not too early).
7. For each requested medication: - System creates a refill request record (in PIS/CPOE context) and a message to the prescribing provider via portal_messages or provider refill queue.
8. Provider reviews refill request in Physician Portal: - Approve as requested, - Modify (change quantity, switch medication), - Deny (with reason).
9. System updates refill request status and notifies patient via portal_notifications.
10. If approved:
    • System sends electronic prescription/order to PIS (CPOE integration) for dispensing.
    • PIS updates dispensing status; portal shows “Ready for pickup” or “In process”.
11. Patient picks up medication or receives delivery per pharmacy workflow.

Data Modified:

• PIS / CPOE tables for refill orders — INSERT/UPDATE
• portal_messages — INSERT (refill request thread)
• portal_notifications — INSERT
• portal_audit_log — INSERT (refill request events)

Mermaid Flowchart

Decision Points

1. Refill eligibility: - If medication is controlled or requires in-person review → block refill and suggest appointment. - If refill is too early based on last dispense date → show message and optionally allow provider message.
2. Provider decision: - Approve → direct to PIS. - Modify → treat as new order; may require additional checks. - Deny → require reason to be communicated to patient.

Integration Points

• PIS (pis, INT-PPT-005):
• Read: medication list, dispensing history.
• Write: refill orders / MedicationRequest updates.
• CPOE (cpoe):
• For provider order entry of modified/denied refills that become new prescriptions.
• Physician Portal:
• Refill approval queue and messaging.

Exception Handling

• Medication list not available:
• Show message: “We are unable to retrieve your medications at this time.”
• PIS integration failure during approval:
• Queue order for retry; inform provider and patient that processing may be delayed.
• Patient selects non-eligible medication:
• Provide clear explanation and link to book appointment or send message.

Paperless Transformation

Remaining Paper Touchpoints: Some pharmacies may still print labels and paper information leaflets, but refill initiation and approval are fully digital.

Inputs and Outputs

Inputs:

Outputs:

Post-conditions:

• Refill request submitted and routed to prescribing provider
• Provider has reviewed and taken action (approve, modify, or deny)
• Approved refills sent to PIS for dispensing
• Patient notified of status at each stage

SLA and Timing

State Transition Diagram

WF-PPT-006: Bill View & Online Payment

Process Flow

Actor: Patient
Trigger: Patient statement generated or patient wants to view/pay outstanding balance
Pre-conditions:

• Patient has active portal account.
• Billing & Claims module exposes statements and balances via API (INT-PPT-006).
• Payment gateway is configured and PCI DSS compliant.

1. Patient navigates to “Billing & Payments”.
2. System queries Billing & Claims for: - Account summary (total outstanding, by facility), - List of recent statements and invoices (patient_invoices).
3. System displays: - Outstanding balance, - Insurance vs patient responsibility, - Links to itemized statements (bilingual).
4. Patient selects a statement to view details: - Service dates, CPT codes, charges, insurance payments, adjustments, patient share.
5. Patient chooses to: - Pay full balance, or - Pay custom amount, or - Enroll in payment plan (if offered).
6. System checks: - Minimum payment amount, - Eligibility for payment plan (balance threshold, facility rules).
7. Patient selects payment method: - Credit/debit card, Apple Pay, bank transfer (if supported).
8. System redirects or opens embedded payment gateway form with: - Invoice reference, amount, patient details (tokenized).
9. Patient completes payment on gateway; gateway returns success/failure callback.
10. On success:
    • System records payment in Billing & Claims (via API),
    • Creates patient_payments entry (in Billing module),
    • Generates digital receipt.
11. System updates portal view to reflect new balance and shows receipt (downloadable PDF).
12. If patient disputes a charge:
    • Patient clicks “Dispute” on line item or statement.
    • System creates a billing inquiry ticket (in Billing module) and sends notification to billing team.

Data Modified:

• patient_invoices / patient_payments (Billing module) — INSERT/UPDATE
• portal_notifications — INSERT (payment confirmation)
• portal_audit_log — INSERT (payment and dispute events)

Mermaid Flowchart

Decision Points

1. Payment plan eligibility: - If balance above threshold and patient meets criteria → offer installment plan.
2. Payment success: - If gateway declines or error occurs → show reason (if allowed) and allow retry or alternative method.
3. Dispute vs pay: - If patient disputes → block payment for disputed line items per facility policy or allow partial payment.

Integration Points

• Billing & Claims (billing-claims, INT-PPT-006):
• Read: statements, balances, invoice details.
• Write: payment records, dispute tickets.
• Payment Gateway (INT-PPT-009):
• REST API for payment processing and refunds.
• Notification service:
• Payment confirmations and reminders.

Exception Handling

• Billing API unavailable:
• Show message: “Billing information is temporarily unavailable.”
• Payment gateway timeout:
• Show “We could not confirm your payment. Please check your bank before retrying.”
• Mark transaction as “Pending” and reconcile later via gateway reconciliation job.
• Duplicate payment submission:
• Use idempotency keys with gateway; if duplicate detected, show existing receipt.

Paperless Transformation

Remaining Paper Touchpoints: Some patients may still request printed statements or receipts at the facility, but core workflow is digital.

Inputs and Outputs

Inputs:

Outputs:

Post-conditions:

• Payment recorded and reflected in billing system
• Patient has digital receipt and updated balance view
• Disputes tracked and routed to billing team
• Payment gateway reconciliation data available

SLA and Timing

WF-PPT-007: Telehealth Visit

Process Flow

Actor(s): Patient, Provider
Trigger: Telehealth appointment scheduled via portal or call center
Pre-conditions:

• Telehealth appointment exists in appointments with telehealth flag.
• Telehealth platform integrated (WebRTC-based) and compliant with UAE PDPL and local telecom rules.
• Patient has compatible device and internet connection.

1. Prior to visit, system sends reminder notification with telehealth link via portal_notifications (email/SMS/push).
2. Patient logs into portal/app and navigates to “My Appointments” then selects telehealth visit.
3. System performs device check: - Browser/app compatibility, - Camera and microphone access, - Network bandwidth.
4. If device check fails, system displays troubleshooting tips and option to switch device.
5. At appointment time, patient clicks “Join Visit” and enters virtual waiting room.
6. System creates/updates telehealth_sessions record: - scheduled_datetime, patient_account_id, provider_id, platform, connection_quality (initial).
7. Provider opens Physician Portal and joins telehealth session from their side.
8. When both parties are connected: - System updates telehealth_sessions.join_datetime_patient and join_datetime_provider.
9. Provider conducts consultation: - Reviews patient record in EHR, - Documents notes in EHR, - Places orders (labs, meds, referrals) via CPOE if needed.
10. If recording is allowed by policy:
    • System prompts for explicit recording consent (per UAE PDPL) and stores recording_consent flag in telehealth_sessions.
11. At end of visit:
    • Provider ends session; patient is disconnected.
    • System sets telehealth_sessions.end_datetime and calculates duration_minutes and connection_quality.
12. System generates visit summary in EHR and makes it available in portal (after any configured delay).
13. Billing & Claims module receives telehealth encounter details for charge capture.
14. Patient is prompted to complete satisfaction survey (portal_feedback insert).

Data Modified:

• telehealth_sessions — INSERT/UPDATE
• portal_notifications — INSERT (reminders)
• portal_feedback — INSERT
• portal_audit_log — INSERT (session events)
• EHR encounter and documentation tables — INSERT/UPDATE
• Billing encounter/charge tables — INSERT

Mermaid Flowchart

Decision Points

1. Device check: - If fails → patient can still join but with warning, or be advised to reschedule.
2. Recording consent: - If recording is enabled by facility but patient declines → no recording; only metadata stored.
3. No-show: - If patient does not join within grace period → provider may mark as no-show; billing rules apply accordingly.

Integration Points

• Scheduling (scheduling):
• Telehealth appointments and status updates.
• EHR (ehr-patient-mgmt):
• Encounter documentation and visit summary.
• CPOE / PIS / LIS / RIS:
• Orders placed during telehealth visit.
• Billing & Claims (billing-claims):
• Telehealth encounter charges.
• Telehealth platform:
• WebRTC session management, recording (if used).

Exception Handling

• Connectivity loss:
• If patient disconnects, system allows rejoin within appointment window.
• If provider disconnects, patient sees message and may wait or reschedule.
• Platform outage:
• Show banner and offer conversion to phone call (documented in EHR) or rescheduling.
• Privacy breach risk (e.g., patient in public place):
• Provider can advise patient to move to private area; may terminate if unsafe.

Paperless Transformation

Remaining Paper Touchpoints: Some facilities may still use paper consent for first-time telehealth use; these can be digitized and linked to the patient record.

Inputs and Outputs

Inputs:

Outputs:

Post-conditions:

• Telehealth consultation completed and documented in EHR
• Visit summary available to patient in portal (after configured delay)
• Billing charges captured for telehealth encounter
• Session quality metrics recorded for analytics
• Patient feedback collected

SLA and Timing

State Transition Diagram

WF-PPT-008: Digital Forms & Consent

Process Flow

Actor: Patient
Trigger: Pre-visit forms required, consent needed, or demographics update requested
Pre-conditions:

• Form templates and consent types are configured in master data.
• Patient has active portal account.
• E-signature method (drawn signature, checkbox + OTP) is configured per UAE legal requirements.

1. Patient receives notification to complete forms (e.g., pre-registration, medical history, consent) via portal_notifications.
2. Patient navigates to “Forms & Consents” and sees list of: - Pending forms, - Completed forms.
3. Patient selects a pending form (e.g., “New Patient Registration”, “Surgery Consent”).
4. System loads form template and pre-populates fields from EHR (patient_demographics, existing consents) where applicable.
5. Patient reviews and completes remaining fields: - Demographics (address, contact), - Medical history, - Insurance details, - Specific consent options (e.g., data sharing with NABIDH/Malaffi).
6. System validates required fields and shows errors inline.
7. For consents requiring signature: - Patient provides e-signature (signature pad) or confirms via OTP to registered mobile. - System records signature metadata (timestamp, IP, device).
8. Patient submits form.
9. System creates/updates patient_submitted_forms: - form_type, form_data_json, submitted_datetime, processed = FALSE, target_module.
10. Background integration or workflow engine:
    • Routes demographic updates to EHR (ehr-patient-mgmt),
    • Routes consent data to patient_consents,
    • Routes clinical history to appropriate modules.
11. On successful processing:
    • System sets patient_submitted_forms.processed = TRUE, processed_by (system or user), and processed_datetime.
12. Patient sees confirmation and can view read-only copy of submitted form/consent.

Data Modified:

• patient_submitted_forms — INSERT/UPDATE
• patient_consents (EHR module) — INSERT/UPDATE
• patient_demographics (EHR module) — UPDATE
• portal_notifications — INSERT (reminders, confirmations)
• portal_audit_log — INSERT (form submission and consent events)

Mermaid Flowchart

Decision Points

1. Signature requirement: - If consent type requires strong authentication → enforce OTP-based confirmation in addition to signature pad.
2. Processing success: - If automatic mapping fails (e.g., invalid insurance policy) → flag for manual review by registration staff.
3. Data overwrite rules: - If patient-submitted demographics conflict with existing data → may require staff approval before updating EHR.

Integration Points

• EHR (ehr-patient-mgmt):
• Demographics updates, medical history, and consent records.
• Patient Access / Pre-registration module (patient-access):
• Pre-registration forms and visit-specific consents.
• NABIDH / Malaffi:
• Consent flags for HIE data sharing, if applicable.

Exception Handling

• Form template changed mid-completion:
• Version forms; if template updated, allow patient to continue with version they started or restart if required.
• Signature capture failure:
• Provide fallback (e.g., OTP-only confirmation) if signature pad fails.
• Processing errors:
• Log detailed error; notify responsible team; show generic “Your form has been submitted and will be reviewed” to patient.

Paperless Transformation

Remaining Paper Touchpoints: Some high-risk procedures may still require paper consent per facility legal policy; these can be scanned and linked to the patient record.

Inputs and Outputs

Inputs:

Outputs:

Post-conditions:

• Form data submitted and routed to appropriate target modules
• Consents recorded with e-signature metadata and timestamp
• Demographics updated (or queued for staff review if conflicts detected)
• Patient can view read-only copy of submitted forms
• Processing status tracked (pending, processed, error)

SLA and Timing