Policy & Contract Management Integration Specifications

Integration Summary

Note: This module does not directly integrate with NABIDH/Malaffi; payer/contract data may be indirectly referenced by other modules that do integrate with those HIEs.

INT-PCM-001: Billing & Claims

Business Context

What flows

• Outbound (Policy & Contract Mgmt → Billing & Claims)
• Payer master (payers): name, DHA/DOH license, payer class, eClaim routing.
• Insurance plans (insurance_plans): plan codes, network type, coverage level.
• Contracts (contracts): contract type, effective/expiry, payment terms, status.
• Fee schedules (contract_fee_schedules, fee_schedule_items): CPT → rate mappings, modifiers.

• Coverage & prior-auth rules (coverage_rules, prior_auth_rules): medical necessity, frequency limits, auth requirements.

• Inbound (Billing & Claims → Policy & Contract Mgmt)

• Claim-level and line-level payment outcomes: paid amount, allowed amount, denial codes, underpayment flags.
• Aggregated reimbursement metrics (reimbursement_rates): actual vs expected rate, variance, claim counts.

When

• Real-time push when: 1. A contract is activated or amended. 2. A fee schedule is published. 3. A coverage/prior-auth rule is activated/deactivated.

• Daily batch pull: 1. Nightly aggregation of claims performance data for payer scorecards.

Why

• Ensure Billing & Claims always uses current contracted rates and rules, reducing denials and underpayments.
• Feed back actual performance to support renegotiation and KPI tracking (e.g., Average Reimbursement vs. Contracted Rate).

How often

• Config push: real-time, within seconds of approval/publish.
• Performance aggregation: once daily (off-peak, e.g., 02:00 UAE time).

Error impact

• Outbound failure: Billing may use outdated rates/rules, causing:
• Higher denial rates.
• Under/over-charging and reconciliation work.
• Inbound failure: Payer performance dashboards become stale; renegotiation decisions may be based on incomplete data.

Technical Detail

This is an internal integration using:

• REST/JSON APIs for event-driven pushes.
• Shared reporting database views for nightly aggregation.

No HL7 v2 or external FHIR is used here; however, internal FHIR-like JSON structures are recommended for consistency.

Outbound Contract & Fee Schedule Payload (JSON)

{
  "eventType": "CONTRACT_PUBLISHED",
  "eventTime": "2026-02-07T10:15:00+04:00",
  "contract": {
    "contractId": "CON-THIQA-ALNOOR-2026",
    "payerId": 101,
    "payerNameEn": "Daman - Thiqa",
    "facilityId": 10,
    "facilityName": "Al Noor Hospital Abu Dhabi",
    "contractType": "fee-for-service",
    "rateMethodology": "percentage_of_doh_tariff",
    "rateMethodologyDetails": {
      "baseTariff": "DOH-2026",
      "percentage": 1.05
    },
    "effectiveDate": "2026-01-01",
    "expiryDate": "2026-12-31",
    "paymentTermsDays": 30,
    "status": "active",
    "version": 3
  },
  "feeSchedules": [
    {
      "feeScheduleId": 5001,
      "scheduleName": "THIQA-OP-2026",
      "baseTariff": "DOH-2026",
      "effectiveDate": "2026-01-01",
      "expiryDate": "2026-12-31",
      "status": "published",
      "items": [
        {
          "itemId": 900001,
          "cptCode": "99213",
          "description": "Office/outpatient visit est",
          "facilityRate": 350.00,
          "professionalRate": 250.00,
          "modifier": null,
          "rateType": "percentage_of_tariff",
          "tariffCode": "DOH-99213",
          "isActive": true
        }
      ]
    }
  ]
}

Key mappings

Inbound Reimbursement Metrics Payload (JSON)

{
  "eventType": "REIMBURSEMENT_AGGREGATE",
  "periodStart": "2026-01-01",
  "periodEnd": "2026-01-31",
  "payerId": 101,
  "contractId": "CON-THIQA-ALNOOR-2026",
  "lines": [
    {
      "cptCode": "99213",
      "expectedRate": 350.00,
      "actualAvgRate": 343.00,
      "variancePct": -2.0,
      "claimCount": 420
    }
  ]
}

Key mappings

Error Handling

Dead-letter queue can be implemented as pcm_integration_dlq with columns: id, integration_id, payload, error_message, created_at, resolved_by, resolved_at.

