Blood Bank Management Workflows

This document defines seven core workflows for the Blood Bank Management (blood-bank) module. Each workflow includes process steps, decision points, integration hooks, exception handling, and the paperless transformation achieved by the HIS.

Regulatory context (UAE): UAE MOH blood safety regulations (donor selection, infectious disease screening, traceability), DOH/DHA facility licensing, NABIDH (Dubai) and Malaffi (Abu Dhabi) HIE connectivity for transfusion history, UAE PDPL (Federal Decree-Law No. 45/2021) for donor/patient data protection, and ADHICS/DHA security standards for clinical systems. All workflows must support full traceability from donor to recipient and hemovigilance reporting to UAE MOH.

WF-BB-001: Donor Registration & Screening

Process Flow

Actor: Blood Bank Technologist, Donor Physician
Trigger: Voluntary donor presents or blood drive event
Pre-conditions:

• Donor identity document available (Emirates ID or passport)
• Donor consent policy and MOH eligibility criteria configured in master data
• Donor Physician available (on-site or teleconsult) for approval/deferral

1. Technologist opens Donor Registration & Screening (SCR-BB-001) and searches existing donors by Emirates ID, name, or phone.
2. System checks blood_donors for existing record: - If found, loads demographics, historical blood type, and deferral history. - If not found, opens new donor registration form.
3. Technologist verifies identity (Emirates ID barcode scan where available) and captures/updates: - Emirates ID, name (Arabic/English), DOB, gender - Contact details, address, preferred communication language.
4. System checks for active deferral in blood_donors: - If donor_status = 'Deferred' and deferral_until > today, system displays hard-stop warning and routes to Donor Physician for review.
5. Technologist administers electronic screening questionnaire: - Travel history, high-risk behaviours, medications, medical conditions, prior transfusions, pregnancy history (for females), prior deferrals. - System auto-scores risk based on MOH-configured Donor Deferral Reasons master data.
6. Technologist records baseline vitals and measurements: - BP, pulse, temperature, weight, hemoglobin; stored in structured fields or JSON.
7. System evaluates eligibility rules: - If any permanent deferral criteria met → propose donor_status = 'Permanently Deferred'. - If temporary deferral criteria met → propose donor_status = 'Temporarily Deferred' with deferral_reason and deferral_until. - If no deferral criteria → propose donor_status = 'Eligible'.
8. Donor Physician reviews questionnaire, vitals, and system proposal: - Confirms eligibility or modifies to temporary/permanent deferral with reason.
9. Technologist records informed consent electronically (per UAE PDPL): - Donor signs on tablet; consent version, timestamp, and user captured.
10. If eligible:
    • System assigns new donation_id placeholder and prints barcoded donation labels (bag + pilot tubes) linked to donor_id.
    • Schedules donor for phlebotomy (immediate or future slot) and records planned collection site.
11. If temporarily or permanently deferred:
    • System updates blood_donors with donor_status, deferral_reason, deferral_until (if applicable), and increments deferral counters for KPIs.
12. System logs all actions in an audit trail (user, timestamp, changes) for regulatory compliance.

Data Modified:

• blood_donors — INSERT (new donor) or UPDATE (demographics, status, deferral fields, last_donation_date, total_donations not yet changed here)
• encounters (if donor is also patient and visit is registered) — referenced only, no ownership
• Donor screening responses (implementation options):
• Either a dedicated donor_screening table — INSERT
• Or JSON field in blood_donors (noted in data model)
• Consent/audit:
• consent_records (owned by another module or shared) — INSERT
• audit_log — INSERT

Mermaid Flowchart

Decision Points

1. Existing donor? - If yes → pre-populate data, check deferrals. - If no → create new donor record.
2. Active deferral? - If yes → hard-stop for donation; Donor Physician may:
   • Confirm deferral (no donation).
   • Override with justification (e.g., deferral period completed but not updated).
3. Eligibility classification (system proposal vs physician decision): - If permanent deferral criteria met → propose permanent deferral; physician may confirm or downgrade to temporary with justification. - If temporary deferral criteria met → propose temporary deferral; physician sets deferral_until. - If no criteria → eligible; physician may still defer based on clinical judgment.

Integration Points

