Hospitals with their own HIMS
Billing desks that want pre-authorizations and claims sent from the system they already use.
Integrations / NHCX
NHCX Integration for Hospitals, TPAs and Insurers
Every insurer and TPA has its own portal, and the billing desk retypes the same cashless pre-authorization into each one. Agnotic Technologies connects your HIMS, TPA or insurer platform to India's National Health Claims Exchange, so eligibility checks, pre-authorizations and claims move as FHIR messages instead.
FHIR R4 claim bundlesSubmit and callback flowsSandbox to productionRejected message tracking
Trusted by global innovators
What is NHCX integration?
NHCX integration connects a hospital information management system (HIMS), TPA platform or insurer system to the National Health Claims Exchange, so coverage eligibility, pre-authorization, claims and payment notices travel as FHIR bundles through one gateway. Agnotic Technologies builds the mapping, the API calls, the callbacks and the onboarding from sandbox to production.
NHCX sits beside ABDM but does a different job. ABHA, consent and health record sharing are covered on our ABDM integration page; this page is about the claims exchange.
API map
Which NHCX APIs carry each claim step?
Each step is a pair: a request through NHCX to the other party, and an answer that comes back later on its own call. This is the map we build against.
| Code | Name | Typical use |
|---|---|---|
| /coverageeligibility/check | Coverage eligibility request | Provider to NHCX to payer, carrying a CoverageEligibilityRequestBundle; the answer returns on /coverageeligibility/on_check |
| /preauth/submit | Pre-authorization request | Provider to NHCX to payer with a ClaimBundle whose use is preauthorization; the decision returns on /preauth/on_submit |
| /predetermination/submit | Predetermination request | Provider to NHCX to payer for an estimate of cover; the answer returns on /predetermination/on_submit |
| /claim/submit | Claim | Provider to NHCX to payer with the final ClaimBundle after discharge; adjudication returns on /claim/on_submit |
| /communication/request | Request for more information | Payer to NHCX to provider asking for documents; the provider answers with the attachments on the paired response call |
| Payment notice | Payment notification and acknowledgment | Payer tells the provider a payment was made, and the provider acknowledges it |
Claim bundles
How is hospital billing data turned into an NHCX claim bundle?
A claim on NHCX is a FHIR Bundle of type collection built around a Claim resource. The same structure carries a pre-authorization, a predetermination or the final claim; the Claim's use element says which one it is.
The mapping work sits on the hospital side. Bill lines become Claim items, diagnoses and procedures become coded entries, the patient's policy becomes a Coverage resource, and discharge summaries, bills and reports go in as supporting documents inside the bundle.
We validate every bundle against the published NRCeS profiles before it is sent, so a structural error is caught at the hospital rather than returned by the payer days later.
Asynchronous flow
How does an asynchronous NHCX request complete?
Nothing on NHCX is answered in the same call. The HIMS has to keep track of every request until its answer arrives.
Send the request
The HIMS posts the bundle to the submit endpoint, with the protocol headers that identify sender, recipient and the request.
Record the acknowledgment
NHCX accepts the request for delivery; the HIMS stores the request ID and marks the case as waiting.
Receive the callback
The payer's answer arrives later on your on_submit endpoint, which must be reachable, secured and idempotent.
Match and update
The answer is matched to the original request ID and the pre-authorization or claim status is updated for the billing desk.
Follow up or chase
Requests for documents open a task; requests with no answer after the agreed time are listed for follow-up.
Onboarding checklist
What is on the NHCX onboarding checklist, from sandbox to production?
We run this checklist with every HIMS, TPA or insurer platform we connect. Each line has an owner and a clear done state before the move to production.
| Checklist item | What done looks like | Usually owned by |
|---|---|---|
| Participant registry entry | The organization is registered with the right role and its details match its legal and network records | Your operations or compliance team |
| Keys and certificates | Encryption keys generated, public keys registered, private keys stored in a vault, with an expiry and rotation plan | Agnotic engineering with your IT security team |
| Bundle validation per message type | Sample eligibility, pre-auth, claim and communication bundles pass the profile validator for the IG version in use | Agnotic engineering |
| End-to-end tests with a payer | Agreed test cases run in the sandbox with at least one payer or TPA, including rejections and document requests | Agnotic engineering with the payer's team |
| Callback and retry handling | Callbacks are received, matched and processed once, even when a message arrives twice or late | Agnotic engineering |
| Production approval | The exchange operator's current go-live steps completed and production credentials issued | Your operations team |
| Rejected message monitoring | Rejections and unanswered requests are listed daily for the billing or claims desk | Your billing desk, with alerts we build |
Onboarding steps are set by the exchange operator and change over time, so we check the current process at the start of each project.
Who it is for
Who connects to NHCX with us?
Both ends of the cashless claim, and the software in between.
HIMS and hospital software vendors
Products that need NHCX built once and offered to many hospital customers.
Third party administrators
TPA platforms that receive requests and return decisions on behalf of insurers.
Insurers
Claims systems that consume FHIR bundles and send adjudication results back.
Hospital groups
Several sites and billing teams that need one consistent claims path.
Scope drivers
What sizes an NHCX integration build?
We size the work on a scoping call. These are the factors that move it.
Which flows come first
Eligibility and pre-authorization alone are smaller than the full set through claims and payment notices.
Billing data quality
Structured bill lines and coded diagnoses map faster than free-text bills.
Documents per claim
How discharge summaries, bills and reports are stored decides the attachment work.
Number of payers in testing
Each payer or TPA can bring its own test cases and timelines.
Your role on the exchange
A provider integration differs from a payer or TPA one, which must answer requests.
Compliance-First Healthcare App Development Services Backed by Global Standards
01
HIPAA
Health Insurance Portability and Accountability Act
Protect PHI with privacy-first architecture, encrypted storage and transmission, strict access controls, and traceable audit logs.
02
GDPR
General Data Protection Regulation
Implement lawful consent flows, data minimization, retention controls, and secure processing for sensitive health data.
03
FHIR
Fast Healthcare Interoperability Resources
Enable standardized health data exchange across apps, care teams, and systems through standards-based FHIR APIs.
04
HL7
Health Level Seven International
Support enterprise-grade interoperability with HL7-based integrations for records, events, and clinical messaging workflows.
05
HITRUST
Health Information Trust Alliance
Align security programs to healthcare-specific control and risk management practices trusted by providers and ecosystem partners.
06
HITECH
Health Information Technology for Economic and Clinical Health Act
Design with breach notification readiness, digital record safeguards, and operational controls that support regulated care programs.
07
SaMD
FDA Software as a Medical Device
Plan software quality, traceability, and documentation pathways for products that may require SaMD review and submission.
08
MDR (EU)
Medical Device Regulation (European Union)
Prepare EU market-ready processes for risk classification, evidence tracking, and lifecycle governance under MDR expectations.
09
SAMHSA
Substance Abuse and Mental Health Services Administration
Apply confidentiality controls and consent-aware sharing models for behavioral and mental health data experiences.
Facts and sources
Which specifications define NHCX messages?
Short facts from NRCeS, which publishes the FHIR profiles NHCX uses, each linked to its source.
The National Health Claims Exchange was developed by the National Health Authority to standardize health insurance claim processing with FHIR. Its initial version focuses on cashless claims: provider and payer details, eligibility check, pre-authorization, claims, payment notification and payment acknowledgment.
Source: NRCeS, FHIR Implementation Guide for ABDM v6.5.0: NHCX ProfilesThe NHCX ClaimBundle profile is a FHIR Bundle of type collection, generated according to the 'use' element of the Claim resource: preauthorization, predetermination or claim.
Source: NRCeS, FHIR Implementation Guide for ABDM v6.5.0: NHCX ProfilesIn ABDM and NHCX, bundles are either Document bundles, used for clinical workflows, or Collection bundles, used for administrative workflows such as claim processing.
Source: NRCeS, Implementation Guide for Adoption of FHIR in ABDM and NHCXNRCeS maps each NHCX API to its flow: a claim travels from provider to NHCX to payer on /claim/submit, and the payer's answer returns through NHCX on /claim/on_submit. Coverage eligibility, pre-authorization and predetermination follow the same paired pattern.
Source: NRCeS, Implementation Guide for Adoption of FHIR in ABDM and NHCX (Annexure)
How we work
How does an NHCX project run?
Three stages, from your billing data to production.
1.
Scoping call
We look at your HIMS or claims system, your billing data and which flows you need first.
Flows first
2.
Sandbox build
Bundle mapping, API calls, callbacks and validation, tested end to end with a payer in the sandbox.
Fixed scope
3.
Production and support
Go-live through the operator's approval, rejected message monitoring and the next flows.
Ongoing
Frequently Asked Questions
No. NHCX is the claims exchange between providers, insurers and TPAs. ABDM covers health IDs, consent and the sharing of health records. Both use FHIR profiles published by NRCeS, and many hospitals integrate with both.
The NHCX profiles are part of the NRCeS FHIR Implementation Guide for ABDM, which is based on FHIR R4. We confirm the IG release your counterparties expect before mapping starts, because profiles change between releases.
The initial version of NHCX focuses on the cashless claims process: eligibility, pre-authorization, claims and payment notices. Check the current NRCeS guide for any flows added since.
Yes. We build the mapping from your billing data, the API calls and the callback endpoints around your HIMS, so the billing desk keeps working in the system it already knows.
Every bundle is validated against the NRCeS profiles, then agreed test cases run in the sandbox with a payer or TPA, including rejections, document requests and duplicate callbacks.
It depends on your billing data, the flows you start with and the payers' testing schedules, and the operator's approval steps sit outside anyone's control. We plan the stages with you on the scoping call rather than quote a date.