EHR & Patient Management Workflows

This document defines nine core workflows for the EHR & Patient Management module. These workflows cover patient registration, demographics maintenance, MPI/duplicate resolution, allergy and problem list management, clinical documentation, document and consent management, and privacy controls (break‑the‑glass).

Regulatory context (UAE):
- UAE PDPL (Federal Decree-Law No. 45/2021) — governs personal data processing, consent, data subject rights, and breach notification.
- MOH / DOH / DHA — licensing, health information exchange (HIE) policies, and minimum dataset requirements.
- NABIDH (Dubai) / Malaffi (Abu Dhabi) — HIE platforms requiring timely, accurate ADT and clinical document submission.
- ADHICS / DHA Security Standards / TDRA/NESA — cybersecurity and audit requirements for access logging and BTG.

All workflows assume role-based access control (RBAC) using users, roles, permissions, and full auditability via audit_log.

WF-EHRPATIENTMGMT-001: Patient Registration (New)

Process Flow

Actor: Registration Clerk
Trigger: Patient arrives at facility (walk-in, scheduled appointment) or pre-registration via call/online request
Pre-conditions:

• Registration Clerk authenticated with register_patient permission.
• Facility and registration location configured in facilities / locations.
• Emirates ID reader (if used) and scanner devices online.

1. Clerk opens Patient Search screen (SCR-EHR-001) and selects facility context.
2. Clerk searches for existing patient using one or more: - Emirates ID, MRN, passport number, mobile number, name + DOB.
3. System queries: - patients, patient_identifiers, patient_demographics, duplicate_suspects and displays: - Exact matches, probable matches (with match score), and “no results”.
4. Decision: Potential match found?
   - If yes, clerk verifies identity (ID card, verbal confirmation of DOB, mobile).
   - If no, proceed to new registration.
5. Decision: Identity confirmed as existing patient?
   - If yes, system opens existing record; workflow ends (no new patient created).
   - If no / uncertain, clerk flags as “possible duplicate” and continues with new registration (system will create duplicate_suspects entry later via MPI job — outside this workflow).
6. Clerk opens Patient Registration Form (SCR-EHR-002) in “New” mode.
7. Clerk captures core identity data: - English/Arabic names, DOB, gender, nationality, Emirates ID, passport, visa details. - System validates Emirates ID format (784-YYYY-NNNNNNN-C) and DOB plausibility.
8. Clerk captures contact and socio-demographic details: - Mobile, email, PO Box, emirate, city, emergency contacts, marital status, occupation, employer.
9. Clerk captures insurance information: - Payer, plan, member ID, card expiry, coverage start/end. - System calls Insurance Eligibility integration (INT-EHR-007) to validate member status.
10. Clerk scans/uploads Emirates ID and insurance card via Document Management (SCR-EHR-008):
    • System creates patient_documents entries with type “ID – Emirates ID”, “Insurance Card”.
11. System assigns MRN:
    • Auto-generated based on facility-specific rules (e.g., prefix per facility) and ensures uniqueness in patients.mrn.
12. System creates:
    • patients row (core identity and flags).
    • patient_demographics row (current demographic snapshot).
    • patient_identifiers rows for MRN, Emirates ID, passport, insurance member ID.
13. System creates initial encounter shell (if appointment exists or walk-in):
    • Calls Scheduling module (INT-EHR-003) to create or link encounters record.
14. Clerk presents PDPL-compliant data processing consent (general treatment + data processing + HIE sharing) via Consent Management (SCR-EHR-009):
    • Patient signs digitally; system inserts patient_consents row and stores signed document in patient_documents.
15. For inpatients, system prints wristband with MRN, name, DOB, barcode; for outpatients, prints appointment slip if needed.
16. System:
    • Sends ADT A04 (or A01 for admitted) to NABIDH/Malaffi (INT-EHR-001/002).
    • Logs all actions in audit_log (registration start/end, data created, consents).

Data Modified:

• patients — INSERT
• patient_demographics — INSERT
• patient_identifiers — INSERT (multiple)
• patient_documents — INSERT (ID, insurance scans)
• patient_consents — INSERT
• audit_log — INSERT (multiple events)
• encounters (in Scheduling module) — INSERT via integration (not owned here)

Mermaid Flowchart

Decision Points

