Patient Access Integration Specifications

Integration Summary

Note: Patient Access does not directly integrate with NABIDH/Malaffi, but must remain consistent with HIE-shared demographics and coverage data coming via EHR.

INT-PAC-001: eClaimLink (DHA Dubai)

Business Context

What flows

• Outbound eligibility request:
• Patient identifiers (MRN, Emirates ID), demographics (name, DOB, gender)
• Insurance details (payer, plan, member ID, policy number, card number)
• Encounter context (facility, department, service date, visit type)
• Inbound eligibility response:
• Coverage status (active/inactive, effective/termination dates)
• Benefit details (co-pay, coinsurance, deductible, annual max)
• Network status, product type, plan limitations
• Outbound prior authorization request:
• Patient and payer details as above
• Service details (CPT codes, ICD-10-AM diagnoses, requested dates, units)
• Referring/requesting provider details
• Inbound prior authorization response:
• Authorization number, status, validity dates, approved units
• Denial reasons, additional info requests

When

• At registration or appointment booking when payer is DHA-regulated and uses eClaimLink.
• At check-in if last eligibility check > 72 hours old.
• When a service requiring prior auth is ordered for a Dubai-based encounter.

Why

• To ensure real-time financial clearance and reduce denials for Dubai encounters.
• To comply with DHA eClaimLink requirements for electronic eligibility and auth.

How often

• Real-time per transaction; volume-driven by outpatient visits and scheduled procedures.

Error impact

• Eligibility failures: encounter may be placed on financial hold; manual phone/fax verification required; increased risk of denials.
• Auth failures: high-cost procedures may be delayed or performed at financial risk; potential non-payment.

Technical Detail (Non-HL7 REST / XML/JSON)

DHA eClaimLink uses its own schemas (e.g., XML/JSON) rather than HL7 v2.5.1. Patient Access must:

• Map internal tables:
• eligibility_checks → eClaimLink eligibility request
• eligibility_responses → parsed eClaimLink response
• prior_authorizations, prior_auth_requests → auth requests/responses
• Include UAE-specific identifiers:
• Emirates ID in patient segment
• DHA facility ID, payer IDs as per eClaimLink registry

Example Eligibility Request Payload (JSON – conceptual)

{
  "transactionType": "ELIGIBILITY",
  "facility": {
    "id": "DHA-FAC-001",
    "name": "Dubai Creek Hospital"
  },
  "patient": {
    "mrn": "MRN-2026-000123",
    "emiratesId": "784-1985-1234567-1",
    "firstName": "Ahmed",
    "lastName": "Al-Maktoum",
    "dateOfBirth": "1985-03-15",
    "gender": "M"
  },
  "insurance": {
    "payerId": "PAYER-DHA-OMAN",
    "planCode": "OMN-GOLD",
    "memberId": "OMN123456789",
    "cardNumber": "CARD987654321",
    "policyNumber": "POL-2026-0001"
  },
  "encounter": {
    "encounterId": "ENC-2026-000567",
    "visitType": "OPD",
    "serviceDate": "2026-02-07"
  }
}

Example Eligibility Response Payload (JSON – conceptual)

{
  "transactionId": "ELG-20260207-0001",
  "status": "SUCCESS",
  "eligibility": {
    "isEligible": true,
    "effectiveDate": "2025-01-01",
    "terminationDate": "2026-12-31",
    "productType": "Enhanced",
    "networkStatus": "IN_NETWORK"
  },
  "benefits": {
    "copayAmount": 50.0,
    "copayPercentage": 20.0,
    "deductibleTotal": 2000.0,
    "deductibleMet": 1200.0,
    "coinsurance": 10.0,
    "annualMax": 50000.0,
    "annualMaxRemaining": 38000.0
  },
  "payerResponseCode": "ELG-APPROVED"
}

Key Field Mapping (Eligibility)

Key Field Mapping (Prior Auth)

HL7 v2.5.1 Technical Detail

Not applicable: eClaimLink does not use HL7 v2.5.1 for eligibility/auth. No HL7 messages are exchanged in this integration.

