Billing & Claims Management Integration Specifications

Integration Summary

INT-BIL-001: CPOE / Clinical Systems → Billing (Automated Charge Capture)

Business Context

What flows

• Completed clinical services converted into billable charges:
• Medication administrations/dispenses
• Performed procedures (CPT), surgeries, anesthesia time
• Laboratory tests (LOINC → CPT mapping)
• Imaging studies (DICOM/RIS orders → CPT)
• Bed days, observation hours
• Key data elements:
• Patient (MRN, Emirates ID), encounter, provider, facility/department
• Service date/time, performing provider
• Clinical codes: CPT/HCPCS, ICD-10-AM diagnoses, modifiers
• Source order IDs for audit

When

• Immediately when: 1. An order is marked “completed” or “resulted” in CPOE/LIS/RIS/PIS, or 2. A procedure is documented as performed in theatre, or 3. A bed/room charge interval closes (e.g., midnight, discharge).

Why

• Eliminate manual paper charge tickets and reduce missed charges.
• Ensure accurate, timely charge capture to support:
• Clean claims to DHA/DOH and private payers
• Accurate revenue reporting and DOH/DHA audits
• Support UAE coding standards (ICD-10-AM, CPT, SNOMED CT, LOINC, RxNorm).

How often

• Real-time, event-driven. Target < 5 seconds from clinical completion to charge creation.

Error impact

• If integration fails:
• Charges may not be created → underbilling, revenue loss.
• Claim generation may be delayed or incomplete.
• Manual reconciliation required from clinical logs.
• System must:
• Queue failed messages
• Alert Revenue Cycle Manager if backlog exceeds threshold (e.g., > 100 pending or > 15 minutes delay).

HL7 v2.5.1 Technical Detail

Message Type: DFT^P03 (Detailed Financial Transaction)

Used by CPOE/LIS/RIS/PIS to send financial transactions to Billing.

MSH|^~\&|CPOE|DUBAI_HOSP|BILLING|DUBAI_HOSP|20260207103015||DFT^P03|BIL20260207103015001|P|2.5.1|||AL|NE||UTF-8
EVN|P03|20260207103010|||USR001^ALI^OMAR
PID|1||2026009876^^^DUBAI_HOSP^MR~784-1985-1234567-1^^^UAE^EID||AL-MAKTOUM^AHMED^MOHAMMED||19850315|M|||PO BOX 12345^^DUBAI^^00000^AE||+971501234567|||M||||||||||AE
PV1|1|O|OPD^CARD^01^DUBAI_HOSP||||SALIM^FATIMA^ALI^^^DR|||CAR||||||||ENC2026020700456|||||||||||||||||||||||||20260207090000
FT1|1|20260207093000|20260207093000||CG|93000^Cardiac stress test^CPT||1|500.00|AED|||SALIM^FATIMA^ALI^^^DR|CARD^Cardiology^DUBAI_HOSP|784-1985-1234567-1^^^UAE^EID|OP^Outpatient|
DG1|1||I20.9^Angina pectoris, unspecified^ICD10AM||20260207090000|F
ZCH|1|AUTO|CPOE|ORD-2026020700123|CDM12345|THIQA|PLAN-THIQA-01

Key Segments

• MSH: Standard header; MSH-3/4 = sending app/facility; MSH-9 = DFT^P03.
• PID-3: MRN and Emirates ID (UAE PDPL: ensure minimum necessary identifiers).
• PV1:
• PV1-2 patient class (O/I/E)
• PV1-3 location (facility/department/room)
• PV1-19 encounter/visit number (encounters.encounter_id).
• FT1 (Financial Transaction):
• FT1-4/5: transaction and posting date/time.
• FT1-6: transaction type CG (charge).
• FT1-7: CPT code and description.
• FT1-10: quantity.
• FT1-11: unit amount (pre-contract).
• FT1-13: currency (AED).
• FT1-16: ordering/performing provider.
• FT1-18: department.
• DG1: ICD-10-AM diagnosis for medical necessity.
• ZCH (custom segment):
• ZCH-2: charge source (AUTO vs MANUAL).
• ZCH-3: source module (CPOE, RIS, LIS, PIS, OR).
• ZCH-4: source order ID.
• ZCH-5: CDM item ID.
• ZCH-6: primary payer (e.g., THIQA, Daman).
• ZCH-7: plan ID.

Field Mapping to Billing Tables

FHIR R4 Technical Detail

This integration is primarily HL7 v2.5.1. For future internal APIs, a FHIR-based representation of a charge event can be modeled using ChargeItem.

Resource: ChargeItem

{
  "resourceType": "ChargeItem",
  "id": "CHG-202602070001",
  "status": "billable",
  "code": {
    "coding": [
      {
        "system": "http://www.ama-assn.org/go/cpt",
        "code": "93000",
        "display": "Cardiovascular stress test"
      }
    ],
    "text": "Cardiac stress test"
  },
  "subject": {
    "reference": "Patient/2026009876",
    "display": "Ahmed Mohammed Al-Maktoum"
  },
  "context": {
    "reference": "Encounter/ENC2026020700456"
  },
  "occurrenceDateTime": "2026-02-07T09:30:00+04:00",
  "performer": [
    {
      "function": {
        "coding": [
          {
            "system": "http://terminology.hl7.org/CodeSystem/chargeitem-performance",
            "code": "performer"
          }
        ]
      },
      "actor": {
        "reference": "Practitioner/SALIM-FATIMA",
        "display": "Dr. Fatima Ali Salim"
      }
    }
  ],
  "enterer": {
    "reference": "PractitionerRole/USR001"
  },
  "quantity": {
    "value": 1
  },
  "unitPriceComponent": [
    {
      "type": "base",
      "amount": {
        "value": 500.0,
        "currency": "AED"
      }
    }
  ],
  "reason": [
    {
      "coding": [
        {
          "system": "http://hl7.org/fhir/sid/icd-10-am",
          "code": "I20.9",
          "display": "Angina pectoris, unspecified"
        }
      ]
    }
  ],
  "extension": [
    {
      "url": "http://gatesgroup.ae/fhir/StructureDefinition/sourceOrderId",
      "valueString": "ORD-2026020700123"
    }
  ]
}

