Laboratory Information System Workflows

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

Regulatory context: UAE Federal Decree-Law No. 45/2021 on Personal Data Protection (UAE PDPL), MOH laboratory licensing requirements, DOH (Abu Dhabi) ADHICS security standards, DHA NABIDH connectivity, Malaffi connectivity, and local quality standards for laboratory practice. All workflows must ensure secure handling of patient-identifiable data, minimum-necessary access, and full auditability of result changes and critical notifications.

WF-LIS-001: Lab Order Receipt & Validation

Process Flow

Actor: Lab Technologist, Lab Supervisor
Trigger: Lab order received from CPOE (HL7 ORM^O01 or FHIR ServiceRequest)
Pre-conditions:

• Patient exists in patients and has an active encounter in encounters
• Ordering provider exists in providers and is authorized to order labs
• LIS–CPOE interface (INT-LIS-001) is available
• Lab test catalog and LOINC mappings are configured and active

1. Receive Order Message - System (interface engine) receives HL7 ORM^O01 or FHIR ServiceRequest from CPOE with patient, encounter, ordering provider, and ordered tests. - Message is logged in integration_message_log (owned by integration layer).

2. Validate Patient & Encounter - LIS validates patient_id and encounter_id against shared patients and encounters tables. - If not found or encounter inactive, order is placed in an “Error – Patient/Encounter” queue.

3. Create Lab Order Header - LIS creates a new record in lab_orders with:

   • order_id (internal)
   • patient_id, encounter_id, ordering_provider_id
   • order_datetime, priority, clinical_indication, fasting_status
   • facility_id, department_id
   • Initial order_status = 'RECEIVED'.

4. Validate Order Completeness - For each requested test, system checks:

   • Valid test code (mapped to LOINC and internal test catalog)
   • Required fields: priority, clinical indication (ICD-10-AM), specimen type requirements.
   • If missing/invalid, order is flagged “Incomplete” and appears in a lab technologist review queue.

5. Check Duplicate Orders - System queries lab_order_tests and lab_results for the same patient, same test code, within test-specific lookback windows (e.g., CBC 24h, HbA1c 90 days). - If duplicate detected:

   • System flags the test as “Potential Duplicate” and notifies ordering provider via CPOE (status update).
   • Depending on facility policy, test may be auto-held pending provider confirmation.

6. Apply Order-Entry Edits - System enforces test-specific rules:

   • Example: Fasting glucose requires fasting_status = 'FASTING'.
   • Example: Certain tests require specific clinical indication codes.
   • If rule fails, test is set to status = 'ON_HOLD' with a reason; provider is notified via CPOE.

7. Assign Accession Number - LIS generates an accession number per facility/section format (e.g., DXB-CH-20260207-000123). - lab_orders.accession_number is set. - For multi-section orders, section-specific sub-accession numbers may be generated at lab_order_tests level.

8. Create Lab Order Tests - For each valid test:

   • Insert into lab_order_tests with:
   • order_test_id, order_id, test_code_loinc, test_name
   • lab_section (chemistry, hematology, micro, pathology, send-out)
   • specimen_type_required, status = 'PENDING_COLLECTION'.

9. Route to Lab Sections - System assigns each test to a lab section worklist based on lab_section and facility routing rules. - Worklist entries are created for SCR-LIS-001 and SCR-LIS-002.

10. Generate Specimen Collection Labels

    • For each required specimen:
    • System generates barcoded labels containing patient name, MRN, Emirates ID (if available), accession number, test list, and collection date/time placeholder.
    • Label print jobs are queued to the appropriate collection station.

11. Update CPOE/EHR Status

    • LIS sends order acknowledgement/status update back to CPOE/EHR:
    • HL7 ORM^O01 ACK or FHIR Task/ServiceRequest status update.
    • Order status in CPOE set to “Sent to Lab”.

12. Supervisor Oversight (Optional)

    • Lab Supervisor can review high-risk or send-out orders in a dedicated queue and adjust routing or priority if needed.

Data Modified:

• lab_orders — INSERT
• lab_order_tests — INSERT
• lab_specimens — (optional pre-creation for planned specimens) INSERT
• order_audit_log (module-specific or shared) — INSERT (order receipt, validation events)

Mermaid Flowchart

Decision Points

1. Patient/Encounter Validation - IF patient_id or encounter_id not found or inactive
   THEN route to error queue and do not create lab_orders until resolved.

2. Order Completeness - IF required fields (test code, clinical indication, fasting status, specimen type) missing
   THEN set order_status = 'INCOMPLETE', notify lab technologist and ordering provider.

3. Duplicate Order Check - IF same test exists within configured lookback window
   THEN flag as potential duplicate and:

   • IF provider cancels via CPOE → set lab_order_tests.status = 'CANCELLED'
   • ELSE proceed with status = 'PENDING_COLLECTION' but retain duplicate flag.