FHIR R4 Technical Detail

Not applicable: eClaimLink uses its own schemas, not FHIR. Internal mapping to FHIR is only used for Patient Portal (INT-PAC-008).

Error Handling

Dead Letter Queue

• Failed requests after max retries are stored in integration_dlq with:
• integration_id = 'INT-PAC-001'
• payload, error_code, error_message, last_attempt_at
• Dashboard for interface team to reprocess or close.

Manual Recovery

• Patient Access Supervisor can:
• Re-trigger eligibility/auth from Eligibility Verification screen.
• Override holds with documented reason (logged for audit).
• Interface team can:
• Edit malformed payloads and replay from DLQ.

Retry and Recovery

Retry Strategy:

Dead Letter Queue:

• Failed requests after max retries → integration_dlq table with integration_id = 'INT-PAC-001'
• Fields: dlq_id, payload, error_code, error_message, last_attempt_at, resolved_by, resolved_at
• Dashboard for interface team to inspect, edit malformed payloads, and replay
• Retention: 90 days (per DHA audit requirements), then archive

Idempotency:

• Deduplication key: [transaction_type]_[facility_id]_[patient_mrn]_[service_date]_[check_datetime]
• Duplicate eClaimLink transactions (same transactionId) update existing eligibility_responses record rather than creating duplicates
• Auth requests use system-generated transactionId stored in prior_auth_requests.request_id

Reconciliation:

• Daily: compare submitted eligibility/auth requests vs eClaimLink acknowledgements; flag unresolved transactions older than 24 hours
• Weekly: review DLQ entries; ensure all failed items resolved or escalated
• Monthly: audit log review per DHA requirements; certificate expiry check (alert 30 days before)

INT-PAC-002: DOH eClaims (Shafafiya)

Business Context

What flows

Similar to INT-PAC-001 but for Abu Dhabi encounters:

• Eligibility requests/responses via DOH eClaims/Shafafiya.
• Prior auth requests/responses with DOH-specific codes and reference numbers.

When

• For encounters at Abu Dhabi facilities or with DOH-regulated payers.
• At registration, booking, check-in, and when auth-required services are ordered.

Why

• To comply with DOH eClaims requirements and reduce denials for Abu Dhabi encounters.

How often

• Real-time per transaction.

Error impact

• Same as INT-PAC-001, but may also impact DOH reporting and Shafafiya compliance.

Technical Detail (Non-HL7 REST / XML)

DOH eClaims uses its own XML/JSON schemas. Mapping is analogous to eClaimLink, but with DOH-specific identifiers:

• DOH facility code, payer codes.
• Shafafiya transaction IDs.

Example Eligibility Request (XML – conceptual)

<EligibilityRequest>
  <Header>
    <FacilityId>DOH-FAC-001</FacilityId>
    <TransactionDate>2026-02-07T10:15:00+04:00</TransactionDate>
  </Header>
  <Patient>
    <MRN>MRN-2026-000789</MRN>
    <EmiratesId>784-1990-7654321-3</EmiratesId>
    <FirstName>Fatima</FirstName>
    <LastName>Al-Nahyan</LastName>
    <DateOfBirth>1990-07-21</DateOfBirth>
    <Gender>F</Gender>
  </Patient>
  <Insurance>
    <PayerCode>THIQA</PayerCode>
    <PlanCode>THQ-STD</PlanCode>
    <MemberId>THQ99887766</MemberId>
  </Insurance>
  <Encounter>
    <EncounterId>ENC-2026-001234</EncounterId>
    <VisitType>OPD</VisitType>
    <ServiceDate>2026-02-08</ServiceDate>
  </Encounter>
</EligibilityRequest>

Example Eligibility Response (XML – conceptual)