• EHR Patient Management (ehr-patient-mgmt):
• If donor is also a patient, optional link to patients.patient_id for shared demographics and PDPL consent alignment.
• Scheduling module:
• For planned donation appointments (blood drives, future slots).
• Notification/Communication module:
• SMS/email reminders for future donation appointments or deferral expiry (subject to PDPL consent).

Exception Handling

• Identity mismatch (Emirates ID already linked to another donor):
• System blocks registration and prompts technologist to verify documents; escalates to supervisor for merge/cleanup.
• Incomplete questionnaire or missing vitals:
• System prevents eligibility decision until mandatory fields completed.
• System downtime during consent capture:
• Local offline capture (if supported) or temporary paper consent with later scanning and back-entry; flagged in audit log.
• Donor Physician not immediately available:
• System allows provisional status "Pending Physician Review"; donation cannot proceed until final decision recorded.

Paperless Transformation

Remaining Paper Touchpoints: Optional printed donor information leaflets (non-identifiable); can be replaced by digital brochures/portal.

Inputs and Outputs

Inputs:

Outputs:

Post-conditions:

• Donor record exists with current demographics, screening data, and eligibility status
• If eligible: donation labels generated and phlebotomy scheduled
• If deferred: donor status and reason recorded; deferral counters updated for KPIs
• Informed consent captured and linked to donor record
• Full audit trail for regulatory compliance

SLA and Timing

Note: Donor registration and screening is a linear assessment workflow that results in an eligibility classification. No separate entity lifecycle or state diagram is required.

WF-BB-002: Blood Collection & Component Processing

Process Flow

Actor: Blood Bank Technologist
Trigger: Donor approved for collection (WF-BB-001 completed with status Eligible)
Pre-conditions:

• Donor marked donor_status = 'Eligible' and not actively deferred
• Donation labels (bag + pilot tubes) generated and linked to donor_id
• Collection site and phlebotomist assigned

1. Technologist opens Blood Collection & Processing (SCR-BB-002) and selects scheduled donor or scans donation label barcode.
2. System verifies: - donor_id exists and donor_status = 'Eligible'. - No recent donation violating minimum interval rules (e.g., <56 days for whole blood, configurable).
3. Technologist confirms collection site, phlebotomist (collector_id), and starts venipuncture: - Records collection_start_datetime.
4. After collection, technologist records: - collection_end_datetime, volume_ml, any immediate complications (e.g., vasovagal). - System creates blood_donations row with status = 'Collected'.
5. Technologist collects pilot tubes for: - ABO/Rh confirmation, infectious disease panel (HBV, HCV, HIV, syphilis, malaria per MOH), other facility-defined tests. - Tubes are barcoded and linked to donation_id.
6. System generates component processing plan based on donation type: - Whole blood → RBCs, platelets, FFP, cryoprecipitate. - Apheresis → specific component(s).
7. Technologist processes components (centrifugation, separation) and records: - component_type, volume_ml, collection_datetime, expiry_datetime, ABO/Rh, special processing (irradiated, leukoreduced, washed). - System creates blood_components rows with status = 'Quarantined'.
8. System sends pilot tube orders to LIS (INT-BB-002): - Infectious disease panel, confirmatory ABO/Rh. - Each test linked to donation_id and component_id where relevant.
9. All components remain in quarantine: - blood_quarantine_log entry created with quarantine_reason = 'Pending Infectious Disease Results'.
10. When LIS returns results:
    • If all infectious markers negative and ABO/Rh confirmed:
    • System updates blood_components.status = 'Available'.
    • Creates/updates blood_component_inventory entries with storage location, received_datetime.
    • Closes quarantine log (released_datetime, release_reason = 'Cleared').
    • If any marker positive or critical issue:
    • System sets blood_components.status = 'Rejected'.
    • Updates blood_quarantine_log.final_disposition = 'Discard'.
    • Creates blood_discard_log entries with discard_reason = 'Infectious Positive'.
    • Triggers donor notification workflow (outside this module’s scope but logged).
11. System updates donor record:
    • Increments total_donations, sets last_donation_date, and updates blood_type/ABO/Rh if confirmed.

Data Modified:

• blood_donations — INSERT (new donation) and UPDATE (status, complications, infectious_disease_status)
• blood_components — INSERT (per component) and UPDATE (status, expiry, special processing flags)
• blood_component_inventory — INSERT (when components released) and UPDATE (status/location)
• blood_quarantine_log — INSERT (quarantine) and UPDATE (release/disposition)
• blood_discard_log — INSERT (for discarded units)
• blood_donors — UPDATE (total_donations, last_donation_date, blood_type/ABO/Rh)
• LIS-related tables (in LIS module) — referenced via INT-BB-002