Retry and Recovery

Retry Strategy:

Dead Letter Queue:

• Failed outbound config events → pcm_integration_dlq table
• Admin dashboard for manual review, correction, and requeue
• Retention: 30 days active, then archive
• Alert: RCM IT notified on DLQ insertion; Finance Director notified if aggregation job fails

Idempotency:

• Outbound config push deduplication key: [contract_id]_[event_type]_[event_datetime]
• Billing module checks for duplicate contract/fee schedule publications before processing
• Duplicate events return success without reprocessing

Reconciliation:

• Daily: compare PCM active contracts and fee schedules vs Billing module's cached configuration
• Discrepancies flagged for Contract Analyst and IT review
• Weekly: aggregation job success rate and data freshness report
• Monthly: contract-to-billing alignment audit

INT-PCM-002: Patient Access (Eligibility & Estimation)

Business Context

What flows

• Payer and plan master data for selection at registration.
• Contract linkage: which contracts apply to a given facility and payer/plan.
• Coverage rules: age/gender limits, frequency limits, benefit caps.
• Prior-auth rules: which services require auth, method, turnaround.
• Contracted rates: used to estimate patient responsibility (copay, deductible).

When

• At registration or scheduling when staff select payer/plan.
• When an eligibility check or cost estimate is requested for a planned encounter or order.

Why

• Provide accurate eligibility and financial estimates to patients.
• Ensure PDPL-compliant transparency of expected patient financial responsibility.

How often

• Real-time, synchronous API calls from Patient Access UI.

Error impact

• If unavailable, front desk may:
• Fall back to cached data (risk of inaccuracy).
• Delay eligibility verification and estimation.
• Potential patient dissatisfaction and financial risk.

FHIR R4 Technical Detail (Internal API)

Use FHIR-like resources to expose coverage and contract info.

Resource: Coverage (Plan & Contract Link)

{
  "resourceType": "Coverage",
  "id": "COV-THIQA-2026-0001",
  "status": "active",
  "type": {
    "coding": [
      {
        "system": "http://terminology.dha.gov.ae/coverage-type",
        "code": "THIQA",
        "display": "Thiqa Government Scheme"
      }
    ]
  },
  "subscriberId": "784-1985-1234567-1",
  "beneficiary": {
    "reference": "Patient/2026000456",
    "display": "Fatima Al-Nahyan"
  },
  "payor": [
    {
      "identifier": {
        "system": "http://dha.gov.ae/payers",
        "value": "DHA-THIQA"
      },
      "display": "Daman - Thiqa"
    }
  ],
  "class": [
    {
      "type": {
        "coding": [
          {
            "system": "http://terminology.hl7.org/CodeSystem/coverage-class",
            "code": "plan"
          }
        ]
      },
      "value": "THIQA-PLATINUM",
      "name": "Thiqa Platinum"
    },
    {
      "type": {
        "coding": [
          {
            "system": "http://terminology.hl7.org/CodeSystem/coverage-class",
            "code": "subplan"
          }
        ]
      },
      "value": "NETWORK-T1",
      "name": "Tier 1 Network"
    }
  ],
  "network": "Tier 1",
  "contract": [
    {
      "reference": "Contract/CON-THIQA-ALNOOR-2026"
    }
  ],
  "period": {
    "start": "2026-01-01",
    "end": "2026-12-31"
  }
}

Key mappings

Resource: CoverageEligibilityRequest (Estimation Input)

{
  "resourceType": "CoverageEligibilityRequest",
  "id": "ELIG-REQ-20260207-0001",
  "status": "active",
  "purpose": ["benefits"],
  "patient": {
    "reference": "Patient/2026000456"
  },
  "created": "2026-02-07T09:30:00+04:00",
  "insurer": {
    "identifier": {
      "system": "http://dha.gov.ae/payers",
      "value": "DHA-THIQA"
    }
  },
  "provider": {
    "reference": "Organization/AlNoor-AbuDhabi"
  },
  "insurance": [
    {
      "focal": true,
      "coverage": {
        "reference": "Coverage/COV-THIQA-2026-0001"
      }
    }
  ],
  "item": [
    {
      "category": {
        "coding": [
          {
            "system": "http://www.ama-assn.org/go/cpt",
            "code": "99213",
            "display": "Office/outpatient visit est"
          }
        ]
      },
      "productOrService": {
        "coding": [
          {
            "system": "http://www.ama-assn.org/go/cpt",
            "code": "99213"
          }
        ]
      },
      "unitPrice": {
        "value": 350.0,
        "currency": "AED"
      }
    }
  ]
}

