Case Management Integration Specifications

Integration Summary

INT-CSM-001: Scheduling / ADT → Case Management

Business Context

What flows

Inbound admission/transfer/discharge events to drive case creation and LOS tracking:

• Patient demographics (from ADT PID)
• Encounter/visit details (PV1/PV2): class, location, attending, admit/discharge timestamps
• Discharge disposition (PV1-36 + UAE-specific codes)
• Diagnosis codes (DG1) using ICD-10-AM

When

• A01 (admit/visit notification) – inpatient admission
• A02 (transfer) – ward/bed/service change
• A03 (discharge) – discharge/expiry
• Optionally A08 (update) for LOS-impacting changes

Why

• Auto-create case management records (case_reviews) for eligible encounters
• Maintain up-to-date census and LOS for UM and discharge planning
• Trigger readmission risk assessment and discharge planning within 24 hours
• Ensure DOH/DHA payer rules (e.g., observation vs inpatient) are applied based on class/location

How often

• Real-time, per ADT event.

Error impact

• Missed A01: case not created; UM reviews and discharge planning delayed; risk of non-compliance with payer UM timelines.
• Missed A03: LOS overstated; avoidable days miscounted; billing may misalign with actual stay.
• Missed A02: wrong case manager assignment and review schedule.
• For UAE PDPL: ADT failures must not cause uncontrolled retries that leak PHI to logs.

HL7 v2.5.1 Technical Detail

Message Types

• ADT^A01, ADT^A02, ADT^A03 (core)
• Optional: ADT^A08 for updates

Sample ADT^A01 (Inpatient Admission)

MSH|^~\&|ADT_SYS|DUBAIHOSP|HIS_CSM|DUBAIHOSP|20260207101530||ADT^A01|CSM20260207101530001|P|2.5.1|||AL|NE||UTF-8
EVN|A01|20260207101525|||USR123^ALI^OMAR^^^MR
PID|1||2026009876^^^DUBAIHOSP^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^DUBAIHOSP^^BED^WARD4B|E||^AL-NAHAYAN^FATIMA^^^DR^^^PRS||||MED||||ADM|SELF|||||||||ENC20260207000123^^^DUBAIHOSP^VN||||||||||||||||||||20260207094500
PV2|||R|||||||||||||||||||||||||||||||||||||||||20260210120000
DG1|1||I21.0^Acute transmural myocardial infarction^ICD10AM||20260207094500|A|W

Sample ADT^A03 (Discharge)

MSH|^~\&|ADT_SYS|DUBAIHOSP|HIS_CSM|DUBAIHOSP|20260211113000||ADT^A03|CSM20260211113000001|P|2.5.1|||AL|NE||UTF-8
EVN|A03|20260211112945|||USR123^ALI^OMAR^^^MR
PID|1||2026009876^^^DUBAIHOSP^MR~784-1985-1234567-1^^^UAE^EID||AL-MAKTOUM^AHMED^MOHAMMED||19850315|M
PV1|1|I|4B^412^01^DUBAIHOSP^^BED^WARD4B|E||^AL-NAHAYAN^FATIMA^^^DR^^^PRS||||MED||||ADM|SELF|||||||||ENC20260207000123^^^DUBAIHOSP^VN||||||||||||||||||||01^Home/self care^HL70112|||||20260211110000
DG1|1||I21.0^Acute transmural myocardial infarction^ICD10AM||20260207094500|F|F

Key Segment Mapping

Processing Rules

1. A01: - If encounter not yet in case_reviews, create:

   • case_status = 'OPEN'
   • priority based on diagnosis/service line
   • readmission_risk_score initially null
   • Create initial utilization_reviews record with review_type = 'ADMISSION'.

2. A02: - Update case_reviews.department_id, case_type if class changes. - Re-evaluate case_management_assignments for possible reassignment.

3. A03: - Set actual_discharge_date and closed_datetime. - Update case_status = 'CLOSED'. - Trigger readmission risk finalization and discharge plan completion check.

Error Handling

