Radiology Information System Workflows
Home / Clinical Modules / Radiology Information System / Workflows

Radiology Information System Workflows

This document defines eight core workflows for the Radiology Information System (RIS) module for Gates Group facilities in the UAE. Each workflow includes process steps, decision points, integration hooks, exception handling, and the paperless transformation achieved by the HIS.

Regulatory context includes UAE Federal Decree-Law No. 45/2021 on Personal Data Protection (UAE PDPL), MOH radiation safety guidance, DOH (Abu Dhabi) ADHICS cybersecurity standards, DHA (Dubai) NABIDH policies, and Malaffi/NABIDH HIE connectivity requirements. All workflows must ensure minimum necessary data sharing, consent management where applicable, and full auditability of access and changes.

WF-RIS-001: Imaging Order Receipt & Protocolling

Process Flow

Actor: Radiology Technologist, Radiologist, Lead Technologist
Trigger: Imaging order received from CPOE (HL7 ORM^O01 or FHIR ServiceRequest)
Pre-conditions:

  • Patient exists in patients (from ehr-patient-mgmt)
  • Encounter exists in encounters (from scheduling)
  • Ordering provider exists in providers
  • Exam code (CPT) and modality are valid master data
  • Connectivity to PACS and modalities is available
  1. CPOE sends a signed imaging order via HL7 ORM^O01 / FHIR ServiceRequest to RIS.
  2. RIS validates message structure and maps to internal fields (patient, encounter, exam code, priority, clinical indication).
  3. System creates a new record in radiology_orders with status = received, populating: - order_id, patient_id, encounter_id, ordering_provider_id - exam_code_cpt, exam_description, body_part, laterality, modality_type - clinical_indication, icd10_code, priority, order_datetime, facility_id, department_id.
  4. System checks for duplicate active orders for the same patient, body part, and modality within a configurable look-back window (e.g., 24–72 hours).
  5. Lead Technologist or Radiologist opens the order in the protocolling screen and reviews: - Clinical indication and ICD-10-AM code - Prior imaging history (via PACS / HIE) - Relevant labs (e.g., creatinine for contrast CT, pregnancy test for CT/XR).
  6. System checks for contraindications: - Contrast allergy (from allergy list in EHR) - Renal impairment (eGFR below threshold) - Pregnancy risk (female of childbearing age with radiation exam) - MRI implants/metallic devices (from safety profile if available).
  7. If contraindications are detected, system displays alerts and suggests alternative protocols or modalities (e.g., non-contrast CT, ultrasound instead of CT).
  8. Radiologist or Lead Technologist selects an appropriate protocol from radiology_protocols based on exam code, body part, and modality, or overrides with justification.
  9. System verifies insurance / prior authorization requirements by calling Prior Authorization workflow (WF-RIS-008) if payer rules indicate pre-approval is needed.
  10. Priority is confirmed or adjusted (Routine / Urgent / STAT / Wet Read) according to clinical need and facility policy.
  11. System queries modality_resources for available equipment matching modality, facility, and department, and proposes available time slots.
  12. User selects a scheduled date/time; system updates radiology_orders.scheduled_datetime and creates/updates corresponding appointment in scheduling module.
  13. RIS generates an accession number and study identifiers, updates radiology_exams (pre-created or new) with linkage to the order.
  14. System publishes a DICOM Modality Worklist (MWL) entry to the relevant modality via INT-RIS-002/003, including patient demographics, accession number, scheduled time, and protocol.
  15. Order status is updated to scheduled and visible on the Radiology Worklist (SCR-RIS-001).

Data Modified:

  • radiology_orders — INSERT (new order), UPDATE (status, scheduled_datetime, priority, protocol reference)
  • radiology_exams — INSERT or UPDATE (link to order, accession_number, modality_resource_id, exam_status = scheduled)
  • radiology_worklist — INSERT (reading worklist entry may be pre-created for planning)
  • radiology_protocols — READ (no modification)
  • modality_resources — READ (no modification)
  • radiology_quality_metrics — INSERT/UPDATE (optional logging of protocolling time, appropriateness metrics)

Mermaid Flowchart

flowchart TD A["Receive HL7 ORM^O01 / FHIR ServiceRequest"] --> B["Validate message & map fields"] B --> C{"Patient & encounter valid?"} C -->|"No"| C1["Reject order & send error to CPOE"] --> Z["End"] C -->|"Yes"| D["Create radiology_orders status=received"] D --> E{"Duplicate recent order?"} E -->|"Yes"| E1["Alert user & suggest linking/cancelling"] E1 --> F["Open protocolling screen"] E -->|"No"| F["Open protocolling screen"] F --> G["Review indication, prior imaging, labs"] G --> H{"Contraindications?"} H -->|"Yes"| H1["Show alerts & alternative suggestions"] H1 --> I["Select/adjust protocol"] H -->|"No"| I["Select protocol from radiology_protocols"] I --> J{"Prior auth required?"} J -->|"Yes"| J1["Call WF-RIS-008 Prior Authorization"] J1 --> J2{"Auth approved?"} J2 -->|"No"| J3["Update order_status=on_hold & notify ordering provider"] --> Z J2 -->|"Yes"| K["Confirm priority & schedule slot"] J -->|"No"| K["Confirm priority & schedule slot"] K --> L["Assign modality_resource & scheduled_datetime"] L --> M["Generate accession_number & exam record"] M --> N["Publish DICOM MWL entry to modality"] N --> O["Update order_status=scheduled"] O --> Z["End"]

Decision Points

  1. Patient & encounter valid? - If no: reject order, log error, notify CPOE; no radiology_orders record created. - If yes: proceed to order creation.
  2. Duplicate recent order? - If yes: prompt user to cancel new order, merge, or proceed with justification. - If no: continue protocolling.
  3. Contraindications present? - If yes: require protocol adjustment or radiologist override with reason; may change modality or contrast usage. - If no: proceed with standard protocol.
  4. Prior authorization required? - If yes: call WF-RIS-008; if denied, set order to on_hold and notify ordering provider. - If no: proceed to scheduling.

Integration Points

  • CPOE (cpoe module):
  • Inbound: Imaging orders (ORM^O01 / FHIR ServiceRequest) — INT-RIS-001.
  • Outbound: Order acceptance/rejection acknowledgements.
  • Scheduling (scheduling module):
  • Outbound: Exam slot creation/updates linked to encounters.
  • PACS / Modalities:
  • Outbound: DICOM Modality Worklist (MWL) entries — INT-RIS-002/003.
  • Billing & Claims (billing-claims module):
  • Read: Payer rules for prior auth (via policy-contract-mgmt).
  • HIE (NABIDH/Malaffi):
  • Read: Prior imaging history (via PACS/HIE viewer integration; no direct DB writes).
  • EHR Patient Mgmt:
  • Read: Allergies, labs, pregnancy status, demographics.

Exception Handling

  • Invalid or incomplete HL7/FHIR order:
  • Log to integration_message_log; send error ACK to CPOE; display task for Radiology admin.
  • Missing master data (exam code, modality):
  • Flag order as error; route to Radiology admin queue; prevent scheduling until resolved.
  • Prior auth denied:
  • Update radiology_orders.order_status = 'on_hold'; send notification to ordering provider; optionally suggest alternative covered exam.
  • MWL publication failure (network / DICOM error):
  • Retry with exponential backoff; if repeated failure, alert Lead Technologist and IT; allow manual entry on modality if needed with reconciliation later.
  • PDPL data minimisation:
  • If external modality operated by third party, restrict MWL fields to minimum necessary (no sensitive notes) and log disclosure.

Paperless Transformation

Previously Paper-Based Now Digital In-System Notes
Paper imaging requisition forms carried from clinic to radiology Electronic orders from CPOE into radiology_orders Eliminates lost forms and transcription errors
Manual routing of requisitions to radiologist for protocolling In-system protocolling screen with worklist and alerts Faster turnaround, full audit trail
Whiteboards / printed lists for modality scheduling Digital scheduling linked to modality_resources and DICOM MWL Real-time updates, no double-booking
Handwritten notes on contrast/protocol Structured radiology_protocols selection and storage Standardised protocols, supports QA and benchmarking

Remaining Paper Touchpoints: None — fully digital for order receipt and protocolling.

Inputs and Outputs

Inputs:

Source Data Element Format
CPOE Imaging order (exam code, modality, body part, laterality, priority, clinical indication) HL7 ORM^O01 / FHIR ServiceRequest
EHR / Patient Chart Patient demographics, Emirates ID, allergies, labs (creatinine, pregnancy test) patients, patient_allergies, lab_results tables
EHR / Patient Chart Prior imaging history PACS / HIE viewer integration
Policy & Contract Mgmt Payer rules, prior auth requirements payer_contracts, coverage_rules tables
Master Data Radiology protocols, modality resources, scheduling slots radiology_protocols, modality_resources tables

Outputs:

Destination Data Element Format
radiology_orders New order record with status, scheduled datetime, protocol SQL INSERT/UPDATE
radiology_exams Exam record with accession number, modality assignment SQL INSERT/UPDATE
DICOM Modality Worklist MWL entry with patient demographics, protocol, scheduled time DICOM MWL (INT-RIS-002/003)
CPOE Order acceptance/rejection acknowledgement HL7 ACK / FHIR status update
Scheduling Exam slot creation linked to encounter Internal API
radiology_quality_metrics Protocolling time, appropriateness metrics SQL INSERT/UPDATE

Post-conditions:

  • Radiology order exists with order_status = 'scheduled' and assigned accession number
  • DICOM Modality Worklist entry published to the assigned modality
  • Protocol selected and linked to the order
  • Prior authorisation obtained (if required) or order placed on hold pending approval
  • Exam visible on Radiology Worklist (SCR-RIS-001)

SLA and Timing

Step Target Time Escalation Measurement Source
Order receipt to acknowledgement < 2 seconds Retry queue; alert IT if > 10s integration_message_log.received_at
Protocolling (routine) < 30 minutes from receipt Alert Lead Technologist at 30 min radiology_orders.protocolled_datetime
Protocolling (STAT) < 5 minutes from receipt Alert Radiologist at 5 min radiology_orders.protocolled_datetime
Prior auth submission to response < 2 hours (payer-dependent) Alert Insurance Coordinator at 2 h radiology_orders.auth_response_datetime
MWL publication after scheduling < 30 seconds Alert IT if > 1 min radiology_exams.mwl_published_datetime
STAT scheduling (slot assignment) < 15 minutes from receipt Alert radiology scheduler at 15 min radiology_exams.scheduled_datetime

State Transition Diagram

stateDiagram-v2 [*] --> Received : Order arrives from CPOE Received --> Protocolling : Technologist/Radiologist opens order Received --> Error : Validation failure Error --> Received : Corrected and reprocessed Protocolling --> AuthRequired : Payer rules require prior auth AuthRequired --> AuthApproved : Payer approves AuthRequired --> OnHold : Payer denies or pending OnHold --> AuthRequired : Resubmission after correction OnHold --> Cancelled : Provider cancels AuthApproved --> Scheduled : Slot and modality assigned Protocolling --> Scheduled : No auth needed, slot assigned Scheduled --> InProgress : Patient arrives (WF-RIS-002) Scheduled --> Cancelled : Provider or patient cancels Scheduled --> Rescheduled : Time/modality changed Rescheduled --> Scheduled : New slot confirmed InProgress --> ImagesAcquired : Acquisition complete (WF-RIS-003) ImagesAcquired --> Reported : Report signed (WF-RIS-004) Reported --> Corrected : Addendum created (WF-RIS-006) Corrected --> Reported : Addendum signed Reported --> [*] Cancelled --> [*]

WF-RIS-002: Patient Check-In & Exam Preparation

Process Flow

Actor: Radiology Receptionist, Radiology Technologist, Radiology Nurse
Trigger: Patient arrives for scheduled imaging exam
Pre-conditions:

  • radiology_orders record exists with status scheduled
  • Appointment time and modality assigned
  • Patient demographics and identifiers available from ehr-patient-mgmt
  • Safety questionnaires and consent templates configured
  1. Radiology Receptionist opens Patient Check-In screen (SCR-RIS-002) and searches by Emirates ID, MRN, or name/DOB.
  2. System retrieves patient from patients and validates against radiology_orders for today’s scheduled exams.
  3. Receptionist verifies identity using: - Emirates ID (e.g., 784-1990-1234567-1) - MRN - Date of birth.
  4. System displays scheduled exam details (modality, body part, laterality, priority, ordering provider).
  5. Receptionist confirms exam with patient (right patient, right exam, right side) and updates radiology_exams.check_in_time and exam_status = 'patient_arrived'.
  6. Radiology Nurse or Technologist initiates safety screening: - MRI safety questionnaire (implants, pacemakers, metallic foreign bodies) - Contrast allergy history - Pregnancy status for applicable exams - Fasting status and last meal time.
  7. System records responses in structured safety form (linked to encounter) and flags any positive risk factors.
  8. Patient weight and height are measured/confirmed and entered; system stores in EHR and uses for contrast dosing and dose calculations.
  9. If imaging-specific consent is required (contrast, interventional procedures), system presents digital consent form; patient signs on tablet; consent is stored as a document reference.
  10. If safety issues or missing consent are detected, system prevents progression and alerts Radiologist/Lead Technologist for decision.
  11. Receptionist assigns dressing room/preparation area; system logs location and status (e.g., “In changing room”).
  12. Radiology Nurse/Technologist prepares patient:
    • Establish IV access if contrast required
    • Administer oral contrast per protocol (with timing reminders)
    • Document any pre-medication given (e.g., for contrast allergy prophylaxis).
  13. System updates radiology_exams.exam_status = 'ready_for_scan' and notifies modality worklist (optional status update).
  14. Patient is escorted to modality waiting area; technologist is notified via Radiology Worklist (SCR-RIS-001).

Data Modified:

  • radiology_exams — UPDATE (check_in_time, exam_status, contrast_used pre-flag, prep notes)
  • radiology_orders — UPDATE (may update order_status to in_progress)
  • critical_result_notifications — READ only (for prior critical flags)
  • radiology_quality_metrics — INSERT/UPDATE (check-in times, prep delays)
  • EHR safety/consent tables (owned by other modules) — INSERT/UPDATE (not defined here)

Mermaid Flowchart

flowchart TD A["Patient arrives"] --> B["Search by Emirates ID/MRN/DOB"] B --> C{"Scheduled exam found today?"} C -->|"No"| C1["Offer walk-in or reschedule; notify ordering provider"] --> Z["End"] C -->|"Yes"| D["Verify identity with ID + MRN + DOB"] D --> E["Confirm exam details with patient"] E --> F["Update exam_status=patient_arrived & check_in_time"] F --> G["Perform safety screening & record responses"] G --> H{"Any safety risk factors?"} H -->|"Yes"| H1["Alert Radiologist/Lead Tech; decide to proceed/modify/cancel"] H1 --> H2{"Proceed with modified plan?"} H2 -->|"No"| H3["Cancel or defer exam; update status & notify ordering provider"] --> Z H2 -->|"Yes"| I["Adjust protocol/contrast & document"] H -->|"No"| J["Measure weight/height; capture vitals if needed"] I --> J J --> K{"Consent required?"} K -->|"Yes"| K1["Capture digital consent & store"] K -->|"No"| L K1 --> L["Assign dressing room/prep area"] L --> M["Prepare patient: IV/oral contrast, pre-medication"] M --> N["Update exam_status=ready_for_scan"] N --> O["Notify technologist via worklist"] O --> Z["End"]

Decision Points

  1. Scheduled exam found today? - If no: handle as walk-in or reschedule; may require new order from CPOE. - If yes: proceed with check-in.
  2. Safety risk factors present? - If yes: Radiologist/Lead Technologist must decide to:
    • Proceed with modified protocol (e.g., non-contrast, alternative modality), or
    • Defer/cancel exam and notify ordering provider.
    • If no: continue preparation.
  3. Consent required? - If yes: digital consent must be captured before exam can proceed. - If no: proceed directly to preparation.

Integration Points

  • EHR Patient Mgmt:
  • Read: Demographics, allergies, prior safety data.
  • Write: Updated vitals/weight, safety questionnaire, consent references.
  • Scheduling:
  • Read: Appointment details; update status (arrived, no-show).
  • CPOE:
  • Outbound: Notifications if exam cancelled/deferred due to safety issues.
  • Modalities / PACS:
  • Outbound: Optional status updates (e.g., “patient arrived”, “ready_for_scan”) via DICOM MPPS or internal API.