Key Element Mappings

Search Parameters (if exposed)

• GET /ChargeItem?patient=Patient/2026009876
• GET /ChargeItem?encounter=ENC2026020700456
• GET /ChargeItem?code=93000
• GET /ChargeItem?occurrence=ge2026-02-07&occurrence=le2026-02-07

Error Handling

Transport / Parsing Errors

• Retry with exponential backoff: 30s, 1m, 2m, 5m, 10m (max 5 attempts).
• On each failure:
• Log full HL7 message and error.
• Keep in billing_integration_queue with status error.
• After max retries:
• Move to dead-letter queue billing_dlt with reason.
• Alert:
  • Interface engine team
  • Revenue Cycle Manager if > 50 messages in DLT or oldest > 1 hour.

Application Errors

• Validation failures (e.g., unknown CPT, missing encounter):
• Mark charge as rejected.
• Create worklist item on Charge Review Worklist (SCR-BIL-001).
• No auto-retry; requires manual correction or mapping update.

Idempotency

• Use composite key (source_module, source_order_id, cpt_code, service_date) to prevent duplicate charges.
• If duplicate detected:
• Log as duplicate_ignored.
• Return ACK to sender to avoid re-sending.

Manual Recovery

• Interface admin can:
• Reprocess messages from DLT after fixing mappings.
• Bulk re-run for a date range.
• Charge Entry Clerk can manually create charges for services that failed integration and cannot be re-sent.

Retry and Recovery

Retry Strategy:

Dead Letter Queue:

• Messages exhausting all retries moved to billing_dlt table with full payload and failure reason
• Admin dashboard for manual review, correction, and requeue
• Retention: 30 days active, then archive to cold storage
• Alert: Revenue Cycle Manager notified when DLT count > 50 or oldest message > 1 hour

Idempotency:

• Deduplication key: (source_module, source_order_id, cpt_code, service_date)
• If duplicate detected: log as duplicate_ignored, return ACK to sender
• Prevents double-charging from message retransmission

Reconciliation:

• Daily batch comparison: clinical completed orders vs charges table
• Unmatched clinical events flagged for Charge Entry Clerk review
• Reconciliation report: charges missing source orders and orders missing charges
• Monthly trend reporting on charge capture rate and integration success rate

INT-BIL-002: Scheduling / ADT → Billing (Encounter & Bed/OR Data)

Business Context

What flows

• Encounter lifecycle and visit attributes:
• Encounter creation, updates, closure.
• Admission, discharge, transfer events.
• Bed/room/ward, ICU vs ward, OR time blocks.
• Visit type (inpatient, outpatient, ED, day surgery).
• Used for:
• Determining billable bed days and OR time.
• Linking charges to correct encounter and payer episode.
• Calculating claim submission lag KPI.

When

• On each ADT event:
• Registration (A04), admission (A01), transfer (A02), discharge (A03), update (A08).
• On OR schedule updates (via internal API).

Why

• Billing must know:
• When the billable episode starts/ends.
• Which bed/ward/OR to apply correct room and board charges.
• Required for DOH/DHA audits and payer validation of length-of-stay.

How often

• Real-time, event-driven.

Error impact

• Missing or incorrect encounter data:
• Wrong bed-day counts → over/under billing.
• Claims rejected due to inconsistent admission/discharge dates.
• AR aging and KPIs distorted.

HL7 v2.5.1 Technical Detail

Message Types: ADT^A01 (admit), ADT^A03 (discharge), ADT^A08 (update).

Sample ADT^A01 (Inpatient Admission)

MSH|^~\&|ADT|ABUDHABI_HOSP|BILLING|ABUDHABI_HOSP|20260207100000||ADT^A01|ADT20260207100000001|P|2.5.1|||AL|NE||UTF-8
EVN|A01|20260207100000|||REG001^HASSAN^LAILA
PID|1||2026005555^^^ABUDHABI_HOSP^MR~784-1990-7654321-3^^^UAE^EID||AL-NAHYAN^FATIMA^KHALID||19900320|F|||PO BOX 54321^^ABU DHABI^^00000^AE||+971502223344|||M||||||||||AE
PV1|1|I|5A^510^02^ABUDHABI_HOSP^^^^WARD|R|ADM|ALI^MOHAMMED^SAEED^^^DR|||MED|||||||VIA ED|ENC2026020712345|||||||||||||||||||||||||20260207100000
PV2|||EL^Elective||||||||||||||||||||||||||||||||||||||||||20260210120000

Sample ADT^A03 (Discharge)

MSH|^~\&|ADT|ABUDHABI_HOSP|BILLING|ABUDHABI_HOSP|20260210123000||ADT^A03|ADT20260210123000001|P|2.5.1
EVN|A03|20260210123000|||REG001^HASSAN^LAILA
PID|1||2026005555^^^ABUDHABI_HOSP^MR~784-1990-7654321-3^^^UAE^EID||AL-NAHYAN^FATIMA^KHALID||19900320|F
PV1|1|I|5A^510^02^ABUDHABI_HOSP^^^^WARD|R|ADM|ALI^MOHAMMED^SAEED^^^DR|||MED|||||||VIA ED|ENC2026020712345||||||||||||||||||||01|||||20260210120000