• Network / MLLP failure:
• Retry with exponential backoff: 15s, 30s, 1m, 2m, 5m (max 5 attempts).
• If still failing, write to ADT dead-letter queue dlq_csm_adt and alert integration team (email/on-call).
• Malformed HL7 / parsing error:
• Reject message, log control ID, send ACK^AE back to sender.
• No auto-retry; manual correction required.
• Missing encounter/patient in local DB:
• Place message in suspense table csm_adt_suspense with reason.
• Nightly job attempts re-processing; if still unresolved after 24h, escalate to HIM/registration.
• Duplicate A01 for same encounter:
• Idempotent check on visit number; update existing case instead of creating new.

Retry and Recovery

Retry Strategy:

Dead Letter Queue:

• ADT messages exhausting retries moved to dlq_csm_adt with full message payload and failure reason
• Admin dashboard for review, correction, and requeue
• Retention: 30 days active
• Alert: integration team notified on DLQ insertion; CM Director if > 5 messages or oldest > 8 hours

Idempotency:

• Deduplication key: (encounter_id, event_type, event_datetime)
• Duplicate A01 for same encounter updates existing case_reviews instead of creating new
• Duplicate A03 acknowledged without reprocessing if case already closed

Reconciliation:

• Daily: compare ADT admission census vs case_reviews open cases
• Flag admissions without corresponding case records (missed A01)
• Flag cases still open after ADT A03 discharge received (missed close)
• Weekly: LOS accuracy check — case management LOS vs ADT-derived LOS

INT-CSM-002: Case Management ↔ EHR & Patient Management

Business Context

What flows

• Inbound from EHR (for UM and discharge planning):
• Problem list (SNOMED CT), diagnoses (ICD-10-AM)
• Clinical notes (progress, nursing, operative)
• Vitals (LOINC-coded observations)
• Labs and imaging summaries
• Outbound from Case Management:
• UM review notes and decisions (utilization_reviews, um_criteria_evaluations)
• Discharge plans (discharge_plans, discharge_plan_tasks)
• Care coordination notes (care_coordination_notes)
• Readmission risk assessments (readmission_risk_assessments)

When

• Inbound: when a review is due, or when new clinical data is saved for an active case.
• Outbound: when a UM review is completed, discharge plan updated, or care coordination note saved.

Why

• Provide case managers with up-to-date clinical context for UM decisions.
• Make UM decisions and discharge plans visible in the main EHR for clinicians.
• Support NABIDH/Malaffi HIE completeness (UM notes may be included in summary documents).

How often

• Real-time, event-driven via internal APIs and FHIR.

Error impact

• Inbound failure: case manager may work with stale data, risking incorrect level-of-care decisions.
• Outbound failure: clinicians may not see UM decisions; billing may lack documentation; potential payer denials.

Technical Detail – Internal REST / FHIR (Representative)

This integration is primarily internal API/FHIR; no HL7 v2 required here.

Example: Inbound Clinical Snapshot (Internal REST)

GET /api/ehr/cases/{encounterId}/snapshot

Response (truncated):

{
  "encounterId": "ENC20260207000123",
  "patientId": "PAT2026009876",
  "problems": [
    {
      "code": "44054006",
      "system": "http://snomed.info/sct",
      "display": "Diabetes mellitus type 2"
    }
  ],
  "diagnoses": [
    {
      "code": "I21.0",
      "system": "http://hl7.org/fhir/sid/icd-10-am",
      "display": "Acute transmural myocardial infarction"
    }
  ],
  "latestVitals": [
    {
      "type": "BP",
      "systolic": 130,
      "diastolic": 80,
      "unit": "mm[Hg]",
      "takenAt": "2026-02-07T10:00:00+04:00"
    }
  ],
  "recentLabs": [
    {
      "code": "718-7",
      "system": "http://loinc.org",
      "display": "Hemoglobin",
      "value": 13.5,
      "unit": "g/dL",
      "resultedAt": "2026-02-07T09:30:00+04:00"
    }
  ]
}

FHIR R4: Outbound Discharge Plan as CarePlan

When a discharge plan is saved, a corresponding CarePlan is pushed to the EHR.

