Denial Analysis Integration Specifications

Integration Summary

Note: This module does not directly integrate with NABIDH or Malaffi; denial data may be indirectly used in broader analytics but no direct HIE messaging is required.

INT-DEN-001: Billing & Claims

Business Context

What flows

• Inbound to Denial Analysis
• Claim header & line identifiers (claims.claim_id, claim_lines.line_id)
• Payer, plan, billed amount, allowed amount, paid amount
• Denial codes (payer-specific), denial reason text, CARC/RARC equivalents if available
• Posting dates, check/EFT identifiers
• Claim status (fully paid, partially denied, fully denied)
• Outbound to Billing & Claims
• Appeal status and outcomes (overturned, upheld, partial)
• Recovered amounts and dates
• Flags for corrected claim resubmission
• Recommended write-off vs rebill indicators

When

• Inbound: Whenever a denial is recorded during payment posting in Billing & Claims.
• Outbound: When an appeal outcome is recorded or a denial is reclassified (e.g., preventable, root cause updated).

Why

• Centralise denial analytics while keeping Billing & Claims as the system of record for financial postings.
• Drive re-billing, corrected claims, and write-off decisions based on structured denial analysis.
• Provide feedback loop to improve coding, billing, and front-end processes.

How often

• Real-time event-driven integration (near-instant after posting or appeal update).

Error impact

• If inbound feed fails: new denials are not visible in worklists; analysts may miss appeal deadlines.
• If outbound feed fails: Billing & Claims may not resubmit corrected claims or post recovered amounts; financials and KPIs become inconsistent.
• Both directions require robust retry and alerting.

HL7 v2.5.1 Technical Detail

This integration is internal and primarily DB/API-based. HL7 is not used between Denial Analysis and Billing & Claims; however, Billing & Claims may itself be fed by HL7 DFT^P03 messages from external systems. Denial Analysis consumes the normalized claim/denial data from the shared database.

No HL7 message definition is required for this internal integration.

FHIR R4 Technical Detail

Internal integration is via shared DB / internal APIs; FHIR is not required. For future extensibility, a FHIR-based analytics API could expose denial summaries as MeasureReport resources, but this is out of scope for this release.

Error Handling

• Transport / DB errors
• Retry with exponential backoff: 30s, 1m, 2m, 5m, 10m (max 5 attempts).
• If still failing, write to dead letter queue dlq_denial_billing_sync with payload and error.

• Raise alert to RCM IT support and Denial Manager dashboard.

• Data validation errors (e.g., missing claim_id)

• Reject record, log to denial_integration_errors with reason.
• No auto-retry; requires data correction in Billing & Claims.

• Denial Analyst can view error list and request correction.

• Concurrency / duplicate events

• Use idempotency key: combination of claim_id + payer_id + denial_code + denial_date.

• On duplicate, update existing denial_records rather than insert.

• Manual recovery

• Reprocess failed batches by date range from Billing & Claims using an admin UI.
• Reconciliation job compares claims with denial_records to identify missing denials.

Retry and Recovery

Retry Strategy:

Dead Letter Queue:

• Inbound denial events exhausting retries moved to dlq_denial_billing_sync with full payload and error details
• Outbound appeal outcomes moved to dlq_denial_billing_outbound if Billing API unavailable
• Admin dashboard for review, correction, and requeue
• Retention: 60 days active (to cover appeal and timely filing windows)
• Alert: Denial Manager notified if DLQ count > 10 or oldest message > 4 hours; RCM IT for transport failures

Idempotency:

• Inbound deduplication key: (claim_id, payer_id, denial_code, denial_date)
• Duplicate inbound events update existing denial_records rather than creating new
• Outbound deduplication key: (denial_id, appeal_id, outcome_datetime)
• Billing checks for existing appeal outcome before processing duplicate

Reconciliation:

• Daily: compare claims with denial-related statuses vs denial_records in Denial Analysis
• Flag claims denied in billing but without corresponding denial_records (missed inbound feed)
• Flag denial_records with appeal outcomes not reflected in billing payment postings
• Weekly: reconcile recovered amounts in Denial Analysis vs payments posted in Billing
• Monthly: denial volume cross-check and financial reconciliation between modules