Resource: CoverageEligibilityResponse (Estimation Output)

{
  "resourceType": "CoverageEligibilityResponse",
  "id": "ELIG-RESP-20260207-0001",
  "status": "active",
  "purpose": ["benefits"],
  "patient": {
    "reference": "Patient/2026000456"
  },
  "insurer": {
    "identifier": {
      "system": "http://dha.gov.ae/payers",
      "value": "DHA-THIQA"
    }
  },
  "insurance": [
    {
      "coverage": {
        "reference": "Coverage/COV-THIQA-2026-0001"
      },
      "inforce": true,
      "item": [
        {
          "category": {
            "coding": [
              {
                "system": "http://www.ama-assn.org/go/cpt",
                "code": "99213"
              }
            ]
          },
          "benefit": [
            {
              "type": {
                "coding": [
                  {
                    "system": "http://terminology.hl7.org/CodeSystem/benefit-type",
                    "code": "copay"
                  }
                ]
              },
              "allowedMoney": {
                "value": 350.0,
                "currency": "AED"
              },
              "usedMoney": {
                "value": 0.0,
                "currency": "AED"
              }
            }
          ],
          "authorizationRequired": false
        }
      ]
    }
  ]
}

Search parameters

• GET /Coverage?subscriber-id=784-1985-1234567-1
• GET /Coverage?payor-identifier=DHA-THIQA&beneficiary=Patient/2026000456
• GET /CoverageEligibilityRequest?patient=Patient/2026000456&_lastUpdated=ge2026-02-01

Error Handling

Retry and Recovery

Retry Strategy:

Timeout and Circuit Breaker (Synchronous):

• Per-request timeout: 5 seconds (eligibility lookups must not block registration)
• Circuit breaker: opens after 5 consecutive failures within 2 minutes; half-open probe every 30 seconds
• When circuit is open: return cached plan/coverage data (last successful snapshot) with “stale data” flag
• Circuit breaker state changes logged and alerted to IT and Patient Access Supervisor

Idempotency:

• Read-only queries are inherently idempotent; no deduplication key required
• If Patient Access retries the same eligibility lookup, PCM returns the same result without side effects

Reconciliation:

• Nightly comparison of Patient Access cached payer/plan data vs PCM master to identify stale cache entries
• Any discrepancies flagged in integration dashboard for Contract Analyst review
• Cache TTL: 24 hours for plan/coverage rules; 1 hour for fee schedule lookups

INT-PCM-003: Denial Analysis

Business Context

What flows

• Outbound:
• Contract terms, fee schedules, coverage/prior-auth rules for context.
• Inbound:
• Denial statistics by payer/contract/CPT.
• Underpayment flags and root causes (e.g., non-covered service, invalid auth).

When

• Nightly batch to refresh analytics mart.
• On-demand when a contract review is initiated (to pull latest denial patterns).

Why

• Support workflows WF-PCM-005 and WF-PCM-006 (Contract Renewal / Payer Performance Monitoring).
• Identify contracts with high denial rates or underpayments for renegotiation.

How often

• Daily batch; on-demand API for drill-down.

Error impact

• Analytics dashboards may be stale; no direct impact on operational billing.

Technical Detail

Internal ETL / DB views; no HL7/FHIR.

Example outbound contract context record (JSON):

{
  "contractId": "CON-OMAN-ALNOOR-2026",
  "payerId": 205,
  "payerNameEn": "Oman Insurance",
  "facilityId": 10,
  "contractType": "percentage_of_tariff",
  "rateMethodology": "percentage_of_dha_tariff",
  "paymentTermsDays": 45,
  "effectiveDate": "2026-01-01",
  "expiryDate": "2026-12-31",
  "coverageRulesCount": 120,
  "priorAuthRulesCount": 35
}

Inbound denial pattern record:

{
  "contractId": "CON-OMAN-ALNOOR-2026",
  "periodStart": "2026-01-01",
  "periodEnd": "2026-01-31",
  "payerId": 205,
  "denialRatePct": 12.5,
  "topDenialReasons": [
    {
      "code": "CO-50",
      "description": "Non-covered service",
      "count": 85
    },
    {
      "code": "CO-197",
      "description": "Precertification/authorization absent",
      "count": 60
    }
  ],
  "underpaymentCases": 45
}