{
  "resourceType": "CarePlan",
  "id": "DP-20260207-0001",
  "status": "active",
  "intent": "plan",
  "category": [
    {
      "coding": [
        {
          "system": "http://terminology.hl7.org/CodeSystem/care-plan-category",
          "code": "discharge",
          "display": "Discharge planning"
        }
      ]
    }
  ],
  "subject": {
    "reference": "Patient/PAT2026009876",
    "display": "Ahmed Mohammed Al-Maktoum"
  },
  "encounter": {
    "reference": "Encounter/ENC20260207000123"
  },
  "period": {
    "start": "2026-02-07T10:30:00+04:00"
  },
  "created": "2026-02-07T10:30:00+04:00",
  "author": {
    "reference": "Practitioner/CM-001",
    "display": "Nurse Aisha Al-Nahyan"
  },
  "title": "Inpatient Discharge Plan",
  "description": "Discharge home with home health nursing and cardiology follow-up.",
  "goal": [
    {
      "reference": "Goal/DP-20260207-0001-goal1"
    }
  ],
  "activity": [
    {
      "detail": {
        "kind": "ServiceRequest",
        "status": "scheduled",
        "description": "Schedule cardiology follow-up within 7 days",
        "scheduledPeriod": {
          "start": "2026-02-14",
          "end": "2026-02-21"
        }
      }
    },
    {
      "detail": {
        "kind": "ServiceRequest",
        "status": "in-progress",
        "description": "Arrange home health nursing visits 3x/week for 2 weeks"
      }
    }
  ],
  "note": [
    {
      "text": "Patient and family educated on medication regimen and warning signs."
    }
  ]
}

Key Element Mapping

Search Parameters (EHR side)

• GET /CarePlan?encounter=ENC20260207000123&category=discharge
• GET /CarePlan?patient=PAT2026009876&status=active

Error Handling

• EHR snapshot API timeout:
• Retry 3 times with 5s, 10s, 20s backoff.
• If still failing, show banner on UM screen: “Clinical summary unavailable – please open EHR directly.”
• FHIR validation error on outbound CarePlan:
• EHR returns 400 with OperationOutcome.
• Log error, mark discharge_plans.sync_status = 'ERROR' with message.
• Case manager sees warning and can re-trigger sync after correction.
• EHR API 5xx:
• Queue outbound payload in csm_ehr_outbox.
• Retry for up to 2 hours; after that, move to dead-letter dlq_csm_ehr and alert integration team.

Retry and Recovery

Retry Strategy:

Dead Letter Queue:

• Outbound payloads (CarePlan, UM notes) exhausting retries moved to dlq_csm_ehr
• Admin dashboard for review; clinician UI shows banner: "Discharge plan not yet visible in EHR"
• Retention: 30 days active
• Alert: integration team notified on DLQ insertion; CM Supervisor if discharge plan not synced > 4 hours

Idempotency:

• Outbound deduplication key: (plan_id, resource_type, version_hash)
• EHR checks for existing CarePlan by id before creating duplicate
• Re-sync of same plan version returns success without reprocessing

Reconciliation:

• Daily: compare discharge_plans with portal_sync_status = 'SYNCED' vs EHR CarePlan records
• Flag discharge plans not visible in EHR for investigation
• Weekly: compare UM review notes in Case Management vs EHR clinical notes for completeness
• Monthly: outbound sync success rate and average sync latency

INT-CSM-003: Case Management ↔ Patient Access (Prior Authorization)

Business Context

What flows

• Inbound:
• Initial authorization details for admission: auth number, authorized days, payer, start/end dates.
• Outbound:
• Continued-stay authorization (CSA) requests with clinical justification and requested days.
• Updates to CSA status (approved/denied/appeal).

When

• On admission: Patient Access sends initial auth details.
• On each continued-stay review: Case Management sends CSA request.
• On payer response: Patient Access updates CSA record.

Why

• Ensure inpatient days are authorized per payer UM rules (from DOH/DHA contracts).
• Reduce UM-related denials (medical necessity, auth expired, level-of-care mismatch).

How often

