Radiology Information System Integration Specifications

Integration Summary

INT-RIS-001: CPOE (Computerized Physician Order Entry)

Business Context

What flows

• Inbound to RIS
• New/updated imaging orders: exam CPT, modality, body part, laterality, priority, clinical indication (ICD-10-AM), ordering provider, encounter, facility/department.
• Order updates: cancel, reschedule, change priority.
• Outbound from RIS
• Radiology report content (findings, impression, critical flag).
• Report status (preliminary, final, corrected).
• Exam status updates (scheduled, arrived, in progress, completed, cancelled).

When

• Inbound order: when ordering physician signs imaging order in CPOE.
• Outbound report: when radiologist signs preliminary or final report.
• Status updates: when radiology_orders.order_status or radiology_exams.exam_status changes.

Why

• Ensure radiology has complete, structured orders.
• Deliver results back into the ordering clinician’s workflow and patient chart.
• Maintain consistent order and exam status across HIS.

How often

• Real-time, per event (< 2 seconds target).

Error impact

• Inbound failure: exam not visible in RIS worklists; risk of missed imaging.
• Outbound failure: report not visible in CPOE; clinical decisions delayed.
• Status sync failure: scheduling confusion, duplicate exams.

HL7 v2.5.1 Technical Detail

Message Types

• Inbound orders: ORM^O01 (New/Update/Cancel imaging order).
• Outbound results: ORU^R01 (Radiology report as observation/result).
• Status updates: ORM^O01 with updated ORC-1 and OBR-25.

Sample Inbound Order (ORM^O01 – CPOE → RIS)

MSH|^~\&|HIS_CPOE|DUBAIHOSP|RIS|DUBAIHOSP|20260207103015+0400||ORM^O01|RISORD20260207103015001|P|2.5.1|||AL|NE||UTF-8
PID|1||MRN100245^^^DUBAIHOSP^MR~784-1985-1234567-1^^^UAE^EID||AL-MAKTOUM^AHMED^ALI||19850315|M|||PO BOX 12345^^DUBAI^^00000^AE||+971501234567|||M||||||||||AE
PV1|1|O|RAD^XRAY^01^DUBAIHOSP^^RADIOLOGY||||AL-NAHYAN^FATIMA^OMAR^^^DR|||RAD||||||||ENC2026020710001|||||||||||||||||||||||||20260207102000+0400
ORC|NW|ORD-20260207-0001||ACC-20260207-0001|SC||^^^20260207113000+0400^^ROUTINE|||AL-NAHYAN^FATIMA^OMAR^^^DR^MD|||||DUBAIHOSP^Dubai General Hospital^99DGH
OBR|1|ORD-20260207-0001|ACC-20260207-0001|71046^CHEST X-RAY 2 VIEWS^CPT|R||20260207113000+0400|||||||AL-NAHYAN^FATIMA^OMAR^^^DR^MD||RAD^Radiology|||||||R^^HL7P||RAD^Radiology|CR^Computed Radiography^DCM|^^CHEST^SNM|L^Left^HL7L|784-1985-1234567-1^^^UAE^EID|20260207103015+0400
DG1|1||J18.9^Pneumonia, unspecified organism^ICD10AM||20260207103000+0400|||A
NTE|1|L|Clinical indication: Persistent cough and fever. Rule out pneumonia.

Key Segment Notes & Table Mapping

• PID-3 → radiology_orders.patient_id (via MRN/EID resolution).
• PV1-19 (Visit Number) → radiology_orders.encounter_id (FK to encounters).
• ORC-1:
• NW = new order → insert into radiology_orders.
• XO = change order → update.
• CA = cancel order → set order_status = 'cancelled'.
• ORC-2 → radiology_orders.order_id.
• ORC-5 → radiology_orders.order_status (map HL7 status to internal enum).
• ORC-7 → radiology_orders.scheduled_datetime.
• OBR-4 (CPT) → radiology_orders.exam_code_cpt, exam_description.
• OBR-18 (Placer field 1 – modality) → radiology_orders.modality_type.
• OBR-15 (Provider) → radiology_orders.ordering_provider_id.
• DG1-3 → radiology_orders.icd10_code.
• NTE-3 → radiology_orders.clinical_indication.

Sample Outbound Result (ORU^R01 – RIS → CPOE)