<EligibilityResponse>
  <TransactionId>ELG-DOH-20260207-0005</TransactionId>
  <Status>APPROVED</Status>
  <Eligibility>
    <IsEligible>true</IsEligible>
    <EffectiveDate>2025-01-01</EffectiveDate>
    <TerminationDate>2026-12-31</TerminationDate>
  </Eligibility>
  <Benefits>
    <CopayAmount>40.00</CopayAmount>
    <CopayPercentage>10</CopayPercentage>
    <DeductibleTotal>1500.00</DeductibleTotal>
    <DeductibleMet>500.00</DeductibleMet>
    <Coinsurance>20</Coinsurance>
    <AnnualMax>60000.00</AnnualMax>
    <AnnualMaxRemaining>52000.00</AnnualMaxRemaining>
  </Benefits>
  <PayerResponseCode>APPROVED</PayerResponseCode>
</EligibilityResponse>

Mapping to HIS tables is the same as INT-PAC-001.

HL7 v2.5.1 Technical Detail

Not applicable: DOH eClaims does not use HL7 v2.5.1 for eligibility/auth.

FHIR R4 Technical Detail

Not applicable for this external integration.

Error Handling

Same pattern as INT-PAC-001, with DOH-specific logging:

• Include doh_transaction_id in logs and eligibility_checks.request_source = 'DOH_ECLAIMS'.
• Alert routed to DOH-facing RCM team.

Retry and Recovery

Retry Strategy:

Dead Letter Queue:

• Failed requests after max retries → integration_dlq table with integration_id = 'INT-PAC-002'
• Same schema as INT-PAC-001 DLQ; distinguished by integration_id
• Retention: 90 days (per DOH audit and ADHICS requirements), then archive

Idempotency:

• Deduplication key: [transaction_id] (system-generated, stored in eligibility_checks / prior_auth_requests)
• Duplicate DOH eClaims transactions update existing records rather than creating duplicates
• Separate transaction_id namespace from INT-PAC-001 to avoid cross-regulator collisions

Reconciliation:

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

INT-PAC-003: EHR & Patient Management

Business Context

What flows

• Inbound from EHR:
• Patient demographics (from patients, patient_demographics)
• Insurance coverage (from insurance_plans, patient coverage tables)
• Encounter context (from encounters)
• Outbound to EHR:
• Eligibility results (status, dates, benefits summary)
• Financial clearance status per encounter
• Prior auth numbers and statuses
• Referral status (if required for visit)

When

• On patient registration or update in EHR.
• When eligibility is verified or re-verified.
• When prior auth or referral status changes.

Why

• To keep clinical systems aware of financial clearance, enabling holds or warnings at order entry and check-in.
• To avoid duplicate data entry.

How often

• Real-time, event-driven.

Error impact

• If inbound fails: Patient Access may work with outdated demographics/coverage, increasing eligibility failures.
• If outbound fails: EHR may not show correct financial clearance; services may proceed without auth.

HL7 v2.5.1 Technical Detail

Some EHRs may use HL7 ADT messages internally. Patient Access must be able to consume ADT^A08 (update) messages for insurance changes.

Message Type: ADT^A08 (Update Patient Information)

MSH|^~\&|EHR|DUBAI_CREEK_HOSP|HIS_PATACCESS|DUBAI_CREEK_HOSP|20260207103000||ADT^A08|MSG20260207103000001|P|2.5.1|||AL|NE||UTF-8
EVN|A08|20260207102930|||USR123^ALI^OMAR
PID|1||MRN-2026-000123^^^DUBAI_CREEK_HOSP^MR~784-1985-1234567-1^^^UAE^EID||AL-MAKTOUM^AHMED^M||19850315|M|||PO BOX 12345^^DUBAI^^00000^AE||+971501234567
PV1|1|O|OPD^CLINIC1^RM01^DUBAI_CREEK_HOSP||||KHAN^SARA^A^^^DR|||MED||||||||ENC-2026-000567
IN1|1|PAYER-DHA-OMAN|OMN-GOLD^Oman Insurance Gold^LOCAL|Oman Insurance||PO BOX 1234^^DUBAI^^00000^AE|+97142000000|||AL-MAKTOUM^AHMED^M|784-1985-1234567-1|19850315|M|||CARD987654321|GRP-001|20250101|20261231||||||||||||||||||OMN123456789