• Real-time, per admission and per review cycle.

Error impact

• Missing initial auth: CSA may be requested late or with wrong baseline.
• Failed CSA submission: risk of unauthorized days and claim denials.

Technical Detail – Internal REST (JSON)

Inbound Initial Authorization (from Patient Access)

POST /api/csm/encounters/{encounterId}/initial-authorization

{
  "encounterId": "ENC20260207000123",
  "payerId": "PAYER-DAMAN",
  "planId": "PLAN-DAMAN-ENHANCED",
  "authId": "AUTH-20260207-0001",
  "authNumber": "DXB-PA-456789",
  "authorizedDays": 3,
  "startDate": "2026-02-07",
  "endDate": "2026-02-10",
  "status": "approved",
  "notes": "Initial inpatient authorization for ACS."
}

Mapping to continued_stay_authorizations:

Outbound Continued-Stay Request (to Patient Access)

POST /api/patient-access/authorizations/continued-stay

{
  "csaId": "CSA-20260209-0003",
  "encounterId": "ENC20260207000123",
  "payerId": "PAYER-DAMAN",
  "requestedDays": 2,
  "clinicalSummary": "Patient remains hemodynamically unstable, troponin trending up, requires IV nitroglycerin and telemetry.",
  "latestUmReviewId": "UR-20260209-0005",
  "levelOfCare": "INPATIENT",
  "nextReviewDate": "2026-02-11",
  "attachments": [
    {
      "type": "progress_note",
      "id": "NOTE-20260209-0012"
    }
  ]
}

Patient Access will map this into payer-specific eClaimLink / DOH eClaims transactions.

Error Handling

• Initial auth POST fails (4xx):
• Reject and return error to Patient Access; no record created.
• Patient Access UI must show error and allow correction.
• CSA request POST fails (5xx):
• Queue in csm_csa_outbox, retry 5 times (1m, 2m, 5m, 10m, 20m).
• If still failing, mark CSA as status='PENDING_SUBMISSION' and alert UM team.
• Mismatch encounter/case:
• Return 409 Conflict with message; log for reconciliation.

Retry and Recovery

Retry Strategy:

Dead Letter Queue:

• CSA requests exhausting retries queued in csm_csa_outbox with full payload
• Mark CSA as status = 'PENDING_SUBMISSION'; UM team alerted for manual phone-based submission
• Retention: 30 days active
• Alert: UM Nurse notified immediately (auth deadline risk); CM Director if > 3 pending > 4 hours

Idempotency:

• Inbound auth deduplication key: (encounter_id, auth_id)
• Duplicate initial auth POSTs update existing continued_stay_authorizations instead of creating duplicates
• Outbound CSA deduplication key: (csa_id, request_date)

Reconciliation:

• Daily: compare continued_stay_authorizations with status = 'PENDING' vs Patient Access auth records
• Flag CSA requests submitted but without Patient Access acknowledgement > 4 hours
• Weekly: reconcile approved days in Case Management vs Patient Access authorized days
• Monthly: auth request success rate and average turnaround time

INT-CSM-004: Case Management → Billing & Claims

Business Context

What flows

• Authorization and UM data needed for compliant billing:

• Final authorization numbers and approved days per stay.

• UM review outcomes (criteria met/not met, level-of-care decisions).
• Avoidable days and non-covered days (if determined).
• Discharge disposition for billing edits.

When

• When an authorization is obtained or updated.
• When a UM review is completed and impacts coverage.
• At discharge, to finalize UM-related billing flags.

Why

• Reduce UM-related claim denials (medical necessity, auth expired, level-of-care).
• Provide audit trail for payer audits.

How often

• Near real-time; also batch reconciliation prior to claim submission.

Error impact

• Missing auth number: claim may be denied or pended.
• Missing UM flags: inability to segment avoidable days or adjust level-of-care billing.

Technical Detail – Internal REST / DB

Example Outbound Payload

POST /api/billing/encounters/{encounterId}/um-summary