MSH|^~\&|RIS|DUBAIHOSP|HIS_CPOE|DUBAIHOSP|20260207134530+0400||ORU^R01|RISRES20260207134530001|P|2.5.1|||AL|NE||UTF-8
PID|1||MRN100245^^^DUBAIHOSP^MR~784-1985-1234567-1^^^UAE^EID||AL-MAKTOUM^AHMED^ALI||19850315|M
PV1|1|O|RAD^XRAY^01^DUBAIHOSP^^RADIOLOGY||||AL-NAHYAN^FATIMA^OMAR^^^DR|||RAD||||||||ENC2026020710001
ORC|CM|ORD-20260207-0001||ACC-20260207-0001|CM||||20260207134500+0400|||AL-RAHMAN^KHALID^HASSAN^^^DR^MD
OBR|1|ORD-20260207-0001|ACC-20260207-0001|71046^CHEST X-RAY 2 VIEWS^CPT||20260207113000+0400|20260207120000+0400|||||||AL-RAHMAN^KHALID^HASSAN^^^DR^MD||RAD^Radiology|||||||F||RAD^Radiology|CR^Computed Radiography^DCM|^^CHEST^SNM|L^Left^HL7L|||20260207134000+0400
OBX|1|TX|RPT^Radiology Report^LN||FINDINGS: Heart size normal. No focal consolidation, pleural effusion, or pneumothorax identified.||||||F|||20260207134000+0400
OBX|2|TX|IMP^Impression^LN||IMPRESSION: No radiographic evidence of pneumonia.||||||F|||20260207134000+0400
OBX|3|CE|CRIT^Criticality^LN||N^Non-critical^HL7CRIT||||||F
NTE|1|L|Recommendation: Correlate clinically. Repeat chest X-ray if symptoms worsen.

Mapping to RIS Tables

• ORC-2 → radiology_reports.order_id.
• OBR-3 → radiology_reports.exam_id (via accession).
• OBR-25 (F) → radiology_reports.report_status = 'Final'.
• OBX[1].5 → radiology_reports.findings_text.
• OBX[2].5 → radiology_reports.impression_text.
• OBX[3].5 (N) → radiology_reports.is_critical = false.
• OBR-22 (Results Rpt/Status Chng Date/Time) → radiology_reports.final_sign_datetime.

FHIR R4 Technical Detail

Used primarily for internal APIs between RIS and CPOE/EHR.

Resource Types

• Inbound order: ServiceRequest.
• Outbound result: DiagnosticReport (+ optional Observation for structured findings).

Sample ServiceRequest (CPOE → RIS)

{
  "resourceType": "ServiceRequest",
  "id": "ORD-20260207-0001",
  "status": "active",
  "intent": "order",
  "priority": "routine",
  "code": {
    "coding": [
      {
        "system": "http://www.ama-assn.org/go/cpt",
        "code": "71046",
        "display": "Radiologic examination, chest; 2 views"
      }
    ],
    "text": "Chest X-ray 2 views"
  },
  "subject": {
    "reference": "Patient/MRN100245",
    "display": "Ahmed Ali Al-Maktoum"
  },
  "encounter": {
    "reference": "Encounter/ENC2026020710001"
  },
  "authoredOn": "2026-02-07T10:30:15+04:00",
  "requester": {
    "reference": "Practitioner/AL-NAHYAN-FATIMA",
    "display": "Dr. Fatima Omar Al-Nahyan"
  },
  "reasonCode": [
    {
      "coding": [
        {
          "system": "http://hl7.org/fhir/sid/icd-10-am",
          "code": "J18.9",
          "display": "Pneumonia, unspecified organism"
        }
      ],
      "text": "Persistent cough and fever. Rule out pneumonia."
    }
  ],
  "bodySite": [
    {
      "coding": [
        {
          "system": "http://snomed.info/sct",
          "code": "51185008",
          "display": "Structure of thorax"
        }
      ],
      "text": "Chest"
    }
  ],
  "note": [
    {
      "text": "Clinical indication: Persistent cough and fever. Rule out pneumonia."
    }
  ],
  "occurrenceDateTime": "2026-02-07T11:30:00+04:00",
  "performer": [
    {
      "reference": "Organization/DUBAIHOSP-RAD",
      "display": "Dubai General Hospital - Radiology"
    }
  ]
}

Key Element Mapping

• ServiceRequest.id ↔ radiology_orders.order_id.
• code.coding[0].code ↔ exam_code_cpt.
• priority ↔ radiology_orders.priority.
• occurrenceDateTime ↔ scheduled_datetime.
• reasonCode[0].coding[0].code ↔ icd10_code.
• bodySite ↔ body_part.

Sample DiagnosticReport (RIS → CPOE/EHR)

{
  "resourceType": "DiagnosticReport",
  "id": "RPT-20260207-0001",
  "status": "final",
  "category": [
    {
      "coding": [
        {
          "system": "http://terminology.hl7.org/CodeSystem/v2-0074",
          "code": "RAD",
          "display": "Radiology"
        }
      ]
    }
  ],
  "code": {
    "coding": [
      {
        "system": "http://www.ama-assn.org/go/cpt",
        "code": "71046",
        "display": "Radiologic examination, chest; 2 views"
      }
    ],
    "text": "Chest X-ray 2 views"
  },
  "subject": {
    "reference": "Patient/MRN100245",
    "display": "Ahmed Ali Al-Maktoum"
  },
  "encounter": {
    "reference": "Encounter/ENC2026020710001"
  },
  "effectiveDateTime": "2026-02-07T11:30:00+04:00",
  "issued": "2026-02-07T13:40:00+04:00",
  "performer": [
    {
      "reference": "Practitioner/AL-RAHMAN-KHALID",
      "display": "Dr. Khalid Hassan Al-Rahman"
    }
  ],
  "resultsInterpreter": [
    {
      "reference": "Practitioner/AL-RAHMAN-KHALID"
    }
  ],
  "conclusion": "No radiographic evidence of pneumonia.",
  "conclusionCode": [
    {
      "coding": [
        {
          "system": "http://snomed.info/sct",
          "code": "366979004",
          "display": "Normal chest X-ray"
        }
      ]
    }
  ],
  "presentedForm": [
    {
      "contentType": "text/plain",
      "language": "en",
      "data": "RklORElOR1M6IEhlYXJ0IHNpemUgbm9ybWFsLiBObyBmb2NhbCBjb25zb2xpZGF0aW9uLgpJT1NJT046IE5vIHJhZGlvZ3JhcGhpYyBldmlkZW5jZSBvZiBwbmV1bW9uaWEu"
    }
  ],
  "basedOn": [
    {
      "reference": "ServiceRequest/ORD-20260207-0001"
    }
  ]
}