Key Segment Usage

• PV1-2 patient class: I, O, E, OBS.
• PV1-3 location: ward/room/bed.
• PV1-19 visit number → encounters.encounter_id.
• PV1-36 discharge disposition (for some payer rules).
• PV1-44 admit date/time.
• PV1-45 discharge date/time.

Field Mapping

Bed and OR time charges are generated by internal billing logic based on these timestamps and facility-specific charge_capture_rules.

FHIR R4 Technical Detail

Internal APIs may expose encounter data using Encounter.

Resource: Encounter

{
  "resourceType": "Encounter",
  "id": "ENC2026020712345",
  "status": "finished",
  "class": {
    "system": "http://terminology.hl7.org/CodeSystem/v3-ActCode",
    "code": "IMP",
    "display": "inpatient encounter"
  },
  "subject": {
    "reference": "Patient/2026005555",
    "display": "Fatima Khalid Al-Nahyan"
  },
  "period": {
    "start": "2026-02-07T10:00:00+04:00",
    "end": "2026-02-10T12:00:00+04:00"
  },
  "serviceProvider": {
    "reference": "Organization/ABUDHABI_HOSP",
    "display": "Abu Dhabi General Hospital"
  },
  "location": [
    {
      "location": {
        "reference": "Location/5A-510-02",
        "display": "Ward 5A, Room 510, Bed 02"
      },
      "period": {
        "start": "2026-02-07T10:00:00+04:00",
        "end": "2026-02-10T12:00:00+04:00"
      }
    }
  ],
  "type": [
    {
      "coding": [
        {
          "system": "http://terminology.hl7.org/CodeSystem/encounter-type",
          "code": "ADMS",
          "display": "Admission"
        }
      ]
    }
  ]
}

Key Mappings

Search Parameters

• GET /Encounter?patient=Patient/2026005555
• GET /Encounter?date=ge2026-02-07&date=le2026-02-10
• GET /Encounter?class=IMP

Error Handling

• Missing encounter:
• If ADT received for unknown MRN: log and request patient sync from EHR.
• Out-of-order events:
• If discharge (A03) arrives before admit (A01):
  • Queue event until admit exists or timeout (e.g., 30 minutes).
• Retry strategy:
• Same exponential backoff as INT-BIL-001.
• Dead letter:
• ADT messages that cannot be reconciled after 24 hours → DLT with reason.
• Manual recovery:
• Billing admin can manually correct encounter dates/locations in an admin UI, then re-run bed/OR charge generation.

Retry and Recovery

Retry Strategy:

Dead Letter Queue:

• ADT messages that cannot be reconciled after 24 hours moved to billing_dlt with reason
• Admin dashboard for manual review, re-ordering, and requeue
• Retention: 30 days active, then archive
• Alert: interface team notified on DLQ insertion; Revenue Cycle Manager if > 20 ADT messages in DLQ

Idempotency:

• Deduplication key: (encounter_id, event_type, event_datetime)
• Duplicate ADT events (same encounter + event type + timestamp) are acknowledged without reprocessing
• Ensures bed-day and OR charges are not duplicated on retransmission

Reconciliation:

• Daily comparison: encounters (from scheduling) vs billing encounter references
• Flag encounters with charges but no matching ADT discharge event
• Flag discharged encounters with no charges (potential missed billing)
• Weekly LOS audit: billing bed-day charges vs ADT admission/discharge timestamps

INT-BIL-003: Policy & Contract Management ↔ Billing

Business Context

What flows

• Inbound to Billing:
• Fee schedule items (CPT/HCPCS → contracted rate per payer/plan).
• Contracted rules: bundled services, modifiers, multiple procedure discounts.
• Payer-specific claim edit rules (e.g., DHA/DOH format constraints).
• Outbound from Billing:
• Charge and claim utilization data for contract performance:
  • Actual allowed vs contracted.
  • Underpayment patterns.
  • Denial reasons by contract.

When

• Fee schedules and contracts:
• On creation/update in Policy & Contract Management (near real-time).
• Claim generation:
• On-demand rate lookup per charge/claim.
• Analytics:
• Periodic (e.g., nightly) data feed for performance dashboards.

Why

• Ensure correct expected reimbursement and minimize underpayments.
• Centralize contract logic and avoid duplication in billing rules.
• Support negotiation with payers using accurate performance data.

How often

• Real-time API calls for rate lookup.
• Batch or streaming for analytics.

Error impact

• If fee schedule unavailable:
• Claims may be generated without expected amount; underpayment detection impaired.
• If rules outdated:
• Higher denial rates due to incorrect edits.

Technical Detail (Internal API / Shared DB)

No HL7/FHIR here; internal REST + shared schema.

Example REST: Rate Lookup

GET /contracts/{contractId}/rates?cpt=93000&serviceDate=2026-02-07&placeOfService=OP

Sample Response

{
  "contractId": "CON-THIQA-2026",
  "planId": "PLAN-THIQA-01",
  "cptCode": "93000",
  "effectiveFrom": "2026-01-01",
  "effectiveTo": "2026-12-31",
  "baseRate": 500.0,
  "currency": "AED",
  "modifierRules": [
    {
      "modifier": "26",
      "rateAdjustmentType": "percentage",
      "rateAdjustmentValue": 0.6
    }
  ],
  "bundlingRules": [
    {
      "primaryCpt": "93000",
      "secondaryCpt": "93005",
      "ruleType": "secondary_not_payable_same_day"
    }
  ]
}

Mapping

• Used to populate:
• charges.contracted_rate
• claim_lines.allowed_amount
• claims.expected_reimbursement (derived).

Error Handling