Key Segment Mapping

Patient Access uses this to update or create eligibility_checks records when insurance changes.

FHIR R4 Technical Detail

Not required for this internal integration; EHR–Patient Access may use internal REST with JSON, but not necessarily FHIR.

Error Handling

Dead letter and manual recovery as per INT-PAC-001.

Retry and Recovery

Retry Strategy:

Dead Letter Queue:

• Failed inbound HL7 messages → integration_dlq with integration_id = 'INT-PAC-003'
• Failed outbound clearance updates → pac_outbound_dlq table
• Interface team dashboard for manual inspection, correction, and replay
• Retention: 30 days active, then archive

Idempotency:

• Inbound ADT messages: deduplication key = MSH-10 (Message Control ID); duplicate messages logged and discarded
• Outbound clearance updates: deduplication key = [encounter_id]_[update_type]_[timestamp]; EHR ignores duplicate updates for same encounter and status

Reconciliation:

• Daily: compare Patient Access patient/insurance records vs EHR master; flag discrepancies
• Weekly: review DLQ entries for both inbound and outbound queues
• Monthly: full patient demographics reconciliation report for data quality review

INT-PAC-004: Scheduling

Business Context

What flows

• Inbound from Scheduling:
• Appointment details (date/time, department, provider, visit type)
• Appointment status (booked, rescheduled, cancelled, checked-in)
• Outbound to Scheduling:
• Pre-registration status (complete/incomplete, missing items)
• Financial clearance flags (eligibility verified, auth obtained, referral valid)
• Cost estimate availability

When

• When appointments are created/updated.
• When pre-registration or financial clearance status changes.

Why

• To drive pre-registration worklists and ensure patients are financially cleared before arrival.

How often

• Real-time.

Error impact

• If inbound fails: Patient Access may not see upcoming appointments → missed pre-reg.
• If outbound fails: Scheduling staff may book or check-in patients without seeing holds.

HL7 v2.5.1 Technical Detail

Not typically HL7-based internally; use internal APIs. No HL7 messages required.

FHIR R4 Technical Detail

Not required; internal JSON structures are sufficient.

Error Handling

• Same retry/backoff and DLQ pattern as INT-PAC-003.
• If outbound clearance update fails, Scheduling UI shows last-known status with “Sync error” indicator.

Retry and Recovery

Retry Strategy:

Dead Letter Queue:

• Failed outbound status updates → integration_dlq with integration_id = 'INT-PAC-004'
• Same DLQ schema as other internal integrations
• Retention: 30 days active, then archive

Idempotency:

• Inbound appointment events: deduplication key = [appointment_id]_[event_type]_[event_timestamp]
• Outbound pre-reg status updates: deduplication key = [appointment_id]_[prereg_status]_[update_timestamp]; Scheduling ignores duplicate updates

Reconciliation:

• Daily: compare Patient Access pre-registration records vs Scheduling appointment list; flag appointments missing pre-reg records
• Weekly: review sync error indicators in Scheduling UI; resolve outstanding discrepancies
• Monthly: pre-registration coverage rate report (appointments with vs without pre-reg)

INT-PAC-005: Billing & Claims

Business Context

What flows

• Outbound from Patient Access:
• Eligibility details (payer, plan, coverage dates, benefits summary) linked to encounter.
• Prior auth numbers and statuses for claims.
• Co-pay amounts collected at point of service.
• Cost estimate details (for variance analysis).
• Inbound from Billing:
• Patient account balances and payment history (for financial counseling).
• Claim status and denial reasons (especially “no_auth” denials for KPI tracking).

When

• Immediately after eligibility verification and auth approval.
• When claims are generated or updated.
• When financial counseling sessions are recorded.

Why

• To ensure claims include required auth numbers and accurate coverage info.
• To support financial counseling and KPI reporting.

How often

• Real-time.

Error impact

• Missing auth numbers on claims → denials.
• Outdated balances → poor counseling decisions.