Search Parameters (internal use)

• GET /DiagnosticReport?based-on=ServiceRequest/ORD-20260207-0001
• GET /DiagnosticReport?subject=Patient/MRN100245&category=RAD
• GET /ServiceRequest?subject=Patient/MRN100245&status=active

Error Handling (INT-RIS-001)

• Transport/network failure
• Retry with exponential backoff: 15s, 30s, 1m, 2m, 5m (max 5 attempts).
• On failure: write to integration_message_log with status='failed', push to dead-letter queue.
• HL7 ACK handling
• Expect ACK^O01 / ACK^R01.
• MSA-1 = AA: mark message delivered.
• MSA-1 = AE or AR: no auto-retry; flag for interface analyst; show alert in RIS admin console.
• FHIR errors
• 4xx: parse OperationOutcome, log validation errors; no auto-retry.
• 5xx: retry with same backoff as above.
• User-facing
• Worklist banner when CPOE link is down.
• Ability to manually requeue failed messages from an admin screen.

Retry and Recovery

Retry Strategy:

Dead Letter Queue:

• Messages exhausting all retries written to integration_dlq table with full payload, error details, and original timestamps
• Admin dashboard (accessible from RIS admin console) for manual review, correction, and requeue
• Retention: 30 days active, then archive per UAE PDPL and facility retention policies
• Alert: integration team notified on DLQ insertion via email and in-app banner

Idempotency:

• Deduplication key: [order_id]_[message_type]_[message_datetime]
• CPOE checks MSH-10 (Message Control ID) before processing inbound results; duplicates return AA ACK without reprocessing
• RIS checks ServiceRequest.id for duplicate inbound orders

Reconciliation:

• Daily batch comparison: RIS radiology_orders vs CPOE acknowledged orders
• Unmatched records flagged for radiology admin / interface analyst review
• Monthly trend reporting on message success rates and DLQ volumes

INT-RIS-002: PACS

Business Context

What flows

• Outbound from RIS
• DICOM Modality Worklist (MWL) entries per scheduled exam.
• Study metadata (accession, patient, procedure) for PACS registration.
• Inbound to RIS
• Confirmation that images are stored (via MPPS or PACS callbacks).
• WADO-RS URLs for viewer launch (stored in RIS for deep-linking).
• Dose reports (RDSR) if PACS aggregates them.

When

• MWL: when exam is scheduled or protocolled (radiology_exams.exam_status becomes scheduled).
• Image storage: when modality sends C-STORE to PACS.
• Dose: when RDSR is received by PACS and forwarded/queried.

Why

• Ensure modalities and PACS have consistent patient/exam data.
• Enable radiologists to open images from RIS worklists.
• Support radiation dose tracking and quality metrics.

How often

• Real-time, per exam.

Error impact

• MWL failure: technologists must manually type patient/exam data; risk of wrong-patient imaging.
• PACS linkage failure: images not visible from RIS; delays reporting.
• Dose failure: incomplete dose history; non-compliance risk with UAE MOH radiation safety guidance.

DICOM Technical Detail (High Level)

• MWL SCP: RIS acts as DICOM Modality Worklist Server.
• Key attributes:
  • (0010,0010) Patient Name
  • (0010,0020) Patient ID
  • (0010,0030) Patient Birth Date
  • (0010,0040) Patient Sex
  • (0032,1032) Requesting Physician
  • (0032,1060) Requested Procedure Description
  • (0040,0100) Scheduled Procedure Step Sequence:
  • (0040,0001) Scheduled Station AE Title (modality resource)
  • (0040,0002) Scheduled Procedure Step Start Date
  • (0040,0003) Scheduled Procedure Step Start Time
  • (0040,0006) Scheduled Performing Physician’s Name
  • (0040,0007) Scheduled Procedure Step Description
  • (0040,0008) Scheduled Protocol Code Sequence
  • (0008,0060) Modality
  • (0040,0010) Scheduled Station Name
  • (0040,0011) Scheduled Procedure Step Location
• MPPS: PACS or modality sends MPPS to RIS or PACS; RIS consumes status via PACS integration.
• Tracks IN PROGRESS, COMPLETED, DISCONTINUED.
• Maps to radiology_exams.exam_status.
• C-STORE: Modality → PACS; RIS does not terminate C-STORE but stores:
• (0020,000D) Study Instance UID → radiology_exams.study_instance_uid.
• (0008,0050) Accession Number → radiology_exams.accession_number.