4. Order-Entry Edits - IF test-specific rule fails (e.g., fasting required but fasting_status != 'FASTING')
   THEN set test status = 'ON_HOLD' and send alert to provider to correct.

Integration Points

Exception Handling

• Invalid Patient/Encounter
• Order is not created in lab_orders.
• Entry logged in error queue; notification to HIS support and lab supervisor.

• Once master data corrected, message can be reprocessed.

• Unknown Test Code / Inactive Test

• Test line set to status = 'REJECTED' with reason “Unknown/Inactive test”.

• Provider notified via CPOE; lab supervisor can map or activate test and re-trigger.

• Interface Failure (INT-LIS-001)

• Orders queued in interface engine with retry logic.

• If retry window exceeded, alert to IT and lab supervisor; manual entry option available.

• Accession Number Collision

• System detects duplicate accession; regenerates using next sequence and logs event.

• PDPL/Data Minimization

• If message contains unnecessary identifiers (e.g., full address when not needed), LIS stores only required fields and masks others in logs per UAE PDPL.

Paperless Transformation

Remaining Paper Touchpoints: None — fully digital for in-scope facilities. External paper referrals (from non-digital clinics) are handled via separate scanning/indexing workflow outside this LIS module.

Inputs and Outputs

Inputs:

Outputs:

Post-conditions:

• Lab order exists with order_status = 'RECEIVED' and assigned accession number
• Individual test records created and routed to appropriate lab section worklists
• Barcoded specimen labels generated and queued for collection stations
• CPOE/EHR updated with order receipt status
• Any incomplete or on-hold tests flagged for provider or technologist action

SLA and Timing

State Transition Diagram

WF-LIS-002: Specimen Collection & Accessioning

Process Flow

Actor: Phlebotomist, Lab Technologist
Trigger: Lab order on collection worklist; patient available
Pre-conditions:

• Valid lab_orders and lab_order_tests records with status = 'PENDING_COLLECTION'
• Patient wristband printed (inpatient) or verified registration (outpatient)
• Label printers and barcode scanners operational
• Collection locations configured in locations and departments

1. Access Collection Worklist - Phlebotomist opens SCR-LIS-002 (Specimen Collection Worklist) filtered by location, priority, and time. - Worklist shows patient name, MRN, location, tests ordered, tube types, and priority.

2. Patient Identification - At bedside or phlebotomy station, phlebotomist:

   • Scans patient wristband barcode (inpatient) or searches by MRN/Emirates ID (e.g., 784-1990-1234567-3).
   • Confirms at least two identifiers (name + MRN/Emirates ID + DOB) per facility policy.

3. Match to Orders - System displays all pending collections for that patient. - Phlebotomist selects the appropriate order(s) and confirms.

4. Print/Confirm Labels - System prints or confirms pre-printed barcoded labels for required specimens (tube type, color, volume). - Phlebotomist verifies label content against patient identifiers.

5. Specimen Collection - Phlebotomist collects specimens according to test requirements:

   • Correct tube type and order of draw.
   • Required volume and special handling (e.g., on ice).
   • Immediately after collection, labels are applied at bedside.

6. Record Collection Details - Phlebotomist records:

   • collection_datetime
   • collector_id (linked to users)
   • Collection site and any complications.
   • LIS creates/updates lab_specimens:
   • specimen_id, order_id, patient_id, specimen_type, tube_type, collection_datetime, collector_id, condition = 'COLLECTED', accession_number.

7. Chain of Custody Tracking - At each handoff (e.g., ward → transport → lab reception), staff scan specimen barcode. - System appends events to lab_specimens.chain_of_custody_json (timestamp, user, location).

8. Transport to Lab - Specimens are placed in transport containers. - Transport staff scan container and specimens; LIS records departure time and expected arrival.

9. Specimen Receipt in Lab - Lab Technologist at accessioning station (SCR-LIS-003) scans specimen barcode. - System verifies:

   • Label matches patient and order.
   • Specimen type and tube type match test requirements.

10. Assess Specimen Condition

    • Technologist records:
    • received_datetime
    • condition (e.g., acceptable, hemolyzed, clotted, insufficient volume).
    • If acceptable:
    • lab_specimens.condition = 'ACCEPTED'
    • Associated lab_order_tests.status = 'IN_LAB_QUEUE'.

11. Specimen Rejection (If Needed)

    • If specimen unacceptable:
    • lab_specimens.condition = 'REJECTED'
    • Rejection reason from master “Specimen Rejection Reason Codes”.
    • lab_order_tests.status = 'RECOLLECT_REQUIRED'.
    • LIS sends status update to CPOE/EHR and generates recollection task.

