Blood Bank Management Master Data & Configuration

Master Data Inventory

Note: Shared entities (patients, providers, facilities, encounters, users, payers) are referenced from their owning modules and are not redefined here. See ../ehr-patient-mgmt/06-master-data.md and ../policy-contract-mgmt/06-master-data.md.

Setup Sequence

Dependency Graph

Recommended Load Order

1. Foundational coding & facility identifiers - MD-BB-001 ABO/Rh Blood Group Codes
   - MD-BB-003 Antibody Specificity Codes
   - MD-BB-021 Antibody Screen Result Codes
   - MD-BB-020 Crossmatch Result Codes
   - MD-BB-030 MOH/DOH/DHA Facility Blood Bank IDs

2. Component catalogue & storage - MD-BB-002 Blood Component Types
   - MD-BB-007 Component Storage Requirements
   - MD-BB-013 Component Status Codes
   - MD-BB-025 Storage Location Types
   - MD-BB-026 Temperature Zone Codes

3. Donor management - MD-BB-005 Donor Deferral Reasons
   - MD-BB-028 Donor Status Codes
   - MD-BB-010 Donation Types
   - MD-BB-011 Donation Complication Codes
   - MD-BB-012 Donation Status Codes
   - MD-BB-029 Donor Questionnaire Question Bank

4. Infectious disease testing - MD-BB-006 Infectious Disease Testing Panel
   - MD-BB-022 Infectious Disease Result Codes

5. Transfusion ordering & compatibility - MD-BB-008 Crossmatch Eligibility Rules
   - MD-BB-009 Transfusion Indication Codes
   - MD-BB-017 Transfusion Priority Codes
   - MD-BB-018 Special Requirement Codes
   - MD-BB-019 Transfusion Order Status Codes
   - MD-BB-027 Massive Transfusion Protocol Packs

6. Hemovigilance & disposal - MD-BB-004 Transfusion Reaction Types
   - MD-BB-023 Reaction Severity Codes
   - MD-BB-024 Hemovigilance Report Types
   - MD-BB-014 Quarantine Reasons
   - MD-BB-015 Discard Reasons
   - MD-BB-016 Disposal Methods

7. Validation & Go-Live - Cross-check mappings with LIS, CPOE, MOH hemovigilance portal
   - Lock system-owned code sets; enable governed change workflows

Master Data Specifications

Below are detailed specifications for the core blood-bank–specific master data sets explicitly mentioned in the brief. Additional sets (MD-BB-010+ etc.) follow the same pattern and can be extended in implementation.

MD-BB-001: ABO/Rh Blood Group Codes

Purpose

Standardised coding of patient and donor ABO/Rh blood groups used across:

• blood_donors, blood_components, blood_type_screen, crossmatch_records
• Compatibility logic, inventory filtering, transfusion decision support
• Reporting to UAE MOH, DOH, DHA, NABIDH/Malaffi

Schema

Table: ref_blood_group

Sample Data

Data Governance

• Owner: System Admin; clinical authority: Blood Bank Medical Director
• Approval process: Any change requires: 1. Written request from Blood Bank Medical Director 2. Review by Clinical Informatics + Integration team (impact on LIS/CPOE) 3. Change implemented in test, validated with sample orders/results 4. Scheduled production deployment
• Update frequency: Fixed; only on international standard change
• Change notification:
• Release note to blood bank staff, LIS, CPOE teams
• Update to interface mapping tables (HL7, FHIR) if codes change

Validation Rules

• blood_group_code must be unique and in set {O-,O+,A-,A+,B-,B+,AB-,AB+}
• abo_group must be in {O,A,B,AB}
• rh_factor must be in {POS,NEG}
• is_universal_donor TRUE only for O-
• is_universal_recipient TRUE only for AB+
• is_active cannot be set to FALSE for standard 8 without explicit super-admin override

MD-BB-002: Blood Component Types

Purpose

Defines all blood components that can be produced, stored, issued, and billed:

• Used in blood_components, blood_component_inventory, transfusion_orders, transfusion_administration
• Mapped to ISBT 128 product codes and billing (CPT/RCM) where applicable
• Drives storage requirements, shelf life, and compatibility rules