Exception Handling

  • Patient mismatch (ID vs MRN):
  • Hard stop; require re-verification; log incident; do not proceed until resolved.
  • Incomplete safety questionnaire:
  • System prevents status change to ready_for_scan; prompts user to complete missing sections.
  • Patient refuses consent:
  • Update radiology_exams.exam_status = 'cancelled'; log refusal; notify ordering provider.
  • Late arrival / missed slot:
  • System flags as late or no_show; triggers rescheduling workflow; updates KPIs (No-Show Rate).
  • PDPL consent:
  • If patient has restricted data sharing preferences, ensure only necessary staff can view safety/consent details; all access logged.

Paperless Transformation

Previously Paper-Based Now Digital In-System Notes
Paper safety questionnaires (MRI, contrast) Structured electronic safety forms linked to exam Enables decision support and reuse across visits
Handwritten check-in logs radiology_exams timestamps and status tracking Accurate KPIs for wait times and throughput
Paper consent forms stored in folders Digital consent with e-signature and document storage Easier retrieval, PDPL-compliant audit trail
Sticky notes/labels for dressing room assignment On-screen location/status tracking Reduces misplacement and delays

Remaining Paper Touchpoints: Patient may request printed copy of signed consent or prep instructions.

Inputs and Outputs

Inputs:

Source Data Element Format
radiology_orders Scheduled exam details (modality, body part, laterality, priority, ordering provider) SQL SELECT
EHR / Patient Chart Patient demographics, Emirates ID, MRN, DOB patients table
EHR / Patient Chart Allergy list, implant/device history, pregnancy status patient_allergies, EHR safety profile
Scheduling Appointment time and modality assignment encounters, radiology_exams tables
Master Data Safety questionnaire templates, consent form templates form_templates configuration
Patient Identity documents, verbal confirmations, vitals (weight, height) Manual entry / device capture

Outputs:

Destination Data Element Format
radiology_exams Check-in time, exam status update (patient_arrived / ready_for_scan), contrast pre-flag, prep notes SQL UPDATE
radiology_orders Order status update (in_progress) SQL UPDATE
EHR Safety Forms Completed MRI/contrast safety questionnaire responses Structured form INSERT
EHR Consent Signed digital consent document reference Document storage INSERT
EHR Vitals Patient weight, height SQL INSERT/UPDATE
Radiology Worklist Status notification to technologist Real-time UI update
radiology_quality_metrics Check-in time, prep delay metrics SQL INSERT/UPDATE

Post-conditions:

  • Patient identity verified against order (right patient, right exam, right side)
  • Safety screening completed with all risk factors documented
  • Consent obtained and stored digitally (where required)
  • Exam status updated to ready_for_scan and technologist notified
  • Patient vitals captured and available for contrast dosing calculations

SLA and Timing

Step Target Time Escalation Measurement Source
Patient arrival to check-in complete < 5 minutes Alert receptionist supervisor at 10 min radiology_exams.check_in_time minus arrival
Safety screening completion < 10 minutes from check-in Alert Lead Technologist at 15 min Safety form completed_datetime
Consent capture (when required) < 5 minutes Alert Radiologist if patient hesitant > 10 min Consent document signed_datetime
Check-in to ready-for-scan < 20 minutes (routine), < 10 minutes (STAT) Alert Lead Technologist if exceeded radiology_exams.ready_for_scan_datetime
No-show detection 15 minutes past appointment time Auto-flag as late; 30 min → no_show radiology_exams.scheduled_datetime vs check-in

WF-RIS-003: Image Acquisition

Process Flow

Actor: Radiology Technologist
Trigger: Patient prepared and modality available (exam_status = 'ready_for_scan')
Pre-conditions:

  • radiology_exams record exists with exam_status = 'ready_for_scan'
  • DICOM Modality Worklist entry published to modality
  • Patient safety screening and consent completed (where required)
  • Modality connected and authenticated to RIS/PACS
  1. Technologist opens modality console and queries DICOM Modality Worklist for scheduled patients.
  2. Technologist selects the correct patient/exam based on name, MRN, accession number, and scheduled time.
  3. At the modality, technologist performs final identity check (name, MRN, DOB) and confirms exam details and laterality.
  4. Technologist positions patient according to selected protocol and verifies parameters (kVp, mAs, sequences, contrast timing).
  5. Technologist starts acquisition; modality records procedure progress via DICOM MPPS.
  6. During acquisition, technologist monitors patient and image previews; if patient discomfort or technical issue occurs, acquisition may be paused or aborted.
  7. After acquisition, technologist performs immediate image quality review (tech QA) on modality or PACS preview.
  8. If image quality is insufficient (motion, incorrect coverage, artefacts), technologist repeats acquisition as needed, documenting reason in technologist notes.
  9. Modality automatically sends images to PACS via DICOM C-STORE; RIS receives confirmation or monitors via PACS integration.
  10. Modality sends Radiation Dose Structured Report (RDSR) where applicable; RIS parses and stores dose metrics in radiation_dose_records.
  11. Technologist records any manual dose data (for modalities without RDSR) and contrast details (type, volume) in Exam Execution screen (SCR-RIS-003).
  12. System updates radiology_exams:
    • exam_start_time, exam_end_time
    • exam_status = 'images_acquired'
    • contrast_used, contrast_type, contrast_volume
    • modality_resource_id, technologist_id, study_instance_uid.
  13. RIS updates radiology_worklist to add or activate the exam for radiologist reading (status = pending_read).
  14. System triggers Radiation Dose Monitoring workflow (WF-RIS-007) asynchronously.

Data Modified:

  • radiology_exams — UPDATE (exam_status, times, contrast fields, modality_resource_id, technologist_id, accession/study identifiers)
  • radiation_dose_records — INSERT (per exam; dose metrics)
  • radiology_worklist — INSERT/UPDATE (reading worklist entry)
  • radiology_quality_metrics — INSERT/UPDATE (repeat rate, tech performance)

Mermaid Flowchart

flowchart TD A["Technologist queries DICOM MWL"] --> B["Select patient/exam on modality"] B --> C["Final identity & exam verification"] C --> D["Position patient & set protocol parameters"] D --> E["Start image acquisition"] E --> F["Monitor images & patient"] F --> G{"Image quality adequate?"} G -->|"No"| G1["Document reason & repeat acquisition"] G1 --> E G -->|"Yes"| H["Send images to PACS via C-STORE"] H --> I["Receive/monitor C-STORE success"] I --> J["Receive RDSR & parse dose (if available)"] J --> K["Record contrast details & technologist notes"] K --> L["Update radiology_exams: times, status=images_acquired"] L --> M["Create/update radiology_worklist entry"] M --> N["Trigger WF-RIS-007 Dose Monitoring"] N --> Z["End"]

Decision Points

  1. Image quality adequate? - If no: repeat acquisition; increment repeat counter; log reason (e.g., motion, incorrect protocol). - If yes: proceed to send images to PACS.
  2. RDSR available? - If yes: auto-create radiation_dose_records with structured metrics. - If no: require manual dose entry for dose-tracked modalities.
  3. C-STORE success? - If failure: retry; if persistent, alert IT and Radiologist; exam status may be set to images_pending until resolved.

Integration Points

  • Modalities:
  • Inbound: DICOM MWL (from RIS).
  • Outbound: DICOM C-STORE (images), MPPS (status), RDSR (dose) — INT-RIS-002/003.
  • PACS:
  • Inbound: Images from modalities; RIS may query for study status.
  • Dose Monitoring (internal):
  • Trigger: New radiation_dose_records created → WF-RIS-007.
  • EHR:
  • Read: Allergies, safety flags (for final check).

Exception Handling

  • Wrong patient selected on modality:
  • If detected before acquisition: cancel and reselect; log near-miss.
  • If detected after acquisition: mark study as wrong-patient in PACS; quarantine images; create incident record; PDPL breach assessment if images were shared.
  • Network failure to PACS:
  • Modality queues images; RIS displays alert; IT notified; once restored, queued images sent and reconciled.
  • Dose data missing:
  • System prompts technologist to enter manual dose; if not provided, flag exam for RSO review.
  • Contrast reaction during acquisition:
  • Technologist documents reaction; system flags exam and patient record; triggers alert to Radiologist and RSO; may generate incident report.