1. Potential match found? - If yes → verify identity; avoid duplicate creation. - If no → proceed with new patient creation.
2. Identity confirmed as existing? - If yes → open existing record; do not create new patients row. - If no/uncertain → proceed but flag for MPI review.
3. Insurance eligibility valid? - If yes → mark insurance as verified; allow normal billing. - If no → mark as unverified; prompt for self-pay or alternative payer.
4. Inpatient vs outpatient? - Inpatient → wristband printing mandatory. - Outpatient → appointment slip optional.

Integration Points

• Scheduling (INT-EHR-003)
• Direction: Bidirectional
• Data: Patient demographics, encounter creation/linkage
• Trigger: New registration or walk-in without existing encounter.
• Billing & Claims (INT-EHR-004)
• Direction: Outbound
• Data: Patient demographics, insurance details, encounter shell
• Trigger: Registration completion or insurance update.
• NABIDH / Malaffi (INT-EHR-001 / INT-EHR-002)
• Direction: Bidirectional
• Data: ADT A04/A01 messages with demographics and encounter info
• Trigger: New patient registration, admission.
• Insurance Eligibility (INT-EHR-007)
• Direction: Bidirectional
• Data: Payer, member ID, DOB, name
• Trigger: Insurance details entry or update.

Exception Handling

• Duplicate MRN risk:
• System enforces unique MRN constraint; if conflict, regenerate MRN and log incident.
• Emirates ID validation failure:
• System blocks saving Emirates ID; allows registration with alternative ID, flags record as “ID not verified”.
• Insurance API timeout/error:
• System marks insurance status as “pending verification”; allows registration but flags for follow-up.
• HIE (NABIDH/Malaffi) transmission failure:
• ADT message queued with retry; if repeated failures, alert integration admin; registration not blocked.
• Consent refusal:
• System records refusal in patient_consents with status “declined”; may restrict data sharing to HIE per facility policy.

Paperless Transformation

Remaining Paper Touchpoints: Optional printed wristbands and appointment slips; can be minimized if facility uses mobile/virtual tokens.

Inputs and Outputs

Inputs:

Outputs:

Post-conditions:

• Patient record exists with unique MRN and validated Emirates ID
• Insurance eligibility status recorded (verified, unverified, or pending)
• PDPL-compliant consent captured and stored
• ADT message queued or transmitted to applicable HIE
• Encounter shell created or linked in Scheduling module

SLA and Timing

State Transition Diagram

WF-EHRPATIENTMGMT-002: Patient Demographics Update

Process Flow

Actor: Registration Clerk, Senior Registration Clerk, Patient (via Portal)
Trigger: Patient reports change in personal information or periodic verification; insurance change; portal self-service update
Pre-conditions:

• Patient exists in patients.
• Actor authenticated with appropriate permissions:
• Clerk: update_demographics
• Senior Clerk: approve_demographic_changes
• Patient: update_contact_info (limited fields via portal).

1. Actor opens Patient Search (SCR-EHR-001) and locates patient by MRN/Emirates ID/name.
2. System displays Patient Demographics View/Edit (SCR-EHR-003) with: - Current demographics and change history. - Highlighting of previously modified fields.
3. Actor initiates “Edit” mode; system checks: - For portal users, restricts editable fields (contact info, address, emergency contacts, insurance).
4. Actor updates relevant fields: - Address, PO Box, emirate, mobile, email, emergency contacts, insurance details, next-of-kin.
5. System validates: - Emirates ID format (if changed). - Mobile number format (+971 5X XXX XXXX). - Email syntax.
6. Decision: Critical fields changed? (name, DOB, Emirates ID, gender)
   - If yes, system flags update as “critical change” requiring Senior Clerk approval. - If no, change can be auto-approved.
7. System creates new patient_demographics row with updated values and effective_date = now; previous row remains for history.
8. System updates patient_identifiers if Emirates ID, passport, or insurance member ID changed: - Inserts new identifier rows with is_primary flags and expiry of old identifiers.
9. For portal-initiated changes: - System sets status “pending approval” for critical changes; visible to Senior Clerk work queue.
10. Senior Registration Clerk reviews pending critical changes:
    • Compares before/after values, may request supporting documents (e.g., updated Emirates ID scan).
    • Approves or rejects change.
11. Upon approval:
    • System finalizes changes (if not already applied) and logs approval in audit_log.
12. System sends ADT A08 (update) to:
    • NABIDH/Malaffi (INT-EHR-001/002).
    • Scheduling and Billing modules (INT-EHR-003/004).
13. System logs full before/after snapshots for each changed field in audit_log.

Data Modified:

• patient_demographics — INSERT (new snapshot)
• patient_identifiers — INSERT/UPDATE (new identifiers, mark old as non-primary/expired)
• patient_documents — INSERT (if new ID/insurance scans uploaded)
• audit_log — INSERT (field-level change records, approvals)