{
  "encounterId": "ENC20260207000123",
  "payerId": "PAYER-DAMAN",
  "primaryAuthNumber": "DXB-PA-456789",
  "totalApprovedDays": 5,
  "umReviews": [
    {
      "reviewId": "UR-20260207-0001",
      "reviewType": "ADMISSION",
      "criteriaMet": true,
      "levelOfCare": "INPATIENT",
      "reviewDate": "2026-02-07T11:00:00+04:00"
    },
    {
      "reviewId": "UR-20260209-0005",
      "reviewType": "CONTINUED_STAY",
      "criteriaMet": true,
      "levelOfCare": "INPATIENT",
      "reviewDate": "2026-02-09T10:00:00+04:00"
    }
  ],
  "avoidableDays": 0,
  "nonCoveredDays": 0,
  "dischargeDisposition": "01",
  "lastUpdated": "2026-02-11T11:15:00+04:00"
}

Mapping:

Error Handling

• Billing API unavailable:
• Queue in csm_billing_outbox; retry for 24h with exponential backoff.
• If still failing, mark encounter as UM_SYNC_ERROR and alert revenue cycle team.
• Validation error (e.g., missing payer):
• Return 400; log and mark case with billing_sync_status='ERROR'.
• Case Management Director dashboard shows unsynced cases.

Retry and Recovery

Retry Strategy:

Dead Letter Queue:

• UM summaries exhausting retries moved to dlq_csm_billing
• Mark encounter as UM_SYNC_ERROR; revenue cycle team alerted
• Critical priority: unsynced UM data risks claim denials
• Retention: 60 days active (to cover claim submission windows)
• Alert: Revenue Cycle Manager notified if any encounter unsyncable > 24 hours

Idempotency:

• Deduplication key: (encounter_id, last_updated_timestamp)
• Billing checks for existing UM summary by encounter and compares timestamps
• Newer summaries overwrite older ones; same-timestamp submissions acknowledged without reprocessing

Reconciliation:

• Daily: compare cases with UM reviews completed vs Billing UM summary receipts
• Flag encounters with completed UM reviews but no corresponding Billing acknowledgement
• Pre-claim-submission batch: verify all encounters pending claim generation have current UM data
• Monthly: UM-related denial rate vs UM sync success rate correlation

INT-CSM-005: Policy & Contract Management → Case Management

Business Context

What flows

• Payer-specific UM rules:

• Review schedules (e.g., first review at day 2, then every 3 days).

• Required documentation elements.
• Level-of-care definitions and criteria references.
• Precertification rules for certain DRGs or procedures.

When

• On case assignment (to load applicable rules).
• On demand when payer rules are updated or UM team requests refresh.

Why

• Ensure UM reviews follow payer contracts (DOH/DHA, MOH).
• Automate review scheduling and reminders.

How often

• On-demand, with caching; rules change infrequently.

Error impact

• Missing or outdated rules: reviews may be done too early/late; risk of non-compliance and denials.

Technical Detail – Internal REST

GET /api/policy/um-rules?payerId=PAYER-DAMAN&planId=PLAN-DAMAN-ENHANCED

{
  "payerId": "PAYER-DAMAN",
  "planId": "PLAN-DAMAN-ENHANCED",
  "reviewSchedules": [
    {
      "caseType": "INPATIENT",
      "initialReviewDay": 2,
      "subsequentReviewIntervalDays": 3
    }
  ],
  "authRules": [
    {
      "drgGroup": "ACS",
      "requiresPrecert": true,
      "maxInitialDays": 3
    }
  ],
  "documentationRequirements": [
    "Latest progress note within 24h",
    "Vital signs trend for last 24h",
    "Key lab results (troponin, ECG summary)"
  ],
  "lastUpdated": "2026-01-15T09:00:00+04:00"
}

Mapping:

• Used to populate master data “Payer Review Schedules”.
• Drives utilization_reviews.next_review_date calculation.

Error Handling

• Policy service unavailable:
• Use cached rules if available (must be < 12 months old per governance).
• If no cache, flag case as rules_missing and require manual scheduling.
• Invalid response:
• Log and fall back to default facility rules.

Retry and Recovery

Retry Strategy:

Circuit Breaker (Synchronous API):