Error Handling

• ETL job failures logged with job ID and timestamp.
• Auto-retry once after 30 minutes.
• If still failing, alert analytics team; dashboards show “data as of” timestamp so users know last successful refresh.

Retry and Recovery

Retry Strategy:

Dead Letter Queue:

• Failed ETL batch records → pcm_etl_dlq table with job_id, batch_date, error_message, payload_summary
• Admin dashboard for analytics team to inspect, fix, and rerun individual batches
• Retention: 60 days active, then archive

Idempotency:

• ETL jobs keyed by [job_type]_[batch_date]; re-running same batch overwrites (upsert) rather than duplicating
• On-demand drill-down queries are read-only and inherently idempotent

Reconciliation:

• Daily: verify that denial analytics mart has data for all active contracts; flag contracts with missing data
• Weekly: cross-check denial counts between Billing & Claims source and analytics mart totals
• Monthly: analytics team reviews data freshness and completeness report

INT-PCM-004: DHA eClaimLink (Dubai)

Business Context

What flows

• Payer connectivity configuration:
• eClaimLink payer codes, submission endpoints, encryption keys.
• Eligibility queries:
• Patient, payer, plan, and service details → eligibility response.
• Prior authorization:
• Requests for services requiring auth; responses with auth numbers, status, validity.

When

• During payer onboarding (configure payer code and connectivity).
• At registration/scheduling when eligibility is checked for Dubai-based encounters.
• When services requiring prior auth are ordered or scheduled.

Why

• Comply with DHA eClaimLink requirements for electronic eligibility and prior auth.
• Reduce claim denials due to missing or invalid authorization.

How often

• On-demand, synchronous calls.

Error impact

• If eligibility fails: staff may proceed at risk or delay service.
• If prior auth fails: claims may be denied; clinical services may be delayed.

Technical Detail (DHA eClaimLink REST)

This integration uses DHA-defined XML/JSON schemas over HTTPS. Below is a conceptual example; actual schemas must follow eClaimLink specifications.

Eligibility Request (XML)

<EligibilityRequest>
  <Header>
    <SenderID>ALNOOR_DUBAI</SenderID>
    <ReceiverID>DHA_ECLAIMLINK</ReceiverID>
    <TransactionDate>2026-02-07T09:45:00+04:00</TransactionDate>
    <TransactionID>ELIG-ALNOOR-20260207-0001</TransactionID>
  </Header>
  <Patient>
    <EmiratesID>784-1985-1234567-1</EmiratesID>
    <FirstName>Ahmed</FirstName>
    <LastName>Al-Maktoum</LastName>
    <DOB>1985-03-15</DOB>
    <Gender>M</Gender>
  </Patient>
  <Payer>
    <PayerCode>DHA-OMAN</PayerCode>
    <CardNumber>OMN-123456789</CardNumber>
    <PolicyNumber>POL-2026-0001</PolicyNumber>
  </Payer>
  <Provider>
    <FacilityLicense>DHA-FAC-12345</FacilityLicense>
  </Provider>
  <Service>
    <CPTCode>99213</CPTCode>
    <ServiceDate>2026-02-08</ServiceDate>
  </Service>
</EligibilityRequest>

Eligibility Response (XML)

<EligibilityResponse>
  <Header>
    <TransactionID>ELIG-ALNOOR-20260207-0001</TransactionID>
    <Status>ACCEPTED</Status>
    <ResponseDate>2026-02-07T09:45:05+04:00</ResponseDate>
  </Header>
  <Eligibility>
    <CoverageStatus>ACTIVE</CoverageStatus>
    <PlanCode>OMAN-GOLD</PlanCode>
    <NetworkTier>Tier 1</NetworkTier>
    <CopayPercentage>20</CopayPercentage>
    <DeductibleRemaining>500.00</DeductibleRemaining>
    <AuthorizationRequired>false</AuthorizationRequired>
  </Eligibility>
</EligibilityResponse>

Key mappings

Prior Authorization Request (JSON)