Mermaid Flowchart

Decision Points

1. Eligibility & donation interval check: - If donor not eligible or interval too short → collection blocked; Donor Physician review required.
2. Infectious disease results: - If all negative and ABO/Rh confirmed → components released to inventory. - If any positive or inconclusive → components rejected and discarded; donor flagged for follow-up/deferral.
3. Component processing completeness: - If processing not completed within defined time window (e.g., 8 hours) → system alerts and may require supervisor override to proceed or discard.

Integration Points

• LIS (lis) — INT-BB-002:
• Outbound: specimen and test orders (infectious panel, ABO/Rh confirmation).
• Inbound: test results (marker status, confirmatory blood group).
• EHR Patient Management:
• If donor is also patient, optional update of patient blood type (subject to policy).
• Inventory Management (internal):
• blood_component_inventory updates drive dashboard KPIs and alerts.

Exception Handling

• Barcode scan failure / label unreadable:
• Manual entry with double verification; system flags record for audit.
• Partial test results from LIS:
• Components remain quarantined until all mandatory tests completed.
• Result mismatch (ABO/Rh discrepancy with previous donation):
• System flags discrepancy; components held in quarantine; supervisor review required.
• System or network outage during collection:
• Minimal offline capture (donor ID, time, volume) with later reconciliation; all late entries marked accordingly.

Paperless Transformation

Remaining Paper Touchpoints: Biohazard disposal manifests (may remain partially paper due to external waste contractor requirements).

Inputs and Outputs

Inputs:

Outputs:

Post-conditions:

• Donation record created with collection details and linked components
• Components quarantined pending infectious disease screening results
• When results received: components either released to available inventory or rejected and discarded
• Donor record updated with donation count and confirmed blood type
• Full traceability chain from donor to component to inventory

SLA and Timing

State Transition Diagram

WF-BB-003: Type and Screen (Pre-Transfusion Testing)

Process Flow

Actor: Blood Bank Technologist
Trigger: Type & Screen order received from CPOE (INT-BB-001)
Pre-conditions:

• Valid transfusion-related order in CPOE (type & screen or transfusion order requiring pre-testing)
• Patient identified with active encounter
• Properly labeled blood specimen received in blood bank

1. Technologist opens Type & Screen / Crossmatch Workbench (SCR-BB-003) and selects the patient/order from the worklist.
2. System verifies specimen: - Scans specimen barcode and matches to patient_id, encounter_id, collection time, and collector. - Confirms two identifiers (e.g., name, MRN) match EHR.
3. If specimen verification fails (mismatch or missing identifiers): - System rejects specimen, records reason, and notifies clinical area to recollect.
4. If verification passes, technologist performs ABO/Rh typing: - Records forward and reverse grouping results, Rh D status, and any weak D testing.
5. Technologist performs antibody screen (indirect antiglobulin test): - Records antibody_screen_result (Negative/Positive).
6. If antibody screen positive: - Performs antibody identification panel. - Records antibody_specificity (e.g., anti-K, anti-E) using master data codes.
7. System compares new ABO/Rh with historical blood_type_screen records: - If concordant → sets historical_type_concordant = true. - If discrepant → flags for investigation; crossmatch and transfusion blocked until resolved.
8. System calculates validity window: - Default 72 hours from specimen collection (configurable). - Sets valid_until in blood_type_screen.
9. Technologist reviews and validates results; supervisor co-sign may be required for complex antibodies.
10. System:
    • Inserts new blood_type_screen record.
    • Updates patient summary (via EHR integration) with current blood type, antibody status, and validity.
    • Notifies ordering provider via CPOE/EHR that type & screen is complete.

Data Modified:

• blood_type_screen — INSERT (new result)
• crossmatch_records — not yet; used in WF-BB-004
• transfusion_orders — UPDATE (may set status to "Ready for Crossmatch" or similar)
• EHR patient summary tables — UPDATE (via integration, not owned here)
• audit_log — INSERT

Mermaid Flowchart

Decision Points