12. Assign to Section Worklists

    • Accepted specimens are routed to analyzer/section worklists (chemistry, hematology, micro, etc.) based on lab_section and specimen_type.

Data Modified:

• lab_specimens — INSERT (on collection), UPDATE (on receipt, condition, chain of custody)
• lab_orders — UPDATE (e.g., order_status to IN_PROGRESS when first specimen accepted)
• lab_order_tests — UPDATE (status transitions: PENDING_COLLECTION → IN_LAB_QUEUE / RECOLLECT_REQUIRED)
• lab_critical_notifications — none in this workflow

Mermaid Flowchart

Decision Points

1. Patient Identification - IF scanned wristband/Emirates ID does not match selected patient
   THEN system blocks collection documentation and prompts re-identification.

2. Label–Order Match - IF specimen barcode does not match any active lab_orders/lab_specimens
   THEN specimen is placed in “Unmatched Specimen” queue for investigation.

3. Specimen Condition - IF condition is unacceptable (hemolyzed, clotted, insufficient, wrong container)
   THEN mark specimen as REJECTED, update tests to RECOLLECT_REQUIRED, and notify provider.

Integration Points

Exception Handling

• Scanner/Printer Failure
• Phlebotomist can manually select patient and print labels from another station.

• System logs manual override; lab supervisor review recommended.

• Unmatched Specimen

• Specimen placed in a dedicated “Unmatched” queue.

• Lab staff search by patient demographics/time; if not resolved, specimen discarded per policy and incident logged.

• Delayed Transport

• If transport time exceeds stability window (based on test requirements), LIS flags specimens as “Expired” and triggers recollection.

• PDPL Considerations

• Only minimum identifiers printed on labels (e.g., name, MRN, accession number); Emirates ID not printed if policy restricts.
• Chain-of-custody JSON excludes unnecessary personal data, storing only user IDs and timestamps.

Paperless Transformation

Remaining Paper Touchpoints: Possible use of paper transport bags/containers (non-clinical packaging), which do not contain PHI beyond barcodes.

Inputs and Outputs

Inputs:

Outputs:

Post-conditions:

• Specimen record exists with collection details, chain of custody, and condition assessment
• If accepted: tests routed to section worklists for analysis
• If rejected: rejection reason documented, recollection task created, provider notified
• Full chain of custody audit trail maintained from bedside to lab

SLA and Timing

State Transition Diagram

WF-LIS-003: Analyzer Interface & Result Capture

Process Flow

Actor: Lab Technologist, Lab Analyzer (automated)
Trigger: Specimen loaded on analyzer; analyzer completes testing
Pre-conditions:

• Specimen accepted in lab_specimens with valid specimen_id and accession_number
• Analyzer configured in lab_analyzers and lab_analyzer_interfaces
• QC status for analyzer is “In Control” (from lab_qc_records) or within acceptable window

1. Load Specimen on Analyzer - Lab Technologist loads barcoded specimen onto analyzer. - Analyzer scans barcode and reads accession/sample ID.

2. Worklist Query / Download - Analyzer sends host query or receives worklist from LIS via INT-LIS-002. - LIS responds with pending tests for that analyzer, including test codes and sample positions.

3. Analyzer Performs Testing - Analyzer runs tests according to configured methods. - Internal QC checks may run automatically per analyzer configuration.

4. Transmit Results to LIS - Analyzer sends results via ASTM/HL7/serial/TCP to LIS interface. - Message includes sample ID, test codes, result values, units, flags, and QC info.

5. Match Results to Orders - LIS matches incoming results to lab_order_tests and lab_specimens using accession/sample ID and test code. - If no match, result goes to “Unmatched Results” queue.

6. Create/Update Result Records - For each matched test:

   • Insert into lab_results (if not existing) with:
   • result_id, order_test_id, patient_id, test_code_loinc, result_status = 'PENDING_REVIEW', reported_datetime.
   • Insert into lab_result_components for each component:
   • component_id, result_id, component_code_loinc, value_numeric/value_text/value_coded, unit.

7. Apply Auto-Validation Rules - LIS evaluates:

   • Reference range check using lab_reference_ranges.
   • Delta check vs previous results for same test/patient.
   • QC status from lab_qc_records (Westgard rules).
   • If all criteria met and no critical values:
   • Set lab_results.result_status = 'AUTO_VERIFIED'.
   • Flag auto_verified = true.

8. Flag for Manual Review - If any rule fails (e.g., out-of-range, delta check fail, QC out-of-control):

   • lab_results.result_status = 'PENDING_REVIEW'.
   • delta_check_flag = true or qc_flag = true as appropriate.
   • Result appears in SCR-LIS-004 for technologist review.