INT-DEN-002: Policy & Contract Management

Business Context

What flows

• Inbound to Denial Analysis
• Payer contract metadata:
  • Appeal deadlines per payer/plan/denial type
  • Maximum appeal levels allowed
  • Contracted denial categories considered non-appealable
  • Escalation contacts and SLAs
• Outbound to Policy & Contract Management
• Payer denial scorecards:
  • Overall denial rate, denial rate by category
  • Appeal rate and success rate
  • Average days to appeal and resolution
  • Denied and recovered amounts
• Denial patterns:
  • High-frequency denial reasons
  • Contract compliance issues (e.g., denials outside contract terms)

When

• Inbound: Nightly sync of contract terms; on-demand when a contract is updated.
• Outbound: After monthly or quarterly scorecard generation (WF-DEN-006).

Why

• Ensure appeal timelines and strategies comply with payer contracts.
• Provide objective denial performance data to support contract renegotiations.
• Align denial prevention actions with contractual obligations.

How often

• Contract terms: Daily batch + on-change push.
• Scorecards: Monthly/quarterly batch.

Error impact

• If inbound fails: appeal deadlines may be miscalculated, risking late appeals.
• If outbound fails: contract team lacks up-to-date denial performance data; weaker negotiation position.

HL7 v2.5.1 Technical Detail

No HL7 messaging is used; this is an internal RCM-to-RCM integration.

FHIR R4 Technical Detail

Not applicable; internal DB/API integration. Future versions may expose payer performance as FHIR Measure/MeasureReport, but not required now.

Error Handling

• Inbound contract sync failure
• Retry batch with exponential backoff: 5m, 15m, 30m (max 3 attempts).
• If still failing, freeze last-known contract rules and flag UI banner: “Contract data may be outdated as of ”.

• Log to dlq_contract_rules_sync for investigation.

• Outbound scorecard push failure

• Queue scorecard payloads in pending_payer_scorecard_push.
• Retry hourly for 24 hours.

• After 24h, mark as “Not delivered” and notify Policy & Contract Management users via in-app notification.

• Manual recovery

• Admin screen to re-trigger:
  • Contract rules import for a specific payer.
  • Scorecard export for a specific period and payer.

Retry and Recovery

Retry Strategy:

Dead Letter Queue:

• Failed contract rule imports logged to dlq_contract_rules_sync with error details
• Failed scorecard pushes queued in pending_payer_scorecard_push
• Admin dashboard for review and manual re-trigger
• Retention: 30 days for contract sync failures; 90 days for scorecard push failures
• Alert: Denial Manager on contract sync failures (appeal deadline risk); Policy & Contract Manager on scorecard delivery failures

Idempotency:

• Inbound contract rules use (payer_id, plan_id, rule_type, effective_date) as deduplication key
• Duplicate rule imports update existing records rather than creating duplicates
• Outbound scorecards use (payer_id, period_start, period_end) as deduplication key
• Re-pushed scorecards overwrite previous version for same period

Reconciliation:

• Daily: verify appeal deadline rules loaded for all active payers with open denials
• Flag payers with open denials but missing or stale deadline rules (> 30 days old)
• Monthly: compare scorecard data delivered to Policy & Contract Management vs source payer_denial_scorecards
• Quarterly: audit contract rule coverage (payers with claims but no configured rules)

INT-DEN-003: Patient Access

Business Context

What flows

• Outbound only:
• Aggregated denial trends related to:
  • Eligibility failures (coverage terminated, no active policy, plan not covered)
  • Authorization failures (no prior auth, auth expired, auth for different service)
• Metrics per department, provider, and registration location:
  • Denial counts and rates
  • Financial impact (denied amount)
  • Preventable vs non-preventable flags
• Linked prevention actions (training, workflow changes, system rules).

When

• Monthly batch after trend analysis (WF-DEN-005) completes.

Why

