Cleaning Management Integration Specifications

Integration Summary

Note: No direct NABIDH/Malaffi integration is required for Cleaning Management; however, infection-control data consumed from EHR must remain consistent with HIE-sourced clinical data.

INT-CLN-001: Scheduling (Bed Management)

Business Context

What flows

• Inbound (from Bed Management → Cleaning)
• Bed release events when an inpatient encounter is discharged or transferred:
  • Encounter ID, patient ID (for infection context only), facility/department/location, bed ID
  • Discharge/transfer type and timestamp
  • Bed type (e.g., isolation, ICU)

• Optional: expected next admission time (for prioritisation)

• Outbound (from Cleaning → Bed Management)

• Cleaning task lifecycle for the bed/location:
  • Task ID, task type (discharge, transfer, terminal)
  • Status: pending, assigned, in_progress, completed, failed
  • Timestamps: created, assigned, started, completed
  • Protocol applied (standard/enhanced/terminal)
  • Inspection requirement and result (pass/fail)
  • Final bed readiness flag

When

• Inbound: immediately when Scheduling emits ADT A03 (discharge) or A02 (transfer) and marks bed as released.
• Outbound: on each status change of the corresponding cleaning_tasks record, especially when status = 'completed'.

Why

• To minimise bed turnaround time and support real-time bed availability for admissions.
• To ensure beds used for infectious patients are not reallocated until terminal cleaning is completed and, where required, inspected and cleared by Infection Control.
• To provide a single, authoritative bed status across Scheduling and Cleaning.

How often

• Real-time, event-driven. Every bed release generates at least one cleaning task; every task status change generates an outbound event.

Error impact

• Inbound failure: Cleaning tasks are not created; beds remain in “dirty” or “unknown” state, delaying admissions and potentially breaching DOH/DHA operational KPIs.
• Outbound failure: Bed Management does not see beds as “clean/ready”; manual calls and workarounds are required, and audit trail for cleaning may be incomplete.

HL7 v2.5.1 Technical Detail (Inbound ADT)

Although the primary integration is via internal APIs/event bus, the Scheduling module may also emit HL7 ADT messages internally. Cleaning Management subscribes to ADT A02 (transfer) and A03 (discharge) events to infer bed release.

Message Types

• ADT^A03 – Discharge (bed release)
• ADT^A02 – Transfer (bed release from source bed; optional new bed assignment)

Sample HL7 ADT^A03 (Discharge – Bed Release)

MSH|^~\&|ADT_SCHED|DUBAI_HOSPITAL|HIS_CLEANING|DUBAI_HOSPITAL|20260207113000||ADT^A03|MSG20260207113000001|P|2.5.1|||AL|NE||UTF-8
EVN|A03|20260207112930|||USR123^ALI^HASSAN^^^MR
PID|1||2026009876^^^DUBAI_HOSPITAL^MR~784-1985-1234567-1^^^UAE^EID||AL-MAKTOUM^AHMED^MOHAMMED||19850315|M|||PO BOX 12345^^DUBAI^^00000^AE||+971501234567|||M||||||||||AE
PV1|1|I|4B^412^01^DUBAI_HOSPITAL^^BED^ISO||^^^MED||||MED|||||||ENC2026020400456^^^DUBAI_HOSPITAL^VN||||||||||||||||||||01|||||20260207112900
ZBE|1|BED-4B-412-01|DISCHARGE|20260207112900|ISO^Isolation^HL70001

Key Segments for Cleaning

• PID-3: Patient identifiers (MRN and Emirates ID) – used only to link to infection flags from EHR; Cleaning does not store PHI beyond what is necessary per UAE PDPL.
• PV1-3: Assigned patient location (Point of Care^Room^Bed^Facility^…); used to map to beds.bed_id and locations.location_id.
• PV1-19: Visit/encounter number → encounters.encounter_id.
• PV1-36: Discharge disposition (e.g., 01 home, 20 expired) – may influence protocol selection.
• PV1-45: Discharge date/time – used as task_created_datetime baseline.
• ZBE (custom segment):
• ZBE-2: Internal bed identifier.
• ZBE-3: Event reason (DISCHARGE, TRANSFER_OUT).
• ZBE-4: Bed release timestamp.
• ZBE-5: Bed type/flag (e.g., isolation).