Schema

Table: ref_blood_component_type

Sample Data

(Long plasma/cryoprecipitate shelf life expressed in hours; implementation may use days.)

Data Governance

• Owner: Blood Bank Medical Director
• Approval process: 1. Proposal for new/changed component from Blood Bank Supervisor 2. Review by Transfusion Committee (clinical indication, billing impact) 3. Mapping to ISBT 128 and billing codes validated by RCM team 4. Build/update in test → validation with LIS/CPOE → production deployment
• Update frequency: On ISBT updates, new component introduction, or policy change
• Change notification:
• Email to blood bank staff, nursing, ordering physicians
• Update to training materials and transfusion guidelines
• Interface mapping updates for LIS, billing, MOH reporting

Validation Rules

• component_type_code unique, uppercase, alphanumeric + underscore only
• component_category in {RBC,PLATELET,PLASMA,CRYO,WHOLE,OTHER}
• shelf_life_hours > 0
• storage_temp_min_c < storage_temp_max_c
• If requires_irradiation_flag = TRUE then component_category must be RBC or PLATELET
• is_active cannot be set FALSE if referenced by active inventory records (enforce via application-level checks)

MD-BB-003: Antibody Specificity Codes

Purpose

Standardised coding of red cell antibodies for:

• Recording antibody screen/identification results in blood_type_screen
• Driving antigen-negative unit selection and crossmatch rules
• Hemovigilance and clinical decision support (e.g., anti-D, anti-K)

Schema

Table: ref_antibody_specificity

Sample Data

Data Governance

• Owner: Blood Bank Supervisor
• Approval process:
• New antibody codes only added based on ISBT updates or Medical Director request
• Changes reviewed by Medical Director and LIS lead (for result mapping)
• Update frequency: Rare; on ISBT nomenclature updates
• Change notification:
• Update LIS result dictionaries and mapping tables
• Communicate to technologists via SOP updates

Validation Rules

• antibody_code unique, pattern ANTI_ + uppercase letters/numbers
• clinical_significance in {HIGH,MODERATE,LOW,UNKNOWN}
• If requires_antigen_negative_units = TRUE then clinical_significance must be HIGH or MODERATE
• blood_group_system must be from controlled list (Rh, Kell, Duffy, Kidd, MNS, Lewis, P, etc.)

MD-BB-004: Transfusion Reaction Types

Purpose

Standardised classification of transfusion reactions for:

• Documentation in transfusion_reactions
• MOH hemovigilance reporting
• Analytics (reaction rates, severity, component association)

Schema

Table: ref_transfusion_reaction_type

Sample Data

Data Governance

• Owner: Blood Bank Medical Director
• Approval process:
• Changes proposed by Hemovigilance Officer or Medical Director
• Reviewed against UAE MOH hemovigilance definitions
• Tested in reporting templates before activation
• Update frequency: Annual review or when MOH updates hemovigilance categories
• Change notification:
• Updated hemovigilance SOPs
• Training sessions for nursing and medical staff
• Update mapping to MOH online reporting portal

Validation Rules

• reaction_type_code unique, uppercase, alphanumeric + underscore
• default_severity in {MILD,MODERATE,SEVERE,FATAL}
• If requires_moh_reporting = TRUE then must be mapped in MOH reporting templates
• Cannot delete codes referenced in transfusion_reactions; only inactivate (is_active = FALSE)

MD-BB-005: Donor Deferral Reasons

Purpose

Standardised reasons for temporary or permanent donor deferral, aligned with UAE MOH blood safety guidelines:

• Used in blood_donors (deferral history) and donor screening workflow
• Supports reporting of deferral rates and regulatory compliance

Schema

Table: ref_donor_deferral_reason

Sample Data

Data Governance

• Owner: Blood Bank Medical Director
• Approval process:
• Changes initiated by Donor Physician or Medical Director
• Must be cross-checked with latest UAE MOH blood donation guidelines
• Clinical governance committee sign-off for permanent deferral categories
• Update frequency: On MOH guideline updates; otherwise annual review
• Change notification:
• Update donor screening questionnaire and SOPs
• Communicate to donor clinic staff
• Update any public-facing donor eligibility materials