• Provide Patient Access with actionable insights to reduce front-end denials.
• Support process improvements in registration, eligibility verification, and authorization workflows.

How often

• Monthly (configurable to weekly if needed).

Error impact

• If integration fails, Patient Access will not see updated trends; improvement initiatives may be misdirected or delayed, but no immediate financial posting impact.

HL7 v2.5.1 Technical Detail

Not applicable; this is internal analytics data, not HL7-based.

FHIR R4 Technical Detail

To support future analytics APIs, denial trends can be exposed as FHIR MeasureReport resources.

Resource: MeasureReport (summary)

{
  "resourceType": "MeasureReport",
  "id": "denial-trend-eligibility-2026-01",
  "status": "complete",
  "type": "summary",
  "measure": "https://his.gates-group.ae/fhir/Measure/denial-eligibility-rate",
  "period": {
    "start": "2026-01-01",
    "end": "2026-01-31"
  },
  "date": "2026-02-05T10:00:00+04:00",
  "reporter": {
    "reference": "Organization/denial-analytics",
    "display": "Denial Analytics Service"
  },
  "group": [
    {
      "id": "by-department",
      "population": [
        {
          "code": {
            "coding": [
              {
                "system": "http://terminology.hl7.org/CodeSystem/measure-population",
                "code": "denominator",
                "display": "Total claims"
              }
            ]
          },
          "count": 12500
        },
        {
          "code": {
            "coding": [
              {
                "system": "http://terminology.hl7.org/CodeSystem/measure-population",
                "code": "numerator",
                "display": "Eligibility denials"
              }
            ]
          },
          "count": 140
        }
      ],
      "measureScore": {
        "value": 1.12
      },
      "stratifier": [
        {
          "code": {
            "text": "Department"
          },
          "stratum": [
            {
              "value": {
                "text": "Outpatient Registration - Dubai"
              },
              "population": [
                {
                  "code": {
                    "coding": [
                      {
                        "system": "http://terminology.hl7.org/CodeSystem/measure-population",
                        "code": "denominator"
                      }
                    ]
                  },
                  "count": 6000
                },
                {
                  "code": {
                    "coding": [
                      {
                        "system": "http://terminology.hl7.org/CodeSystem/measure-population",
                        "code": "numerator"
                      }
                    ]
                  },
                  "count": 90
                }
              ],
              "measureScore": {
                "value": 1.5
              }
            }
          ]
        }
      ]
    }
  ]
}

Key element mappings

• MeasureReport.period → denial_trends.period_start, period_end.
• group.population[denominator].count → total claims.
• group.population[numerator].count → eligibility denials.
• group.measureScore.value → denial rate percentage.
• stratifier.stratum.value.text → department / registration location.

Search parameters

• GET [base]/MeasureReport?measure=denial-eligibility-rate&period=ge2026-01-01&period=le2026-01-31
• GET [base]/MeasureReport?measure=denial-eligibility-rate&group=by-department

Error Handling

• Batch generation failure
• Log error and retry batch generation once within 1 hour.

• If still failing, mark the period as “No data generated” and notify Denial Manager and Patient Access Manager.

• API delivery failure (if using FHIR API)

• Retry with exponential backoff: 10m, 30m, 1h (max 3 attempts).

• On repeated failure, store reports locally and allow Patient Access to pull via UI instead of push.

• Manual recovery

• Re-run trend generation for a given month and re-publish to Patient Access.

Retry and Recovery

Retry Strategy:

Dead Letter Queue:

• Failed trend reports queued in dlq_denial_patient_access with report payload
• Patient Access can pull reports via UI if push delivery fails
• Retention: 90 days (covers quarterly reporting cycles)
• Alert: Denial Manager and Patient Access Manager notified if report not delivered within 48 hours of generation

Idempotency:

• Deduplication key: (measure_type, period_start, period_end)
• Re-published reports for same period overwrite previous version
• Patient Access checks MeasureReport.date to ensure latest version displayed

Reconciliation:

• Monthly: verify all scheduled trend reports were generated and delivered
• Flag months with missing reports or incomplete data
• Quarterly: cross-check denial trend totals in Patient Access view vs Denial Analysis source data