9. Preliminary Status (Optional) - For certain tests, LIS may set result_status = 'PRELIMINARY' pending additional runs or confirmatory tests.

10. Update Test and Order Status

    • lab_order_tests.status updated to RESULT_AVAILABLE or PENDING_REVIEW.
    • If all tests in lab_orders have results, lab_orders.order_status updated to RESULTS_READY_FOR_VERIFICATION.

Data Modified:

• lab_results — INSERT/UPDATE
• lab_result_components — INSERT
• lab_order_tests — UPDATE (status)
• lab_orders — UPDATE (status)
• lab_qc_records — READ (no modification in this workflow)

Mermaid Flowchart

Decision Points

1. Result–Order Matching - IF no matching lab_order_tests/lab_specimens found for sample ID
   THEN route to “Unmatched Results” queue for manual mapping.

2. Auto-Validation Eligibility - IF result within reference range AND delta check within configured limits AND QC in control AND not critical
   THEN auto-verify; ELSE require manual review.

3. QC Status - IF latest lab_qc_records for analyzer/test indicate Westgard rule violation
   THEN block auto-verification and flag all affected results for manual review.

Integration Points

Exception Handling

• Unmatched Results
• Results held in queue; technologist can manually assign to patient/order using accession number and test code.

• All manual mappings logged for audit.

• Interface Downtime

• Analyzer may print paper results as contingency.

• Technologist manually enters results into LIS; once interface restored, duplicate detection prevents double entry.

• Corrupted/Incomplete Messages

• Interface engine rejects and logs; LIS displays error to IT and lab supervisor.

• Analyzer retransmission requested.

• PDPL/Data Security

• Analyzer interfaces transmit only necessary identifiers (accession/sample ID, not full demographics).
• All interface traffic secured via TLS where supported (per ADHICS/NABIDH/Malaffi profiles).

Paperless Transformation

Remaining Paper Touchpoints: Limited to analyzer internal printouts used only during downtime; not part of normal workflow.

Inputs and Outputs

Inputs:

Outputs:

Post-conditions:

• All analyzer results captured electronically in lab_results and lab_result_components
• Auto-validation applied where criteria met (reference range OK, delta OK, QC in control, non-critical)
• Results requiring manual review flagged with appropriate indicators
• Order and test statuses updated to reflect result availability

SLA and Timing

WF-LIS-004: Result Verification & Release

Process Flow

Actor: Lab Technologist, Lab Supervisor, Pathologist/Lab Director (for micro/pathology)
Trigger: Results received from analyzer or manually entered
Pre-conditions:

• lab_results and lab_result_components exist with result_status in PENDING_REVIEW, AUTO_VERIFIED, or PRELIMINARY
• QC status acceptable or corrective actions documented
• User has appropriate verification privileges for the lab section

1. Open Verification Worklist - Technologist opens SCR-LIS-004 filtered by lab section, priority, and status. - Worklist shows patient banner, test name, abnormal flags, QC status, and auto-validation indicators.

2. Select Result for Review - User selects a result; LIS displays:

   • Current values with reference ranges.
   • Previous results (trend graph).
   • Delta check flags and QC status.

3. Clinical Context Review - System retrieves patient age, gender, diagnosis (ICD-10-AM), location, and relevant medications from EHR. - User confirms that results are consistent with clinical context.

4. Delta Check Assessment - If delta_check_flag = true, LIS highlights change magnitude and time since last result. - User decides whether change is clinically plausible or indicates potential error.

5. QC Status Confirmation - QC status for the analyzer/test is displayed (from lab_qc_records). - If QC out-of-control and no documented corrective action, user cannot finalize result without supervisor override.

6. Critical Value Detection - LIS evaluates result against lab_critical_values thresholds (age group, test code). - If critical:

   • lab_results.is_critical = true.
   • Workflow WF-LIS-005 (Critical Value Notification) is triggered.

7. Result Edits/Comments (If Needed) - User may:

   • Correct obvious data entry errors (with reason).
   • Add interpretive comments (e.g., “Hemolyzed sample may affect potassium result”).
   • All changes logged in result audit trail.

8. Verification - Technologist verifies result:

   • lab_results.result_status = 'FINAL'.
   • verified_by = user_id, verified_datetime = now().
   • For certain sections (e.g., blood bank, pathology), dual verification or pathologist sign-off may be required:
   • Second user must co-sign before status becomes FINAL.

9. Release to EHR/CPOE - LIS sends HL7 ORU^R01 or FHIR DiagnosticReport + Observation to:

   • CPOE/EHR (ordering provider inbox, patient chart).
   • HIEs (NABIDH/Malaffi) when applicable (final results only).
   • Result appears in patient’s lab results view and provider notification list.

10. Charge Capture Trigger

    • For billable tests, LIS sends charge details (CPT/LOINC, specimen type, facility) to Billing via INT-LIS-006 (HL7 DFT^P03 or internal API).