1. Specimen & patient match: - If mismatch → specimen rejected; new sample required. - If match → proceed with testing.
2. Antibody screen result: - Negative → standard crossmatch or electronic crossmatch possible. - Positive → antibody identification required; may limit compatible units.
3. Historical type concordance: - Concordant → normal workflow. - Discrepant → investigation required; crossmatch blocked until resolved.

Integration Points

• CPOE (cpoe) — INT-BB-001:
• Inbound: Type & Screen orders (HL7 ORM / internal API).
• Outbound: Result status and completion notification.
• LIS (lis):
• Optionally, if ABO/Rh and antibody screen performed in LIS, results imported via HL7 ORU and mapped into blood_type_screen.
• EHR Patient Chart — INT-BB-003:
• Outbound: Blood type, antibody status, and transfusion history to patient summary (FHIR Procedure/Observation).

Exception Handling

• Specimen labeling errors:
• System enforces rejection rules; reason recorded; PDPL-compliant notification without exposing other patients’ data.
• Inconclusive antibody identification:
• System allows interim classification (e.g., "Antibody of Undetermined Specificity") and requires pathologist review.
• System downtime:
• Results may be recorded on contingency forms and later back-entered; all back-dated entries flagged for audit.

Paperless Transformation

Remaining Paper Touchpoints: None — fully digital once specimen is labeled and received.

Inputs and Outputs

Inputs:

Outputs:

Post-conditions:

• Patient blood type and antibody status recorded with validity window (default 72 hours)
• Historical type concordance verified; discrepancies flagged and investigated
• Ordering provider notified of completion
• Patient chart updated with current blood bank status
• Ready for crossmatch if transfusion order exists

SLA and Timing

Note: Type and Screen is a linear laboratory testing workflow. No separate entity lifecycle or state diagram is required; the blood_type_screen record progresses from creation to validation to notification.

WF-BB-004: Crossmatch & Component Issue

Process Flow

Actor: Blood Bank Technologist
Trigger: Transfusion order received and type/screen complete
Pre-conditions:

• Valid transfusion_orders record with order_status indicating ready for crossmatch
• Recent valid blood_type_screen (within configured validity window)
• Available compatible components in blood_component_inventory

1. Technologist opens Type & Screen / Crossmatch Workbench (SCR-BB-003) or Blood Issue & Return (SCR-BB-005) and selects the transfusion order.
2. System verifies: - blood_type_screen.valid_until >= now. - No unresolved blood group discrepancy or serious transfusion reaction that would block transfusion.
3. System suggests compatible units from blood_component_inventory: - Filters by component_type_requested, ABO/Rh compatibility, antigen-negative requirements (based on antibody_specificity), and FEFO (earliest expiry first).
4. Technologist selects unit(s) for crossmatch.
5. System determines crossmatch type: - If patient has two concordant historical types, negative antibody screen, and no significant history → eligible for electronic crossmatch. - Otherwise → serological crossmatch required.
6. For electronic crossmatch: - System performs rule-based checks (ABO/Rh compatibility, unit status, no conflicting antibodies). - If all checks pass → creates crossmatch_records with crossmatch_type = 'Electronic', result = 'Compatible'.
7. For serological crossmatch: - Technologist performs lab crossmatch (e.g., IAT crossmatch) and records result (Compatible/Incompatible) and performed_datetime.
8. If any unit is incompatible: - System marks crossmatch_records.result = 'Incompatible' and prevents issue of that unit; technologist selects alternative unit.
9. Once compatible units confirmed: - System prints crossmatch/issue tag with patient identifiers, unit number, ABO/Rh, expiry, and special requirements. - Updates blood_component_inventory.status = 'Issued', sets issued_datetime, issued_to_patient_id, and destination location.
10. Technologist records pickup details:
    • Person collecting (nurse ID), time, clinical area.
11. System starts timer for return monitoring:
    • If unit not started within defined time (e.g., 30 minutes) and returned, system evaluates temperature and visual inspection before re-inventory.
12. If unit returned unused and acceptable:
    • blood_component_inventory.status updated back to Available, returned_datetime recorded.
    • If unacceptable (e.g., out of temperature range) → status = 'Discarded' and blood_discard_log entry created.

Data Modified:

• crossmatch_records — INSERT (per unit crossmatched)
• blood_component_inventory — UPDATE (status, issued/returned timestamps, issued_to_patient_id)
• transfusion_orders — UPDATE (order_status, e.g., "Crossmatched", "Partially Filled")
• blood_discard_log — INSERT (for discarded units)
• audit_log — INSERT