{
  "transactionId": "AUTH-ALNOOR-20260207-0001",
  "patient": {
    "emiratesId": "784-1990-7654321-2",
    "firstName": "Fatima",
    "lastName": "Al-Nahyan",
    "dob": "1990-06-10",
    "gender": "F"
  },
  "payer": {
    "payerCode": "DHA-OMAN",
    "cardNumber": "OMN-987654321",
    "policyNumber": "POL-2026-0100"
  },
  "provider": {
    "facilityLicense": "DHA-FAC-12345"
  },
  "services": [
    {
      "cptCode": "70450",
      "description": "CT head without contrast",
      "icd10Code": "S06.0",
      "requestedDate": "2026-02-09",
      "estimatedCost": 1200.0
    }
  ]
}

Response will include authorizationNumber, status (approved/denied/pending), validFrom, validTo.

Error Handling

All requests/responses must be stored for audit (DHA requirements) with timestamps and user IDs.

Retry and Recovery

Retry Strategy:

Dead Letter Queue:

• Failed eligibility/auth requests after max retries → pcm_eclaim_dlq table
• Fields: dlq_id, integration_id = 'INT-PCM-004', transaction_id, request_type (eligibility/auth), payload, error_code, error_message, created_at, resolved_by, resolved_at
• Admin dashboard for Utilization Management and IT to review, correct, and resubmit
• Retention: 90 days (per DHA audit requirements), then archive

Idempotency:

• Deduplication key: [transaction_id] (system-generated unique per request)
• If retry sends same transaction_id, eClaimLink should return existing response
• PCM stores transaction_id in eligibility_checks / prior_auth_requests to prevent duplicate submissions

Reconciliation:

• Daily: compare PCM-submitted eligibility/auth requests vs eClaimLink acknowledgements; flag unresolved transactions
• Weekly: review DLQ entries and offline-mode events; ensure all pending items resolved or escalated
• Monthly: audit log review per DHA requirements; certificate expiry monitoring (alert 30 days before expiry)

INT-PCM-005: DOH eClaims / Shafafiya (Abu Dhabi)

Business Context

Similar to DHA eClaimLink but for Abu Dhabi DOH eClaims (Shafafiya).

What flows

• Payer connectivity configuration (Shafafiya payer codes).
• Eligibility checks and prior-auth requests/responses for Abu Dhabi encounters.

When / Why / How often

• Same patterns as INT-PCM-004, but using DOH-specific schemas and endpoints.

Error impact

• Same as DHA: risk of denials and service delays.

Technical Detail (DOH eClaims)

DOH eClaims uses XML over HTTPS; some implementations use SOAP.

Eligibility Request (XML – conceptual)

<eClaim>
  <Header>
    <SenderID>ALNOOR_ABUDHABI</SenderID>
    <ReceiverID>DOH_ECLAIMS</ReceiverID>
    <TransactionID>ELIG-ALNOOR-20260207-ABU-0001</TransactionID>
    <TransactionDate>2026-02-07T10:00:00+04:00</TransactionDate>
  </Header>
  <Eligibility>
    <Patient>
      <EmiratesID>784-1982-1122334-3</EmiratesID>
      <FirstName>Mohammed</FirstName>
      <LastName>Al-Falahi</LastName>
      <DOB>1982-11-20</DOB>
      <Gender>M</Gender>
    </Patient>
    <Payer>
      <PayerCode>DOH-THIQA</PayerCode>
      <CardNumber>THQ-44556677</CardNumber>
    </Payer>
    <Provider>
      <FacilityLicense>DOH-FAC-56789</FacilityLicense>
    </Provider>
    <Service>
      <CPTCode>99214</CPTCode>
      <ServiceDate>2026-02-08</ServiceDate>
    </Service>
  </Eligibility>
</eClaim>

Response will include coverage status, plan, network, copay, and whether prior auth is required.

Error Handling

Same patterns as INT-PCM-004, with separate monitoring because DOH and DHA endpoints are independent.

• Separate configuration for timeouts and retry limits per regulator.
• Separate audit logs to support DOH audits and ADHICS compliance.

Retry and Recovery

Retry Strategy:

Dead Letter Queue:

• Failed eligibility/auth requests after max retries → pcm_eclaim_dlq table (shared with INT-PCM-004, distinguished by integration_id = 'INT-PCM-005')
• Fields: same schema as INT-PCM-004 DLQ
• Admin dashboard for Utilization Management and IT to review, correct, and resubmit
• Retention: 90 days (per DOH audit and ADHICS requirements), then archive