Mermaid Flowchart

Decision Points

1. Validation passed? - If no → user must correct invalid Emirates ID/mobile/email before saving.
2. Critical fields changed? - If yes → require Senior Clerk approval; changes may be staged as pending. - If no → auto-apply changes.
3. Senior Clerk approval? - If approved → finalize changes and propagate downstream. - If rejected → revert pending changes; notify originator (clerk or patient).

Integration Points

• NABIDH / Malaffi (INT-EHR-001 / INT-EHR-002)
• ADT A08 messages with updated demographics.
• Scheduling (INT-EHR-003)
• Updated demographics for appointment communications.
• Billing & Claims (INT-EHR-004)
• Updated insurance details for claim accuracy.
• Patient Portal (INT-EHR-006)
• FHIR Patient updates initiated by patient; status flags for pending approval.

Exception Handling

• Invalid Emirates ID or mobile:
• System blocks save; displays field-level error messages.
• Portal user attempts to change restricted fields (e.g., DOB):
• System disallows direct change; offers “request correction” workflow (logged for HIM review).
• HIE update failure:
• ADT A08 queued; retries with backoff; integration admin alerted on repeated failures.
• Approval SLA breach (e.g., pending > 48 hours):
• System escalates to HIM Supervisor via dashboard/notification.

Paperless Transformation

Remaining Paper Touchpoints: None — fully digital for facilities using scanners and portal; optional printed confirmation receipts if desired.

Inputs and Outputs

Inputs:

Outputs:

Post-conditions:

• New patient_demographics snapshot exists with effective date and previous snapshot preserved
• Critical field changes approved by Senior Clerk (if applicable)
• ADT A08 transmitted to HIE and downstream modules
• Full audit trail with before/after values for every changed field

SLA and Timing

Note: Demographics updates modify the existing patient record through versioned snapshots. No separate state diagram is required; the update follows a linear path from edit to validation to approval (if critical) to propagation.

WF-EHRPATIENTMGMT-003: Patient Merge / Duplicate Resolution (MPI)

Process Flow

Actor: Medical Records Officer (MRO), HIM Supervisor
Trigger: System flags potential duplicates via MPI algorithm or staff reports duplicate MRNs
Pre-conditions:

• Duplicate candidates exist in duplicate_suspects with status “new” or “in review”.
• MRO authenticated with merge_records; HIM Supervisor with approve_merges.

1. MRO opens Duplicate Resolution screen (SCR-EHR-010) and views duplicate_suspects list.
2. MRO selects a suspect pair; system loads side-by-side comparison: - patients, patient_demographics, patient_identifiers, key encounter counts.
3. MRO reviews identifiers (Emirates ID, passport, mobile, address, insurance) and clinical context.
4. Decision: Are records duplicates?
   - If no, MRO marks suspect as “not duplicate” with reason; workflow ends.
   - If yes, proceed to select surviving record.
5. MRO selects “primary/surviving” patient record and “secondary/to be merged” record.
6. System generates merge preview: - Lists all linked entities to secondary patient: encounters, orders, results, clinical_notes, patient_documents, patient_allergies, patient_problems, patient_consents, etc.
7. MRO reviews preview, adjusts field-level preferences if supported (e.g., choose preferred address).
8. MRO submits merge request for approval; status of duplicate_suspects set to “pending_approval”.
9. HIM Supervisor opens pending merge request, reviews comparison and merge impact.
10. Decision: Approve merge?
    • If no, marks as “rejected” with reason; no data changes.
    • If yes, approves merge.
11. System executes merge transactionally:
    • Updates all FKs in owned tables (patient_allergies, patient_problems, clinical_notes, patient_documents, patient_consents, audit_log) from secondary to primary patient_id.
    • Marks secondary patients.is_active = false and stores reference to primary (e.g., merged_into_patient_id).
12. System updates duplicate_suspects:
    • status = 'resolved', resolution = 'merged', reviewed_by, reviewed_at.
13. System broadcasts ADT A40 (merge) to:
    • NABIDH/Malaffi (INT-EHR-001/002).
    • Downstream modules via internal ADT (all modules referencing patient).
14. System generates merge audit report and logs detailed events in audit_log.

Data Modified:

• patients — UPDATE (secondary record deactivated, merged_into reference)
• patient_allergies — UPDATE (patient_id)
• patient_problems — UPDATE (patient_id)
• clinical_notes — UPDATE (patient_id)
• patient_documents — UPDATE (patient_id)
• patient_consents — UPDATE (patient_id)
• audit_log — INSERT (merge actions)
• duplicate_suspects — UPDATE (status, resolution, reviewed_by, reviewed_at)

Mermaid Flowchart

Decision Points

1. Are records duplicates? - If no → mark suspect as “not duplicate”; no merge. - If yes → proceed to merge workflow.
2. Approve merge? - If yes → execute merge and propagate. - If no → reject; keep both records active.
3. Field-level preference (optional): - For conflicting demographics, system may allow choosing which value to keep (e.g., newer address vs older).

Integration Points

• All downstream modules (via ADT A40)
• Direction: Outbound
• Data: Merge information (old MRN → new MRN, patient IDs).
• Trigger: Successful merge.
• NABIDH / Malaffi (INT-EHR-001 / INT-EHR-002)
• ADT A40 messages to maintain HIE MPI consistency.

Exception Handling

• Merge conflict during FK updates:
• System performs merge in a database transaction; on error, rolls back and logs incident; marks suspect as “error” for manual investigation.
• Attempt to merge patients with conflicting Emirates IDs:
• System enforces additional warning/hard stop; may require documented justification.
• HIE merge message failure:
• ADT A40 queued with retries; integration admin alerted; local merge still valid but flagged for reconciliation.

Paperless Transformation

Remaining Paper Touchpoints: None — fully digital.

Inputs and Outputs

Inputs:

Outputs:

Post-conditions:

• Secondary patient record is deactivated with merged_into_patient_id reference
• All clinical and administrative records repointed to primary patient
• duplicate_suspects entry resolved with reviewer and timestamp
• ADT A40 transmitted to HIE and all downstream modules
• Full audit trail documenting every FK change and approval decision

SLA and Timing

State Transition Diagram

WF-EHRPATIENTMGMT-004: Allergy Documentation

Process Flow

Actor: Physician, Nurse, Pharmacist
Trigger: Patient encounter (admission, clinic visit, ED) requiring allergy review; new allergy reported
Pre-conditions:

• Patient and encounter context established.
• Actor has manage_allergies permission.

1. Clinician opens Allergy Management screen (SCR-EHR-005) from patient chart.
2. System displays current allergy list from patient_allergies: - Active, inactive, entered-in-error, and NKA/NKDA flags.
3. Clinician reviews existing entries with patient; updates status if needed (e.g., resolved, entered-in-error).
4. Decision: New allergy or intolerance to add?
   - If no, clinician may confirm “reviewed” and exit.
   - If yes, proceed to add.
5. Clinician searches allergen: - Drug allergens via RxNorm; food/environmental via SNOMED CT. - System suggests common allergens and maps codes to allergen_code / allergen_system.
6. Clinician selects allergen and records: - Reaction type (allergy vs intolerance vs adverse event). - Severity (mild, moderate, severe, life-threatening). - Manifestation (coded SNOMED term, e.g., rash, anaphylaxis). - Onset date, verification status (confirmed, unconfirmed), reporter.
7. System validates required fields and checks for duplicates (same allergen + similar reaction).
8. Decision: Duplicate or near-duplicate found?
   - If yes, system prompts to update existing entry instead of creating new.
   - If no, proceed to save.
9. System inserts new row into patient_allergies linked to current encounter_id and entered_by.
10. If clinician records NKA/NKDA:
    • System inserts special-coded entries or flags in patient_allergies to represent NKA/NKDA status.
11. System updates patient chart:
    • Allergy banner, CPOE CDS context (via INT-EHR-005), and risk alerts.
12. System logs action in audit_log (add/update, old/new values).

Data Modified:

• patient_allergies — INSERT/UPDATE
• audit_log — INSERT

Mermaid Flowchart

Decision Points

1. New allergy to add? - If no → mark list as reviewed; no new entries.
2. Validation ok? - If no → user must complete mandatory fields.
3. Duplicate found? - If yes → encourage updating existing entry to avoid clutter and confusion.

Integration Points

• CPOE (INT-EHR-005)
• Direction: Outbound
• Data: Updated allergy list for CDS (drug-allergy checks).
• Trigger: Insert/update in patient_allergies.
• NABIDH / Malaffi (INT-EHR-001 / INT-EHR-002)
• Direction: Outbound
• Data: Allergy updates in ADT or CDA/clinical document payloads.
• Trigger: Allergy list changes, note signing.

Exception Handling