• Threshold: 3 consecutive failures or > 50% error rate in 60-second window
• Open state: use cached payer rules if available (cache must be < 12 months old); flag case as "UM rules not verified"
• Half-open: after 2 minutes, attempt single test request
• Closed: resume normal rule lookup
• Alert: CM Director notified when circuit opens; IT notified for investigation

Idempotency:

• Rule lookups are read-only and inherently idempotent
• Cached rules tagged with lastUpdated timestamp to detect staleness

Reconciliation:

• Daily: verify cached payer rules version matches Policy & Contract Management current version
• Flag stale caches (> 30 days without refresh) for manual update
• Weekly: compare review schedules used in Case Management vs current payer rules
• Monthly: circuit breaker activation frequency and cache hit rate

INT-CSM-006: Case Management → Patient Portal (FHIR R4)

Business Context

What flows

• Patient-facing discharge and care coordination information:

• Discharge plan summary.

• Follow-up appointments.
• Home care instructions and contact details.
• Risk flags and recommended actions (if appropriate).

When

• When discharge plan is finalized and marked as “shared with patient”.

Why

• Support safe transitions of care and reduce readmissions.
• Meet UAE PDPL expectations for patient access to their health information.

How often

• On-demand / near real-time, per discharge plan finalization.

Error impact

• Failure means patient portal may not show updated discharge plan; risk of confusion and non-adherence.

FHIR R4 Technical Detail

Resources

• CarePlan – discharge plan.
• Optionally Appointment – follow-up visits (usually created by Scheduling and already visible to portal).

Sample CarePlan JSON (to Patient Portal)

{
  "resourceType": "CarePlan",
  "id": "DP-20260207-0001",
  "status": "active",
  "intent": "plan",
  "category": [
    {
      "coding": [
        {
          "system": "http://terminology.hl7.org/CodeSystem/care-plan-category",
          "code": "discharge",
          "display": "Discharge planning"
        }
      ]
    }
  ],
  "subject": {
    "reference": "Patient/PAT2026009876",
    "display": "Ahmed Mohammed Al-Maktoum"
  },
  "period": {
    "start": "2026-02-07",
    "end": "2026-03-07"
  },
  "title": "Your Discharge Plan from Dubai General Hospital",
  "description": "You are discharged home with support from home health nurses and a cardiology follow-up.",
  "author": {
    "reference": "Practitioner/CM-001",
    "display": "Nurse Aisha Al-Nahyan"
  },
  "activity": [
    {
      "detail": {
        "status": "scheduled",
        "description": "Cardiology clinic appointment within 7 days after discharge.",
        "scheduledPeriod": {
          "start": "2026-02-14",
          "end": "2026-02-21"
        }
      }
    },
    {
      "detail": {
        "status": "in-progress",
        "description": "Home health nurse will visit you at home three times per week for two weeks."
      }
    },
    {
      "detail": {
        "status": "not-started",
        "description": "Daily walking for at least 20 minutes as tolerated."
      }
    }
  ],
  "note": [
    {
      "text": "If you experience chest pain, shortness of breath, or dizziness, call 998 or go to the nearest emergency department."
    }
  ]
}

Key Element Mapping

Search Parameters (Portal)

• GET /CarePlan?patient={patientId}&category=discharge
• GET /CarePlan?patient={patientId}&_lastUpdated=ge2026-02-01

Error Handling

• Portal FHIR endpoint unavailable (5xx):
• Queue CarePlan in csm_portal_outbox.
• Retry for 24h; if still failing, show banner in clinician UI: “Discharge plan not yet visible in portal.”
• Unauthorized (401/403):
• Check OAuth client credentials; disable further attempts until configuration fixed.
• Validation error:
• Portal returns OperationOutcome; log and mark discharge_plans.portal_sync_status='ERROR'.

Retry and Recovery

Retry Strategy:

Dead Letter Queue:

• CarePlan payloads exhausting retries queued in csm_portal_outbox (DLQ partition)
• Clinician UI shows banner: "Discharge plan not yet visible in portal"
• Retention: 30 days active
• Alert: integration team notified on DLQ insertion; CM Supervisor if discharge plan not synced > 4 hours pre-discharge