RIS Table Mapping

• radiology_exams:
• exam_id ↔ internal key.
• accession_number ↔ DICOM (0008,0050).
• study_instance_uid ↔ (0020,000D).
• modality_resource_id ↔ MWL Scheduled Station AE Title.
• exam_start_time, exam_end_time from MPPS.

Error Handling (INT-RIS-002)

• MWL query failure
• Monitor MWL SCP; if unavailable, alert technologist and RIS admin.
• Log failed C-FIND requests with modality AE and IP.
• MPPS mismatch
• If MPPS references unknown accession, log and alert interface team.
• Dose RDSR missing
• If exam modality type requires dose and no RDSR within 30 minutes of completion:
  • Flag exam in radiation_dose_records as missing_source.
  • Show alert on Radiation Dose Dashboard.

Retries are typically handled at DICOM layer (modality/PACS); RIS focuses on monitoring and reconciliation.

Retry and Recovery

Retry Strategy:

Dead Letter Queue:

• DICOM failures are managed by PACS/modality internal queues, not a traditional DLQ
• RIS monitors for missing data (MPPS, RDSR) via scheduled reconciliation jobs
• Unreconciled exams appear on RIS admin dashboard for manual resolution

Idempotency:

• DICOM Study Instance UID and Accession Number ensure uniqueness
• Duplicate MPPS updates (same Performed Procedure Step ID) are idempotent — RIS stores latest status
• Duplicate MWL entries for same accession are merged/overwritten

Reconciliation:

• Hourly: RIS checks radiology_exams with status scheduled and past scheduled time but no MPPS → flag for technologist review
• Daily: RIS compares exams marked images_acquired against PACS study list to detect orphaned studies or missing links
• RDSR reconciliation: flag exams with dose-tracked modalities missing radiation_dose_records after 24 hours

INT-RIS-003: Imaging Modalities (CT, MRI, US, XR, etc.)

Business Context

What flows

• Outbound from RIS
• Modality Worklist items per exam (same MWL as INT-RIS-002, but from modality perspective).
• Inbound to RIS
• MPPS status updates (start, complete, discontinue).
• Images (indirectly via PACS, but RIS may receive notifications).
• Dose data (RDSR) if modalities send directly.

When

• MWL: when exam is scheduled and modality resource assigned.
• MPPS: when technologist starts and completes exam on modality console.
• RDSR: immediately after acquisition.

Why

• Drive technologist workflow.
• Automatically update exam status and dose without manual entry.

Error impact

• MWL down: manual patient entry; risk of misidentification.
• MPPS down: exam status not updated; billing and reporting delays.
• Dose missing: incomplete ALARA compliance evidence.

DICOM Technical Detail

Same attribute set as INT-RIS-002; here focus is on RIS as MWL SCP and RIS as MPPS SCP (if implemented).

• RIS must support:
• C-FIND (MWL) from modalities.
• C-STORE or N-CREATE/N-SET (MPPS) depending on architecture.
• modality_resources table holds:
• ae_title, ip_address, modality_type, facility_id, department_id.

Mapping

• MPPS Performed Procedure Step Status:
• IN PROGRESS → radiology_exams.exam_status = 'in_progress', set exam_start_time.
• COMPLETED → exam_status = 'completed', set exam_end_time.
• DISCONTINUED → exam_status = 'cancelled'.

Error Handling (INT-RIS-003)

• MPPS not received
• If no MPPS within configurable time (e.g., 2 hours after scheduled time):
  • Flag exam as status='pending_confirmation'.
  • Show on technologist dashboard for manual reconciliation.
• RDSR parsing error
• Store raw DICOM file reference.
• Log parsing error; allow Radiation Safety Officer to reprocess after fix.

Retry and Recovery

Retry Strategy:

Dead Letter Queue:

• Failed RDSR parsing: raw DICOM objects stored in dicom_error_queue directory for RSO/IT reprocessing
• MPPS timeouts: exams flagged in radiology_exams with status = 'pending_confirmation' serve as a logical DLQ visible on technologist dashboard

Idempotency:

• MPPS updates keyed by Performed Procedure Step Instance UID — duplicate status updates are idempotent
• RDSR records keyed by Study Instance UID + irradiation event UID — duplicates overwrite existing dose records

Reconciliation:

• Scheduled job (every 2 hours): detect exams past scheduled time without MPPS confirmation
• Daily: cross-reference modality logs (where available) with RIS exam records to identify unreported exams
• Weekly: RSO reviews unresolved RDSR parsing errors

INT-RIS-004: NABIDH (Dubai HIE)

Business Context

What flows

• Outbound only:
• Imaging order metadata.
• Radiology reports (final only).
• Radiation dose summaries for applicable modalities.

When

• On final report signing (radiology_reports.report_status = 'Final').
• Dose data included if available at that time.

Why

• Comply with DHA NABIDH requirements for sharing diagnostic imaging data.
• Enable cross-facility access to imaging reports in Dubai.

How often

• Real-time per final report.

Error impact

• Non-submission or late submission may breach DHA/NABIDH participation rules.
• Clinicians at other facilities may lack access to recent imaging.