Idempotency:

• Deduplication key: [transaction_id] (system-generated unique per request)
• If retry sends same transaction_id, DOH eClaims should return existing response
• PCM stores transaction_id in eligibility_checks / prior_auth_requests to prevent duplicate submissions

Reconciliation:

• Daily: compare PCM-submitted eligibility/auth requests vs DOH eClaims acknowledgements; flag unresolved transactions
• Weekly: review DLQ entries and offline-mode events; ensure all pending items resolved or escalated
• Monthly: audit log review per DOH/ADHICS requirements; certificate expiry monitoring (alert 30 days before expiry)
• Separate reconciliation dashboards for DOH and DHA to allow independent monitoring

INT-PCM-006: CPOE (Coverage & Prior Auth Decision Support)

Business Context

What flows

• From Policy & Contract Mgmt to CPOE:
• Coverage rules for ordered CPT/ICD combinations.
• Prior-auth requirements by payer/plan/service category.
• Benefit limits (annual/visit caps).
• Contracted rates for cost display (if enabled).

When

• When a provider signs an order in CPOE that is billable and associated with a payer/plan.

Why

• Provide real-time decision support:
• Indicate if service is covered.
• Indicate if prior auth is required.
• Warn about benefit limits (e.g., visit cap reached).
• Reduce denials and improve provider awareness of payer rules.

How often

• Real-time, synchronous API call from CPOE to Policy & Contract Mgmt.

Error impact

• If unavailable, CPOE may:
• Proceed without coverage checks (configurable).
• Show a warning that coverage/prior-auth status is unknown.

FHIR R4 Technical Detail

Use a custom FHIR Operation on a Coverage-like service, returning a Bundle with rule evaluation.

Request: $coverage-check (Operation)

POST /pcm-fhir/$coverage-check

{
  "resourceType": "Parameters",
  "parameter": [
    {
      "name": "patient",
      "valueReference": {
        "reference": "Patient/2026000456"
      }
    },
    {
      "name": "payerId",
      "valueInteger": 205
    },
    {
      "name": "planCode",
      "valueString": "OMAN-GOLD"
    },
    {
      "name": "service",
      "part": [
        {
          "name": "cpt",
          "valueString": "70450"
        },
        {
          "name": "icd10",
          "valueString": "S06.0"
        },
        {
          "name": "serviceDate",
          "valueDate": "2026-02-09"
        },
        {
          "name": "age",
          "valueInteger": 36
        },
        {
          "name": "gender",
          "valueString": "M"
        }
      ]
    }
  ]
}

Response: Bundle with Coverage Decision

{
  "resourceType": "Bundle",
  "type": "collection",
  "entry": [
    {
      "resource": {
        "resourceType": "CoverageEligibilityResponse",
        "id": "COVCHK-20260207-0001",
        "status": "active",
        "purpose": ["validation"],
        "patient": {
          "reference": "Patient/2026000456"
        },
        "insurer": {
          "identifier": {
            "system": "http://doh.gov.ae/payers",
            "value": "DOH-OMAN"
          }
        },
        "insurance": [
          {
            "inforce": true,
            "item": [
              {
                "productOrService": {
                  "coding": [
                    {
                      "system": "http://www.ama-assn.org/go/cpt",
                      "code": "70450"
                    }
                  ]
                },
                "authorizationRequired": true,
                "authorizationSupporting": [
                  {
                    "coding": [
                      {
                        "system": "http://terminology.hl7.org/CodeSystem/coverageeligibilityresponse-ex-auth-support",
                        "code": "diagnosis"
                      }
                    ],
                    "text": "Head trauma (S06.0) required"
                  }
                ],
                "benefit": [
                  {
                    "type": {
                      "coding": [
                        {
                          "system": "http://terminology.hl7.org/CodeSystem/benefit-type",
                          "code": "visit"
                        }
                      ]
                    },
                    "allowedUnsignedInt": 3,
                    "usedUnsignedInt": 2
                  }
                ]
              }
            ]
          }
        ]
      }
    },
    {
      "resource": {
        "resourceType": "Observation",
        "id": "PCM-RULE-EVAL-70450",
        "status": "final",
        "code": {
          "coding": [
            {
              "system": "http://snomed.info/sct",
              "code": "710818004",
              "display": "Coverage decision"
            }
          ]
        },
        "valueCodeableConcept": {
          "coding": [
            {
              "system": "http://terminology.hl7.org/CodeSystem/v3-ActCode",
              "code": "COVAUTH",
              "display": "Covered with authorization"
            }
          ]
        },
        "note": [
          {
            "text": "Prior authorization required for CPT 70450 under OMAN-GOLD. Visits used: 2/3 this year."
          }
        ]
      }
    }
  ]
}