HL7 v2.5.1 Technical Detail

Some billing systems may use DFT^P03 for financial transactions, but for this HIS, internal APIs are preferred. No external HL7 required here.

FHIR R4 Technical Detail

Not required; internal JSON.

Error Handling

• Same pattern as INT-PAC-003.
• If auth number fails to sync to Billing:
• Billing UI shows “Auth info missing – refresh from Patient Access”.
• Background job retries every 10 minutes until success or encounter closed.

Retry and Recovery

Retry Strategy:

Dead Letter Queue:

• Failed outbound eligibility/auth/co-pay updates → integration_dlq with integration_id = 'INT-PAC-005'
• Priority flag for auth number sync failures (directly impacts claim submission)
• Retention: 30 days active, then archive

Idempotency:

• Outbound eligibility updates: deduplication key = [encounter_id]_[eligibility_check_id]
• Outbound auth number updates: deduplication key = [encounter_id]_[auth_id]_[auth_status]
• Billing module checks for existing records before creating duplicates

Reconciliation:

• Daily: compare Patient Access auth records vs Billing claims; flag claims missing auth numbers
• Weekly: review “Auth info missing” indicators in Billing UI; resolve outstanding sync failures
• Monthly: denial analysis — track “no_auth” denials and correlate with sync failures for root cause analysis

INT-PAC-006: Policy & Contract Management

Business Context

What flows

• Inbound to Patient Access:
• Payer and plan master data (names, IDs, product types).
• Coverage rules (which services require auth, referral, or have special limits).
• Fee schedules and contracted rates (for cost estimation).
• Financial assistance program rules.

When

• At runtime when:
• Eligibility is checked (to know which endpoint to call).
• Prior auth determination is needed.
• Cost estimates are generated.
• Also via periodic sync (e.g., nightly) for master data updates.

Why

• To centralize payer rules and avoid hardcoding in Patient Access.
• To keep cost estimates aligned with current contracts.

How often

• Real-time lookups + scheduled batch refresh.

Error impact

• If unavailable: Patient Access may:
• Fail to identify auth requirements → denials.
• Use outdated rates → inaccurate estimates.

HL7 v2.5.1 / FHIR R4 Technical Detail

Not applicable; internal master data APIs/DB views only.

Error Handling

• If master data API unavailable:
• Use cached rules (last successful snapshot) with timestamp.
• Display banner “Payer rules may be outdated” to Patient Access Manager.
• If cache older than configured threshold (e.g., 7 days):
• Block new cost estimates for affected payer until resolved or override by Manager.

Retry and Recovery

Retry Strategy:

Timeout and Circuit Breaker (Synchronous):

• Per-request timeout: 5 seconds (must not block eligibility or estimation workflows)
• Circuit breaker: opens after 5 consecutive failures within 2 minutes; half-open probe every 30 seconds
• When circuit is open: use cached payer/plan/coverage data with “stale data” warning banner
• If cache older than 7 days: block cost estimates for affected payer; allow eligibility checks to proceed with warning
• Circuit breaker state changes logged and alerted to IT

Idempotency:

• Read-only lookups are inherently idempotent; no deduplication required
• Nightly batch sync uses upsert logic: [payer_id]_[plan_id]_[rule_id] as natural key

Reconciliation:

• Daily: verify Patient Access cached payer/plan/coverage data matches PCM master; flag discrepancies
• Weekly: review batch sync success rates and data freshness
• Monthly: full cache vs master data audit; report on stale cache incidents and their impact on estimates

INT-PAC-007: CPOE

Business Context

What flows

• Inbound from CPOE:
• Orders that may require prior auth or referral (e.g., high-cost imaging, procedures).
• Clinical details needed for auth (diagnoses, indications, sometimes lab results).
• Outbound to CPOE:
• Auth status and numbers for each order.
• Referral status (valid/expired, visits remaining).
• Messages for clinicians when auth is denied or peer review is needed.

When

• When an order is placed or modified.
• When auth/referral status changes.

Why