Paperless Transformation

Previously Paper-Based Now Digital In-System Notes
Handwritten exposure logs per exam Automatic dose capture via RDSR into radiation_dose_records Supports DRL compliance and MOH reporting
Paper technologist worksheets for protocol and repeats Structured technologist notes and repeat flags in radiology_exams Enables Image Repeat Rate KPI and QA
Manual film jackets and physical films Digital images in PACS linked via accession/study UID Faster access, no physical storage
Paper stickers for contrast details Electronic contrast documentation in Exam Execution screen Better tracking of reactions and usage

Remaining Paper Touchpoints: None — acquisition workflow is fully digital.

Inputs and Outputs

Inputs:

Source Data Element Format
DICOM Modality Worklist Scheduled patient/exam entries (name, MRN, accession, protocol, scheduled time) DICOM MWL C-FIND
radiology_exams Exam record with status ready_for_scan, protocol, contrast requirements SQL SELECT
EHR / Patient Chart Allergies, safety flags (for final check before acquisition) patient_allergies table
Technologist Protocol parameter adjustments, patient positioning, contrast administration details Manual entry on modality console / SCR-RIS-003
Modality Acquired images, MPPS status, RDSR dose data DICOM C-STORE, MPPS, RDSR

Outputs:

Destination Data Element Format
PACS Acquired images linked by accession and Study Instance UID DICOM C-STORE (INT-RIS-002)
radiology_exams Exam times, status (images_acquired), contrast details, technologist ID, study UID SQL UPDATE
radiation_dose_records Per-exam dose metrics (CTDIvol, DLP, DAP, effective dose) SQL INSERT
radiology_worklist Reading worklist entry with status pending_read SQL INSERT/UPDATE
radiology_quality_metrics Image repeat rate, technologist performance metrics SQL INSERT/UPDATE
WF-RIS-007 Trigger for radiation dose monitoring Async event

Post-conditions:

  • Images stored in PACS and linked to RIS via accession number and Study Instance UID
  • Exam status updated to images_acquired
  • Radiation dose recorded (from RDSR or manual entry)
  • Reading worklist entry created for radiologist interpretation
  • Contrast details documented if contrast was administered

SLA and Timing

Step Target Time Escalation Measurement Source
Patient ready to acquisition start < 10 minutes (routine), < 5 minutes (STAT) Alert Lead Technologist if exceeded radiology_exams.exam_start_time minus ready_for_scan_datetime
Acquisition duration Modality-dependent (XR < 5 min, CT < 15 min, MRI < 45 min) Alert if > 2x expected duration radiology_exams.exam_end_time minus exam_start_time
Images to PACS (C-STORE) < 2 minutes after acquisition Alert IT if PACS confirmation > 5 min PACS storage confirmation timestamp
Dose data capture (RDSR) < 5 minutes after acquisition Flag for manual entry if > 30 min radiation_dose_records.created_at
Worklist update (pending_read) < 1 minute after images confirmed in PACS Alert RIS admin if delayed radiology_worklist.created_at

State Transition Diagram

stateDiagram-v2 [*] --> ReadyForScan : Patient prepared (WF-RIS-002) ReadyForScan --> InProgress : Technologist starts acquisition InProgress --> QAReview : Acquisition complete, tech reviews images QAReview --> InProgress : Image quality insufficient, repeat QAReview --> ImagesSentToPACS : Images acceptable, C-STORE initiated ImagesSentToPACS --> ImagesAcquired : PACS confirms storage ImagesSentToPACS --> PACSError : C-STORE failure PACSError --> ImagesSentToPACS : Retry C-STORE PACSError --> ImagesAcquired : Manual reconciliation after restoration ImagesAcquired --> PendingRead : Worklist entry created for radiologist InProgress --> Discontinued : Patient unable to complete, exam aborted Discontinued --> [*] PendingRead --> [*]

WF-RIS-004: Radiologist Interpretation & Reporting

Process Flow

Actor: Radiologist, Chief Radiologist (for oversight)
Trigger: Exam status = images_acquired and images available in PACS
Pre-conditions:

  • radiology_exams.exam_status = 'images_acquired'
  • Images stored in PACS and linked via accession/study UID
  • radiology_worklist entry created for exam
  • Radiologist has appropriate privileges and reading assignment
  1. Radiologist opens Reading Worklist (SCR-RIS-004), filtered by modality, location, and assignment.
  2. System displays prioritized list of exams (STAT > Urgent > Routine, then oldest first), including patient name, MRN, exam type, clinical indication, and prior exams count.
  3. Radiologist selects an exam; system: - Locks the worklist item to that radiologist (to avoid double-reading) - Updates radiology_worklist.started_datetime.
  4. PACS viewer opens with current images and relevant prior studies; RIS displays clinical context (indication, history, labs).
  5. Radiologist reviews images systematically, using PACS tools (MPR, measurements, comparison).
  6. Radiologist opens Report Dictation/Editor screen (SCR-RIS-005); system suggests appropriate radiology_templates based on modality and body part.
  7. Radiologist selects a template or free-text mode and begins dictation (voice recognition) or typing; system records dictation_start.
  8. Radiologist documents findings and impression, optionally using structured fields (RadLex/SNOMED CT) stored in structured_findings_json.
  9. If a critical or unexpected life-threatening finding is identified, radiologist flags is_critical = true and enters critical_finding_text; system prepares to trigger WF-RIS-005.
  10. Radiologist reviews the report, corrects recognition errors, and finalizes findings and impression.
  11. Radiologist chooses to sign as:
    • Preliminary (e.g., resident read) — report_status = 'preliminary', preliminary_sign_datetime set; or
    • Final — report_status = 'final', final_sign_datetime set.
  12. On signing, system:
    • Updates radiology_reports with full text, status, timestamps, and radiologist ID.
    • Updates radiology_exams.exam_status to reported (preliminary or final).
    • Updates radiology_worklist.completed_datetime and status.
  13. RIS generates and sends HL7 ORU^R01 or FHIR DiagnosticReport to:
    • CPOE/EHR for ordering provider and patient chart (INT-RIS-001, INT-RIS-007).
    • NABIDH (Dubai) or Malaffi (Abu Dhabi) as required (INT-RIS-004/005).
  14. If is_critical = true, system automatically triggers WF-RIS-005 (Critical Result Notification).
  15. Chief Radiologist may later review preliminary reports and either co-sign or return for correction; status updated accordingly.

Data Modified:

  • radiology_reports — INSERT (new report), UPDATE (status, timestamps, critical flags)
  • radiology_exams — UPDATE (exam_status, link to report_id)
  • radiology_worklist — UPDATE (started_datetime, completed_datetime, worklist_status)
  • critical_result_notifications — INSERT (if critical)
  • radiology_quality_metrics — INSERT/UPDATE (TAT, productivity, addendum rate basis)

Mermaid Flowchart

flowchart TD A["Radiologist opens Reading Worklist"] --> B["View prioritized exams"] B --> C["Select exam & lock worklist item"] C --> D["Open PACS viewer with images & priors"] D --> E["Open Report Editor & select template"] E --> F["Dictate/type findings & impression"] F --> G{"Critical finding identified?"} G -->|"Yes"| G1["Set is_critical=true & enter critical_finding_text"] G1 --> H["Review & edit report"] G -->|"No"| H["Review & edit report"] H --> I{"Sign as preliminary or final?"} I -->|"Preliminary"| I1["Set report_status=preliminary & preliminary_sign_datetime"] I -->|"Final"| I2["Set report_status=final & final_sign_datetime"] I1 --> J["Update radiology_exams & worklist"] I2 --> J["Update radiology_exams & worklist"] J --> K["Send ORU^R01 / FHIR DiagnosticReport to EHR & HIE"] K --> L{"is_critical=true?"} L -->|"Yes"| L1["Trigger WF-RIS-005 Critical Notification"] L -->|"No"| Z["End"] L1 --> Z["End"]

Decision Points

  1. Critical finding identified? - If yes: set is_critical = true, capture details, and trigger WF-RIS-005. - If no: proceed with standard reporting.
  2. Sign as preliminary or final? - Preliminary: used for trainee reads; requires later final sign-off; both timestamps tracked for KPIs. - Final: triggers full distribution and HIE submission.
  3. HIE submission required? - Based on facility location (Dubai/Abu Dhabi) and configuration; if required, ORU must meet NABIDH/Malaffi profiles; failures logged.