Validation Rules

• deferral_type in {TEMPORARY,PERMANENT}
• If deferral_type = TEMPORARY then deferral_duration_days must be > 0
• If deferral_type = PERMANENT then deferral_duration_days must be NULL
• At least one of is_infectious_risk, is_pregnancy_related, is_travel_related should be TRUE for MOH risk-related deferrals

MD-BB-006: Infectious Disease Testing Panel

Purpose

Defines mandatory infectious disease tests performed on donor samples, aligned with UAE MOH requirements:

• Used to configure LIS orders and interpret results for blood_donations and blood_quarantine_log
• Drives automatic quarantine release/discard logic

Schema

Table: ref_infectious_test_panel

(Assumes ref_infectious_result is part of MD-BB-022.)

Sample Data

Data Governance

• Owner: Blood Bank Medical Director (with Lab Director)
• Approval process:
• MOH circular or guideline triggers review
• Joint decision by Lab Director and Medical Director
• LIS and HIS configuration updated in coordination
• Update frequency: On MOH requirement change; at least annual review
• Change notification:
• Notify MOH if required
• Update donor consent forms and information leaflets
• Communicate to LIS team and donor clinic

Validation Rules

• test_code unique, uppercase, no spaces
• is_mandatory TRUE for all tests required by current MOH regulation
• reactive_result_code and nonreactive_result_code must exist in ref_infectious_result
• At least one active mandatory test per major pathogen category (HBV, HCV, HIV, Syphilis, Malaria)

MD-BB-007: Component Storage Requirements

Purpose

Defines storage temperature and shelf life per component category/type:

• Used to validate blood_component_inventory storage conditions
• Drives expiry calculation and FEFO (First Expiry First Out) logic
• Supports regulatory compliance with ISBT and UAE MOH standards

Schema

Table: ref_component_storage_requirement

Sample Data

Data Governance

• Owner: Blood Bank Supervisor
• Approval process:
• Proposed changes reviewed by Medical Director
• Cross-checked with ISBT and MOH regulations
• Validated with Biomedical Engineering (storage equipment capabilities)
• Update frequency: Rare; on standard changes
• Change notification:
• Update SOPs and temperature monitoring protocols
• Reconfigure temperature alarm thresholds where needed

Validation Rules

• Either component_type_code OR component_category must be populated; not both NULL
• storage_temp_min_c < storage_temp_max_c
• default_shelf_life_hours > 0
• For a given component_type_code, only one active rule allowed

MD-BB-008: Crossmatch Eligibility Rules

Purpose

Defines when electronic crossmatch is allowed vs. when serological crossmatch is required:

• Used in crossmatch_records workflow and decision support
• Ensures compliance with AABB/facility guidelines and UAE safety expectations

Schema

Table: ref_crossmatch_rule

Sample Data

Data Governance

• Owner: Blood Bank Medical Director
• Approval process:
• Proposed by Senior Technologist or Medical Director
• Reviewed by Transfusion Committee
• Tested in simulation (test patients) before activation
• Update frequency: Annual review or when guidelines change
• Change notification:
• Training for technologists and ordering clinicians
• Update to policy documents and audit criteria

Validation Rules

• crossmatch_type in {ELECTRONIC,SEROLOGICAL}
• Only one active is_default_rule = TRUE per crossmatch_type
• If crossmatch_type = ELECTRONIC then requires_two_concordant_types must be TRUE and allow_if_antibodies_present must be FALSE

MD-BB-009: Transfusion Indication Codes

Purpose

Standardised clinical indications for transfusion orders:

• Used in transfusion_orders.indication
• Supports audit, utilisation review, and guideline adherence monitoring

Schema

Table: ref_transfusion_indication

Sample Data

(For INR>1.5 threshold, implementation may store numeric threshold and operator separately.)

Data Governance

• Owner: Transfusion Committee Chair
• Approval process:
• Proposed by clinical departments or Medical Director
• Reviewed and approved by Transfusion Committee
• Mapped to internal guidelines and audit rules
• Update frequency: Annual or on guideline change
• Change notification:
• Communicated to ordering clinicians
• Incorporated into order set templates and CDS alerts