• To prevent ordering services that will not be reimbursed.
• To support clinicians with real-time financial information.

How often

• Real-time.

Error impact

• If inbound fails: Patient Access may not see orders needing auth → missed auth.
• If outbound fails: CPOE may allow order to proceed without showing auth status.

HL7 v2.5.1 Technical Detail

Internal integration; no external HL7 required.

FHIR R4 Technical Detail

Not required; internal JSON. However, internally, orders may be represented as FHIR ServiceRequest or ProcedureRequest resources; mapping is handled within CPOE.

Error Handling

• Same retry/backoff and DLQ pattern.
• If auth status cannot be returned to CPOE:
• CPOE displays “Auth status unknown – check Patient Access” and may enforce soft/hard stop based on configuration.

Retry and Recovery

Retry Strategy:

Dead Letter Queue:

• Failed outbound auth status updates → integration_dlq with integration_id = 'INT-PAC-007'
• Priority flag for auth approvals (clinicians waiting for confirmation)
• Retention: 30 days active, then archive

Idempotency:

• Inbound order events: deduplication key = [order_id]_[event_type]_[event_timestamp]
• Outbound auth status updates: deduplication key = [order_id]_[auth_id]_[auth_status]; CPOE ignores duplicate status updates

Reconciliation:

• Daily: compare Patient Access auth records vs CPOE orders requiring auth; flag orders without corresponding auth records
• Weekly: review “Auth status unknown” indicators in CPOE; resolve outstanding sync failures
• Monthly: track orders that proceeded without auth confirmation and their claim outcomes

INT-PAC-008: Patient Portal (FHIR R4)

Business Context

What flows

• Outbound to Patient Portal:
• Pre-registration “packages” for upcoming appointments:
  • Demographics to confirm/update.
  • Insurance details to confirm/update.
  • Consent forms (PDPL consent, facility-specific consents).
  • Cost estimates for planned services (if available).
• Inbound from Patient Portal:
• Updated demographics and insurance.
• Completed consent forms (signatures, timestamps).
• Patient acknowledgment of cost estimates.

When

• When an appointment is booked and pre-registration is enabled.
• When staff manually triggers a pre-reg invitation.
• When patient submits or updates pre-reg data.

Why

• To reduce front-desk workload and waiting times.
• To improve data quality and ensure PDPL-compliant consent capture.

How often

• On-demand (per appointment/patient).

FHIR R4 Technical Detail

The Patient Portal exposes a FHIR R4 API. Patient Access acts as a client and server:

• Outbound: Patient Access populates FHIR resources for the portal:
• Patient
• Coverage
• Appointment
• Questionnaire / QuestionnaireResponse (for pre-reg forms)
• Consent (for PDPL and facility consents)
• Communication or DocumentReference for cost estimate PDFs
• Inbound: Patient Access receives:
• Patient updates
• Coverage updates
• QuestionnaireResponse (completed forms)
• Consent resources
• Communication acknowledging cost estimate

Example FHIR Bundle – Pre-Registration Package (Outbound)