HL7 v2.5.1 Technical Detail (NABIDH Profile)

Message Type: ORU^R01 (Radiology Result) with NABIDH-specific constraints.

Key NABIDH requirements (high level):

• Emirates ID in PID-3 with EID assigning authority.
• Facility licensed code in MSH-4 and PV1-3.
• Use ICD-10-AM for diagnoses, LOINC/SNOMED where applicable.
• OBX segments for:
• Narrative report.
• Structured conclusion.
• Dose summary (for CT/fluoroscopy).

Sample NABIDH ORU^R01 (RIS → NABIDH)

MSH|^~\&|RIS|DUBAIHOSP^99DGH|NABIDH|DHA|20260207140000+0400||ORU^R01|NABIDH-RIS-20260207140000001|P|2.5.1|||AL|NE||UTF-8
PID|1||MRN100245^^^DUBAIHOSP^MR~784-1985-1234567-1^^^UAE^EID||AL-MAKTOUM^AHMED^ALI||19850315|M|||PO BOX 12345^^DUBAI^^00000^AE||+971501234567
PV1|1|O|RAD^XRAY^01^DUBAIHOSP^99DGH^^RADIOLOGY||||AL-NAHYAN^FATIMA^OMAR^^^DR|||RAD||||||||ENC2026020710001
ORC|RE|ORD-20260207-0001||ACC-20260207-0001|CM||||20260207134500+0400|||AL-RAHMAN^KHALID^HASSAN^^^DR^MD
OBR|1|ORD-20260207-0001|ACC-20260207-0001|71046^CHEST X-RAY 2 VIEWS^CPT||20260207113000+0400|20260207120000+0400|||||||AL-RAHMAN^KHALID^HASSAN^^^DR^MD||RAD^Radiology|||||||F|||RAD^Radiology|CR^Computed Radiography^DCM|^^CHEST^SNM|L^Left^HL7L|||20260207134000+0400
OBX|1|TX|RPT^Radiology Report^LN||FINDINGS: Heart size normal. No focal consolidation, pleural effusion, or pneumothorax.||||||F
OBX|2|TX|IMP^Impression^LN||IMPRESSION: No radiographic evidence of pneumonia.||||||F
OBX|3|CE|ICD10AM^Diagnosis^ICD10AM||J18.9^Pneumonia, unspecified organism^ICD10AM||||||F

RIS Mapping

• integration_message_log:
• target_system = 'NABIDH'.
• hie_submission_status updated based on ACK.
• radiology_reports:
• hie_submission_datetime.
• hie_submission_status (for KPI “NABIDH/Malaffi Report Submission Rate”).

Error Handling (INT-RIS-004)

• Transport / MLLP failure
• Retry with exponential backoff (30s, 1m, 2m, 5m, 10m).
• After 5 failures: mark as pending_manual and alert integration team.
• ACK handling
• NABIDH ACK with MSA-1 = AA: mark as accepted.
• AE or AR: store ERR segment; no auto-retry; manual correction required.
• Regulatory
• Audit log retained per UAE PDPL and DHA retention policies.
• No PHI sent to non-approved endpoints.

Retry and Recovery

Retry Strategy:

Dead Letter Queue:

• Messages exhausting all retries written to integration_dlq with target_system = 'NABIDH'
• Admin dashboard for manual review, payload correction, and requeue
• Retention: per DHA/NABIDH and UAE PDPL retention policies (minimum 30 days active)
• Alert: integration team notified on DLQ insertion; daily summary of pending NABIDH submissions

Idempotency:

• Deduplication key: [report_id]_[ORU^R01]_[message_datetime]
• NABIDH checks MSH-10 (Message Control ID); duplicate submissions return AA without reprocessing
• Re-sent corrected reports use new MSH-10 with updated OBR-25 status

Reconciliation:

• Daily: compare radiology_reports with report_status = 'Final' against integration_message_log where target_system = 'NABIDH' and status = 'accepted'
• Unmatched records flagged for integration team; shown on NABIDH submission compliance dashboard
• Monthly: trend reporting on NABIDH submission success rate for KPI "NABIDH/Malaffi Report Submission Rate"

INT-RIS-005: Malaffi (Abu Dhabi HIE)

Business Context

Similar to NABIDH but for Abu Dhabi facilities under DOH.

What flows

• Final radiology reports and associated order metadata.
• Dose summaries where required by DOH radiation safety reporting.

When

• On final report signing for encounters at Abu Dhabi facilities.

Why

• Comply with DOH/Malaffi participation and ADHICS-aligned data sharing.

HL7 v2.5.1 Technical Detail (Malaffi Profile)

Message Type: ORU^R01 with DOH-specific facility and coding requirements.

Differences vs NABIDH (conceptual):

• Facility identifiers follow DOH coding.
• Some fields (e.g., insurance) may be required in IN1 segments (if configured).

Sample Malaffi ORU^R01 (RIS → Malaffi)