• Terminology service unavailable (RxNorm/SNOMED):
• System allows free-text allergen entry with local code; flags for later normalization.
• Conflicting NKA vs existing allergies:
• System prevents setting NKA/NKDA if active allergies exist; requires deactivation or clarification.
• Allergy entered in error:
• Clinician can mark as “entered-in-error”; system retains record but excludes from CDS.

Paperless Transformation

Remaining Paper Touchpoints: Physical allergy wristbands may still be used at bedside but are driven by digital data.

Inputs and Outputs

Inputs:

Outputs:

Post-conditions:

• patient_allergies reflects current, coded allergy status with full provenance
• CPOE CDS context updated for real-time drug-allergy checking
• Allergy banner in patient chart reflects latest data
• Full audit trail for every allergy add, update, or status change

SLA and Timing

Note: Allergy documentation is a linear data-entry workflow that adds or updates individual records. No separate entity lifecycle or state diagram is required.

WF-EHRPATIENTMGMT-005: Problem List Management

Process Flow

Actor: Physician
Trigger: New diagnosis, encounter assessment, periodic problem list review
Pre-conditions:

• Patient and encounter context established.
• Physician has manage_problem_list permission.

1. Physician opens Problem List screen (SCR-EHR-006) from patient chart.
2. System displays current active and resolved problems from patient_problems with ICD-10-AM and SNOMED codes.
3. Physician reviews list with patient; identifies outdated or incorrect entries.
4. Decision: New problem to add?
   - If no, physician may update statuses or priorities and exit.
   - If yes, proceed to add.
5. Physician searches for problem: - Free-text search mapped to ICD-10-AM and SNOMED CT via terminology service.
6. Physician selects appropriate coded problem and enters attributes: - Onset date, status (active, resolved, ruled out), priority (chronic, acute, high-risk), treating provider.
7. Physician links problem to current encounter and optionally to supporting evidence (labs, imaging, notes).
8. System validates coding completeness (ICD-10-AM required; SNOMED optional but recommended).
9. Decision: Problem already exists as active?
   - If yes, system suggests updating existing entry (e.g., adjust priority or add evidence) instead of creating duplicate.
   - If no, proceed to save.
10. System inserts or updates patient_problems row with entered_by and encounter_id.
11. Physician may resolve/inactivate problems:
    • Sets status = resolved and resolved_date, with reason (e.g., condition resolved, misdiagnosis).
12. System updates:
    • Problem list view, CPOE indication-based ordering context, and case management flags.
13. System logs all changes in audit_log.

Data Modified:

• patient_problems — INSERT/UPDATE
• audit_log — INSERT

Mermaid Flowchart

Decision Points

1. New problem to add? - If no → only updates to existing problems.
2. Validation ok? - If no → enforce ICD-10-AM coding and required attributes.
3. Active problem already exists? - If yes → encourage updating instead of duplicating.

Integration Points

• CPOE (INT-EHR-005)
• Direction: Outbound
• Data: Updated problem list for indication-based ordering and CDS.
• Trigger: Problem list changes.
• Billing & Claims (INT-EHR-004)
• Direction: Outbound
• Data: ICD-10-AM codes for encounters.
• Trigger: Problem list updates linked to encounters.
• Case Management / Chronic Disease Programs
• Direction: Outbound (internal)
• Data: Chronic problem flags and priorities.

Exception Handling

• Terminology service unavailable:
• System allows temporary free-text problem with local code; flags for later coding.
• Conflicting statuses (e.g., same problem active and resolved):
• System warns and suggests consolidating entries.
• Problem entered in error:
• Physician can mark as “entered-in-error”; system retains record but excludes from active lists.

Paperless Transformation

Remaining Paper Touchpoints: None — fully digital.

Inputs and Outputs

Inputs:

Outputs:

Post-conditions:

• patient_problems reflects current, coded problem status with full provenance
• CPOE CDS context updated for indication-based ordering support
• Billing module notified of ICD-10-AM codes for encounter coding
• Chronic disease registries and case management flags updated
• Full audit trail for every problem add, update, resolve, or status change

SLA and Timing

Note: Problem list management is a linear data-entry workflow that adds, updates, or resolves individual problem records. No separate entity lifecycle or state diagram is required.

WF-EHRPATIENTMGMT-006: Clinical Notes / Documentation

Process Flow

Actor: Physician, Nurse, Allied Health Professional
Trigger: Patient encounter requires documentation (H&P, progress note, discharge summary, nursing assessment, consultation)
Pre-conditions:

• Patient and encounter context established.
• User has appropriate documentation permissions (document_notes, document_nursing_notes, etc.).

1. Clinician opens Clinical Notes screen (SCR-EHR-007) from patient chart.
2. System prompts for note type (H&P, progress, discharge, nursing, allied health) and template.
3. Clinician selects template; system loads structured sections and auto-populates: - Demographics, vitals, medications, allergies, problem list, recent results.
4. Clinician documents: - Structured fields (e.g., ROS, physical exam) and free-text narrative; may use voice-to-text and smart phrases.
5. Clinician may link note to specific problems, orders, or procedures.
6. System validates: - Required sections completed for note type (e.g., discharge summary must include diagnosis, medications, follow-up).
7. Decision: Save as draft or sign?
   - If draft, note remains editable; status = “draft”.
   - If sign, proceed to signature workflow.
8. For signing: - System confirms user identity and checks sign_notes permission. - For trainees, system may require co-signature by supervising physician.
9. Clinician signs note electronically: - System sets status = 'signed', records signed_by, signed_datetime.
10. Decision: Co-signature required?
    • If yes, system notifies cosigner and sets cosigner_id pending.
    • If no, note considered final.
11. After signing, note content becomes immutable; corrections require addendum:
    • New clinical_notes row with addendum_of referencing original.
12. System:
    • Updates patient chart timeline.
    • Generates CDA or FHIR DocumentReference for HIE (NABIDH/Malaffi) where applicable.
13. System logs all actions (create, edit, sign, addendum) in audit_log.

Data Modified:

• clinical_notes — INSERT/UPDATE
• audit_log — INSERT

Mermaid Flowchart

Decision Points

1. Validation ok? - If no → enforce completion of mandatory sections.
2. Save as draft or sign? - Draft → editable; Signed → immutable.
3. Co-signature required? - Based on user role, note type, and facility policy.

Integration Points

• NABIDH / Malaffi (INT-EHR-001 / INT-EHR-002)
• Direction: Outbound
• Data: CDA clinical documents or FHIR resources representing signed notes.
• Trigger: Note signed.
• CPOE / RIS / LIS
• Direction: Internal
• Data: Notes may reference orders/results; no direct write-back but used for context.

Exception Handling

• Attempt to edit signed note:
• System blocks direct edits; offers addendum workflow.
• HIE document submission failure:
• CDA/FHIR document queued; retries; integration admin alerted if persistent.
• Signature failure (session timeout):
• User prompted to re-authenticate before signing.

Paperless Transformation

Remaining Paper Touchpoints: Printed discharge summaries may still be provided to patients who request paper copies.

Inputs and Outputs

Inputs:

Outputs:

Post-conditions:

• Signed note is immutable; corrections require addendum
• CDA/FHIR document generated and queued for HIE submission (for signed notes)
• Co-signature workflow initiated if required by role/note type
• Full audit trail for every note lifecycle event

SLA and Timing

Note: Clinical notes follow a simple linear lifecycle (Draft → Signed → optionally Addendum). This progression is managed through the status field on clinical_notes and does not warrant a separate state diagram.

WF-EHRPATIENTMGMT-007: Document Management (Scanned/Uploaded)

Process Flow

Actor: Medical Records Clerk, Nurse, Patient (via Portal)
Trigger: External documents received (referral letters, outside records, consent forms), patient uploads via portal
Pre-conditions:

• Patient exists in patients.
• Scanners and upload endpoints available.
• User has scan_documents or upload_documents permission.

1. User opens Document Management screen (SCR-EHR-008) for selected patient.
2. User clicks “Scan/Upload” and selects source: - Scanner (for paper), file upload (PDF, image), or portal upload.
3. System prompts for metadata: - Document type (from master data), title/description, document date, source (external provider, patient), language.
4. User optionally links document to specific encounter.
5. System validates: - File type (PDF, JPEG, PNG, TIFF), size limits, required metadata.
6. Decision: Validation passed?
   - If no, system shows errors and prevents upload.
   - If yes, proceed.
7. System stores file in secure repository and creates patient_documents row: - file_path, mime_type, file_size, upload_date, uploaded_by, document_type, encounter_id.
8. System triggers OCR (Arabic + English) for text-extractable formats: - Stores OCR text in ocr_text field.
9. Decision: Clinical relevance review required? (e.g., external reports)
   - If yes, system routes document to responsible provider’s review queue.
   - If no, document immediately visible in chart.
10. Provider reviews document (if required) and may:
    • Mark as “reviewed”, add note, or link to specific problems.