• Rate lookup failure (timeout/500):
• Retry 3 times with 5s, 10s, 20s backoff.
• If still failing:
  • Mark claim as pending_pricing.
  • Exclude from submission batch.
  • Alert Revenue Cycle Manager if > 50 claims pending.
• Missing rate:
• Flag claim edit error: “No contracted rate for CPT 93000 under contract CON-THIQA-2026”.
• Route to Billing Specialist for manual pricing or contract update.

Retry and Recovery

Retry Strategy:

Circuit Breaker (Synchronous API):

• Threshold: 5 consecutive failures or > 50% error rate in 60-second window
• Open state: bypass rate lookup; mark claims as pending_pricing; exclude from submission batch
• Half-open: after 2 minutes, attempt single test request
• Closed: resume normal operation on successful test
• Alert: Revenue Cycle Manager notified when circuit opens; IT notified for investigation

Idempotency:

• Rate lookups are read-only and inherently idempotent
• Analytics outbound feed uses (claim_id, metric_type, period) as deduplication key to avoid double-counting in contract performance reports

Reconciliation:

• Nightly comparison: claims generated without contracted rates (pending_pricing) vs current fee schedule availability
• Auto-reprice claims where rate has since been loaded
• Weekly report: claims with rate variances > 10% between charge amount and contracted rate
• Monthly contract utilization report reconciled against Policy & Contract Management

INT-BIL-004: Billing ↔ DHA eClaimLink (Dubai)

Business Context

What flows

• Outbound:
• DHA eClaimLink-compliant XML claim files:
  • Patient demographics, Emirates ID.
  • Encounter details, providers.
  • Service lines (CPT, ICD-10-AM, quantities, charges).
• Inbound:
• Acknowledgements (accepted/rejected).
• Adjudication responses (approved, partially approved, denied).
• Electronic Remittance Advice (ERA) with payment and adjustment details.

When

• Claims marked “ready for submission” for Dubai-based payers.
• Typically:
• Batch submission once or multiple times daily.
• Real-time status queries for high-value claims.

Why

• Mandatory for Dubai facilities under DHA.
• Enables automated payment posting and denial management.
• Supports DHA analytics and compliance.

How often

• Batch: at least daily (configurable).
• Status checks: real-time on demand.

Error impact

• Failed submission:
• Delayed reimbursement.
• Risk of missing timely filing deadlines.
• Incorrect mapping:
• High denial/rejection rates.

Technical Detail (DHA eClaimLink REST API)

DHA eClaimLink uses XML payloads over HTTPS. No HL7 v2 here; however, internal mapping from HL7/DB to XML is required.

Example Claim XML (Simplified)

<ClaimBatch xmlns="http://www.eclaimlink.ae/schema/claim">
  <Header>
    <SenderID>DUBAI_HOSP</SenderID>
    <ReceiverID>ECLAIMLINK</ReceiverID>
    <TransactionDate>2026-02-07T14:00:00+04:00</TransactionDate>
    <RecordCount>1</RecordCount>
    <BatchNumber>DBH-20260207-001</BatchNumber>
  </Header>
  <Claim>
    <ClaimID>CLM-20260207-0001</ClaimID>
    <PayerID>OMAN_INS</PayerID>
    <MemberID>THIQA-123456</MemberID>
    <Patient>
      <EmiratesID>784-1985-1234567-1</EmiratesID>
      <FirstName>Ahmed</FirstName>
      <LastName>Al-Maktoum</LastName>
      <Gender>M</Gender>
      <DOB>1985-03-15</DOB>
    </Patient>
    <Encounter>
      <EncounterID>ENC2026020700456</EncounterID>
      <FacilityID>DUBAI_HOSP</FacilityID>
      <Start>2026-02-07T09:00:00+04:00</Start>
      <End>2026-02-07T11:00:00+04:00</End>
      <Type>OP</Type>
    </Encounter>
    <DiagnosisList>
      <Diagnosis>
        <Code>I20.9</Code>
        <Type>Principal</Type>
      </Diagnosis>
    </DiagnosisList>
    <ServiceLines>
      <Service>
        <LineNumber>1</LineNumber>
        <CPT>93000</CPT>
        <Quantity>1</Quantity>
        <UnitPrice>500.00</UnitPrice>
        <Gross>500.00</Gross>
        <ClinicianID>DR-SALIM</ClinicianID>
        <ServiceDate>2026-02-07</ServiceDate>
      </Service>
    </ServiceLines>
    <Financial>
      <Gross>500.00</Gross>
      <PatientShare>50.00</PatientShare>
      <Net>450.00</Net>
    </Financial>
  </Claim>
</ClaimBatch>

Mapping to Billing Tables

Adjudication Response / ERA

• Parsed into:
• remittance_advice
• payments
• payment_allocations
• claim_responses (allowed, paid, adjustments, denial codes).

Error Handling

• HTTP/Transport errors:
• Retry submission of batch:
  • 1 min, 5 min, 15 min (max 3 attempts).
• If still failing:
  • Mark claim_submissions.gateway_status = 'failed'.
  • Notify Billing Specialist and IT.
• Schema/validation errors (rejected by eClaimLink):
• Capture error code/message.
• Set claim_submissions.gateway_status = 'rejected', rejection_reason.
• Create worklist item in Claim Generation & Scrubbing (SCR-BIL-002).
• No auto-retry until corrected.
• Partial batch failures:
• Track per-claim status.
• Allow resubmission of corrected subset with new batch ID.
• Dead letter:
• Claims that repeatedly fail validation beyond configurable attempts → flagged as “manual submission required”.

Retry and Recovery

Retry Strategy:

Dead Letter Queue:

• Claims exhausting all transport retries moved to billing_dlt with gateway error details
• Claims repeatedly failing validation (> 3 correction attempts) flagged as MANUAL_SUBMISSION_REQUIRED
• Admin dashboard: filter by payer, error type, age; bulk requeue after fix
• Retention: 60 days active (to cover payer timely filing windows), then archive
• Alert: Billing Specialist notified on each DLQ insertion; Revenue Cycle Manager if > 10 claims in DLQ or oldest > 48 hours

Idempotency:

• Deduplication key: (claim_id, batch_id, submission_datetime)
• eClaimLink assigns gateway_reference_id on acceptance; system stores and checks before resubmission
• Prevents duplicate claim submissions that could trigger payer duplicate edits

Reconciliation:

• Daily: compare claim_submissions with SUBMITTED status vs eClaimLink acknowledgement log
• Flag claims submitted but without gateway acknowledgement > 24 hours
• Weekly: compare total claims submitted vs total adjudication responses received
• Monthly: reconcile expected reimbursement vs actual payments per DHA payer

INT-BIL-005: Billing ↔ DOH eClaims / Shafafiya (Abu Dhabi)

Business Context

Similar to INT-BIL-004 but for Abu Dhabi DOH eClaims (Shafafiya).

What flows

• Outbound DOH-compliant claim messages.
• Inbound adjudication and ERA.

When

• Claims for encounters at Abu Dhabi facilities or with Abu Dhabi-regulated payers.

Why

• Mandatory under DOH regulations.
• Supports Malaffi-aligned data quality expectations.

How often

• Batch daily; real-time status queries as needed.

Technical Detail

DOH eClaims uses XML/flat file formats over HTTPS. Internal mapping is similar to DHA but with DOH-specific codes (e.g., facility IDs, payer IDs).

Example (Simplified Claim XML)

<DOHClaimBatch>
  <Header>
    <SenderID>ABUDHABI_HOSP</SenderID>
    <ReceiverID>DOH</ReceiverID>
    <BatchNumber>ADH-20260207-001</BatchNumber>
    <CreationDate>2026-02-07T13:00:00+04:00</CreationDate>
  </Header>
  <Claim>
    <ClaimID>CLM-ADH-20260207-0001</ClaimID>
    <PayerID>DAMAN</PayerID>
    <MemberID>DAMAN-998877</MemberID>
    <EncounterID>ENC2026020712345</EncounterID>
    <FacilityID>ABUDHABI_HOSP</FacilityID>
    <AdmissionDate>2026-02-07</AdmissionDate>
    <DischargeDate>2026-02-10</DischargeDate>
    <DiagnosisList>
      <Diagnosis>
        <Code>I20.9</Code>
        <Type>Principal</Type>
      </Diagnosis>
    </DiagnosisList>
    <ServiceLines>
      <Service>
        <LineNumber>1</LineNumber>
        <CPT>99223</CPT>
        <Quantity>1</Quantity>
        <UnitPrice>800.00</UnitPrice>
        <Gross>800.00</Gross>
      </Service>
    </ServiceLines>
    <Financial>
      <Gross>800.00</Gross>
      <PatientShare>80.00</PatientShare>
      <Net>720.00</Net>
    </Financial>
  </Claim>
</DOHClaimBatch>

Mapping is analogous to DHA.

Error Handling

• Same retry/backoff pattern as INT-BIL-004.
• Additional DOH-specific checks:
• If DOH returns error codes indicating data quality issues (e.g., invalid Emirates ID, invalid facility license):
  • Flag as high severity.
  • Notify Compliance Officer as per DOH/ADHICS governance.

Retry and Recovery

Retry Strategy:

Dead Letter Queue:

• Claims exhausting all transport retries moved to billing_dlt with DOH error details
• DOH data quality rejections flagged separately for Compliance Officer review
• Admin dashboard: filter by payer, error type, DOH error code, age
• Retention: 60 days active (to cover DOH timely filing windows), then archive
• Alert: Billing Specialist on each DLQ insertion; Compliance Officer for DOH data quality errors; Revenue Cycle Manager if > 10 claims in DLQ

Idempotency:

• Deduplication key: (claim_id, batch_id, submission_datetime)
• DOH assigns unique response reference on acceptance; stored to prevent duplicate submissions
• Malaffi-aligned encounter IDs used as secondary deduplication check

Reconciliation:

• Daily: compare claim_submissions with DOH SUBMITTED status vs DOH acknowledgement responses
• Flag claims submitted but without DOH response > 24 hours
• Weekly: total DOH claims submitted vs adjudication responses received
• Monthly: reconcile expected vs actual payments per Abu Dhabi payer (Daman, THIQA, etc.)
• Quarterly: DOH data quality error trend analysis for process improvement

INT-BIL-006: Billing → Denial Analysis

Business Context

What flows

• Denial and underpayment data:
• Claim ID, payer, plan, contract.
• Denial codes (CARC/RARC + payer-specific).
• Denial category (eligibility, authorization, coding, medical necessity, timely filing).
• Financial impact (denied amount, recovered amount).
• Appeal status and outcome.

When

• At payment posting (ERA/EOB processing).
• At appeal resolution.

Why

• Support denial trending and root-cause analysis.
• Drive process improvements and payer negotiations.

How often

• Near real-time (event-driven) or periodic sync.

Technical Detail

Internal API or shared DB views.

Example Event Payload (Internal REST)

{
  "eventType": "claim_denial",
  "eventTime": "2026-02-08T11:30:00+04:00",
  "claimId": "CLM-20260207-0001",
  "payerId": "OMAN_INS",
  "planId": "PLAN-OMAN-01",
  "contractId": "CON-OMAN-2026",
  "denialCodes": [
    { "code": "CO-50", "description": "Non-covered services" }
  ],
  "deniedAmount": 200.0,
  "currency": "AED",
  "patientId": "2026009876",
  "encounterId": "ENC2026020700456"
}