INT-DEN-004: eClaimLink (DHA Dubai)

Business Context

What flows

• Outbound (Denial Analysis → eClaimLink)
• Appeal submissions for Dubai-based payers:
  • Claim reference (eClaimLink claim ID)
  • Denial reason and category
  • Appeal level (reconsideration, formal appeal)
  • Narrative justification and references to clinical documentation
  • Supporting document metadata (document type, file name, hash, size)
• Inbound (eClaimLink → Denial Analysis)
• Payer responses:
  • Appeal status (received, under review, additional info requested, approved, rejected, partially approved)
  • Decision date
  • Adjusted amounts and codes
  • Notes from payer

When

• Outbound: When an appeal is submitted from the Appeal Management screen (WF-DEN-003) for claims under DHA jurisdiction.
• Inbound: When eClaimLink posts asynchronous responses or when Denial Analysis polls for status.

Why

• Comply with DHA eClaimLink requirements for electronic appeals.
• Avoid manual portal entry and duplicate documentation.
• Ensure appeal timelines and statuses are accurately tracked in the HIS.

How often

• On-demand per appeal, with periodic polling (e.g., every 24 hours) for status updates where webhooks are not available.

Error impact

• If outbound fails: appeal may not be registered with payer; risk of missing appeal deadline.
• If inbound fails: HIS may not reflect updated payer decisions; financial postings and KPIs may lag.

HL7 v2.5.1 Technical Detail

DHA eClaimLink is REST/JSON/XML-based and does not use HL7 v2.5.1. No HL7 messages are exchanged for this integration.

FHIR R4 Technical Detail

eClaimLink uses its own schemas; however, internally Denial Analysis can represent appeals as FHIR ClaimResponse resources to standardise processing.

Resource: ClaimResponse (internal representation of payer appeal decision)

{
  "resourceType": "ClaimResponse",
  "id": "ECL-APPEAL-20260207-0001",
  "status": "active",
  "type": {
    "coding": [
      {
        "system": "http://terminology.hl7.org/CodeSystem/claim-type",
        "code": "professional"
      }
    ]
  },
  "use": "claim",
  "patient": {
    "reference": "Patient/2025007890",
    "display": "Fatima Al-Nahyan"
  },
  "created": "2026-02-07T11:20:00+04:00",
  "insurer": {
    "reference": "Organization/oman-insurance",
    "display": "Oman Insurance (Dubai)"
  },
  "request": {
    "reference": "Claim/ECL-CLM-20260115-12345"
  },
  "outcome": "partial",
  "disposition": "Appeal partially approved. Additional 1,200 AED allowed.",
  "item": [
    {
      "itemSequence": 1,
      "adjudication": [
        {
          "category": {
            "coding": [
              {
                "system": "http://terminology.hl7.org/CodeSystem/adjudication",
                "code": "submitted"
              }
            ]
          },
          "amount": {
            "value": 3500,
            "currency": "AED"
          }
        },
        {
          "category": {
            "coding": [
              {
                "system": "http://terminology.hl7.org/CodeSystem/adjudication",
                "code": "eligible"
              }
            ]
          },
          "amount": {
            "value": 2500,
            "currency": "AED"
          }
        }
      ]
    }
  ],
  "payment": {
    "amount": {
      "value": 2500,
      "currency": "AED"
    },
    "date": "2026-02-20"
  },
  "extension": [
    {
      "url": "https://his.gates-group.ae/fhir/StructureDefinition/appeal-level",
      "valueString": "first-level"
    },
    {
      "url": "https://his.gates-group.ae/fhir/StructureDefinition/eclaimlink-appeal-id",
      "valueString": "ECL-AP-998877"
    }
  ]
}

Key element mappings

• ClaimResponse.request.reference → Billing & Claims claims.external_eclaimlink_id.
• ClaimResponse.outcome → appeal_outcomes.payer_decision (overturned/partial/upheld).
• ClaimResponse.payment.amount.value → appeal_outcomes.recovered_amount.
• extension[appeal-level] → appeals.appeal_level.
• extension[eclaimlink-appeal-id] → external appeal identifier.