Data Modified:

• lab_results — UPDATE (status, verified_by, verified_datetime, is_critical)
• lab_result_components — UPDATE (if values/flags adjusted)
• lab_orders — UPDATE (order_status to COMPLETED when all tests final)
• lab_order_tests — UPDATE (status to FINAL)
• lab_critical_notifications — INSERT (if critical)
• Billing tables (in Billing module) — INSERT via integration

Mermaid Flowchart

Decision Points

1. Delta/QC Acceptability - IF delta change exceeds configured threshold OR QC out-of-control
   THEN user must either repeat test, document justification, or escalate to supervisor.

2. Critical Value - IF result meets or exceeds lab_critical_values thresholds
   THEN is_critical = true and WF-LIS-005 must be completed before result is considered fully released (per facility policy).

3. Dual Verification - IF test belongs to section requiring dual verification (e.g., blood bank, pathology)
   THEN second verifier must sign before result_status = 'FINAL'.

Integration Points

Exception Handling

• Incorrect Result Detected After Finalization
• Result is amended:
  • New version created; lab_results.status = 'CORRECTED'.
  • Amendment reason recorded; provider notified.

• HIEs receive corrected result messages as per NABIDH/Malaffi guidelines.

• Failed Transmission to EHR/HIE

• Results queued with retry logic.

• If retries fail, alerts sent to IT and lab supervisor; manual export option available.

• Unauthorized User Attempting Verification

• System blocks action and logs security event per ADHICS/UAE PDPL requirements.

• PDPL Considerations

• Access to results limited to authorized users with a treatment relationship.
• All result views and modifications logged for audit.

Paperless Transformation

Remaining Paper Touchpoints: Optional printed result copies for external providers or patients who request paper; controlled and logged.

Inputs and Outputs

Inputs:

Outputs:

Post-conditions:

• Results verified with status FINAL and full audit trail (who verified, when, any edits)
• Results distributed to ordering provider via EHR and to HIE (NABIDH/Malaffi)
• If critical value detected, WF-LIS-005 triggered
• Charge capture sent to billing for billable tests
• All tests in order finalised → order status updated to COMPLETED

SLA and Timing

State Transition Diagram

WF-LIS-005: Critical Value Notification

Process Flow

Actor: Lab Technologist, Ordering Physician, Nurse
Trigger: Result meets critical value threshold
Pre-conditions:

• lab_results.is_critical = true based on lab_critical_values
• Responsible provider identified (ordering or covering provider)
• Notification channels configured (in-app, SMS, phone, escalation rules)

1. Identify Critical Result - During auto-validation or verification (WF-LIS-003/004), LIS compares result to lab_critical_values thresholds by test, age group, and gender. - If critical, lab_results.is_critical = true.

2. Create Critical Notification Record - Insert into lab_critical_notifications:

   • notification_id, result_id, critical_value, notifying_tech_id, target_provider_id, notification_method = 'IN_APP', sent_datetime = now(), escalation_level = 0, read_back_confirmed = false.

3. Generate In-App Alert - Notification service sends alert to responsible provider’s inbox and, optionally, nurse station dashboard. - EHR displays high-priority banner for the patient.

4. Start Escalation Timer - LIS starts a 15-minute timer for acknowledgment. - Timer metadata stored in lab_critical_notifications (or related scheduler).

5. Check Acknowledgment at 15 Minutes - IF acknowledged_datetime is still null after 15 minutes:

   • escalation_level = 1.
   • notification_method updated to include SMS or phone call.
   • Technologist is prompted to call provider; call details recorded.

6. Second Escalation at 30 Minutes - IF still not acknowledged after 30 minutes:

   • escalation_level = 2.
   • Notification escalated to department head/on-call consultant.
   • Additional SMS/phone calls triggered; all attempts logged.

7. Provider Acknowledgment - When provider (or delegate) opens alert:

   • They click “Acknowledge” in Critical Value Alert Manager (SCR-LIS-007).
   • acknowledged_datetime and acknowledged_by recorded.

8. Read-Back Verification - System prompts technologist to document read-back:

   • Provider repeats critical value; technologist confirms.
   • read_back_confirmed = true and timestamp recorded.

9. Close Notification - Notification status set to “Completed”. - Result remains accessible in EHR; critical flag visible in result history.

Data Modified:

• lab_results — UPDATE (is_critical already set; may store link to notification)
• lab_critical_notifications — INSERT/UPDATE (acknowledgment, escalation, read-back)
• Notification logs (in notification service) — INSERT

Mermaid Flowchart

Decision Points

1. Critical Threshold - IF result value outside critical_low/critical_high for test and age group
   THEN mark as critical and start notification workflow.