Integration Points

  • PACS:
  • Viewer launch with study context (accession, StudyInstanceUID).
  • EHR / CPOE:
  • Outbound: HL7 ORU^R01 / FHIR DiagnosticReport to update patient chart and notify ordering provider — INT-RIS-001, INT-RIS-007.
  • NABIDH / Malaffi:
  • Outbound: Report and key dose data — INT-RIS-004/005.
  • Notification Service:
  • Triggered for critical results (WF-RIS-005).
  • Policy / Quality Modules:
  • Read: Reading assignments; Write: QA metrics.

Exception Handling

  • PACS viewer launch failure:
  • Display error; allow retry; if persistent, allow report creation from limited image access or defer exam; log incident.
  • Voice recognition failure / downtime:
  • Fall back to typed entry; system flags downtime period for QA.
  • ORU/HIE transmission failure:
  • Queue messages with retry; if repeated failure, alert IT and Radiology admin; mark hie_submission_status for KPI tracking.
  • PDPL constraints:
  • Ensure only authorised users access reports; all report views logged; sensitive exams (e.g., oncology, reproductive health) may have additional access controls.

Paperless Transformation

Previously Paper-Based Now Digital In-System Notes
Film-based reading on lightboxes PACS viewer integrated with RIS worklist Faster access, remote reading possible
Dictation tapes and paper transcription Real-time voice recognition and structured templates Reduces turnaround time and transcription errors
Printed paper reports delivered to wards/clinics Electronic ORU^R01 / FHIR DiagnosticReport to EHR Immediate availability to ordering providers
Manual logbooks for critical findings radiology_reports + critical_result_notifications with timestamps Supports regulatory audits and KPIs

Remaining Paper Touchpoints: Optional printed report copies for external referring physicians without electronic access.

Inputs and Outputs

Inputs:

Source Data Element Format
radiology_worklist Exam entry with status pending_read, prioritised by urgency and age SQL SELECT
PACS Current images and relevant prior studies via viewer integration DICOM WADO-RS / viewer launch URL
radiology_exams Exam metadata (modality, body part, clinical indication, accession, study UID) SQL SELECT
EHR / Patient Chart Clinical history, indication, relevant lab results patients, encounters, lab_results tables
Master Data Report templates by modality and body part radiology_templates table
Radiologist Dictated/typed findings, impression, critical flag, structured findings Voice recognition / manual entry

Outputs:

Destination Data Element Format
radiology_reports Report text (findings, impression), status, timestamps, radiologist ID, critical flag SQL INSERT/UPDATE
radiology_exams Status update to reported (preliminary or final) SQL UPDATE
radiology_worklist Completion timestamps and status SQL UPDATE
CPOE / EHR Report content and status HL7 ORU^R01 / FHIR DiagnosticReport (INT-RIS-001, INT-RIS-007)
NABIDH / Malaffi Final report and dose data HL7 ORU^R01 (INT-RIS-004, INT-RIS-005)
critical_result_notifications Critical finding record (if is_critical = true) SQL INSERT
WF-RIS-005 Trigger for critical result notification Async event
radiology_quality_metrics TAT metrics, productivity counts, critical finding rates SQL INSERT/UPDATE

Post-conditions:

  • Signed report exists in radiology_reports with status preliminary or final
  • Report distributed to ordering provider via EHR and to HIE (NABIDH/Malaffi) as required
  • If critical finding identified, WF-RIS-005 triggered automatically
  • Reading worklist item marked complete
  • Turnaround time metrics captured for KPI reporting

SLA and Timing

Step Target Time Escalation Measurement Source
STAT exam: images acquired to report signed < 1 hour Alert Chief Radiologist at 1 h radiology_reports.final_sign_datetime minus radiology_exams.exam_end_time
Urgent exam: images to report < 4 hours Alert at 4 h Same as above
Routine exam: images to report < 24 hours Alert at 24 h Same as above
Preliminary to final sign-off < 24 hours Alert Chief Radiologist at 24 h final_sign_datetime minus preliminary_sign_datetime
Report transmission to EHR < 30 seconds after signing Alert IT if > 2 min integration_message_log.sent_datetime
HIE submission (NABIDH/Malaffi) < 5 minutes after final sign Alert integration team at 10 min radiology_reports.hie_submission_datetime

State Transition Diagram

stateDiagram-v2 [*] --> PendingRead : Exam on reading worklist PendingRead --> InDictation : Radiologist opens exam and starts report InDictation --> PendingReview : Dictation/typing complete PendingReview --> Preliminary : Resident/fellow signs preliminary PendingReview --> Final : Attending signs final report Preliminary --> Final : Attending co-signs / finalises Preliminary --> InDictation : Returned for correction Final --> Distributed : ORU/FHIR sent to EHR and HIE Distributed --> Corrected : Addendum created (WF-RIS-006) Corrected --> Distributed : Corrected report re-sent Distributed --> [*]

WF-RIS-005: Critical Result Notification

Process Flow

Actor: Radiologist, Ordering Physician, Nurse, Department Head
Trigger: Radiologist flags a critical/unexpected finding during interpretation (WF-RIS-004)
Pre-conditions:

  • radiology_reports.is_critical = true and critical_finding_text populated
  • Ordering provider and covering provider details available
  • Notification channels configured (in-app, SMS, phone, email)
  • Escalation rules defined per facility policy and UAE regulations
  1. When radiologist sets is_critical = true, system automatically creates a new critical_result_notifications record with: - report_id, critical_finding, notifying_radiologist_id, target_provider_id, notification_method = 'pending', sent_datetime = NULL.
  2. System identifies responsible provider: - Primary: ordering physician. - If unavailable (off-shift), use covering provider or on-call list from scheduling/on-call roster.
  3. System sends an in-app alert to the target provider’s EHR inbox and mobile app (if enabled), updating notification_method = 'in_app' and sent_datetime.
  4. System starts a 15-minute timer to wait for acknowledgement.
  5. If provider opens the alert and acknowledges, system: - Records acknowledged_datetime, acknowledged_by, read_back_confirmed (after provider confirms verbal read-back if phone used). - Sets escalation_level = 0 and closes notification.
  6. If no acknowledgement within 15 minutes, system escalates: - Sends SMS and/or phone call trigger to registered mobile number. - Updates notification_method to include sms/phone, escalation_level = 1.
  7. System starts a 30-minute timer from initial send; if still not acknowledged, system escalates to department head or on-call consultant: - Sends in-app + SMS/phone alerts to escalation contact. - Updates escalation_level = 2.
  8. If acknowledgement occurs at any stage, system: - Captures who acknowledged and at what time. - Prompts radiologist or nurse to document read-back verification (content of critical finding).
  9. If no acknowledgement after maximum escalation time (configurable, e.g., 45–60 minutes), system: - Logs as non-compliant event. - Notifies Quality/Safety team via dashboard and email.
  10. All timestamps and methods are stored in critical_result_notifications for KPI “Critical Result Notification Compliance”.
  11. For outpatients or external referrals, system may also call patient contact workflow if clinically appropriate and allowed by policy.

Data Modified:

  • critical_result_notifications — INSERT (new notification), UPDATE (method, timestamps, escalation_level, read_back_confirmed)
  • radiology_reports — READ (critical details)
  • radiology_quality_metrics — INSERT/UPDATE (compliance metrics)

Mermaid Flowchart

flowchart TD A["Report signed with is_critical=true"] --> B["Create critical_result_notifications record"] B --> C["Identify responsible provider"] C --> D["Send in-app alert & set sent_datetime"] D --> E{"Acknowledged within 15 min?"} E -->|"Yes"| E1["Record acknowledged_datetime & user"] E1 --> E2["Document read-back confirmation"] E2 --> Z["End - compliant"] E -->|"No"| F["Escalate: send SMS/phone alert; escalation_level=1"] F --> G{"Acknowledged before 30 min?"} G -->|"Yes"| G1["Record acknowledgement & read-back"] --> Z G -->|"No"| H["Escalate to department head; escalation_level=2"] H --> I{"Acknowledged before max time?"} I -->|"Yes"| I1["Record acknowledgement & read-back"] --> Z I -->|"No"| J["Mark as non-compliant; notify Quality/Safety"] --> Z