{
  "resourceType": "Bundle",
  "type": "collection",
  "id": "prereg-ENC-2026-000567",
  "entry": [
    {
      "fullUrl": "urn:uuid:patient-1",
      "resource": {
        "resourceType": "Patient",
        "id": "MRN-2026-000123",
        "identifier": [
          {
            "system": "http://dubai-creek-hosp.example.org/mrn",
            "value": "MRN-2026-000123"
          },
          {
            "system": "http://www.emiratesid.ae",
            "value": "784-1985-1234567-1"
          }
        ],
        "name": [
          {
            "use": "official",
            "family": "Al-Maktoum",
            "given": ["Ahmed"]
          }
        ],
        "gender": "male",
        "birthDate": "1985-03-15",
        "telecom": [
          {
            "system": "phone",
            "value": "+971501234567",
            "use": "mobile"
          }
        ],
        "address": [
          {
            "line": ["PO BOX 12345"],
            "city": "Dubai",
            "country": "AE"
          }
        ]
      }
    },
    {
      "fullUrl": "urn:uuid:coverage-1",
      "resource": {
        "resourceType": "Coverage",
        "id": "COV-OMN123456789",
        "status": "active",
        "beneficiary": {
          "reference": "Patient/MRN-2026-000123"
        },
        "payor": [
          {
            "identifier": {
              "system": "http://dha.gov.ae/payers",
              "value": "PAYER-DHA-OMAN"
            },
            "display": "Oman Insurance"
          }
        ],
        "class": [
          {
            "type": {
              "coding": [
                {
                  "system": "http://terminology.hl7.org/CodeSystem/coverage-class",
                  "code": "plan"
                }
              ]
            },
            "value": "OMN-GOLD",
            "name": "Oman Insurance Gold"
          }
        ],
        "subscriberId": "OMN123456789",
        "period": {
          "start": "2025-01-01",
          "end": "2026-12-31"
        }
      }
    },
    {
      "fullUrl": "urn:uuid:appointment-1",
      "resource": {
        "resourceType": "Appointment",
        "id": "APT-2026-000999",
        "status": "booked",
        "serviceCategory": [
          {
            "coding": [
              {
                "system": "http://terminology.hl7.org/CodeSystem/service-category",
                "code": "17",
                "display": "General Practice"
              }
            ]
          }
        ],
        "start": "2026-02-10T09:30:00+04:00",
        "end": "2026-02-10T10:00:00+04:00",
        "participant": [
          {
            "actor": {
              "reference": "Patient/MRN-2026-000123"
            },
            "status": "accepted"
          }
        ]
      }
    },
    {
      "fullUrl": "urn:uuid:questionnaire-1",
      "resource": {
        "resourceType": "Questionnaire",
        "id": "prereg-basic-1",
        "status": "active",
        "title": "Pre-Registration Demographics and Insurance",
        "item": [
          {
            "linkId": "contact-phone",
            "text": "Mobile phone number",
            "type": "string",
            "required": true
          },
          {
            "linkId": "insurance-card-photo",
            "text": "Upload insurance card photo",
            "type": "attachment",
            "required": false
          }
        ]
      }
    },
    {
      "fullUrl": "urn:uuid:consent-1",
      "resource": {
        "resourceType": "Consent",
        "id": "consent-pdpl-1",
        "status": "draft",
        "scope": {
          "coding": [
            {
              "system": "http://terminology.hl7.org/CodeSystem/consentscope",
              "code": "patient-privacy"
            }
          ]
        },
        "category": [
          {
            "coding": [
              {
                "system": "http://terminology.hl7.org/CodeSystem/consentcategorycodes",
                "code": "INFA",
                "display": "Information Access"
              }
            ]
          }
        ],
        "patient": {
          "reference": "Patient/MRN-2026-000123"
        },
        "dateTime": "2026-02-07T11:00:00+04:00",
        "organization": [
          {
            "reference": "Organization/DUBAI_CREEK_HOSP"
          }
        ]
      }
    }
  ]
}

Example FHIR QuestionnaireResponse – Completed Pre-Registration (Inbound)

{
  "resourceType": "QuestionnaireResponse",
  "id": "QR-PREREG-0001",
  "questionnaire": "Questionnaire/prereg-basic-1",
  "status": "completed",
  "subject": {
    "reference": "Patient/MRN-2026-000123"
  },
  "authored": "2026-02-08T18:45:00+04:00",
  "item": [
    {
      "linkId": "contact-phone",
      "answer": [
        {
          "valueString": "+971509876543"
        }
      ]
    }
  ]
}

Key Element Mappings

Search Parameters (Portal → Patient Access)

• GET /QuestionnaireResponse?subject=Patient/MRN-2026-000123&questionnaire=prereg-basic-1
• GET /Consent?patient=Patient/MRN-2026-000123&status=active
• GET /Appointment?patient=Patient/MRN-2026-000123&date=ge2026-02-01

Error Handling

Dead letter and manual recovery as per other integrations. Staff can resend pre-reg invitation from Pre-Registration Dashboard.