Denial Analysis module reads from:

• claim_responses.denial_codes
• payment_allocations.adjustment_code
• claims.claim_status.

Error Handling

• If Denial Analysis API unavailable:
• Queue events and retry with exponential backoff.
• If queue age > 24 hours:
  • Alert Denial Specialist lead.
• Shared DB mode:
• Ensure read-only access from Denial Analysis.
• Use materialized views refreshed every 15 minutes.

Retry and Recovery

Retry Strategy:

Dead Letter Queue:

• Denial events exhausting all retries queued in billing_denial_outbox with full event payload
• Events held until Denial Analysis API recovers; auto-drain on recovery
• Retention: 30 days active
• Alert: Denial Specialist lead notified if queue age > 24 hours or > 100 pending events

Idempotency:

• Deduplication key: (claim_id, denial_code, event_datetime)
• Denial Analysis module checks for existing denial record before creating duplicate
• Appeal outcome updates use (claim_id, appeal_id) as idempotency key

Reconciliation:

• Daily: compare claims with denial-related statuses vs Denial Analysis module denial records
• Flag claims with denial codes in billing but no corresponding Denial Analysis record
• Weekly: reconcile appeal outcomes in Denial Analysis vs payment postings in Billing
• Monthly: denial volume and recovery rate cross-check between modules

INT-BIL-007: Billing ↔ Patient Portal (Statements & Online Payments)

Business Context

What flows

• Outbound to Portal:
• Patient financial summary:
  • Open invoices, balances, due dates.
  • Line-item details (encounter, service, insurance payments).
• Inbound from Portal:
• Online payments:
  • Amount, method (card, bank transfer), transaction reference.
  • Allocation to invoice/encounter.

When

• Outbound:
• On-demand when patient views billing in portal.
• On statement generation.
• Inbound:
• When patient completes payment via portal.

Why

• Improve patient experience and collection rate.
• Support UAE PDPL-compliant digital communication (bilingual EN/AR statements).

How often

• On-demand, real-time.

FHIR R4 Technical Detail

Resources: Account, Invoice, PaymentNotice (or custom profile), PaymentReconciliation.

Outbound: Patient Statement

Use Account to represent patient account and Invoice for statements.

{
  "resourceType": "Bundle",
  "type": "collection",
  "entry": [
    {
      "resource": {
        "resourceType": "Account",
        "id": "ACC-2026009876",
        "status": "active",
        "type": {
          "coding": [
            {
              "system": "http://gatesgroup.ae/fhir/CodeSystem/account-type",
              "code": "patient",
              "display": "Patient account"
            }
          ]
        },
        "name": "Patient Financial Account - Ahmed Al-Maktoum",
        "subject": {
          "reference": "Patient/2026009876",
          "display": "Ahmed Mohammed Al-Maktoum"
        },
        "balance": {
          "value": 350.0,
          "currency": "AED"
        }
      }
    },
    {
      "resource": {
        "resourceType": "Invoice",
        "id": "INV-20260207-0001",
        "status": "issued",
        "subject": {
          "reference": "Patient/2026009876"
        },
        "date": "2026-02-07",
        "totalGross": {
          "value": 500.0,
          "currency": "AED"
        },
        "totalNet": {
          "value": 350.0,
          "currency": "AED"
        },
        "totalPriceComponent": [
          {
            "type": "base",
            "amount": {
              "value": 500.0,
              "currency": "AED"
            }
          },
          {
            "type": "deduction",
            "amount": {
              "value": 150.0,
              "currency": "AED"
            }
          }
        ],
        "lineItem": [
          {
            "sequence": 1,
            "chargeItemReference": {
              "reference": "ChargeItem/CHG-202602070001"
            },
            "priceComponent": [
              {
                "type": "base",
                "amount": {
                  "value": 500.0,
                  "currency": "AED"
                }
              }
            ]
          }
        ],
        "paymentTerms": "Due within 30 days",
        "note": [
          {
            "text": "Statement available in English and Arabic."
          }
        ]
      }
    }
  ]
}

Mapping

Inbound: Online Payment

Use PaymentNotice to represent a patient payment notification.

{
  "resourceType": "PaymentNotice",
  "id": "PP-20260208-0001",
  "status": "active",
  "created": "2026-02-08T10:15:00+04:00",
  "paymentStatus": {
    "coding": [
      {
        "system": "http://terminology.hl7.org/CodeSystem/paymentstatus",
        "code": "paid",
        "display": "Paid"
      }
    ]
  },
  "amount": {
    "value": 200.0,
    "currency": "AED"
  },
  "request": {
    "reference": "Invoice/INV-20260207-0001"
  },
  "recipient": {
    "reference": "Organization/DUBAI_HOSP"
  },
  "payee": {
    "reference": "Patient/2026009876"
  },
  "extension": [
    {
      "url": "http://gatesgroup.ae/fhir/StructureDefinition/paymentMethod",
      "valueCode": "online-card"
    },
    {
      "url": "http://gatesgroup.ae/fhir/StructureDefinition/paymentGatewayRef",
      "valueString": "GATEWAY-TXN-123456"
    }
  ]
}

Mapping to Billing Tables

Search Parameters

• GET /Invoice?subject=Patient/2026009876&status=issued
• GET /PaymentNotice?payee=Patient/2026009876

Error Handling

• Portal → Billing (Payment):
• If Billing API returns 4xx (validation error):
  • Portal displays clear message and does not mark payment as successful.
• If 5xx or timeout:
  • Portal retries 3 times (2s, 5s, 10s).
  • If still failing but payment captured by gateway:
  • Mark payment as “pending posting”.
  • Generate reconciliation report for Finance to manually post.