2. Acknowledgment Timers - IF not acknowledged within 15 minutes
   THEN escalate to SMS/phone. - IF not acknowledged within 30 minutes
   THEN escalate to department head.

3. Read-Back Requirement - IF facility policy requires read-back for this test (e.g., potassium, INR, troponin)
   THEN system enforces read-back documentation before closing notification.

Integration Points

Exception Handling

• Incorrect Provider Mapping
• If responsible provider not found, LIS falls back to on-call provider for department.

• Incident logged; master data corrected.

• Notification Channel Failure (SMS/Phone)

• System retries and logs failures.

• If all channels fail, on-screen alert for lab supervisor to intervene manually.

• PDPL Considerations

• SMS content minimized (no full diagnosis; only “Critical lab result for patient in [Unit] – please log into HIS”).
• Full result details only accessible within secure HIS.

Paperless Transformation

Remaining Paper Touchpoints: None — all critical notification documentation is digital; phone calls still occur but are documented in-system.

Inputs and Outputs

Inputs:

Outputs:

Post-conditions:

• Critical value communicated to responsible provider with documented acknowledgement
• Read-back confirmation captured where required by facility policy
• All timestamps and methods recorded for regulatory compliance and KPI tracking
• If unacknowledged after max escalation, non-compliance event logged

SLA and Timing

WF-LIS-006: Microbiology Culture & Sensitivity

Process Flow

Actor: Microbiology Technologist, Microbiologist
Trigger: Culture specimen received and plated
Pre-conditions:

• Specimen accepted in lab_specimens with appropriate specimen_type (e.g., blood, urine, sputum)
• Microbiology tests in lab_order_tests with lab_section = 'MICROBIOLOGY'
• Incubators and media configured in analyzer/micro systems

1. Specimen Receipt in Microbiology - Micro technologist selects specimen from microbiology worklist. - Confirms specimen type and test requested (e.g., blood culture, urine culture).

2. Plating and Setup - Technologist plates specimen onto appropriate media. - Records plating_datetime, media_type, and incubation_conditions in lab_micro_cultures with growth_status = 'INCUBATING'.

3. Incubation - Specimen incubated per protocol (time, temperature, atmosphere). - LIS tracks expected read times (e.g., 24h, 48h, 72h) and adds to worklist.

4. Interim Reading - At scheduled intervals, technologist opens SCR-LIS-005 (Microbiology Workbench). - Records interim observations:

   • No growth, scant growth, colony morphology, gram stain results.
   • Interim results may be released as PRELIMINARY in lab_results/lab_result_components.

5. Organism Identification - When growth observed:

   • growth_status updated to GROWTH_DETECTED.
   • Organism identification performed (e.g., MALDI-TOF, biochemical tests).
   • lab_micro_cultures updated with:
   • organism_code_snomed, organism_name, colony_count, identification_method, identified_by, identified_datetime.

6. Antibiotic Susceptibility Testing (AST) - AST performed per CLSI/EUCAST guidelines. - For each antibiotic:

   • Insert into lab_micro_sensitivities:
   • sensitivity_id, culture_id, antibiotic_code, antibiotic_name, mic_value, interpretation (S/I/R), testing_method.

7. Cascade Reporting & Stewardship Rules - LIS applies antimicrobial stewardship rules:

   • Cascade reporting: hide broad-spectrum antibiotics if narrow-spectrum options are effective.
   • Suppress non-recommended combinations.
   • Microbiologist can override suppression if clinically justified.

8. Result Compilation - LIS compiles organism ID and susceptibility matrix into lab_results and lab_result_components:

   • Organism as one component.
   • Each antibiotic susceptibility as separate components.

9. Microbiologist Review & Approval - Microbiologist reviews culture timeline, organism, sensitivities, and stewardship rules. - Adds interpretive comments (e.g., “ESBL-producing E. coli – avoid cephalosporins”). - Sets lab_results.result_status = 'FINAL'.

10. Release & Integration

    • Results sent to EHR/CPOE and HIEs (NABIDH/Malaffi) as DiagnosticReport with coded organisms (SNOMED) and antibiotics.
    • PIS (Pharmacy) receives culture/sensitivity data via INT-LIS-007 for stewardship review and correlation with current antimicrobial orders.

Data Modified:

• lab_micro_cultures — INSERT/UPDATE
• lab_micro_sensitivities — INSERT/UPDATE
• lab_results — INSERT/UPDATE (preliminary and final)
• lab_result_components — INSERT/UPDATE
• lab_orders, lab_order_tests — UPDATE (status)
• Antibiogram aggregates (outside scope here) — UPDATE periodically

Mermaid Flowchart

Decision Points

1. Growth Detection - IF no growth at interim read
   THEN continue incubation or finalize as “No growth” at final time point. - IF growth detected
   THEN proceed to organism identification and AST.