Field Mapping to Cleaning Tables

FHIR R4 Technical Detail (Outbound Bed Cleaning Status)

Bed Management may consume a FHIR-based event or resource representing bed cleaning status. We model this as a Task resource with references to Location and Encounter.

Resource Type: Task

{
  "resourceType": "Task",
  "id": "CLN-TASK-20260207-0001",
  "status": "completed",
  "intent": "order",
  "businessStatus": {
    "coding": [
      {
        "system": "http://gates-his.ae/codes/cleaning-status",
        "code": "ready",
        "display": "Clean/Ready"
      }
    ]
  },
  "code": {
    "coding": [
      {
        "system": "http://gates-his.ae/codes/cleaning-task-type",
        "code": "discharge",
        "display": "Discharge Bed Cleaning"
      }
    ]
  },
  "focus": {
    "reference": "Encounter/ENC2026020400456"
  },
  "for": {
    "reference": "Patient/2026009876",
    "display": "Ahmed Al-Maktoum"
  },
  "location": {
    "reference": "Location/LOC-4B-412-01",
    "display": "Ward 4B, Room 412, Bed 01"
  },
  "authoredOn": "2026-02-07T11:29:05+04:00",
  "lastModified": "2026-02-07T11:44:20+04:00",
  "executionPeriod": {
    "start": "2026-02-07T11:32:00+04:00",
    "end": "2026-02-07T11:44:20+04:00"
  },
  "owner": {
    "reference": "PractitionerRole/CLN-STAFF-102",
    "display": "Cleaning Staff – Zone 4B"
  },
  "extension": [
    {
      "url": "http://gates-his.ae/fhir/StructureDefinition/cleaning-protocol",
      "valueCodeableConcept": {
        "coding": [
          {
            "system": "http://gates-his.ae/codes/cleaning-protocol",
            "code": "standard",
            "display": "Standard Discharge Cleaning"
          }
        ]
      }
    },
    {
      "url": "http://gates-his.ae/fhir/StructureDefinition/inspection-result",
      "valueCodeableConcept": {
        "coding": [
          {
            "system": "http://gates-his.ae/codes/inspection-result",
            "code": "pass",
            "display": "Inspection Passed"
          }
        ]
      }
    }
  ]
}

Key Element Mappings

Search Parameters (Bed Management → Cleaning)

• GET /Task?code=discharge&location=Location/LOC-4B-412-01&status=completed
• GET /Task?focus=Encounter/ENC2026020400456
• GET /Task?business-status=ready&location=Location/LOC-4B-*

Error Handling

Manual Recovery

• Operations dashboard listing:
• Bed releases without corresponding cleaning tasks (derived from ADT vs cleaning_tasks).
• Cleaning tasks completed without corresponding “bed ready” updates.
• Supervisor can:
• Manually create a cleaning task for a bed.
• Manually mark bed as “clean/ready” with justification (audited).
• Interface team can replay messages from dead letter queue after correction.

Retry and Recovery

Retry Strategy:

Dead Letter Queue:

• Messages exhausting all retries → integration_dlq table
• On-call IT operations alerted; bed remains locked for allocation until resolved
• Retention: 30 days active, then archive
• Alert: Cleaning Supervisor + IT notified on DLQ insertion

Idempotency:

• Deduplication key: [encounter_id]_[bed_id]_[event_type]
• Duplicate bed release events ignored beyond the first active cleaning task
• Duplicate outbound status updates are safe (idempotent bed status set)

Reconciliation:

• Hourly comparison: Scheduling bed releases (ADT A03/A02) vs cleaning_tasks records
• Bed releases without corresponding cleaning tasks flagged for Supervisor
• Completed cleaning tasks without corresponding "bed ready" updates flagged for IT
• Daily reconciliation report for Bed Management Coordinator and Cleaning Supervisor

INT-CLN-002: Scheduling (OR Management)

Business Context

What flows

• Inbound (OR → Cleaning)