• Billing → Portal (Statement):
• If Billing unavailable:
  • Portal shows “Billing temporarily unavailable” message.
  • No caching of stale balances beyond configurable TTL (e.g., 15 minutes) to remain PDPL-compliant and accurate.

Retry and Recovery

Retry Strategy:

Dead Letter Queue:

• Payment notifications that fail all retries queued in portal_payment_dlq
• Critical: payments captured by gateway but not posted in Billing are flagged as pending_posting
• Finance team receives daily report of pending_posting items for manual reconciliation
• Retention: 90 days active (to cover payment dispute windows)
• Alert: Finance Manager notified immediately for any pending_posting item; IT for transport failures

Idempotency:

• Deduplication key: (patient_id, invoice_id, gateway_transaction_ref)
• Billing checks for existing patient_payments with same gateway reference before creating duplicate
• Portal displays “Payment already recorded” if duplicate submission detected

Reconciliation:

• Daily: compare payment gateway settlement reports vs patient_payments table
• Flag gateway captures without corresponding patient_payments record (pending_posting)
• Flag patient_payments without corresponding gateway transaction (potential manual entry errors)
• Weekly: reconcile portal-displayed balances vs actual patient_invoices balances
• Monthly: total online collections vs gateway settlement totals

INT-BIL-008: Billing ↔ Patient Access (Eligibility & Co-pay)

Business Context

What flows

• Inbound to Billing:
• Eligibility verification results.
• Pre-authorization approvals and reference numbers.
• Outbound from Billing:
• Estimated co-pay, deductible, and co-insurance amounts for the visit.

When

• At patient check-in (outpatient) or pre-admission (inpatient).
• When new services are ordered that may change patient responsibility.

Why

• Improve point-of-service collection rate.
• Reduce eligibility-related denials.

How often

• Real-time per encounter.

Technical Detail (Internal API)

Eligibility Result → Billing

{
  "encounterId": "ENC2026020700456",
  "patientId": "2026009876",
  "payerId": "OMAN_INS",
  "planId": "PLAN-OMAN-01",
  "eligibilityStatus": "eligible",
  "coverageStart": "2025-01-01",
  "coverageEnd": "2026-12-31",
  "deductibleRemaining": 1000.0,
  "copayRules": [
    {
      "serviceType": "OP_CONSULT",
      "copayAmount": 50.0,
      "currency": "AED"
    }
  ],
  "preauth": [
    {
      "serviceCode": "93000",
      "authNumber": "AUTH-123456",
      "validFrom": "2026-02-07",
      "validTo": "2026-03-07"
    }
  ]
}

Co-pay Estimate → Patient Access

{
  "encounterId": "ENC2026020700456",
  "patientId": "2026009876",
  "estimatedCopay": 50.0,
  "estimatedCoinsurance": 30.0,
  "estimatedDeductiblePortion": 0.0,
  "currency": "AED",
  "calculatedAt": "2026-02-07T08:55:00+04:00"
}

Error Handling

• If eligibility result missing:
• Billing calculates co-pay using default plan rules or flags as “estimate only”.
• Patient Access UI clearly labels as estimate.
• If Patient Access API unavailable:
• Billing logs error and continues; co-pay still visible in Billing screens.
• Cashier can collect based on Billing view.

Retry and Recovery

Retry Strategy:

Circuit Breaker (Synchronous API):

• Threshold: 5 consecutive failures or > 50% error rate in 60-second window
• Open state: Billing uses default plan co-pay rules; labels estimate as "approximate — eligibility verification pending"
• Half-open: after 2 minutes, attempt single test eligibility query
• Closed: resume normal eligibility-driven co-pay calculation
• Alert: Registration Supervisor notified when circuit opens; IT notified for investigation

Idempotency:

• Eligibility queries are read-only and inherently idempotent
• Co-pay estimate responses are stateless and can be safely re-requested
• Pre-authorization reference numbers stored with (encounter_id, auth_number) as unique key to prevent duplicate auth consumption

Reconciliation:

• Daily: compare co-pay amounts collected at POS vs amounts determined by eligibility at check-in
• Flag encounters where collected amount differs from final adjudicated patient responsibility by > AED 50
• Weekly: reconcile pre-authorization usage (auths consumed vs auths on file)
• Monthly: eligibility verification success rate and circuit breaker activation frequency

INT-BIL-009: EHR & Patient Management → Billing (Demographics & Insurance)

Business Context

What flows

• Patient demographics:
• Name (EN/AR), Emirates ID, DOB, gender, contact details, address.
• Insurance information:
• Payer, plan, member ID, coverage dates, financial class.
• Guarantor details (if applicable).

When

• On registration (new patient).
• On demographic or insurance update.
• On encounter creation.

Why

• Populate claims with accurate patient and coverage data.
• Avoid rejections due to invalid Emirates ID or coverage.

How often

• Real-time.

HL7 v2.5.1 Technical Detail

Message Type: ADT^A04 (registration) / ADT^A08 (update).

MSH|^~\&|EHR|DUBAI_HOSP|BILLING|DUBAI_HOSP|20260207083000||ADT^A04|ADT20260207083000001|P|2.5.1|||AL|NE||UTF-8
EVN|A04|20260207083000|||REG002^OMAR^HIND
PID|1||2026007777^^^DUBAI_HOSP^MR~784-1988-1122334-7^^^UAE^EID||AL-MAZROUI^KHALID^AHMED||19881201|M|||PO BOX 77777^^DUBAI^^00000^AE||+971501112233|||M||||||||||AE
PD1|||DUBAI_CLINIC^^^^DUBAI_HOSP
NK1|1|AL-MAZROUI^AHMED^SAEED|FTH^Father|PO BOX 77777^^DUBAI^^00000^AE|+971501234888
IN1|1|OMAN_INS|OMAN_INS|Oman Insurance||PO BOX 1234^^DUBAI^^00000^AE|+97142000000|||||KHALID AHMED AL-MAZROUI|Self|784-1988-1122334-7^^^UAE^EID||||||||PLAN-OMAN-01||20250101|20261231