2. Cascade Reporting - IF narrow-spectrum antibiotic is susceptible
   THEN suppress broad-spectrum antibiotics from default report unless overridden.

3. Stewardship Overrides - IF microbiologist overrides cascade suppression
   THEN justification must be recorded (e.g., allergy to narrow-spectrum agent).

Integration Points

Exception Handling

• Contamination Suspected
• Microbiologist may mark culture as “Contaminant”; result comments reflect this.

• Repeat culture may be recommended; new order may be requested.

• Mixed Flora / Multiple Organisms

• LIS supports multiple lab_micro_cultures per specimen.

• Reporting rules handle complex interpretations.

• AST Failure

• If AST fails (e.g., technical issues), LIS records failure and may:

  • Repeat AST.
  • Send isolate to reference lab (triggers WF-LIS-007).

• PDPL Considerations

• Organism and antibiotic data are clinical data; access restricted to treating team.
• Aggregated antibiogram reports use de-identified data.

Paperless Transformation

Remaining Paper Touchpoints: External reference lab AST reports may arrive on paper/PDF but are transcribed/scanned into LIS; this is covered under WF-LIS-007.

Inputs and Outputs

Inputs:

Outputs:

Post-conditions:

• Culture timeline fully documented from plating through final result
• Organism identified and coded (SNOMED CT) with antibiotic susceptibility matrix
• Cascade reporting and stewardship rules applied (with documented overrides if any)
• Results released to EHR, HIE, and PIS for antimicrobial therapy correlation
• Microbiologist interpretive comments attached to results

SLA and Timing

WF-LIS-007: Reference Lab Send-Out

Process Flow

Actor: Lab Technologist, Senior Lab Technologist, Lab Supervisor
Trigger: Test not performed in-house (esoteric testing)
Pre-conditions:

• lab_order_tests with lab_section = 'SEND_OUT' or flagged as send-out
• Reference laboratory directory configured (master data)
• Contracted logistics/courier services available

1. Identify Send-Out Test - LIS flags tests that are designated as send-out in the test catalog. - These appear in SCR-LIS-009 (Reference Lab Send-Out Tracker) with pending status.

2. Prepare Specimen - Technologist ensures specimen meets reference lab requirements:

   • Correct tube type, volume, storage temperature.
   • Specimen details recorded in lab_specimens (if not already).

3. Select Reference Lab - User selects appropriate reference lab from master directory based on test and payer contract. - reference_lab_id and reference_lab_name captured.

4. Generate Send-Out Manifest - LIS generates manifest including:

   • Patient identifiers (minimum necessary), test details, specimen ID, and destination.
   • Barcoded tracking number created.

5. Create Send-Out Order Record - Insert into lab_sendout_orders:

   • sendout_id, order_test_id, reference_lab_id, reference_lab_name, shipped_datetime (when shipped), tracking_number, expected_tat_days, status = 'PENDING_SHIPMENT'.

6. Pack and Ship Specimen - Specimen packaged per biosafety and transport regulations. - Courier tracking number recorded; shipped_datetime set; status = 'IN_TRANSIT'.

7. Monitor Turnaround Time - LIS tracks elapsed time vs expected_tat_days. - Overdue send-outs flagged with overdue_flag in SCR-LIS-009.

8. Receive Results from Reference Lab - Results received via:

   • HL7 v2.x, secure file transfer, or manual entry from PDF/fax.
   • Results mapped to internal test codes and LOINC.

9. Enter/Import Results - For electronic results:

   • Interface parses and populates lab_results and lab_result_components.
   • For manual results:
   • Technologist enters values, units, and reference ranges into LIS.
   • result_received_datetime set; status = 'RESULT_RECEIVED'.

10. Verify and Release

    • Senior technologist or pathologist verifies send-out results.
    • lab_results.result_status = 'FINAL'.
    • Results released to EHR/CPOE; lab_sendout_orders.status = 'COMPLETED'.

Data Modified:

• lab_sendout_orders — INSERT/UPDATE
• lab_specimens — UPDATE (chain of custody, storage, disposal)
• lab_results — INSERT/UPDATE
• lab_result_components — INSERT/UPDATE
• lab_order_tests — UPDATE (status)
• lab_orders — UPDATE (order_status)

Mermaid Flowchart

Decision Points

1. Reference Lab Selection - IF multiple labs can perform test
   THEN choose based on payer contract, TAT, and cost.

2. Result Import Method - IF electronic HL7/file interface available
   THEN auto-import; ELSE manual entry required.

3. Overdue Send-Out - IF current date > shipped_datetime + expected_tat_days
   THEN flag as overdue and prompt follow-up with reference lab.

Integration Points

Exception Handling