Search parameters (internal API)

• GET /fhir/ClaimResponse?request=Claim/ECL-CLM-20260115-12345
• GET /fhir/ClaimResponse?extension:eclaimlink-appeal-id=ECL-AP-998877

Error Handling

• Outbound submission failure (HTTP 5xx / network)
• Retry with exponential backoff: 1m, 5m, 15m, 1h (max 4 attempts).
• If still failing, mark appeal as submission_failed in appeals.status.

• Notify Denial Analyst via in-app alert and email.

• Client errors (HTTP 4xx)

• Parse error payload from eClaimLink.
• Store error details in appeal_outcomes.notes.

• No auto-retry; Denial Analyst must correct data and resubmit.

• Inbound status polling failure

• Log and retry next scheduled polling window.

• If no update for > 30 days, flag appeal as “stale” and prompt manual portal check.

• Dead letter queue

• All failed outbound payloads stored in dlq_eclaimlink_appeals with:
  • Appeal ID
  • Claim ID
  • Request body
  • Response status and body

• Admin UI to re-send after correction.

• Manual recovery

• Denial Analyst can manually update appeal status and recovered amount based on portal checks if integration is down.

Retry and Recovery

Retry Strategy:

Dead Letter Queue:

• Failed outbound appeal payloads stored in dlq_eclaimlink_appeals with:
• Appeal ID, claim ID, request body, response status and body, failure reason
• Admin UI for review, correction, and re-send
• Retention: 90 days active (to cover payer appeal timelines)
• Alert: Denial Analyst notified on each DLQ insertion (appeal deadline risk); Denial Manager if > 3 appeals in DLQ

Idempotency:

• Deduplication key: (appeal_id, submission_datetime)
• eClaimLink assigns tracking number on acceptance; stored to prevent duplicate submissions
• Re-submission after correction uses new submission_datetime to differentiate from prior attempt

Reconciliation:

• Daily: compare appeals with status = 'SUBMITTED' vs eClaimLink acknowledgement records
• Flag appeals submitted but without tracking number > 24 hours
• Weekly: compare pending appeals in HIS vs eClaimLink portal status
• Monthly: reconcile appeal outcomes received via API vs manual portal checks
• Quarterly: appeal submission success rate and average response time per DHA payer

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

Business Context

What flows

• Outbound (Denial Analysis → DOH eClaims)
• Appeal submissions for Abu Dhabi-based payers:
  • Shafafiya claim ID
  • Denial reason and category
  • Appeal level
  • Justification text
  • Supporting document metadata
• Inbound (DOH eClaims → Denial Analysis)
• Payer responses:
  • Appeal status and decision
  • Adjusted amounts
  • DOH-specific denial/adjustment codes
  • Notes and instructions for further appeal or closure

When

• Outbound: When an appeal is submitted from Appeal Management (WF-DEN-003) for DOH jurisdiction claims.
• Inbound: When DOH eClaims posts responses or when HIS polls Shafafiya for status.

Why

• Comply with DOH eClaims/Shafafiya requirements.
• Ensure accurate tracking of appeal timelines and outcomes for Abu Dhabi facilities.
• Support DOH reporting and ADHICS-aligned audit trails.

How often

• On-demand per appeal, with periodic status polling (e.g., daily).

Error impact

• Similar to eClaimLink: risk of missed appeal deadlines and inaccurate financial tracking if integration fails.

HL7 v2.5.1 Technical Detail

DOH eClaims is XML/REST-based; HL7 v2.5.1 is not used for this integration.

FHIR R4 Technical Detail

As with eClaimLink, internal representation can use FHIR ClaimResponse.

Resource: ClaimResponse (internal representation)