Idempotency:

• Deduplication key: (plan_id, version_hash)
• Portal checks for existing CarePlan by id; updates in place if exists
• Re-push of same version acknowledged without creating duplicate

Reconciliation:

• Daily: compare discharge_plans with portal_sync_status = 'SYNCED' vs Portal CarePlan records
• Flag plans marked as synced but not visible in Portal (potential sync failure)
• Weekly: compare portal-visible discharge plans vs total finalized plans
• Monthly: portal sync success rate and patient engagement metrics (plan views)

NABIDH / Malaffi Integration Considerations

Case Management itself does not send messages directly to NABIDH (Dubai) or Malaffi (Abu Dhabi), but its data may be included in:

• Discharge summaries and care plans shared by the EHR.
• Encounter-level documents that reference UM decisions and discharge planning.

Requirements

• Ensure that UM notes and discharge plans stored in Case Management are:

• Properly linked to encounters and patients (via shared IDs).

• Available to the EHR when constructing CDA/FHIR documents for NABIDH/Malaffi.

• Tagged with appropriate confidentiality flags per UAE PDPL (e.g., sensitive social work notes may be excluded or summarized).

• Acknowledgement handling (ACKs) for HIE messages is managed by the EHR integration engine; Case Management only needs:

• Status callbacks from EHR if UM-related sections are rejected by HIE profiles.

• Logging of which cases have been included in HIE submissions for audit.

Authentication & Security

All integrations must comply with:

• UAE PDPL (Federal Decree-Law No. 45/2021) for personal data protection.
• DHA NABIDH and DOH Malaffi security guidelines where applicable.
• ADHICS and TDRA/NESA cybersecurity standards for Abu Dhabi and federal environments.

Mutual TLS (mTLS)

• Used for all internal HL7 MLLP and REST APIs between HIS components.

• Each system (Case Management, EHR, Scheduling, Billing, Patient Access, Portal) has:

• A client certificate issued by the hospital’s internal CA.

• Server certificates validated against trusted CA chain.

• Connections without valid client certs are rejected.

OAuth 2.0

• Used for REST/FHIR APIs:

• Case Management acts as a confidential client when calling EHR, Patient Access, Policy, and Patient Portal.

• Client Credentials flow for system-to-system calls.

• Access tokens scoped (e.g., scope: csm.read ehr.read ehr.write portal.write).

• Token lifetime: typically 15–60 minutes; refresh via token endpoint.

API Key Management

• For some internal, low-risk service calls (e.g., read-only policy lookups), API keys may be used in addition to mTLS.
• Keys stored in secure configuration vault; rotated at least every 90 days.

Message Encryption & Data Protection

• All traffic over TLS 1.2+.
• HL7 over MLLP is tunneled through TLS where possible.
• Logs must not contain full Emirates ID or clinical free text; use tokenization or partial masking (e.g., 784-1985-XXXXX67-1).
• At-rest encryption for databases holding case_reviews, utilization_reviews, discharge_plans, etc.

Access Control & Auditing

• Access to integration endpoints limited by network segmentation (internal VLAN/VPN).
• Role-based access control (RBAC) enforced via users, roles, permissions from ehr-patient-mgmt.

• All integration calls that create/update case management data are audited:

• Who (client system + user, if propagated).

• What (resource, fields changed).
• When (timestamp).

• From where (IP, system ID).

• Audit logs retained per UAE regulatory and facility policy.

Error Monitoring & Alerting

• Centralized monitoring (e.g., SIEM) collects:

• Integration errors (HTTP 4xx/5xx, HL7 ACK AE/AR).

• Dead-letter queue entries.

• Security events (failed auth, certificate errors).

• Alert thresholds:

• 5% failure rate for any integration over 15 minutes.

• Any dead-letter queue growth beyond 10 messages.
• Any repeated auth failures (possible misconfiguration or attack).

Manual recovery procedures are documented per integration above and must be tested periodically as part of business continuity and disaster recovery exercises.