• OR case completion events:

  • OR room ID, facility, department
  • Case ID, encounter ID
  • Case end time
  • Case contamination/infection risk flag (e.g., clean, contaminated, infected)
  • Next case scheduled start time (for prioritisation)

• Outbound (Cleaning → OR)

• OR cleaning task lifecycle:
  • Task ID, task type or_turnover or terminal_or
  • Status and timestamps (created, started, completed)
  • Protocol applied (standard vs terminal)
  • Turnover time metrics
  • Readiness flag for next case

When

• Inbound: immediately when OR nurse marks case as “completed” in OR Management.
• Outbound: on each status change of OR cleaning tasks, especially when status = 'completed'.

Why

• To ensure OR turnover times meet DOH/DHA standards and internal KPIs (≤ 30 minutes).
• To prevent scheduling the next case into an OR that has not been cleaned or cleared after an infectious case.

How often

• Real-time, per OR case.

Error impact

• Inbound failure: OR cleaning tasks not created; OR may appear available while still dirty, or cleaning may be requested manually, degrading auditability.
• Outbound failure: OR schedule board not updated; next case may be delayed or manually rescheduled.

HL7 v2.5.1 Technical Detail

Most OR systems use internal APIs rather than HL7 for case workflow; for completeness, we define an optional ORU-based notification.

Message Type: ORU^R01 (unsolicited observation – OR case completion)

MSH|^~\&|OR_MGMT|ABUDHABI_HOSPITAL|HIS_CLEANING|ABUDHABI_HOSPITAL|20260207121500||ORU^R01|MSG20260207121500001|P|2.5.1|||AL|NE||UTF-8
PID|1||2026012345^^^ABUDHABI_HOSPITAL^MR~784-1990-7654321-3^^^UAE^EID||AL-NAHYAN^FATIMA^SAEED||19900310|F
PV1|1|I|OR^OR-03^MAIN^ABUDHABI_HOSPITAL||||ALI^OMAR^DR|||SURG|||||||ENC2026020500789^^^ABUDHABI_HOSPITAL^VN
OBR|1|CASE-20260207-OR03||ORPROC^OR Procedure^L||20260207103000|20260207121000||||||||ALi^OMAR^DR
OBX|1|CE|ORSTATUS^OR Case Status^L||COMPLETED^Completed^L||||||F
OBX|2|CE|ORINFECT^OR Infection Risk^L||TERMINAL_REQUIRED^Terminal Cleaning Required^L||||||F

Key Segments

• PV1-3: OR location (OR room).
• OBR-2: Case ID.
• OBR-7/8: Case start/end times.
• OBX-1: Case status (COMPLETED).
• OBX-2: Infection risk / terminal cleaning requirement.

Mapping to Cleaning

FHIR R4 Technical Detail

We model OR cleaning as a Task resource, similar to bed cleaning, with OR-specific codes.

{
  "resourceType": "Task",
  "id": "CLN-OR-20260207-OR03",
  "status": "in-progress",
  "intent": "order",
  "code": {
    "coding": [
      {
        "system": "http://gates-his.ae/codes/cleaning-task-type",
        "code": "or_turnover",
        "display": "OR Turnover Cleaning"
      }
    ]
  },
  "focus": {
    "reference": "Procedure/CASE-20260207-OR03"
  },
  "location": {
    "reference": "Location/OR-03",
    "display": "Operating Room 03"
  },
  "authoredOn": "2026-02-07T12:15:10+04:00",
  "executionPeriod": {
    "start": "2026-02-07T12:17:00+04:00"
  },
  "owner": {
    "reference": "PractitionerRole/OR-CLEAN-TEAM-1",
    "display": "OR Cleaning Team 1"
  },
  "extension": [
    {
      "url": "http://gates-his.ae/fhir/StructureDefinition/cleaning-protocol",
      "valueCodeableConcept": {
        "coding": [
          {
            "system": "http://gates-his.ae/codes/cleaning-protocol",
            "code": "terminal_or",
            "display": "Terminal OR Cleaning"
          }
        ]
      }
    },
    {
      "url": "http://gates-his.ae/fhir/StructureDefinition/next-case-start",
      "valueDateTime": "2026-02-07T13:00:00+04:00"
    }
  ]
}