11. System applies retention policy:
    • Sets retention_date based on document type and UAE regulations/facility policy.
12. System logs all actions in audit_log.

Data Modified:

• patient_documents — INSERT/UPDATE
• audit_log — INSERT

Mermaid Flowchart

Decision Points

1. Validation passed? - If no → user must correct metadata or file issues.
2. Clinical review required? - Based on document type; e.g., external clinical reports require review.
3. Provider review outcome (implicit): - May influence how document is displayed or linked in chart.

Integration Points

• Patient Portal (INT-EHR-006)
• Direction: Bidirectional
• Data: Patient-uploaded documents and provider-reviewed status.
• Trigger: Portal upload or provider review.
• NABIDH
• Direction: Outbound
• Data: Certain document types may be shared as CDA or PDF attachments.
• Trigger: Document classification and facility policy.

Exception Handling

• Unsupported file type or oversized file:
• System rejects upload with clear message and allowed formats.
• OCR failure:
• System logs error; document remains available without searchable text.
• Accidental upload to wrong patient:
• User with appropriate permission can reassign document to correct patient; action fully audited.

Paperless Transformation

Remaining Paper Touchpoints: Incoming paper documents from external providers; these are scanned at point of receipt and not retained beyond required archival policies.

Inputs and Outputs

Inputs:

Outputs:

Post-conditions:

• Document securely stored with full metadata and encounter linkage
• OCR text extracted and searchable (for text-extractable formats)
• Clinical review routed if document type requires provider review
• Retention date set based on document type and UAE regulatory policy
• Full audit trail for upload, review, and any reassignment

SLA and Timing

Note: Document management is a linear upload-and-review workflow. No separate entity lifecycle or state diagram is required.

WF-EHRPATIENTMGMT-008: Patient Consent Management

Process Flow

Actor: Registration Clerk, Nurse, Patient (via Portal), HIM Supervisor, Privacy Officer
Trigger: Registration, procedure scheduling, data sharing with HIE, PDPL data processing requirements
Pre-conditions:

• Patient exists in patients.
• Consent templates configured in master data (general treatment, PDPL data processing, HIE sharing, procedure-specific).

1. User opens Consent Management screen (SCR-EHR-009) for patient.
2. System lists existing consents from patient_consents with type, scope, status, expiry.
3. User selects consent type to obtain: - General treatment, PDPL data processing, specific procedure, HIE data sharing, research (if applicable).
4. System presents consent form: - In patient’s preferred language (Arabic/English), using configured template.
5. User explains consent; patient reviews on tablet/terminal or via portal.
6. Patient provides electronic signature: - On-screen signature pad, or OTP-based confirmation for portal.
7. System captures: - signature_data, signature_method, granted_datetime, consent_scope, witness_id (if required).
8. System inserts new patient_consents row and stores signed document in patient_documents (linked by consent_id).
9. System evaluates expiry rules: - Sets expiry_datetime based on consent type (e.g., general treatment valid for episode; PDPL consent until withdrawn).
10. Decision: Existing conflicting consent? (e.g., previous refusal for HIE sharing)
    • If yes, system marks previous consent as superseded or withdrawn per policy.
11. System updates consent indicators in patient chart and access control logic:
    • E.g., restrict HIE sharing if consent not granted.
12. Patient may later withdraw consent:
    • User records withdrawal with withdrawn_datetime and withdrawal_reason.
    • System updates status and triggers downstream impact assessment (e.g., stop sending to HIE).
13. System logs all consent events in audit_log.

Data Modified:

• patient_consents — INSERT/UPDATE
• patient_documents — INSERT (signed consent file)
• audit_log — INSERT

Mermaid Flowchart

Decision Points

1. Conflicting prior consent? - If yes → supersede or withdraw older consent to avoid ambiguity.
2. Withdrawal requested? (alternate path) - If yes → update status and adjust access/sharing rules.

Integration Points

• Patient Portal (INT-EHR-006)
• Direction: Bidirectional
• Data: Consent records and digital signatures; patient-initiated consent/withdrawal.
• Trigger: Portal interactions.
• NABIDH / Malaffi (INT-EHR-001 / INT-EHR-002)
• Direction: Outbound
• Data: Consent status may influence which data is shared.
• Trigger: Consent grant/withdrawal.
• Billing & Claims (INT-EHR-004)
• Direction: Outbound
• Data: Certain consents (e.g., release of information) may affect claim attachments.

Exception Handling