Mermaid Flowchart

Decision Points

1. Valid type & screen and no blocks: - If invalid or blocked → crossmatch cannot proceed; physician and blood bank medical director notified.
2. Electronic vs serological crossmatch eligibility: - Based on configured Crossmatch Eligibility Rules (master data).
3. Compatibility result: - Incompatible units cannot be issued; alternative units must be selected.

Integration Points

• CPOE (cpoe) — INT-BB-001:
• Inbound: transfusion orders with component type, units, priority.
• Outbound: order status updates (crossmatched, issued).
• Scheduling (scheduling):
• Patient location and encounter details for issue destination.
• EHR Patient Chart — INT-BB-003:
• Outbound: crossmatch results and units issued (for transfusion history).

Exception Handling

• No compatible units available:
• System alerts technologist and supervisor; may trigger emergency release protocol (outside this workflow) or external supplier request (WF-BB-007).
• Electronic crossmatch rule failure:
• System automatically falls back to serological crossmatch.
• Unit not returned within expected time:
• System generates alert to ward and blood bank; may require investigation.

Paperless Transformation

Remaining Paper Touchpoints: Physical tags attached to units (printed from system) remain necessary for bedside verification but are generated digitally.

Inputs and Outputs

Inputs:

Outputs:

Post-conditions:

• Crossmatch result recorded for each unit tested
• Compatible units issued with printed tags and pickup details
• Inventory updated; unreturned-unit timer active
• Ordering provider and EHR updated with crossmatch results
• Incompatible units flagged and alternative units selected

SLA and Timing

State Transition Diagram

WF-BB-005: Transfusion Administration

Process Flow

Actor: Nurse (Transfusion), Ordering Physician (for reaction management)
Trigger: Crossmatched unit issued to clinical area (WF-BB-004)
Pre-conditions:

• Unit issued in blood_component_inventory with status Issued
• Valid transfusion order in EHR
• Patient present with identification band

1. Nurse opens Transfusion Administration (SCR-BB-006) on bedside device and selects patient or scans wristband barcode.
2. System loads active transfusion orders and issued units for that patient.
3. Two nurses perform bedside verification: - Scan patient wristband and unit barcode. - System verifies: patient identifiers, ABO/Rh compatibility, unit number, expiry, special requirements.
4. If verification fails: - System displays hard-stop alert; transfusion cannot start; nurse must contact blood bank.
5. If verification passes: - Nurse records pre-transfusion vitals (temperature, pulse, BP, SpO2) and any pre-medications administered (via PIS/EHR integration).
6. Nurse confirms start of transfusion: - Records start_datetime and initial infusion rate. - System creates transfusion_administration record with status = 'In Progress'.
7. System schedules monitoring prompts: - 15-minute check, then periodic checks as per protocol (e.g., hourly).
8. At each prompt, nurse records vitals and symptoms (e.g., chills, rash, dyspnea).
9. If nurse observes potential reaction: - Activates reaction alert button; system flags reaction_occurred = true and suggests stopping transfusion and notifying physician (transition to WF-BB-006).
10. If transfusion completes without reaction:
    • Nurse records end_datetime, total volume_infused, and post-transfusion vitals.
    • System updates transfusion_administration.status = 'Completed'.
11. Nurse returns completed tag/unit (if applicable) to blood bank; system records completion and may update inventory (e.g., for partial returns, if policy).

Data Modified:

• transfusion_administration — INSERT (new administration) and UPDATE (status, times, vitals JSON, reaction flag)
• blood_component_inventory — UPDATE (may set final disposition or confirm completion)
• transfusion_orders — UPDATE (e.g., units administered count)
• audit_log — INSERT

Mermaid Flowchart

Decision Points

1. Patient-unit match and compatibility: - If mismatch or incompatibility → transfusion blocked; blood bank contacted.
2. Signs of reaction: - If present → transfusion stopped; reaction workflow initiated.
3. Transfusion completion: - If not complete → continue monitoring. - If complete → finalize administration record.

Integration Points

• EHR Patient Chart:
• Vitals and transfusion administration summary visible in nursing flowsheets.
• CPOE/PIS:
• Pre-medication orders and administration may be linked.
• Blood Bank Module:
• Updates blood_component_inventory and transfusion history.

Exception Handling