Decision Points

  1. Acknowledged within 15 minutes? - If yes: compliant; no further escalation. - If no: escalate to SMS/phone.
  2. Acknowledged before 30 minutes? - If yes: compliant at escalation level 1. - If no: escalate to department head.
  3. Acknowledged before maximum allowed time? - If yes: late but captured; flagged for review. - If no: non-compliant; triggers quality incident.

Integration Points

  • EHR / CPOE:
  • In-app alerts to ordering provider and escalation contacts.
  • Notification Service:
  • Outbound: SMS, phone call triggers, push notifications.
  • Quality / Risk Management:
  • Outbound: Non-compliance events to incident management system.
  • NABIDH / Malaffi:
  • Report already sent; critical flag may be included in ORU/DiagnosticReport.

Exception Handling

  • Incorrect target provider mapping:
  • Provider can reassign notification to correct clinician; system logs reassignment.
  • Notification service downtime:
  • System retries; if persistent, displays banner to radiologists and logs downtime; manual phone calls documented in critical_result_notifications.
  • PDPL considerations:
  • Only minimal necessary clinical details included in SMS; full details only in secure in-app messages; all access logged.

Paperless Transformation

Previously Paper-Based Now Digital In-System Notes
Paper critical result logbooks critical_result_notifications with full timestamps Enables KPI tracking and regulatory audits
Phone calls without documentation Structured notification workflow with read-back capture Reduces medico-legal risk
Manual escalation via paging Automated escalation timers and multi-channel alerts Improves compliance with time-to-notify targets

Remaining Paper Touchpoints: None — documentation and tracking are fully digital; phone calls may still occur but are documented in-system.

Inputs and Outputs

Inputs:

Source Data Element Format
radiology_reports Report with is_critical = true and critical_finding_text SQL SELECT
providers / Scheduling Ordering provider, covering provider, on-call roster providers, on_call_schedules tables
Configuration Escalation rules (timers, channels, max escalation levels) System configuration
Notification Service Delivery status (sent, delivered, failed) In-app / SMS / phone callback
Acknowledging Provider Acknowledgement action and read-back confirmation Manual in-app action

Outputs:

Destination Data Element Format
critical_result_notifications Notification record with method, timestamps, escalation level, read-back status SQL INSERT/UPDATE
Ordering Provider In-app alert, SMS, phone call trigger Multi-channel notification
Escalation Contacts Department head / on-call consultant alerts (if escalated) Multi-channel notification
Quality / Safety Team Non-compliance event notification (if max escalation exceeded) Email / dashboard alert
radiology_quality_metrics Critical result notification compliance metrics SQL INSERT/UPDATE

Post-conditions:

  • Critical finding communicated to responsible provider with documented acknowledgement
  • Read-back confirmation captured (content of critical finding verified)
  • All timestamps recorded for regulatory compliance and KPI tracking
  • If unacknowledged after max escalation, non-compliance event logged and Quality team notified

SLA and Timing

Step Target Time Escalation Measurement Source
Report signed to first notification sent < 1 minute Alert IT if notification service delayed > 2 min critical_result_notifications.sent_datetime
First acknowledgement (in-app) < 15 minutes from notification Escalate to SMS/phone at 15 min critical_result_notifications.acknowledged_datetime
Second escalation (department head) < 30 minutes from initial notification Escalate to department head at 30 min critical_result_notifications.escalation_level
Maximum acknowledgement window < 45–60 minutes (configurable) Mark as non-compliant; notify Quality/Safety critical_result_notifications.escalation_level = max
Read-back documentation < 5 minutes after acknowledgement Prompt radiologist/nurse to complete critical_result_notifications.read_back_confirmed

WF-RIS-006: Report Addendum / Amendment

Process Flow

Actor: Radiologist, Chief Radiologist
Trigger: Error discovered in signed report, new clinical information, or follow-up imaging changes interpretation
Pre-conditions:

  • Existing radiology_reports record with report_status = 'final' or preliminary
  • Radiologist has permission to create addenda; Chief Radiologist may be required for certain corrections
  • Original report stored and immutable
  1. Radiologist opens the patient’s imaging report from EHR or RIS and selects “Create Addendum”.
  2. System displays original report text (read-only) and existing addenda (if any).
  3. Radiologist selects addendum_type (correction, additional findings, clinical correlation, administrative).
  4. Radiologist enters addendum_text, clearly describing: - What is being corrected or added. - Reference to original findings/impression sections.
  5. If addendum changes clinical interpretation significantly, radiologist marks a flag (e.g., significant_change = true).
  6. System may require Chief Radiologist approval for certain addendum types (e.g., major diagnostic change) based on configuration.
  7. Radiologist signs addendum electronically; system sets signed_datetime and radiologist_id in radiology_report_addenda.
  8. System updates radiology_reports.report_status to corrected (or equivalent) and links latest addendum.
  9. RIS generates updated HL7 ORU^R01 / FHIR DiagnosticReport with addendum information (e.g., OBX segments with “A” flag or DiagnosticReport.status/history) and sends to: - Ordering provider/EHR. - NABIDH/Malaffi as required.
  10. If significant_change = true, system triggers targeted notification to ordering provider (similar to WF-RIS-005 but not necessarily time-critical).
  11. System logs addendum event in radiology_quality_metrics for Report Addendum Rate KPI.

Data Modified:

  • radiology_report_addenda — INSERT (new addendum)
  • radiology_reports — UPDATE (report_status, link to latest addendum)
  • radiology_quality_metrics — INSERT/UPDATE (addendum-related metrics)

Mermaid Flowchart

flowchart TD A["Radiologist opens existing report"] --> B["Select 'Create Addendum'"] B --> C["View original report & prior addenda"] C --> D["Select addendum_type"] D --> E["Enter addendum_text"] E --> F{"Significant clinical change?"} F -->|"Yes"| F1["Set significant_change=true"] F -->|"No"| G F1 --> G["Sign addendum"] G --> H["Insert into radiology_report_addenda"] H --> I["Update radiology_reports.status=corrected"] I --> J["Send updated ORU^R01 / DiagnosticReport"] J --> K{"significant_change=true?"} K -->|"Yes"| K1["Notify ordering provider of amended report"] K -->|"No"| Z["End"] K1 --> Z["End"]

Decision Points

  1. Significant clinical change? - If yes: mark flag, may require higher-level approval and targeted notification. - If no: standard addendum, still distributed but no urgent notification.
  2. Chief Radiologist approval required? - Based on addendum_type and facility policy; if required, addendum remains in pending state until approved.
  3. HIE update required? - Typically yes for final reports; if patient is in Dubai/Abu Dhabi, updated report must be sent to NABIDH/Malaffi.

Integration Points

  • EHR / CPOE:
  • Outbound: Updated report via ORU/FHIR; in-chart indication that report has addendum.
  • NABIDH / Malaffi:
  • Outbound: Corrected report submission.
  • Notification Service:
  • Outbound: Non-critical notification to ordering provider for significant changes.
  • Quality Management:
  • Outbound: Addendum statistics for QA dashboards.

Exception Handling

  • Attempt to edit original report text:
  • System prevents changes; only addenda allowed; logs attempted action for audit.
  • Addendum created on wrong report:
  • Additional addendum can be created to clarify; original addendum remains for audit; Chief Radiologist may annotate.
  • Transmission failure of updated report:
  • Retry queue; alerts if repeated failures; HIE submission status tracked for KPI.

Paperless Transformation

Previously Paper-Based Now Digital In-System Notes
Paper addendum forms attached to printed reports radiology_report_addenda linked to original report Ensures complete longitudinal record
Re-printing and re-filing corrected reports Electronic update to EHR and HIE Reduces administrative workload and misfiling
Manual phone calls without clear documentation Optional structured notification with addendum flag Improves communication and traceability

Remaining Paper Touchpoints: Optional printed updated reports for external referrers.

Inputs and Outputs

Inputs:

Source Data Element Format
radiology_reports Original signed report (read-only) and existing addenda SQL SELECT
Radiologist Addendum type, addendum text, significant change flag Manual entry via Report Editor
Configuration Addendum approval rules (which types require Chief Radiologist approval) System configuration
Chief Radiologist Approval decision (if required) Manual in-app action