Retry and Recovery

Retry Strategy:

Dead Letter Queue:

• Failed outbound FHIR Bundles → integration_dlq with integration_id = 'INT-PAC-008'
• Failed inbound responses → same DLQ, tagged as direction = 'inbound'
• Staff can resend pre-reg invitation from Pre-Registration Dashboard (SCR-PAC-007)
• Retention: 30 days active, then archive

Idempotency:

• Outbound pre-reg packages: deduplication key = [appointment_id]_[prereg_id]; Portal ignores duplicate packages
• Inbound QuestionnaireResponse: deduplication key = [questionnaire_response_id]; Patient Access updates existing pre-reg record rather than creating duplicates
• Inbound Consent: deduplication key = [consent_id]_[patient_id]_[consent_type]

Reconciliation:

• Daily: compare Patient Access pre-registration records vs Portal submissions; flag records where invitation was sent but no response received within 48 hours
• Weekly: review DLQ entries for both outbound and inbound; ensure all sync failures resolved
• Monthly: pre-registration portal adoption rate report; review failed sync patterns for systemic issues

NABIDH / Malaffi Integration

Patient Access does not directly send messages to NABIDH (Dubai) or Malaffi (Abu Dhabi). However:

• Demographics and coverage data used in Patient Access must remain consistent with:
• NABIDH/Malaffi ADT and coverage data consumed by the EHR.
• When EHR receives updated demographics/coverage from HIE:
• EHR must propagate changes to Patient Access via INT-PAC-003 (HL7 ADT^A08 or internal API).
• Compliance:
• Ensure Emirates ID and MRN mappings are consistent with HIE master patient index.
• Respect UAE PDPL requirements for consent and data minimization; Patient Access should not expose more financial data to HIE than required (typically none directly).

Authentication & Security

All integrations must comply with:

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

mTLS Certificates

• External integrations (INT-PAC-001, INT-PAC-002, INT-PAC-008) must use mutual TLS:
• Client and server certificates issued by approved UAE CAs or as per DHA/DOH requirements.
• Certificates stored in secure keystore with rotation policy (e.g., 12 months).
• TLS version ≥ 1.2; strong cipher suites only.

OAuth 2.0 Flows

• eClaimLink / DOH eClaims:
• Use OAuth 2.0 client credentials flow:
  • Client ID/secret per facility.
  • Token endpoint defined by payer gateway.
  • Access tokens cached in memory with automatic refresh.
• Patient Portal (FHIR):
• Use OAuth 2.0 authorization code flow for patient-facing access.
• Patient Access acts as confidential client when calling portal APIs (client credentials or JWT-based).

API Key Management

• For any payer or internal services that still use API keys:
• Keys stored in secrets manager (not in code).
• Keys rotated per facility policy (e.g., every 90 days).
• Access controlled by role-based permissions.

Message Encryption & Data Protection

• All external traffic over HTTPS (TLS).
• Sensitive fields (e.g., Emirates ID, member IDs) encrypted at rest in HIS databases using field-level encryption where required by policy.
• Logs must:
• Avoid storing full Emirates IDs and card numbers; use masking (e.g., 784-1985-******7-1).
• Store only necessary identifiers for troubleshooting.

Access Control & Audit

• Only roles with appropriate permissions (e.g., Registration Clerk, Authorization Specialist, Financial Counselor) can:
• Trigger eligibility/auth.
• View detailed financial information.
• All integration calls must be auditable:
• who (user or system account),
• what (payload summary, not full PHI),
• when (timestamp),
• where (source IP/system),
• result (success/failure).

Error & Alerting Thresholds

• Repeated failures:
• ≥ 5 failed calls to same external endpoint within 10 minutes → send alert to IT and Patient Access Manager.
• Security anomalies:
• Repeated 401/403 responses → trigger security incident workflow.

This specification covers all Patient Access integrations required for eligibility, prior authorization, referrals, cost estimation, financial counseling, and pre-registration in the UAE context.