{
  "resourceType": "ClaimResponse",
  "id": "DOH-APPEAL-20260207-0003",
  "status": "active",
  "type": {
    "coding": [
      {
        "system": "http://terminology.hl7.org/CodeSystem/claim-type",
        "code": "institutional"
      }
    ]
  },
  "use": "claim",
  "patient": {
    "reference": "Patient/2024005678",
    "display": "Ahmed Al-Maktoum"
  },
  "created": "2026-02-07T09:45:00+04:00",
  "insurer": {
    "reference": "Organization/daman-thiqa",
    "display": "Daman (Thiqa)"
  },
  "request": {
    "reference": "Claim/SHF-CLM-20260110-78901"
  },
  "outcome": "complete",
  "disposition": "Appeal approved. Full amount allowed.",
  "item": [
    {
      "itemSequence": 1,
      "adjudication": [
        {
          "category": {
            "coding": [
              {
                "system": "http://terminology.hl7.org/CodeSystem/adjudication",
                "code": "submitted"
              }
            ]
          },
          "amount": {
            "value": 4200,
            "currency": "AED"
          }
        },
        {
          "category": {
            "coding": [
              {
                "system": "http://terminology.hl7.org/CodeSystem/adjudication",
                "code": "benefit"
              }
            ]
          },
          "amount": {
            "value": 4200,
            "currency": "AED"
          }
        }
      ]
    }
  ],
  "payment": {
    "amount": {
      "value": 4200,
      "currency": "AED"
    },
    "date": "2026-02-18"
  },
  "extension": [
    {
      "url": "https://his.gates-group.ae/fhir/StructureDefinition/appeal-level",
      "valueString": "second-level"
    },
    {
      "url": "https://his.gates-group.ae/fhir/StructureDefinition/doh-eclaims-appeal-id",
      "valueString": "SHF-AP-556677"
    }
  ]
}

Key element mappings

• ClaimResponse.request.reference → claims.external_shafafiya_id.
• ClaimResponse.payment.amount.value → appeal_outcomes.recovered_amount.
• extension[doh-eclaims-appeal-id] → external DOH appeal ID.

Search parameters (internal)

• GET /fhir/ClaimResponse?extension:doh-eclaims-appeal-id=SHF-AP-556677
• GET /fhir/ClaimResponse?request=Claim/SHF-CLM-20260110-78901

Error Handling

• Outbound submission failure
• Retry with exponential backoff: 1m, 5m, 15m, 1h (max 4 attempts).
• On repeated failure, set appeals.status = 'submission_failed'.

• Notify Denial Analyst and Denial Manager.

• Schema/validation errors (4xx)

• Capture DOH error codes and descriptions.
• Store in appeal_outcomes.notes.

• No auto-retry; requires data correction.

• Inbound status polling failure

• Retry next polling cycle.

• If no response for > 30 days, mark appeal as “stale” and prompt manual follow-up.

• Dead letter queue

• dlq_doh_eclaims_appeals for failed outbound payloads.

• Manual recovery

• Manual update of appeal status and recovered amount based on Shafafiya portal if integration unavailable.

Retry and Recovery

Retry Strategy:

Dead Letter Queue:

• Failed outbound appeal payloads stored in dlq_doh_eclaims_appeals with:
• Appeal ID, claim ID, Shafafiya reference, request body, DOH error codes, failure reason
• DOH data quality rejections flagged separately for Compliance Officer review
• Admin UI for review, correction, and re-send
• Retention: 90 days active (to cover DOH appeal timelines)
• Alert: Denial Analyst notified on each DLQ insertion; Compliance Officer for DOH data quality errors; Denial Manager if > 3 appeals in DLQ

Idempotency:

• Deduplication key: (appeal_id, submission_datetime)
• DOH assigns unique response reference on acceptance; stored to prevent duplicate submissions
• Shafafiya claim IDs used as secondary deduplication check

Reconciliation:

• Daily: compare appeals with DOH status = 'SUBMITTED' vs Shafafiya acknowledgement records
• Flag appeals submitted but without DOH response > 24 hours
• Weekly: compare pending DOH appeals in HIS vs Shafafiya portal status
• Monthly: reconcile appeal outcomes received via API vs manual Shafafiya portal checks
• Quarterly: DOH appeal submission success rate, response time, and data quality error trends