• Patient declines consent:
• System records status “declined” with reason; may restrict services or data sharing per facility policy; staff alerted.
• Signature capture failure (device issue):
• System allows fallback to OTP-based consent or defers consent with clear flag.
• Regulatory change in consent templates:
• HIM Supervisor updates templates; system may prompt re-consent for affected patients.

Paperless Transformation

Remaining Paper Touchpoints: Optional printed copies of signed consents for patient; not required for system operation.

Inputs and Outputs

Inputs:

Outputs:

Post-conditions:

• Active consent recorded with digital signature, scope, and expiry
• Any conflicting prior consents superseded or withdrawn
• Access control and HIE sharing rules updated based on consent status
• Signed consent document stored in patient documents
• Full audit trail for consent lifecycle events

SLA and Timing

Note: Consent management follows a linear lifecycle (Pending → Active → Expired/Withdrawn/Superseded). This progression is managed through the status and expiry_datetime fields on patient_consents and does not warrant a separate state diagram.

WF-EHRPATIENTMGMT-009: Patient Record Access / Break-the-Glass (BTG)

Process Flow

Actor: All Clinical Users (Physician, Nurse, Allied Health), Privacy Officer
Trigger: Clinician attempts to access patient record without normal care relationship (e.g., emergency, on-call consult)
Pre-conditions:

• User authenticated with clinical role.
• RBAC and patient-provider relationship rules configured.
• BTG policy defined by Privacy Officer.

1. Clinician searches for patient and attempts to open chart.
2. System evaluates access: - Checks user roles, assigned patients, current encounters, and consent restrictions.
3. Decision: Normal access allowed?
   - If yes, system opens chart; standard audit logging; workflow ends.
   - If no, proceed to BTG prompt.
4. System displays access-denied message with BTG option: - Explains that access is restricted and will be specially audited.
5. Clinician selects BTG option: - System presents list of allowed BTG reasons (emergency, on-call, consult, public health, etc.).
6. Clinician selects reason and may enter free-text justification.
7. System checks: - User has BTG permission (implicit via role) and BTG not blocked for this patient (e.g., VIP with stricter rules).
8. Decision: BTG permitted?
   - If no, system denies access; logs attempt; may notify Privacy Officer.
   - If yes, proceed.
9. System grants temporary access: - Opens patient chart with BTG banner indicating elevated privacy sensitivity.
10. System logs BTG event in audit_log:
    • is_btg = true, access_reason, timestamp, user, patient, IP, user_agent.
11. System may notify Privacy Officer automatically (email/dashboard) for real-time or periodic review.
12. Privacy Officer periodically reviews BTG events:
    • Uses Access Audit Log screen (SCR-EHR-011) to filter is_btg = true.
    • Investigates suspicious access; may initiate incident response per PDPL.

Data Modified:

• audit_log — INSERT (BTG access events and denied attempts)

Mermaid Flowchart

Decision Points

1. Normal access allowed? - Based on care relationship, role, and consent.
2. User selects BTG? - If no → access denied.
3. BTG permitted? - If yes → temporary access granted; if no → deny and escalate.

Integration Points

• All modules
• BTG flag influences access decisions across modules (e.g., CPOE, LIS, RIS) but is centrally logged in audit_log.
• Privacy / Security Monitoring Systems
• Direction: Outbound (reports/feeds)
• Data: BTG events for security analytics and PDPL breach detection.

Exception Handling

• Misuse of BTG (non-emergency):
• Detected via Privacy Officer review; may trigger disciplinary process; system supports exporting logs.
• System misconfiguration (overly restrictive):
• Excessive BTG usage rate (KPI) may indicate need to adjust access rules.
• Audit log write failure:
• System must treat as critical error; deny BTG access if audit cannot be recorded.

Paperless Transformation

Remaining Paper Touchpoints: None — BTG is inherently digital.

Inputs and Outputs

Inputs:

Outputs:

Post-conditions:

• BTG access event recorded with full context (reason, justification, user, patient, timestamp, IP)
• Patient chart accessible with BTG banner for duration of session
• Privacy Officer notified for retrospective review
• Denied attempts logged for security analytics
• No persistent access change — BTG is session-scoped

SLA and Timing

Note: Break-the-glass is a linear access-control workflow (access attempt → evaluation → denial → BTG prompt → grant/deny). No separate entity lifecycle or state diagram is required.

These workflows collectively define how the EHR & Patient Management module supports safe, compliant, and paperless operations in UAE healthcare facilities, while integrating with NABIDH, Malaffi, Scheduling, Billing, and other clinical modules.