NHCX vs TMS 2.0: What Changes in Your Code for PMJAY Claims

For years, hospitals handling Ayushman Bharat Pradhan Mantri Jan Arogya Yojana (AB-PMJAY) claims have relied on TMS (Transaction Management System) portals. Dedicated billing staff manually re-key patient demographics, clinical notes, discharge summaries, and package rates from internal Hospital Information Systems (HIS) into browser tabs.

With the National Health Claims Exchange (NHCX) rollout under the Ayushman Bharat Digital Mission (ABDM), this manual paradigm is being completely retired in favor of automated, machine-to-machine API messaging. But for engineering and health-tech teams, migrating from TMS 2.0 to NHCX requires fundamental changes to backend architecture, data pipelines, and security layers.

The TMS 2.0 Six-Stage Gated Sequence

The PMJAY claim lifecycle under TMS 2.0 is strictly sequential. Each stage acts as a hard gate that blocks subsequent operations:

1. Beneficiary Identification and Registration (Golden Record validation via ABHA)
2. Treatment & Package Selection (mapping clinical findings to the Health Benefit Package master)
3. Pre-Authorization Request & Verification (adjudicated by the State Health Agency or implementation partner)
4. Treatment Execution & Clinical Updates
5. Discharge & Final Claim Submission (with signed discharge summaries and invoice breakdowns)
6. Claim Adjudication & Electronic Remittance Advice (ERA) / Payment Settlement

In TMS 2.0, hospital desk operators continuously refresh browser dashboards waiting for status updates. In NHCX, the entire paradigm shifts: communication is fully asynchronous. Responses do not arrive as synchronous HTTP responses or dashboard refreshes—they arrive as asynchronous webhook callbacks posted to endpoints that your adapter exposes.

Turnaround Times and Timer-Aware State Machines

Statutory timelines defined under PMJAY guidelines dictate rigorous SLA thresholds for adapter logic:

• Pre-Authorization Window: Must be initiated within 48 hours of beneficiary registration for private empanelled healthcare providers (EHCPs). Missing this threshold results in automatic system rejection.
• Claim Submission Deadline: Final claims must be submitted within 7 days of patient discharge. System extensions to 21 or 45 days require formal bureaucratic approval.

If your HIS fails to dispatch pre-authorization within 48 hours of admission, the claim is auto-rejected by rule. Your bidirectional adapter must maintain timer-aware state machines that alert billing desks before deadlines elapse.

Message Formats: From Form Fields to NRCES FHIR R4 Bundles

Under TMS 2.0, claims are constructed using ad-hoc form inputs and insurer-specific proprietary JSON schemas. In NHCX, all payloads must strictly adhere to HL7 FHIR R4 specifications standardized by the National Resource Centre for EHR Standards (NRCES).

• CoverageEligibilityRequest & Response: Real-time insurance policy validation and available wallet balance checks.
• Claim (Pre-Auth): Formal request specifying clinical conditions, planned surgical packages, and estimated costs.
• Claim (Enhancement & Final): Detailed line items, medical devices, medication breakdown, and final billing.
• ClaimResponse: Structured adjudication outcomes, approved sums, and deduction item codes.

Cryptographic Envelopes and Registry Handshakes

Unlike standard REST APIs where HTTPS transport encryption is sufficient, NHCX mandates application-level payload encryption. Every outgoing FHIR bundle must be signed using the sender’s private key (JWS) and encrypted using the recipient’s public key (JWE) fetched from the ABDM Participant Registry.

{
  "protocol": "NHCX",
  "headers": {
    "alg": "RSA-OAEP-256",
    "enc": "A256GCM",
    "x-hcx-sender_code": "HOSPITAL-REGISTRY-CODE",
    "x-hcx-recipient_code": "SHA-INSURER-CODE",
    "x-hcx-action": "/claim/submit",
    "x-hcx-timestamp": "2025-01-22T09:00:00Z"
  },
  "payload": "eyJlbmNyeXB0ZWRfZmhpcl9idW5kbGVfaGVyZS..."
}

Adapter Architecture: What Your System Needs

To successfully interface with NHCX without altering your core clinical software, your bidirectional gateway adapter must provide three essential components: a resilient asynchronous callback receiver, an NRCES-compliant FHIR bundle generator, and a state engine that tracks claim stages from admission through payment settlement.