Outputs:

Destination Data Element Format
radiology_report_addenda New addendum record (type, text, signed datetime, radiologist ID) SQL INSERT
radiology_reports Updated status (corrected), link to latest addendum SQL UPDATE
CPOE / EHR Updated report with addendum content HL7 ORU^R01 / FHIR DiagnosticReport (INT-RIS-001, INT-RIS-007)
NABIDH / Malaffi Corrected report submission HL7 ORU^R01 (INT-RIS-004, INT-RIS-005)
Ordering Provider Notification of amended report (if significant_change = true) In-app / notification service
radiology_quality_metrics Addendum rate metrics SQL INSERT/UPDATE

Post-conditions:

  • Addendum appended to original report (original text remains immutable)
  • Updated report distributed to EHR and HIE
  • If significant clinical change, ordering provider notified
  • Addendum event logged for Report Addendum Rate KPI

SLA and Timing

Step Target Time Escalation Measurement Source
Addendum creation to signing < 30 minutes (once radiologist begins) None — radiologist workflow radiology_report_addenda.signed_datetime
Chief Radiologist approval (when required) < 4 hours Alert Chief Radiologist at 4 h radiology_report_addenda.approved_datetime
Updated report transmission to EHR < 30 seconds after addendum signed Alert IT if > 2 min integration_message_log.sent_datetime
HIE re-submission < 5 minutes after addendum signed Alert integration team at 10 min radiology_reports.hie_submission_datetime
Significant change notification to ordering provider < 5 minutes after addendum signed Alert if notification not delivered in 10 min Notification service delivery timestamp

WF-RIS-007: Radiation Dose Monitoring & ALARA Compliance

Process Flow

Actor: Radiation Safety Officer (RSO), Radiologist, Technologist
Trigger: Exam completed (dose data received) and periodic review (scheduled)
Pre-conditions:

  • radiation_dose_records created for dose-tracked modalities
  • DRL benchmarks configured in master data (Diagnostic Reference Levels)
  • Patient cumulative dose history accessible across encounters and facilities (where HIE allows)
  1. Upon receipt of RDSR or manual dose entry (from WF-RIS-003), RIS creates a new radiation_dose_records entry with: - exam_id, patient_id, modality_type, dose_type, dose_value, dose_unit, ctdi_vol, dlp, dap, effective_dose_msv, body_region, captured_from_rdsr.
  2. System calculates per-exam effective dose (if not provided) based on modality, body region, and standard conversion factors.
  3. System retrieves patient’s historical dose data from radiation_dose_records (and HIE if available) to compute cumulative dose: - Lifetime, last 12 months, per body region.
  4. System compares current exam dose and cumulative dose against configured DRLs for modality/body region (UAE MOH guidance + IAEA references).
  5. If current exam dose exceeds DRL, system sets drl_exceeded = true and generates an alert to: - RSO. - Radiologist. - Lead Technologist (for training/QA).
  6. If cumulative dose exceeds defined thresholds (e.g., for paediatric patients), system flags patient in EHR and suggests alternative imaging modalities for future orders (via CDS in CPOE).
  7. RSO uses Radiation Dose Dashboard (SCR-RIS-007) to: - View patient dose timelines. - Filter by modality, body region, technologist, and device. - Identify outliers and trends.
  8. RSO or QA team may open specific exams to review protocol, technologist notes, and justification for high dose.
  9. System aggregates dose data into radiology_quality_metrics for: - Radiation Dose Compliance (DRL) KPI. - Technologist-level dose metrics.
  10. Periodically (e.g., monthly/quarterly), system generates regulatory reports for UAE MOH/DOH/DHA as required, summarising dose distributions and DRL compliance.
  11. Patient cumulative dose summary is made available in EHR and patient portal, respecting PDPL and consent settings.

Data Modified:

  • radiation_dose_records — INSERT (per exam), UPDATE (drl_exceeded flag)
  • radiology_quality_metrics — INSERT/UPDATE (dose-related metrics)
  • EHR patient flags (owned by other module) — UPDATE (high-dose alerts)

Mermaid Flowchart

flowchart TD A["Exam completed & dose data received"] --> B["Insert radiation_dose_records"] B --> C["Calculate effective dose & cumulative dose"] C --> D["Compare against DRLs & thresholds"] D --> E{"Current exam exceeds DRL?"} E -->|"Yes"| E1["Set drl_exceeded=true & alert RSO/Radiologist/Lead Tech"] E -->|"No"| F E1 --> F["Update quality metrics"] F --> G{"Cumulative dose exceeds threshold?"} G -->|"Yes"| G1["Flag patient & suggest alternative modalities in CDS"] G -->|"No"| H G1 --> H["Update dashboards & KPIs"] H --> I["Generate periodic regulatory reports"] I --> Z["End"]

Decision Points

  1. Current exam exceeds DRL? - If yes: flag exam, alert stakeholders, and review protocol/justification. - If no: still recorded but no immediate alert.
  2. Cumulative dose exceeds threshold? - If yes: flag patient; inform ordering providers via CDS; may require RSO review. - If no: no patient-level alert.
  3. Paediatric vs adult thresholds? - Different DRLs and thresholds applied based on age; paediatric exams have stricter limits.

Integration Points

  • Modalities:
  • Inbound: RDSR via DICOM (INT-RIS-002/003).
  • EHR / CPOE:
  • Outbound: Patient dose flags and CDS suggestions for future imaging orders.
  • Patient Portal:
  • Outbound: Cumulative dose summaries, where allowed by policy.
  • Regulatory Reporting:
  • Outbound: Aggregated dose reports for MOH/DOH/DHA (format defined by local authorities).

Exception Handling

  • Missing or incomplete RDSR:
  • System prompts for manual dose entry; if not provided, marks record as incomplete and flags for RSO review.
  • Incorrect dose units or values:
  • Validation checks; if out-of-range or inconsistent, system flags for manual verification.
  • Cross-facility dose history gaps:
  • If HIE data unavailable, system clearly indicates that cumulative dose may be underestimated; avoids false reassurance.

Paperless Transformation

Previously Paper-Based Now Digital In-System Notes
Manual dose logs in notebooks or spreadsheets radiation_dose_records with structured fields Enables automated DRL comparison and trend analysis
Paper-based DRL tracking and reports Automated dashboards and regulatory reports Reduces manual workload and errors
Ad-hoc communication about high-dose patients System flags and CDS integration with CPOE Supports ALARA and safer ordering decisions

Remaining Paper Touchpoints: None — dose tracking and reporting are fully digital.

Inputs and Outputs

Inputs:

Source Data Element Format
radiation_dose_records Per-exam dose data (CTDIvol, DLP, DAP, effective dose, body region, modality) SQL SELECT / RDSR parse
radiology_exams Exam metadata (patient, modality type, body part, exam datetime) SQL SELECT
Patient History Historical dose records across encounters and facilities radiation_dose_records table / HIE query
Master Data DRL benchmarks by modality and body region (UAE MOH + IAEA) dose_reference_levels configuration
Master Data Paediatric vs adult threshold configurations System configuration
RSO / QA Team Review decisions for flagged exams Manual in-app action

Outputs:

Destination Data Element Format
radiation_dose_records Updated record with drl_exceeded flag, cumulative dose calculations SQL UPDATE
RSO / Radiologist / Lead Technologist DRL exceedance alerts In-app alert / notification
EHR / Patient Flags High cumulative dose flag for patient record SQL UPDATE (via EHR integration)
CPOE / CDS Suggestion for alternative imaging modalities on future orders CDS rule trigger
Patient Portal Cumulative dose summary (where allowed by policy) FHIR / portal API
radiology_quality_metrics DRL compliance rates, technologist-level dose metrics SQL INSERT/UPDATE
Regulatory Reports Aggregated dose distributions for MOH/DOH/DHA Scheduled report generation

Post-conditions:

  • Every dose-tracked exam has a radiation_dose_records entry with DRL comparison
  • Exams exceeding DRL flagged and responsible stakeholders alerted
  • Patients with high cumulative dose flagged in EHR for safer future ordering
  • Dashboard updated with current dose trends and compliance rates
  • Regulatory reports generated on schedule

SLA and Timing