Key mappings

Search / Operation

• POST /pcm-fhir/$coverage-check (operation)
• GET /CoverageEligibilityResponse?patient=Patient/2026000456&insurer.identifier=DOH-OMAN&_lastUpdated=ge2026-01-01

Error Handling

Retry and Recovery

Retry Strategy:

Timeout and Circuit Breaker (Synchronous):

• Per-request timeout: 3 seconds (must not block provider order signing workflow)
• Circuit breaker: opens after 3 consecutive failures within 1 minute; half-open probe every 20 seconds
• When circuit is open: CPOE proceeds without coverage check, displaying “Coverage check unavailable — order will proceed without financial validation”
• Configurable per facility: hard stop (block order) vs soft stop (warn only) when coverage check is unavailable
• Circuit breaker state changes logged and alerted to IT and RCM team

Idempotency:

• Coverage check requests are read-only queries; inherently idempotent
• Same request parameters always return the same rule evaluation result (no side effects)

Reconciliation:

• Daily: audit log of coverage check calls vs orders placed; flag orders that proceeded without successful coverage check
• Weekly: report of circuit breaker activations and average response times
• Monthly: review of “coverage unknown” orders vs actual claim outcomes to assess impact

NABIDH / Malaffi Integration

The Policy & Contract Management module does not directly exchange data with NABIDH (Dubai) or Malaffi (Abu Dhabi). However:

• Other modules (e.g., Billing & Claims, CPOE) that integrate with NABIDH/Malaffi may reference:
• payers (for payer identification in billing context).
• contracts (for internal financial context; not typically transmitted to HIEs).

Compliance considerations:

• Ensure that any payer/contract identifiers included in HIE messages (if ever required by local profiles) do not expose confidential financial terms.
• UAE PDPL: contract financial details are considered sensitive business data; sharing with HIEs should be avoided unless mandated by MOH/DOH/DHA.

Authentication & Security

All integrations must comply with:

• UAE PDPL (Federal Decree-Law No. 45/2021) for personal data protection.
• ADHICS (for Abu Dhabi) and DHA security guidelines (for Dubai).
• TDRA/NESA cybersecurity standards.

Internal APIs (INT-PCM-001, 002, 003, 006)

• Transport: HTTPS (TLS 1.2+), internal network.
• Auth:
• Internal service tokens (JWT) with:
  • iss = HIS integration gateway.
  • aud = target module.
  • scope = e.g., pcm.read, pcm.write.
• Role-based access control enforced at API gateway and module level.
• Encryption at rest:
• Sensitive fields (e.g., payer connectivity secrets) encrypted in DB using AES-256.

External Regulators (INT-PCM-004, 005)

• mTLS:
• Client certificates issued per facility and per regulator (DHA/DOH).
• Certificate rotation procedures documented; expiry monitored.
• OAuth 2.0 / Token-based:
• Where supported by DHA/DOH, use client-credentials flow:
  • client_id / client_secret stored securely (HSM or secrets manager).
  • Short-lived access tokens (e.g., 15–60 minutes).
• Message encryption:
• All traffic over HTTPS.
• No PHI in logs; only transaction IDs and high-level status.
• Audit logging:
• Log every eligibility/prior-auth request/response with:
  • Timestamp.
  • User ID / system account.
  • Payer code.
  • Outcome (success/failure).
• Retention per MOH/DOH/DHA requirements.

Error Handling & Monitoring (Cross-cutting)

• Centralized monitoring dashboard:
• Per-integration success/failure rates.
• Latency metrics.
• Alert thresholds:

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

• No successful calls for >10 minutes during business hours.
• Dead letter queues:
• For all outbound messages to external regulators.
• Manual reprocessing UI with:
  • View payload (masked).
  • Edit (where allowed).
  • Resubmit.

All designs must be reviewed by the facility’s Data Protection Officer to ensure PDPL compliance, especially regarding cross-border data flows and retention periods.