Search Parameters

• GET /Task?code=or_turnover&location=Location/OR-03&status=completed
• GET /Task?focus=Procedure/CASE-20260207-OR03
• GET /Task?location=Location/OR-03&status=in-progress

Error Handling

Retry and Recovery

Retry Strategy:

Dead Letter Queue:

• OR status messages exhausting all retries → integration_dlq table
• OR Coordinator alerted after 15 min of failure; may manually update OR schedule board
• Retention: 30 days active, then archive
• Alert: OR Coordinator + IT notified on DLQ insertion

Idempotency:

• Deduplication key: [case_id]_[or_room_id]_[event_type]
• Duplicate OR completion events ignored beyond the first active cleaning task
• Duplicate outbound status updates are safe (idempotent OR room status set)

Reconciliation:

• After each OR session block: compare OR completed cases vs Cleaning tasks created
• OR rooms with completed cases but no cleaning tasks flagged for OR Coordinator
• Completed cleaning tasks without corresponding "room ready" updates flagged for IT
• Daily OR turnover time reconciliation report

INT-CLN-003: EHR (Infection Control)

Business Context

What flows

• Inbound only (EHR → Cleaning)
• Infection control / isolation flags:
  • Encounter ID, patient ID
  • Isolation type (e.g., airborne, droplet, contact)
  • Pathogen (SNOMED CT/ICD-10-AM coded)
  • Start/end timestamps
  • Requirement for terminal cleaning and specific protocol (e.g., C. difficile, COVID-19)
• Outbreak alerts for specific zones (e.g., ward-level enhanced cleaning).

When

• When infection control nurse sets or updates an isolation precaution in the EHR.
• When a patient with active isolation is discharged or transferred (combined with INT-CLN-001).

Why

• To automatically select the correct cleaning protocol (standard vs enhanced vs terminal).
• To ensure compliance with DOH/DHA infection prevention standards and internal infection-control policies.

How often

• Real-time, low to medium volume.

Error impact

• If infection flags are not received, Cleaning may apply standard protocols instead of terminal/enhanced, increasing infection risk and non-compliance with UAE infection control guidelines.

HL7 v2.5.1 Technical Detail

Infection-control data is typically exposed via EHR APIs or FHIR; HL7 v2 internal messaging is optional. If used, ADT^A08 with Z-segments or ORU^R01 with OBX segments can carry isolation information. This is internal and must not be forwarded to NABIDH/Malaffi from Cleaning.

Example (optional) ORU^R01 for isolation flag:

MSH|^~\&|EHR_IC|DUBAI_HOSPITAL|HIS_CLEANING|DUBAI_HOSPITAL|20260207100000||ORU^R01|MSG20260207100000001|P|2.5.1|||AL|NE||UTF-8
PID|1||2026009876^^^DUBAI_HOSPITAL^MR~784-1985-1234567-1^^^UAE^EID||AL-MAKTOUM^AHMED^MOHAMMED||19850315|M
PV1|1|I|4B^412^01^DUBAI_HOSPITAL|||||||||||||||ENC2026020400456^^^DUBAI_HOSPITAL^VN
OBR|1|ISO-20260207-0001||ISOFLAG^Isolation Flag^L||20260207100000
OBX|1|CE|ISO-TYPE^Isolation Type^L||AIRBORNE^Airborne Precautions^L||||||F
OBX|2|CE|PATHOGEN^Pathogen^L||840539006^COVID-19^SCT||||||F
OBX|3|CE|TERM-REQ^Terminal Cleaning Required^L||YES^Yes^L||||||F

FHIR R4 Technical Detail

We use Flag resources for infection/isolation status and Condition for pathogen details.

Resource Types: Flag, Condition