MSH|^~\&|RIS|ABUDHABIHOSP^ADH001|MALAFFI|DOH|20260207150000+0400||ORU^R01|MALAFFI-RIS-20260207150000001|P|2.5.1|||AL|NE||UTF-8
PID|1||MRN200567^^^ABUDHABIHOSP^MR~784-1990-7654321-2^^^UAE^EID||AL-NAHYAN^FATIMA^MOHAMMED||19900310|F|||PO BOX 67890^^ABU DHABI^^00000^AE||+971507654321
PV1|1|O|RAD^CT^02^ABUDHABIHOSP^ADH001^^RADIOLOGY||||OMAR^HASSAN^ALI^^^DR|||RAD||||||||ENC2026020712002
ORC|RE|ORD-20260207-0100||ACC-20260207-0100|CM||||20260207145500+0400|||AL-SUWAIDI^MAJID^SAEED^^^DR^MD
OBR|1|ORD-20260207-0100|ACC-20260207-0100|71260^CT CHEST W/O CONTRAST^CPT||20260207133000+0400|20260207134500+0400|||||||AL-SUWAIDI^MAJID^SAEED^^^DR^MD||RAD^Radiology|||||||F|||RAD^Radiology|CT^Computed Tomography^DCM|^^CHEST^SNM|||Y||20260207145000+0400
OBX|1|TX|RPT^Radiology Report^LN||FINDINGS: No focal lung lesion. No pleural effusion. Mild dependent atelectasis.||||||F
OBX|2|TX|IMP^Impression^LN||IMPRESSION: No CT evidence of pulmonary embolism.||||||F
OBX|3|CE|ICD10AM^Diagnosis^ICD10AM||R06.02^Shortness of breath^ICD10AM||||||F
OBX|4|NM|DOSE_DLP^CT Dose Length Product^LN||180.0|mGy.cm|||||F
OBX|5|NM|DOSE_EFF^Effective Dose^LN||3.5|mSv|||||F

Mapping

• Dose values (OBX-4/5) → radiation_dose_records for that exam_id.
• MSH-4 facility code must match DOH registration.

Error Handling (INT-RIS-005)

Same pattern as NABIDH, with DOH-specific monitoring:

• Track submission success rate for KPI.
• Ensure ADHICS logging (who/when/what sent).

Retry and Recovery

Retry Strategy:

Dead Letter Queue:

• Messages exhausting all retries written to integration_dlq with target_system = 'MALAFFI'
• Admin dashboard for manual review, payload correction, and requeue
• Retention: per DOH and UAE PDPL retention policies (minimum 30 days active)
• Alert: integration team notified on DLQ insertion; daily summary of pending Malaffi submissions

Idempotency:

• Deduplication key: [report_id]_[ORU^R01]_[message_datetime]
• Malaffi checks MSH-10 (Message Control ID); duplicate submissions return AA without reprocessing
• Re-sent corrected reports use new MSH-10 with updated OBR-25 status

Reconciliation:

• Daily: compare radiology_reports with report_status = 'Final' (Abu Dhabi facilities) against integration_message_log where target_system = 'MALAFFI' and status = 'accepted'
• Unmatched records flagged for integration team; ADHICS-compliant audit trail maintained
• Monthly: trend reporting on Malaffi submission success rate for KPI "NABIDH/Malaffi Report Submission Rate"

INT-RIS-006: Billing & Claims

Business Context

What flows

• Outbound from RIS:
• Completed exam details for charge capture:
  • exam_code_cpt, modifiers (e.g., bilateral), contrast usage, facility/department, technologist, radiologist, duration, DRG-related flags.
• Links to payer/plan from encounter.

When

• When radiology_exams.exam_status = 'completed' AND radiology_reports.report_status = 'Final'.

Why

• Ensure accurate, timely billing.
• Support eClaimLink / DOH eClaims downstream.

How often

• Real-time per completed exam.

Error impact

• Missed or delayed charges; revenue leakage.
• Incorrect coding if modifiers/contrast not transmitted.

HL7 v2.5.1 Technical Detail

Message Type: DFT^P03 (Detailed Financial Transaction).

Sample DFT^P03 (RIS → Billing)

MSH|^~\&|RIS|DUBAIHOSP|BILLING|DUBAIHOSP|20260207141000+0400||DFT^P03|BILL-20260207141000001|P|2.5.1|||AL|NE||UTF-8
EVN|P03|20260207141000+0400
PID|1||MRN100245^^^DUBAIHOSP^MR~784-1985-1234567-1^^^UAE^EID||AL-MAKTOUM^AHMED^ALI||19850315|M
PV1|1|O|RAD^XRAY^01^DUBAIHOSP^^RADIOLOGY||||AL-NAHYAN^FATIMA^OMAR^^^DR|||RAD||||||||ENC2026020710001
FT1|1|20260207113000+0400|20260207120000+0400||CG|71046^CHEST X-RAY 2 VIEWS^CPT|1|EA|250.00|AED|||RAD^Radiology||||AL-RAHMAN^KHALID^HASSAN^^^DR^MD|XRAYROOM1
FT1|2|20260207113000+0400|20260207120000+0400||CG|Q9958^Contrast agent^HCPCS|1|ML|0.00|AED|||RAD^Radiology||||AL-RAHMAN^KHALID^HASSAN^^^DR^MD|XRAYROOM1
DG1|1||J18.9^Pneumonia, unspecified organism^ICD10AM||20260207103000+0400|||A