• Device offline at bedside:
• Local caching of scans and vitals with later sync; system marks entries as offline-captured.
• Barcode unreadable:
• Manual entry with double-check by two nurses; system requires dual authentication.
• Patient moved to another location mid-transfusion:
• System updates location via scheduling/EHR; monitoring prompts continue.

Paperless Transformation

Remaining Paper Touchpoints: Physical unit tag may be returned to blood bank but is generated by the system.

Inputs and Outputs

Inputs:

Outputs:

Post-conditions:

• Transfusion administration record complete with start/end times, volume, and vitals
• Bedside verification confirmed with two-nurse barcode checks
• Monitoring protocol followed with timed vital sign checks
• If reaction detected: transfusion stopped, reaction workflow triggered
• Inventory and order records reflect final disposition

SLA and Timing

State Transition Diagram

WF-BB-006: Transfusion Reaction Investigation

Process Flow

Actor: Blood Bank Technologist, Physician, Nurse
Trigger: Suspected transfusion reaction reported (from WF-BB-005)
Pre-conditions:

• Active or recently completed transfusion administration record
• Unit and tubing available for return to blood bank
• Reaction signs/symptoms documented by nursing

1. Nurse stops transfusion immediately and maintains IV access with saline (per protocol).
2. Nurse opens Transfusion Reaction Investigation (SCR-BB-007) from the patient’s transfusion record and documents: - Onset time, signs/symptoms (fever, chills, rash, dyspnea, hypotension, etc.).
3. Nurse returns the blood product and tubing to the blood bank; system records return time and links to component_id.
4. Physician evaluates patient, orders post-reaction labs (DAT, free hemoglobin, repeat ABO/Rh, renal function, etc.) via CPOE; LIS integration handles results.
5. Blood Bank Technologist reviews the case in SCR-BB-007: - Confirms clerical checks (patient ID, unit number, compatibility). - Performs visual inspection for hemolysis, checks storage and transport conditions.
6. Technologist performs DAT and other required tests; records dat_result, hemolysis_check, and other findings.
7. Blood bank team (technologist + physician/pathologist) classifies reaction: - Using Transfusion Reaction Types master data (e.g., febrile non-hemolytic, allergic, acute hemolytic, TRALI, TACO). - Assigns severity and classification.
8. System creates transfusion_reactions record linked to admin_id, patient_id, component_id.
9. If reaction is serious (as per MOH hemovigilance criteria): - System flags reported_to_moh = false and prompts Blood Bank Medical Director to complete MOH hemovigilance report.
10. Medical Director reviews investigation, approves classification, and records regulatory reporting details (date, reference number).
11. System updates transfusion_reactions.reported_to_moh = true once submitted and stores reference.
12. Patient record updated with reaction history; future transfusion orders trigger alerts referencing this reaction.

Data Modified:

• transfusion_administration — UPDATE (reaction_occurred, status if stopped early)
• transfusion_reactions — INSERT (new reaction record)
• blood_quarantine_log — INSERT (if unit quarantined pending investigation)
• blood_components / blood_component_inventory — UPDATE (status if unit discarded)
• blood_discard_log — INSERT (if unit discarded due to reaction)
• audit_log — INSERT

Mermaid Flowchart

Decision Points

1. Serious vs non-serious reaction: - Based on MOH/ISBT hemovigilance criteria; serious reactions require MOH reporting.
2. Unit disposition: - If investigation suggests product-related cause → unit discarded; blood_discard_log updated.
3. Future transfusion precautions: - System may enforce special requirements (e.g., washed cells, pre-medication) based on reaction type.

Integration Points

• CPOE/LIS:
• Post-reaction lab orders and results.
• MOH Hemovigilance Portal — INT-BB-005:
• Outbound: serious reaction reports (event-driven and summary).
• EHR Patient Chart:
• Reaction history and alerts for future transfusions.

Exception Handling

• Incomplete data (unit not returned):
• System records limitation in investigation_findings; classification may be "Possible" rather than "Definite".
• Delayed reaction recognition:
• Workflow can be initiated after completion; system links to relevant administration by time and unit.
• MOH portal downtime:
• System queues report for later submission and tracks pending status.

Paperless Transformation

Remaining Paper Touchpoints: MOH may still require printed or PDF-signed forms; system should generate these from digital data.

Inputs and Outputs

Inputs:

Outputs:

Post-conditions:

• Reaction classified with severity and linked to administration record and component
• Investigation findings documented (clerical check, DAT, hemolysis, visual inspection)
• Serious reactions reported to MOH with tracking reference
• Patient chart updated with reaction history; future transfusion orders trigger alerts
• If product-related: unit discarded and donor flagged for follow-up

SLA and Timing

Note: Transfusion reaction investigation is a linear clinical investigation workflow. The reaction record progresses from initial report through investigation to classification and regulatory reporting. No separate state diagram is required.

WF-BB-007: Blood Inventory Management

Process Flow

Actor: Blood Bank Supervisor
Trigger: Daily inventory review, low stock alert, component expiry approaching, or usage demand spike
Pre-conditions:

• blood_component_inventory accurately reflects current stock and locations
• Par levels and reorder rules configured per component and ABO/Rh

1. Supervisor opens Blood Component Inventory (SCR-BB-004) or Blood Bank Dashboard (SCR-BB-008).
2. System displays: - Current inventory by component type, ABO/Rh, facility, and storage location. - Expiry countdown and FEFO ordering. - Alerts for low stock (below par) and approaching expiry.
3. Supervisor reviews low-stock alerts: - For each component/ABO group below par, system suggests reorder quantity based on average daily usage and target days on hand.
4. Supervisor initiates order to external blood bank suppliers (INT-BB-006): - System generates electronic request (secure file/API) with required units, component types, and delivery dates.
5. Upon shipment arrival: - Technologist receives shipment, scans unit barcodes, and verifies product details (component type, ABO/Rh, expiry, special processing). - System creates blood_components and blood_component_inventory entries for received units.
6. For inter-facility transfers: - Supervisor initiates transfer; system updates inventory at sending and receiving facilities accordingly.
7. System continuously monitors expiry: - Units approaching expiry trigger alerts; supervisor may prioritize their use or plan redistribution.
8. For expired or unusable units: - Supervisor approves discard; technologist records discard_reason, discard_datetime, discarded_by, witness_id, and disposal_method in blood_discard_log. - blood_component_inventory.status set to Discarded.
9. Supervisor generates daily/weekly inventory and wastage reports for internal review and regulatory compliance.

Data Modified:

• blood_component_inventory — INSERT (new units) and UPDATE (status, location, facility)
• blood_components — INSERT (for externally supplied units) and UPDATE (status)
• blood_discard_log — INSERT (discarded units)
• blood_quarantine_log — may be INSERT/UPDATE for units pending verification
• audit_log — INSERT

Mermaid Flowchart

Decision Points

1. Low stock / expiry alerts: - If triggered → reorder or redistribute. - If not → routine monitoring only.
2. Unit suitability (on receipt): - If details mismatch or damage detected → quarantine or discard.
3. Discard approval: - Supervisor must approve; system enforces dual sign-off (witness) for discards.

Integration Points

• External Blood Bank Suppliers — INT-BB-006:
• Outbound: blood product requests.
• Inbound: shipment manifests and product details.
• Billing & Claims — INT-BB-004:
• Inventory status drives charge capture when units are issued/administered.
• EHR Facilities/Locations:
• Facility and storage location master data for inventory placement.

Exception Handling

• Mismatch between shipment manifest and scanned units:
• System flags discrepancies; supervisor investigates with supplier.
• Inventory count discrepancies (physical vs system):
• Cycle counts performed; adjustments recorded with reason and audit trail.
• System downtime:
• Temporary manual logs used; later reconciled with system entries; all manual adjustments flagged.

Paperless Transformation

Remaining Paper Touchpoints: Some suppliers may still send paper packing slips; data is captured into the system and slips can be scanned/archived.

Inputs and Outputs

Inputs:

Outputs:

Post-conditions:

• Inventory accurately reflects current stock with expiry tracking
• Low-stock alerts triggered and reorder requests sent when below par levels
• External shipments received, verified, and entered into inventory
• Expired or unusable units discarded with dual sign-off and audit trail
• Inter-facility transfers reflected in both sending and receiving inventories
• Daily/weekly reports generated for operational and regulatory review

SLA and Timing

Note: Blood inventory management is an operational monitoring and replenishment workflow. The component lifecycle (from receipt through availability to issue, expiry, or discard) is defined in the state diagram in WF-BB-002. No additional state diagram is required here.