Key Segment Usage

• PID: demographics.
• IN1: insurance:
• IN1-3 payer ID → payers.payer_id.
• IN1-36 plan ID → insurance_plans.plan_id.
• IN1-12 insured’s name.
• IN1-17 insured’s ID (often Emirates ID).

Mapping

FHIR R4 Technical Detail

If EHR exposes FHIR, Billing may consume Patient and Coverage.

Resource: Coverage

{
  "resourceType": "Coverage",
  "id": "COV-2026007777-01",
  "status": "active",
  "beneficiary": {
    "reference": "Patient/2026007777",
    "display": "Khalid Ahmed Al-Mazroui"
  },
  "payor": [
    {
      "reference": "Organization/OMAN_INS",
      "display": "Oman Insurance"
    }
  ],
  "subscriberId": "OMAN-445566",
  "period": {
    "start": "2025-01-01",
    "end": "2026-12-31"
  },
  "class": [
    {
      "type": {
        "coding": [
          {
            "system": "http://terminology.hl7.org/CodeSystem/coverage-class",
            "code": "plan"
          }
        ]
      },
      "value": "PLAN-OMAN-01"
    }
  ]
}

Mapping

Error Handling

• If patient or coverage not found:
• Prevent claim generation; add edit: “Missing coverage for encounter”.
• Route to Registration/Billing worklist.
• Retry for transient EHR API failures with exponential backoff.

Retry and Recovery

Retry Strategy:

Dead Letter Queue:

• ADT/demographics messages exhausting retries moved to billing_dlt with source message and error
• Admin dashboard for review and requeue after resolution
• Retention: 30 days active
• Alert: interface team notified on DLQ insertion; Billing Specialist if > 10 messages or oldest > 4 hours

Idempotency:

• Deduplication key: (patient_id, event_type, message_control_id)
• Duplicate ADT registration/update messages acknowledged without reprocessing
• Insurance coverage updates use (patient_id, payer_id, plan_id, effective_date) to prevent duplicate coverage records

Reconciliation:

• Daily: compare EHR patient registration count vs billing patient reference count
• Flag patients with encounters but no demographics sync (potential missed ADT)
• Weekly: reconcile insurance coverage in billing vs EHR master patient index
• Monthly: demographic data quality audit (missing Emirates ID, invalid DOB, incomplete address)

NABIDH / Malaffi Integration Considerations

While Billing does not directly send HL7 to NABIDH/Malaffi, it must:

• Ensure data consistency with clinical modules that do:
• Patient identifiers, encounter IDs, diagnosis/procedure codes.
• Support DOH/DHA data quality rules that align with HIE profiles:
• Valid Emirates ID, DOB, gender, facility IDs.
• For DOH (Malaffi) and DHA (NABIDH) environments:
• Claims data must not contradict clinical data shared with HIE.
• Internal reconciliation reports should flag discrepancies (e.g., diagnosis on claim not present in clinical documentation).

Authentication & Security

All integrations must comply with:

• UAE PDPL (Federal Decree-Law No. 45/2021):
• Data minimization, purpose limitation, consent where applicable.
• Logging of access and disclosures.
• DOH ADHICS / DHA security guidelines:
• Encryption in transit and at rest.
• Role-based access control and least privilege.
• TDRA/NESA cybersecurity standards.

Mechanisms

1. mTLS Certificates - Used for:

   • DHA eClaimLink (INT-BIL-004).
   • DOH eClaims / Shafafiya (INT-BIL-005).
   • Requirements:
   • Facility-specific client certificates issued by DHA/DOH or approved CA.
   • TLS 1.2+ with strong cipher suites.
   • Certificate rotation and revocation procedures.

2. OAuth 2.0 - Used for:

   • Patient Portal FHIR APIs (INT-BIL-007).
   • Flows:
   • Authorization Code with PKCE for patient-facing apps.
   • Client Credentials for server-to-server (portal backend ↔ billing).
   • Scopes:
   • billing.read, billing.write, payments.create, etc.

3. Internal API Tokens - Used for:

   • INT-BIL-001, 002, 003, 006, 008, 009.
   • Implementation:
   • Short-lived JWTs signed by internal IdP.
   • Claims include sub, aud, scope, exp.
   • Validated at API gateway.

4. API Key Management - For any third-party payer portals (if used outside eClaimLink/DOH APIs). - Stored encrypted; rotated regularly.

5. Message Encryption & Logging - All external traffic over HTTPS (TLS 1.2+). - Sensitive fields (Emirates ID, bank details) masked in logs. - Audit logs:

   • Who submitted claims, when, to which payer.
   • Access to patient financial data via portal.

6. Error & Alerting Thresholds

• Central monitoring:
• Integration queue depth.
• Error rates per integration.
• Alerts:
• Critical: submission failures to DHA/DOH lasting > 30 minutes.
• High: backlog of > 200 unsent claims or > 500 unprocessed charge messages.
• Medium: repeated validation errors for same payer/contract.

7. Access Control

• Only users with appropriate roles (e.g., Billing Specialist, Revenue Cycle Manager) can:
• Trigger submissions.
• Override claim edits.
• Reprocess dead-letter messages.

All implementations must be reviewed against DOH ADHICS and DHA security checklists before go-live.

```