Validation Rules

• component_category in {RBC,PLATELET,PLASMA,CRYO,WHOLE,MULTI}
• If requires_documented_lab = TRUE then system must enforce presence of relevant lab result within configurable time window (e.g., 24h)
• indication_code unique and stable (no reuse)

Configuration Parameters

Module Configuration Matrix

Data Load Procedures

1. Initial Load

Sources:

• ISBT 128 standard tables (ABO/Rh, component types, antigen/antibody nomenclature)
• UAE MOH blood safety and hemovigilance guidelines
• Facility transfusion policies and SOPs
• LIS dictionaries (infectious tests, result codes)

Process:

1. Design phase - Map required master data sets to source documents (ISBT, MOH, facility policies). - Define code systems and ensure no collision with existing enterprise codes.

2. Staging - Prepare CSV templates for each master data table:

   • ref_blood_group.csv
   • ref_blood_component_type.csv
   • ref_antibody_specificity.csv
   • ref_transfusion_reaction_type.csv
   • ref_donor_deferral_reason.csv
   • ref_infectious_test_panel.csv
   • ref_component_storage_requirement.csv
   • ref_crossmatch_rule.csv
   • ref_transfusion_indication.csv
   • Additional ref tables (status codes, reasons, etc.)

3. Import - Use admin UI or ETL scripts to import CSVs into staging tables. - Run validation routines (see below). - On success, promote to production reference tables.

4. Reconciliation - Cross-check:

   • ABO/Rh codes with LIS blood group dictionary.
   • Component types with existing blood bank labels and billing codes.
   • Infectious test panel with LIS test catalogue.
   • Resolve discrepancies before go-live.

2. Ongoing Synchronisation

• ISBT updates:
• Annual review of ISBT bulletins.
• Import new/updated component and antigen codes into staging.

• Impact analysis, then controlled promotion.

• MOH guideline changes:

• Compliance Officer monitors MOH circulars.

• When blood safety or hemovigilance guidance changes:

  • Update donor deferral reasons, infectious panel, reaction types as needed.
  • Ensure MOH hemovigilance report mappings remain valid.

• LIS integration:

• For infectious tests and results, maintain mapping tables between HIS codes and LIS codes.

• Use HL7 ORU messages to validate that LIS result codes map to ref_infectious_result.

• Facility policy changes:

• Transfusion Committee decisions trigger updates to:
  • Transfusion indications
  • Crossmatch rules
  • MTP pack definitions

3. Import/Export Formats

• Import:
• Preferred: CSV with UTF-8 encoding (to support Arabic).

• Optional: JSON via internal admin API for automated synchronisation.

• Export:

• CSV/Excel for governance review and audits.
• JSON for integration with decision support tools or external registries.

Example CSV header for ref_blood_component_type:

component_type_code,isbt_product_code,display_name_en,display_name_ar,component_category,default_volume_ml,requires_irradiation_flag,is_apheresis,shelf_life_hours,storage_temp_min_c,storage_temp_max_c,billable_cpt_code,is_active,sort_order

4. Validation on Import

For each master data set, the import process must:

1. Structural validation - Required columns present. - Data types correct (e.g., numeric fields contain only numbers).

2. Referential validation - Foreign keys (e.g., component_type_code in storage requirements) exist in referenced tables. - Codes referenced in rules (e.g., reactive_result_code) exist in their ref tables.

3. Business rule validation - ABO/Rh combinations valid. - Shelf life and temperature ranges within clinically acceptable bounds. - Only one default rule per rule category (e.g., crossmatch type).

4. UAE regulatory validation - Infectious panel includes all MOH-mandated tests. - Hemovigilance reaction types cover all MOH reportable categories. - Donor deferral reasons align with MOH criteria.

5. Audit & PDPL - All changes logged with user, timestamp, and before/after values. - For deletions, system should prefer soft-delete (is_active = FALSE) to preserve history in line with UAE PDPL and clinical traceability requirements.

This specification provides the master data and configuration foundation for the Blood Bank Management module, ensuring consistent coding, regulatory compliance in the UAE context, and safe, traceable transfusion practice.