• Lost Specimen

• If courier reports loss:

  • lab_sendout_orders.status = 'LOST'.
  • Provider notified; recollection requested.

• Result Discrepancies

• If reference lab result conflicts with clinical picture:

  • Pathologist may request repeat testing or second opinion.
  • LIS records comments and additional orders.

• PDPL Considerations

• Only necessary identifiers sent to reference labs; data sharing agreements must comply with UAE PDPL.
• Cross-border data transfers (if reference lab outside UAE) must follow PDPL cross-border transfer rules.

Paperless Transformation

Remaining Paper Touchpoints: Physical packaging and courier paperwork may remain partially paper-based due to external courier requirements.

Inputs and Outputs

Inputs:

Outputs:

Post-conditions:

• Send-out order fully tracked from shipment to result receipt
• Reference lab results imported and verified by senior technologist/pathologist
• Results released to EHR/CPOE and billing
• Send-out TAT compliance metrics captured for KPI reporting

SLA and Timing

WF-LIS-008: Quality Control (QC) Management

Process Flow

Actor: Lab Technologist, QC Officer, Lab Supervisor
Trigger: Shift start, new reagent lot, analyzer maintenance, periodic schedule
Pre-conditions:

• Analyzers configured in lab_analyzers and lab_analyzer_interfaces
• QC materials and expected ranges defined
• Westgard rules configured in master data

1. Schedule QC Runs - LIS maintains QC schedule per analyzer/test (e.g., every 8 hours, per new lot). - Upcoming QC tasks appear on QC Dashboard (SCR-LIS-008).

2. Run QC on Analyzer - Technologist loads QC materials and runs tests. - Analyzer sends QC results to LIS via interface or technologist enters manually.

3. Record QC Results - For each QC result:

   • Insert into lab_qc_records:
   • qc_id, analyzer_id, test_code, control_level, control_lot, observed_value, expected_mean, expected_sd, run_datetime, technologist_id.

4. Apply Westgard Rules - LIS calculates deviation from mean and applies configured Westgard rules (1-2s, 1-3s, 2-2s, R-4s, etc.). - westgard_rule_violated and qc_status (IN_CONTROL / OUT_OF_CONTROL) set.

5. QC Status Feedback - QC status displayed on QC Dashboard and analyzer worklists. - If OUT_OF_CONTROL, LIS:

   • Blocks auto-verification for affected tests.
   • Flags patient results for review.

6. Corrective Actions - Technologist investigates (e.g., recalibration, reagent replacement). - Corrective actions documented in lab_qc_records.corrective_action.

7. Re-Run QC - After corrective action, QC is re-run. - If new QC results are IN_CONTROL, LIS:

   • Allows auto-verification to resume.
   • Marks time window of invalid QC for review of patient results if needed.

8. Levey-Jennings Charts & Trend Review - QC Officer uses SCR-LIS-008 to view Levey-Jennings charts and trends. - Monthly review performed; lab director sign-off recorded.

Data Modified:

• lab_qc_records — INSERT/UPDATE
• lab_analyzers — UPDATE (e.g., last_maintenance_date)
• lab_results — READ/UPDATE (flags if QC out-of-control affects results)

Mermaid Flowchart

Decision Points

1. QC In/Out of Control - IF Westgard rule violated
   THEN qc_status = 'OUT_OF_CONTROL' and auto-verification blocked.

2. Corrective Action Adequacy - IF repeated QC runs remain out-of-control
   THEN analyzer/test taken offline; lab supervisor notified.

3. Retrospective Review - IF QC failure discovered after patient results released
   THEN LIS identifies affected results for potential review/correction.

Integration Points

Exception Handling

• Missing QC Data
• If analyzer fails to send QC data, LIS prompts manual entry.

• Auto-verification disabled until QC recorded.

• Analyzer Misconfiguration

• If analyzer/test not linked to QC configuration, LIS warns QC Officer to configure before allowing patient testing.

• PDPL Considerations

• QC data generally non-identifiable; however, user IDs and timestamps are still protected and audited.

Paperless Transformation

Remaining Paper Touchpoints: None for QC documentation; QC material packaging remains physical.

Inputs and Outputs

Inputs:

Outputs:

Post-conditions:

• QC results recorded with Westgard rule evaluation
• If in control: auto-verification enabled for affected tests
• If out of control: auto-verification blocked; corrective action documented; affected patient results flagged for review
• Levey-Jennings charts updated for trend monitoring
• Monthly QC review and lab director sign-off tracked

SLA and Timing

These workflows collectively support a fully digital, UAE-compliant laboratory environment, tightly integrated with CPOE, EHR, Billing, and national HIE platforms (NABIDH/Malaffi), while ensuring adherence to UAE PDPL and local regulatory expectations.