Step Target Time Escalation Measurement Source
Dose data capture (after exam) < 5 minutes (RDSR auto), < 1 hour (manual) Flag for RSO if no dose data after 1 h radiation_dose_records.created_at
DRL comparison and alert < 1 minute after dose record created Alert IT if processing delayed > 5 min radiation_dose_records.drl_exceeded timestamp
RSO review of flagged exam < 24 hours Alert RSO supervisor at 24 h RSO review action timestamp
Cumulative dose flag to EHR < 5 minutes after threshold exceeded Alert integration team if delayed EHR patient flag update timestamp
Regulatory report generation Per configured schedule (monthly/quarterly) Alert QA if report overdue by 1 business day Report generation timestamp

WF-RIS-008: Prior Authorization for Imaging

Process Flow

Actor: Radiology Receptionist, Insurance Coordinator
Trigger: Imaging order requires prior authorization per payer rules
Pre-conditions:

  • radiology_orders record created with payer information (from policy-contract-mgmt)
  • Payer rules configured for exams requiring prior auth
  • eClaimLink (Dubai) / DOH eClaims (Abu Dhabi) connectivity available
  1. When a new imaging order is created (WF-RIS-001), RIS checks payer rules (via policy-contract-mgmt and billing-claims) to determine if prior authorization is required based on: - Exam CPT code. - Indication (ICD-10-AM). - Patient plan type (THIQA, Daman, Oman Insurance, etc.).
  2. If prior auth is required, system sets radiology_orders.order_status = 'auth_required' and creates a prior auth task for Insurance Coordinator.
  3. Insurance Coordinator opens Prior Authorization worklist and selects the order.
  4. System pre-populates prior auth request with: - Patient demographics and Emirates ID. - Ordering provider details. - Exam details (CPT, description, modality, body part). - Clinical indication and ICD-10-AM codes. - Relevant prior imaging and conservative management details (if available).
  5. Coordinator reviews and adds any additional required documentation (e.g., clinic notes, lab results) as attachments.
  6. System submits the prior auth request to payer via: - eClaimLink (Dubai) or - DOH eClaims (Abu Dhabi), using appropriate electronic formats (INT-RIS-008).
  7. System updates auth status to pending and tracks payer reference number.
  8. RIS periodically polls or receives responses from payer: - approved, denied, more_info_required, or expired.
  9. On approval: - System updates radiology_orders.order_status = 'authorized'. - Stores authorization number and validity dates. - Allows scheduling (WF-RIS-001) to proceed.
  10. On denial:
    • System updates order_status = 'auth_denied'.
    • Records denial reason.
    • Notifies ordering provider with details and options (appeal, alternative exam).
  11. If more_info_required:
    • System creates a follow-up task for Coordinator to upload additional documents and resubmit.
  12. If authorization expires before exam performed:
    • System flags order as auth_expired and prevents exam scheduling until renewed.
  13. Prior auth outcomes are logged in radiology_quality_metrics for Prior Authorization Approval Rate KPI.

Data Modified:

  • radiology_orders — UPDATE (order_status, auth number, validity dates)
  • radiology_quality_metrics — INSERT/UPDATE (prior auth metrics)
  • Payer/claims tables (in billing-claims / policy-contract-mgmt) — INSERT/UPDATE (not defined here)

Mermaid Flowchart

flowchart TD A["New imaging order created"] --> B["Check payer rules for prior auth"] B --> C{"Prior auth required?"} C -->|"No"| C1["Set order_status=received/scheduled"] --> Z["End"] C -->|"Yes"| D["Set order_status=auth_required & create task"] D --> E["Coordinator reviews & completes auth request"] E --> F["Submit to payer via eClaimLink/DOH eClaims"] F --> G["Set status=pending & store payer ref"] G --> H["Receive payer response"] H --> I{"Approved?"} I -->|"Yes"| I1["Update order_status=authorized & store auth number"] --> Z I -->|"No"| J{"Denied?"} J -->|"Yes"| J1["Set order_status=auth_denied & notify ordering provider"] --> Z J -->|"No"| K{"More info required?"} K -->|"Yes"| K1["Create follow-up task & resubmit after docs"] --> F K -->|"No"| L{"Expired?"} L -->|"Yes"| L1["Set order_status=auth_expired & block scheduling"] --> Z L -->|"No"| Z["End"]

Decision Points

  1. Prior auth required? - If yes: workflow proceeds; scheduling blocked until approval. - If no: order can be scheduled immediately.
  2. Payer response type (approved/denied/more info/expired)? - Approved: scheduling allowed. - Denied: notify provider; consider alternative exam or appeal. - More info: gather additional documentation and resubmit. - Expired: require renewal before proceeding.

Integration Points

  • Billing & Claims:
  • Outbound: Prior auth requests; inbound: responses.
  • Policy-Contract Mgmt:
  • Read: Payer rules, plan details.
  • eClaimLink / DOH eClaims:
  • Bidirectional: Prior auth submission and response (INT-RIS-008).
  • CPOE / EHR:
  • Outbound: Notifications to ordering provider about auth status.

Exception Handling

  • Connectivity issues with eClaimLink/DOH eClaims:
  • Queue requests locally; retry; if prolonged, allow manual fax/phone with manual status entry; log as exception.
  • Incorrect or incomplete clinical documentation:
  • Payer returns more_info_required; system ensures tasks are tracked until resolved.
  • PDPL compliance:
  • Only necessary clinical data sent to payer; sensitive data minimised; all disclosures logged.

Paperless Transformation

Previously Paper-Based Now Digital In-System Notes
Fax-based prior auth forms Electronic submissions via eClaimLink/DOH eClaims Faster turnaround, fewer lost requests
Manual spreadsheets tracking auth status In-system status fields and worklists Real-time visibility and workload management
Phone calls without structured documentation Logged electronic communication with payer responses Better audit trail and KPI measurement

Remaining Paper Touchpoints: Some payers may still require occasional paper/fax attachments; these should be scanned and attached electronically where possible.

Inputs and Outputs

Inputs:

Source Data Element Format
radiology_orders Order details (exam CPT, ICD-10-AM indication, modality, priority, patient, provider) SQL SELECT
Policy & Contract Mgmt Payer rules requiring prior auth by CPT/plan type payer_contracts, coverage_rules tables
EHR / Patient Chart Patient demographics, Emirates ID, clinical notes, prior imaging history patients, encounters tables
Insurance Coordinator Additional documentation, attachments (clinic notes, lab results) Manual upload
Payer Gateway Authorization response (approved/denied/more info/expired) eClaimLink / DOH eClaims response

Outputs:

Destination Data Element Format
radiology_orders Updated status (auth_required, authorized, auth_denied, auth_expired), auth number, validity dates SQL UPDATE
Payer Gateway Prior auth request with clinical documentation eClaimLink / DOH eClaims submission (INT-RIS-008)
Ordering Provider Notification of auth outcome (approval, denial with reason, additional info request) In-app / notification service
Insurance Coordinator Follow-up task for additional documentation (if more_info_required) Task queue
radiology_quality_metrics Prior auth approval rate, turnaround time metrics SQL INSERT/UPDATE

Post-conditions:

  • Authorization status recorded on order with payer reference number and validity dates
  • If approved, order eligible for scheduling (returns to WF-RIS-001)
  • If denied, ordering provider notified with denial reason and appeal options
  • If more info required, follow-up task created for Insurance Coordinator
  • Prior auth metrics captured for KPI reporting

SLA and Timing

Step Target Time Escalation Measurement Source
Auth requirement detection < 5 seconds (automated rule check) Alert if payer rules not configured radiology_orders.order_status change timestamp
Coordinator review and submission < 2 hours from task creation Alert supervisor at 2 h Prior auth task completion timestamp
Payer response (routine) < 24 hours (payer-dependent) Alert Coordinator daily if pending > 24 h radiology_orders.auth_response_datetime
Payer response (urgent/STAT) < 4 hours Alert Coordinator at 4 h; escalate to supervisor at 8 h radiology_orders.auth_response_datetime
Auth expiry monitoring Daily batch check Alert Coordinator 7 days before expiry radiology_orders.auth_expiry_date
Denial notification to provider < 30 minutes after denial received Auto-notification on receipt Notification delivery timestamp
Next → Radiology Information System User Roles & Permissions
content/clinical/ris/01-workflows.md Generated 2026-02-20 22:54