Mapping

• FT1-4/5 → radiology_exams.exam_start_time / exam_end_time.
• FT1-7 → exam_code_cpt.
• FT1-8 quantity (e.g., number of views).
• FT1-10/11 → internal pricing (may be overridden by billing system).
• Contrast line item derived from radiology_exams.contrast_used, contrast_type, contrast_volume.

Error Handling (INT-RIS-006)

• If billing system unavailable:
• Queue DFT messages; retry with exponential backoff.
• Show “Pending Billing” flag on exam in RIS.
• Duplicate detection:
• Billing system uses combination of FT1-2 (transaction ID) and FT1-7 (CPT) for idempotency.

Retry and Recovery

Retry Strategy:

Dead Letter Queue:

• Failed DFT messages written to integration_dlq with target_system = 'BILLING'
• “Pending Billing” flag shown on exam in RIS worklist until resolved
• Admin dashboard for billing analyst review, correction, and requeue
• Retention: 30 days active; alert finance team if DLQ count exceeds threshold

Idempotency:

• Deduplication key: [exam_id]_[DFT^P03]_[FT1-2 transaction_id]
• Billing system checks combination of FT1-2 (transaction ID) and FT1-7 (CPT code) — duplicates are rejected without double-charging
• Re-sent messages after correction use new MSH-10 with same exam reference

Reconciliation:

• Daily: compare radiology_exams with exam_status = 'completed' and report_status = 'Final' against billing system charge records
• Unmatched records (unbilled exams) flagged for revenue integrity review
• Monthly: charge capture rate reported as KPI; trend analysis on billing DLQ volumes

INT-RIS-007: EHR (Patient Chart)

Business Context

What flows

• Outbound from RIS:
• Radiology reports (preliminary and final).
• Critical result flags and links to critical notification records.
• Links to images (PACS viewer URLs).

When

• On report signing (preliminary or final).
• On report addendum.

Why

• Make imaging results visible in the longitudinal patient chart.
• Support clinician workflows (rounding, outpatient follow-up).

FHIR R4 Technical Detail

Resource: DiagnosticReport (primary), with optional Observation components and Communication for critical notifications (often handled by EHR).

Sample DiagnosticReport (RIS → EHR)

{
  "resourceType": "DiagnosticReport",
  "id": "RPT-20260207-0001",
  "status": "final",
  "category": [
    {
      "coding": [
        {
          "system": "http://terminology.hl7.org/CodeSystem/v2-0074",
          "code": "RAD",
          "display": "Radiology"
        }
      ]
    }
  ],
  "code": {
    "coding": [
      {
        "system": "http://www.ama-assn.org/go/cpt",
        "code": "71046",
        "display": "Radiologic examination, chest; 2 views"
      }
    ],
    "text": "Chest X-ray 2 views"
  },
  "subject": {
    "reference": "Patient/MRN100245",
    "display": "Ahmed Ali Al-Maktoum"
  },
  "encounter": {
    "reference": "Encounter/ENC2026020710001"
  },
  "effectiveDateTime": "2026-02-07T11:30:00+04:00",
  "issued": "2026-02-07T13:40:00+04:00",
  "performer": [
    {
      "reference": "Organization/DUBAIHOSP-RAD",
      "display": "Dubai General Hospital - Radiology"
    }
  ],
  "resultsInterpreter": [
    {
      "reference": "Practitioner/AL-RAHMAN-KHALID",
      "display": "Dr. Khalid Hassan Al-Rahman"
    }
  ],
  "conclusion": "No radiographic evidence of pneumonia.",
  "presentedForm": [
    {
      "contentType": "text/plain",
      "language": "en",
      "data": "RklORElOR1M6IEhlYXJ0IHNpemUgbm9ybWFsLiBObyBmb2NhbCBjb25zb2xpZGF0aW9uLgpJT1NJT046IE5vIHJhZGlvZ3JhcGhpYyBldmlkZW5jZSBvZiBwbmV1bW9uaWEu"
    }
  ],
  "extension": [
    {
      "url": "http://gateshealth.ae/fhir/StructureDefinition/critical-flag",
      "valueBoolean": false
    },
    {
      "url": "http://gateshealth.ae/fhir/StructureDefinition/pacs-viewer-url",
      "valueUrl": "https://pacs.dubaihosp.ae/viewer?study=1.2.840.113619.2.55.3.604688435.1234.20260207.113000"
    }
  ],
  "basedOn": [
    {
      "reference": "ServiceRequest/ORD-20260207-0001"
    }
  ]
}

Search Parameters

• GET /DiagnosticReport?subject=Patient/MRN100245&category=RAD
• GET /DiagnosticReport?based-on=ServiceRequest/ORD-20260207-0001
• GET /DiagnosticReport?date=ge2026-02-01&date=le2026-02-07

Error Handling (INT-RIS-007)

• FHIR 4xx: log OperationOutcome, no auto-retry; RIS admin can correct and re-send.
• FHIR 5xx: retry with exponential backoff; after 5 failures, mark as pending_manual.

Retry and Recovery

Retry Strategy:

Dead Letter Queue:

• Failed DiagnosticReport submissions written to integration_dlq with target_system = 'EHR'
• Admin dashboard for RIS admin review, payload correction, and requeue
• Critical reports (with is_critical = true) receive priority DLQ alerts — integration team notified immediately
• Retention: 30 days active

Idempotency:

• Deduplication key: DiagnosticReport.id (report_id)
• EHR checks for existing DiagnosticReport with same id — updates in place rather than creating duplicates
• Addendum reports use same DiagnosticReport.id with updated status and appended content

Reconciliation:

• Daily: compare radiology_reports with signed reports against EHR DiagnosticReport records
• Unmatched records flagged for RIS admin / interface analyst review
• Critical reports verified within 1 hour of signing — any undelivered critical report triggers immediate escalation

INT-RIS-008: Insurance / Prior Authorization

Business Context

What flows

• Outbound from RIS
• Prior authorization requests for imaging:
  • Patient demographics, Emirates ID.
  • Ordering provider details.
  • Exam CPT, ICD-10-AM indication, modality, contrast, priority.
• Inbound to RIS
• Authorization responses:
  • Approved/denied/pending.
  • Authorization number, validity dates.
  • Denial reasons; instructions for peer-to-peer review.

When

• When an imaging order requires prior auth per payer rules (from policy-contract-mgmt).
• Typically before scheduling.

Why

• Avoid claim denials.
• Ensure compliance with payer medical necessity policies.

How often

• Real-time per applicable order.

Error impact

• If requests fail: scheduling may proceed without auth, leading to denied claims.
• If responses not processed: orders may remain blocked or incorrectly allowed.

Technical Detail (eClaimLink / DOH eClaims)

This integration typically uses XML/JSON over HTTPS via payer gateways; detailed schemas are governed by:

• eClaimLink (DHA, Dubai).
• DOH eClaims (Abu Dhabi).

RIS will generally call an internal Prior Auth service in the HIS, which then handles external specifics.

Key Data Elements from RIS

• radiology_orders.order_id
• exam_code_cpt
• icd10_code
• priority
• facility_id, department_id
• patient_id (Emirates ID, MRN)
• ordering_provider_id

Error Handling (INT-RIS-008)

• If internal Prior Auth service unavailable:
• Mark order as auth_pending_system_error.
• Prevent scheduling unless overridden by authorized user.
• If external gateway returns error:
• Show denial/error message to receptionist/insurance coordinator.
• Allow re-submission after correction.

Retry and Recovery

Retry Strategy:

Dead Letter Queue:

• Failed prior auth requests written to integration_dlq with target_system = 'PRIOR_AUTH'
• Orders remain in auth_pending_system_error status until resolved
• Insurance Coordinator dashboard shows pending requests with error details
• Alert: integration team notified; finance/insurance supervisor alerted if > 10 requests queued

Idempotency:

• Deduplication key: [order_id]_[prior_auth_request_id]
• eClaimLink / DOH eClaims gateways use payer reference numbers to detect duplicate submissions
• Re-submissions after correction use new request ID linked to same order

Reconciliation:

• Daily: identify radiology_orders with order_status = 'auth_required' or auth_pending_system_error older than 24 hours
• Weekly: reconcile auth approvals against scheduling — detect approved orders not yet scheduled
• Monthly: prior auth approval rate and turnaround time reported as KPIs

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/onboarding requirements.
• ADHICS and TDRA/NESA cybersecurity standards for Abu Dhabi/Dubai where applicable.

Transport Security

• mTLS (Mutual TLS)
• Used for HL7 over MLLP/TLS to NABIDH, Malaffi, and internal HIS services.

• RIS maintains separate client certificates for:

  • NABIDH (DHA-issued).
  • Malaffi (DOH-issued).
  • Internal HIS (Gates Group PKI).

• VPN / Private Links

• For eClaimLink and DOH eClaims, as required by payers/regulators.

Application-Level Auth

• OAuth 2.0
• Used for FHIR APIs (RIS ↔ CPOE/EHR).
• Client credentials or SMART-on-HIS flows.

• Scopes aligned to least privilege (e.g., diagnosticreport.write, servicerequest.read).

• API Keys / Certificates

• For some internal APIs and payer gateways, as per local implementation.

Message Encryption & Data Protection

• All external traffic encrypted in transit (TLS 1.2+).
• No PHI in logs beyond what is necessary for troubleshooting; where present, logs are:
• Access-controlled.
• Retained per MOH/DHA/DOH policies.
• At rest:
• RIS databases encrypted (disk or field-level) as per ADHICS/NABIDH guidance.
• DICOM archives handled by PACS but integrated with RIS under same security policies.

Access Control & Audit

• Role-based access (see module roles) enforced on:
• Worklists.
• Dose dashboards.
• Integration admin screens.
• Comprehensive audit trails:
• Who triggered outbound messages.
• When messages were sent/received.
• What data was transmitted (message control IDs, order/report IDs).
• Audit logs must support regulatory investigations and internal QA.

This specification covers all RIS integrations listed in the module brief, with HL7/FHIR examples, UAE-specific HIE considerations, and error-handling patterns suitable for implementation by the development and integration teams.