{
  "resourceType": "Flag",
  "id": "ISO-ENC2026020400456",
  "status": "active",
  "category": [
    {
      "coding": [
        {
          "system": "http://terminology.hl7.org/CodeSystem/flag-category",
          "code": "safety",
          "display": "Safety"
        }
      ]
    }
  ],
  "code": {
    "coding": [
      {
        "system": "http://gates-his.ae/codes/isolation-type",
        "code": "airborne",
        "display": "Airborne Precautions"
      }
    ],
    "text": "Airborne isolation – COVID-19"
  },
  "subject": {
    "reference": "Patient/2026009876",
    "display": "Ahmed Al-Maktoum"
  },
  "encounter": {
    "reference": "Encounter/ENC2026020400456"
  },
  "period": {
    "start": "2026-02-04T09:15:00+04:00"
  },
  "extension": [
    {
      "url": "http://gates-his.ae/fhir/StructureDefinition/terminal-cleaning-required",
      "valueBoolean": true
    }
  ]
}

Key Mappings

Search Parameters (Cleaning → EHR)

• GET /Flag?encounter=Encounter/ENC2026020400456&status=active&category=safety
• GET /Condition?encounter=Encounter/ENC2026020400456&code=840539006 (COVID-19)

Error Handling

Retry and Recovery

Retry Strategy:

Dead Letter Queue:

• Not applicable for inbound-only read integration; failed lookups are cached and retried
• If infection flag notification fails persistently (> 10 min), alert Infection Control team

Idempotency:

• Infection flags are idempotent by nature; re-reading the same flag produces the same protocol selection
• Cache key: [encounter_id]_[isolation_type]; updated on each successful retrieval

Reconciliation:

• On each discharge/transfer cleaning task creation: verify infection flags are current (fetched within last 15 min)
• If flags are stale, re-fetch before protocol selection
• Default to conservative protocol (terminal) if infection status cannot be determined
• Weekly comparison: Infection Control active isolation flags vs Cleaning protocol selections for compliance audit

INT-CLN-004: Facilities / Maintenance CMMS

Business Context

What flows

• Outbound only (Cleaning → CMMS)
• Maintenance work order requests created during cleaning:
  • Location (facility, department, room/bed or zone)
  • Issue type (e.g., broken bed, leaking tap, light not working, biohazard spill)
  • Severity/urgency
  • Free-text description
  • Photos/attachments (URLs or binary references)
  • Reporter (cleaning staff ID)
  • Optional: link to cleaning task ID

When

• When cleaning staff records a maintenance issue from the mobile app (WF-CLN-003, WF-CLN-005).

Why

• To ensure environmental issues are tracked and resolved through the formal maintenance workflow, improving safety and compliance with facility standards.

How often

• On-demand, low to medium volume.

Error impact

• If integration fails, maintenance issues may not be logged, leading to unresolved hazards or repeated manual calls to maintenance.

HL7 v2.5.1

Not applicable; this integration is REST/API-based only.

FHIR R4 Technical Detail

If the CMMS supports FHIR, maintenance issues can be represented as ServiceRequest or Task. Here we show ServiceRequest.

Resource Type: ServiceRequest

{
  "resourceType": "ServiceRequest",
  "id": "WO-20260207-0001",
  "status": "active",
  "intent": "order",
  "category": [
    {
      "coding": [
        {
          "system": "http://gates-his.ae/codes/maintenance-category",
          "code": "facility",
          "display": "Facility Maintenance"
        }
      ]
    }
  ],
  "code": {
    "coding": [
      {
        "system": "http://gates-his.ae/codes/maintenance-issue",
        "code": "broken_fixture",
        "display": "Broken Fixture"
      }
    ],
    "text": "Broken bathroom tap"
  },
  "subject": {
    "reference": "Location/LOC-4B-412-BATH",
    "display": "Ward 4B, Room 412, Bathroom"
  },
  "authoredOn": "2026-02-07T10:05:00+04:00",
  "requester": {
    "reference": "PractitionerRole/CLN-STAFF-102",
    "display": "Cleaning Staff – Zone 4B"
  },
  "priority": "urgent",
  "reasonCode": [
    {
      "text": "Water leaking onto floor during cleaning"
    }
  ],
  "note": [
    {
      "text": "Reported from cleaning task CLN-TASK-20260207-0003"
    }
  ]
}

Search Parameters