NABIDH / Malaffi Integration

The Denial Analysis module does not directly exchange data with:

• NABIDH (Dubai HIE), or
• Malaffi (Abu Dhabi HIE)

Denial data is financial/administrative and not part of the clinical datasets typically shared via these HIEs. However:

• Clinical documentation used to support appeals (e.g., medical necessity letters) must remain consistent with clinical data sent to NABIDH/Malaffi.
• Any future reporting that combines denial analytics with HIE data must comply with:
• DHA NABIDH policies for data use and secondary analytics.
• DOH Malaffi data governance and ADHICS requirements.

No HL7 v2.5.1 or FHIR HIE-specific profiles are required for this module at this time.

Authentication & Security

All integrations must comply with UAE PDPL, DOH ADHICS, DHA security policies, and TDRA/NESA cybersecurity standards.

Internal APIs / Shared Database (INT-DEN-001, 002, 003)

• Network
• Restricted to hospital internal network / VPN.

• Segregated RCM subnet with firewall rules limiting access to required services.

• Authentication

• Service-to-service authentication via:
  • Mutual TLS (mTLS) between microservices where applicable.
  • Short-lived JWTs issued by central IAM for internal REST APIs.

• Database access via:

  • Dedicated technical users with least-privilege roles.
  • No shared generic accounts.

• Authorization

• Role-based access control (RBAC) enforced at API and DB layers.

• Denial Analysis services can read/write only to relevant schemas/tables.

• Encryption

• TLS 1.2+ for all internal HTTP traffic.
• Transparent Data Encryption (TDE) for databases containing denial and claim data.
• Encrypted backups with key management aligned to TDRA/NESA guidance.

eClaimLink (INT-DEN-004)

• Transport
• HTTPS with TLS 1.2+.

• Mutual TLS using DHA-approved client certificate issued to the facility.

• Authentication

• OAuth 2.0 client credentials flow:
  • Client ID/secret stored in secure vault.
  • Access tokens cached and refreshed automatically.

• Scope limited to appeal-related operations.

• Message Security

• Request/response payloads logged with sensitive fields masked (e.g., Emirates ID).

• Hashing of uploaded document content for integrity verification.

• Compliance

• DHA eClaimLink security policies.
• UAE PDPL: minimum necessary data, purpose limitation, audit logging of all appeal submissions and responses.

DOH eClaims / Shafafiya (INT-DEN-005)

• Transport
• HTTPS with TLS 1.2+.

• Mutual TLS using DOH-issued client certificate.

• Authentication

• OAuth 2.0 (client credentials or DOH-specified mechanism).

• Token storage and rotation via secure vault.

• Message Security

• Similar to eClaimLink: masked logging, integrity checks, and strict access controls.

• Compliance

• DOH eClaims and Shafafiya security requirements.
• ADHICS controls for:
  • Access control and authentication.
  • Audit logging and monitoring.
  • Data retention and disposal.

General Security Controls

• Audit Logging
• Log all integration events:
  • Who initiated (user ID / service ID).
  • What data was sent/received (with masking).
  • When (timestamp).
  • Outcome (success/failure, error codes).

• Logs retained per facility policy and UAE PDPL requirements.

• Monitoring & Alerting

• Integration health dashboards with:
  • Message volumes.
  • Error rates.
  • Queue depths.

• Alerts to IT and RCM leadership when:

  • Error rate exceeds threshold (e.g., >2% in 1 hour).
  • Dead letter queues accumulate messages.
  • External endpoints unavailable for >15 minutes.

• Paperless Transformation

• All integrations are designed to:
  • Replace paper appeal letters and fax submissions with electronic submissions.
  • Replace manual spreadsheets for denial tracking with system-generated analytics.
  • Provide electronic audit trails for all denial and appeal activities.

This specification provides the integration-level requirements for the Denial Analysis module; table schemas, workflows, and UI details are defined in the corresponding module documents (../denial-analysis/01-domain-model.md, ../denial-analysis/02-workflows.md, etc.).