• GET /ServiceRequest?category=facility&status=active&subject=Location/LOC-4B-412-BATH
• GET /ServiceRequest?authored=ge2026-02-07&requester=PractitionerRole/CLN-STAFF-102

Error Handling

Retry and Recovery

Retry Strategy:

Dead Letter Queue:

• Work orders exhausting all retries → integration_dlq table
• Facilities Manager alerted; maintenance issue may go unresolved until replayed
• Retention: 30 days active, then archive
• Alert: Facilities Manager + IT notified on DLQ insertion

Idempotency:

• Deduplication key: [cleaning_task_id]_[issue_type]_[location_id]_[reported_datetime]
• CMMS checks for duplicate work orders based on location + issue type within configurable time window (e.g., 1 h)
• Duplicate submissions acknowledged without creating new work orders

Reconciliation:

• Daily comparison: Cleaning-reported maintenance issues vs CMMS work orders created
• Issues in Cleaning without corresponding CMMS work orders flagged for IT
• Weekly report on work order creation success rate for Facilities Manager

NABIDH / Malaffi Integration

• Cleaning Management does not directly integrate with NABIDH (Dubai) or Malaffi (Abu Dhabi).
• Infection-control data consumed via INT-CLN-003 originates from the EHR, which is responsible for:
• Applying NABIDH/Malaffi profiles for Condition, Observation, and other clinical resources.
• Ensuring that isolation flags and pathogen data are consistent with HIE-sourced information.
• Cleaning Management must:
• Treat infection-control data as read-only clinical context.
• Not attempt to publish or modify clinical data to HIEs.
• Maintain audit logs of protocol selection decisions based on infection data for DOH/DHA inspections.

Authentication & Security

All integrations must comply with UAE PDPL, DOH ADHICS, and DHA information security requirements, as well as TDRA/NESA cybersecurity standards.

Transport Security

• All API and message traffic between modules uses TLS 1.2+.
• Internal microservices communicate over a service mesh with mutual TLS (mTLS):
• Certificates issued by the organisation’s internal CA.
• Certificate rotation automated and logged.

Authentication & Authorisation

• Internal APIs / Event Bus
• Service-to-service auth via:
  • mTLS client certificates, and
  • Short-lived JWTs issued by the central IAM service (audience = target service).

• Role-based access control enforced at API gateway and service level:

  • Cleaning service scopes: cleaning.read, cleaning.write, cleaning.status.publish.
  • Bed Management scopes: bed.read, bed.status.update.
  • Infection Control scopes: infection.read.

• External CMMS / Maintenance System

• Preferred: OAuth 2.0 client credentials flow:
  • Client ID/secret stored in secure vault.
  • Access tokens cached and rotated before expiry.
• Alternative: Signed API keys with IP allow-list and rate limiting.

Message Confidentiality & Minimisation

• Cleaning Management stores only minimal patient identifiers required for linkage (typically encounter_id, bed_id, location_id); Emirates ID and full demographics remain in EHR/Scheduling.
• Payloads on the event bus are designed to:
• Use encounter and bed/location IDs instead of full PHI where possible.
• Avoid transmitting diagnosis details unless strictly required for protocol selection.
• Logs and dead letter queues:
• Must not contain full Emirates IDs or sensitive clinical details.
• Use tokenised identifiers where feasible.
• Are access-controlled and retained per facility policy and UAE PDPL requirements.

Integrity & Non-Repudiation

• All messages/events include:
• Unique message IDs and timestamps.
• Digital signatures or HMAC where required by internal security policy.
• Audit trails:
• For each cleaning task, record:
  • Source event (ADT message ID or OR event ID).
  • Infection-control data snapshot used for protocol selection.
  • User IDs for staff starting/completing tasks and inspectors.
• Audit logs are immutable and available for DOH/DHA inspections.

Availability & Resilience

• Event bus and API gateways are deployed in high-availability clusters.
• Circuit breakers and timeouts configured per integration:
• Typical timeout: 5–10 seconds for synchronous calls.
• Graceful degradation:
• If infection-control service is unavailable, Cleaning defaults to conservative protocols and flags tasks for review.
• If Bed Management is unavailable, Cleaning continues to operate and queues status updates for later delivery.