NHCX & NHA — Session Q&A Knowledge Base

Question 1

We’ve already completed ABHA integration for all our clients. For first-time NHCX onboarding, what is the procedure — can we use the same credentials?

Accepted Answer

Go to the NHCX website hcx.abdm.gov.in and on the home page click “Apply for sandbox integration.” Since you’ve already done the ABHA work, you just register with NHCX and enter your client ID. When you enter the client ID a backend API hits the server and detects whether you’ve already completed the ABHA milestone(s), and auto-populates information such as nature of activity and registered address. Sometimes the registered address contains commas or special characters that aren’t allowed — remove those, fill all the details, and submit; you’ll get a “request submitted successfully” message. Registry code = your client ID (in sandbox). Role: select “provider.” Important role codes: provider, payer, and the general EUE role = 10009. Encryption key: same as the ABDM/ABHA encryption — generate the encryption certificate, encrypt it in base64 and paste it in. Endpoint URL: supply your public, accessible callback URL (you can reuse the same ABHA M1/M2 callback URL, but it must be registered on the NHCX server separately). Ignore the signing-cert path.

Question 2

We’re a software provider with ~20 hospital clients. Do we create each separately, and will all callbacks come to a single URL?

Accepted Answer

For the 20 hospitals you generate the participant code individually, and you can set the endpoint URL individually per hospital. For a provider an individual endpoint is allowed; for a payer setting an individual endpoint is not allowed. Since you are providers, individual endpoints are fine.

Question 3

How do I apply for the HFR ID so I can communicate it to insurers and TPAs? Is it the same as the ABDM/NDHM hospital ID?

Accepted Answer

Yes — the HFR ID and the ABDM/NDHM hospital ID are the same ID; the same word “HFR ID” is used at both NHCX and ABDM/NDHM (this was never clearly documented, which caused a lot of confusion). To obtain it: (1) Google “National Digital Health Mission” and go to the ABDM website; (2) first register yourself as a healthcare provider in the Health Professional Registry (HPR) — submit your doctor registration certificates (nursing staff can also be registered); (3) log in with your user ID and add the healthcare facility you work at or own; (4) you get verified (e.g. via MCI registration certificate + documents + linked mobile) and receive a Health Professional ID (e.g. Dr.harikrishnan@hp.abdm); (5) once the facility is approved, a certificate is issued — that certificate is the HFR ID, which you communicate to insurance companies and TPAs. To add a facility not yet listed, use “Add new facility,” enter your Rohini registration ID, search for your hospital, enter a pincode, and update ownership/facilities/manpower/photographs/registration certificates. You also need to link the Health Bridge ID, provided by your EMR supplier.

Question 4

How do I actually get started with NHCX integration — what’s the very first API call?

Accepted Answer

First generate the ABDM token using the V3 (session/access) API. Once you have the access token you can hit any participant API (e.g. the Get Policy API). The registry ID you supply in the client field depends on role: in sandbox it = your client ID; in production it = your HFR ID; if you’re a payer it = your insurance registry ID. The Participant Create API takes registry code, registry ID, participant name, state, district, role, email, phone, primary email encryption and endpoint URL; it returns a participant code (your entity identity), which you use in the Participant Update API. After an update it takes ~1 hour for the information to reflect on the NHCX inbox.

Question 5

What is the full onboarding / go-live path?

Accepted Answer

Register on the ABDM sandbox → select NHCX integration → register. You need at least M1 (M1 and M2 desired; M1 is the must-have for API access). You get a unique Participant ID and assign a role (payer, provider, TPA, or EUA = End User Application for the PHR app — a role added in the last 2–3 months). Get the Postman collection from NHCX documentation; the API section has Onboarding and Use-Cases sub-sections. Then: functional testing → internal demo by the NHCX team → HTC demo → on approval, production keys are handed over to go live. A dummy payer lets providers test encryption/decryption and all use cases; a PMJAY payer sandbox tests PMJAY behaviour. To go live you must do a digital handshake with a real payer (a private insurer or the PMJAY payer, which counts as a public-assurance payer).

Question 6

We’ve completed M1 and are working on M2. Is there documentation for how to take M1/M2 live? Is there a technical video showing how M1/M2/M3 work for NHCX?

Accepted Answer

There are completely separate sessions and resources on the sandbox for M1/M2 integration. Under Documentation you’ll find detailed API docs; there are videos walking through the M1/M2/M3 APIs in Postman; and the ABDM YouTube channel has many webinars. The dedicated NHCX technical video is currently in progress (being built) and will take a little time — meanwhile, join the technical sessions.

Question 7

Is NHCX Level 1.1 the same as ABHA M1? And how do you create ABHA in bulk (e.g. for group health insurance)?

Accepted Answer

No — Level 1.1 = NHCX payer participant registration; it is NOT the same as M1 (the ABDM milestone). The levels are: Level 0 = NHCX sandbox registration; Level 1.1 = NHCX payer participant registration; Level 1.2 = ABHA M1 integration + ABHA-policy linking via NHCX; Level 2 = full claims APIs (pre-auth, claims submission/response). For bulk/group ABHA creation without OTP, use Demographic Auth — Aadhaar-based backend ABHA creation using name + DOB + gender, no OTP required (the other two methods, Mobile OTP and Aadhaar OTP, both need an OTP). There is no bulk API — an individual API call is required per member. One mobile number can create ABHAs for multiple family members. One ABHA Number can have multiple ABHA Addresses (14-digit ABHA Number for lookups; UPI-style name@abdm ABHA Address for user-facing communication).

Question 8

At any given time, can a hospital have two competing HMIS softwares submitting claims? What stops a rival from onboarding “my” hospital?

Accepted Answer

No — a hospital cannot have multiple HMIS softwares for claim submission at the same time. Production onboarding requires hospital consent via OTP: you pass your client ID/secret plus the hospital’s HPR ID; NHCX checks whether that HPR ID already exists in the registry. If it does, NHCX emails/messages the hospital an OTP asking whether they want to override with the new bridge URL/data. Entering the OTP = consent, and the HPR ID is remapped from the old software to the new one; the previous software silently loses visibility. The whole NHCX construct is “one IT software submitting claims to multiple payers,” not multiple softwares for one hospital — so it’s an early-bird competitive dynamic.

Question 9

If our software runs at multiple hospitals, do we get one credential or many? Can we use the same bridge URL and same client ID across all of them?

Accepted Answer

You have one individual client ID and secret key, but you register multiple providers (one participant ID per hospital, each tied to its HFR). You can register multiple providers with the same credential, and the bridge URL may be the same or different per hospital — your choice (e.g. a cloud deployment where all requests hit one bridge and you route internally to the respective databases). The production key certifies your software, not one hospital, so you deploy it at any hospital via the bridge-URL API. NHCX validates the participant ID against the HFR, so you must use different participant IDs and segregate data by participant code. For authorization, the single client ID/secret is used. (In sandbox the callback auth token was not enforced; it is now enforced in production — you will receive a real bearer token on every callback and must validate it.)

Question 10

How do we set up the callback URL for a participant, and how do we know which callback maps to which participant ID (as with ABDM’s “get services”)?

Accepted Answer

Yes — there is a participant API to get all the callbacks (all the bridge URLs). Every participant ID must have a URL along with its certificate. It can be the same URL for multiple participants — that doesn’t matter — but you must have one registry entry with the bridge URL per participant ID. Participants set up their own URLs; NHA does not do the mapping for them.

Question 11

If we have any question at integration time, whom do we contact?

Accepted Answer

Every integrator is assigned an independent SPOC to guide use-case-specific items. The official NHCX support email is hcx.integration@nha.gov.in (also given as hcx.integration@nhai.gov.in in one session) — send your queries there. There is also a WhatsApp integrator group; the link is shared on request. Session recordings are uploaded to the sandbox website.

Question 12

Is there a standard encryption methodology used across the whole insurance sector, and how does the digital handshake work?

Accepted Answer

Yes — RFC 7516 (JWE / JSON Web Encryption) is mandated in the NHCX protocol; any insurance partner — HDFC or anyone — must use only that encryption. To submit a claim you first fetch the recipient’s public key from the payer side (via the participant registry). Only the recipient’s private key can decrypt the bundle — so if a provider mistakenly sends an HDFC-policy claim to Medi Assist and Medi doesn’t have that provider’s key, they can’t decrypt it. That public/private-key exchange is the “digital contract” between provider and payer, and it happens in every scenario. Algorithm: RSA-OAEP; encryption method: A256GCM; integrity via a JWS signature (AEAD). NHCX itself is “data-blind” — it cannot read the payload.

Question 13

If NHCX can’t read the encrypted claim, what does it actually validate, and how does it know which payer to route to?

Accepted Answer

Routing and validation use the protocol (protected) header, which carries: algorithm, encoding, HPR provider ID, status, timestamp, sender code and recipient code. The recipient code is how the request is routed to the correct payer. From that header NHCX validates: (1) the sender participant ID exists and is active in the registry (else “not an active participant / not authorized”); (2) the ABHA is valid; (3) the recipient is a valid registered payer (you can’t send to an unregistered participant). It also runs duplicate checks. The claim payload itself stays encrypted end-to-end and NHCX never decrypts it — only the two custodians (provider and payer) can read it, not NHCX, not IRDAI, not any authorized party.

Question 14

What data does NHCX store in its own ecosystem, and what is in the IRDAI registry?

Accepted Answer

NHCX stores mostly participant information, the protocol headers, the ABHA and the policy linked to that ABHA, and workflow IDs (which indicate the scenario, e.g. a discharge request vs a cashless claim submission). The claim information in the payload is encrypted and cannot be read. The IRDAI registry holds information on all insurance companies — name and the unique registration ID IRDAI assigns — so unregulated entities (a broker or a micro-insurance seller not regulated by IRDAI) get flagged as not part of the registry. Because NHCX can’t read the claim data, it doesn’t hold much beyond the headers — which also limits the “surveillance/transparency” concern around adoption.

Question 15

How do we track a claim’s status?

Accepted Answer

There is a set of status APIs. If you raised a pre-authorization and got no information, hit the status API to learn: whether the request was dispatched and successfully reached the payer; whether the payer is currently processing it and how long they’re taking; and whether they’ve completed processing and sent a response/approval back. All stages are trackable.

Question 16

Which doctor identifier must be sent, and which diagnosis/procedure code systems are accepted?

Accepted Answer

You must capture and send the doctor’s HPR ID (Healthcare Professional Registry ID). NHCX validates it in the registry — confirming the person is a doctor and their specialty — and correlates it with the selected procedure. HPR ID integration is mandatory: without a valid HPR ID the claim will not pass, because it’s validated in the backend. Diagnosis codes can be ICD-10 / ICD-11 / SNOMED CT; procedure codes can be ICD-9-CM PCS, ICD-10-PCM, SNOMED CT, or hospital codes (India still uses ICD-9 in places).

Question 17

Why are the APIs asynchronous, and is the claim resource different for each use case?

Accepted Answer

All India DPI (UPI, ABDM) use the async model to handle scale and payer-side processing time, so there are paired request/callback APIs: request↔on-request, check↔on-check, submit↔on-submit. The same Claim resource is used across all use cases from pre-authorization to claim submission — the system distinguishes new pre-auth vs resubmission vs enhancement vs discharge vs claim by the workflow ID in the protocol, not by a different bundle. Coverage Eligibility Request uses purposes validation/benefits/other; the Claim resource uses purposes pre-authorization/predetermination/claim. Each action also has a specific workflow ID (e.g. request initiated = 10, patient admitted = 11).

Question 18

Can integrators add extra/custom fields to the protocol (e.g. for regulatory reporting)?

Accepted Answer

Yes — the protocol is extensible via domain headers (a hash-map in the protocol header). Fields follow an X- naming convention, e.g. X-ABHA-ID, X-use-case-name, X-amount-preauthorized, X-procedure-code/X-benefit-ID. This lets a regulator query e.g. “how many claims from ABC hospital exceeding ₹10,000 with benefit code AB12345.” These are not mandatory in general (some may be mandatory for PMJAY), and only fields within the privacy framework are allowed — NHCX refuses fields like name, age, gender.

Question 19

The callback bearer token was an empty string in sandbox — is that expected? And is the token now a real token we must validate?

Accepted Answer

In sandbox the auth token was purposely not enforced (people just wanted to play and most didn’t have proper role credentials), so the check was removed — hence the empty bearer token. Now that ~two years have passed, it is being enforced: whenever you receive a callback you will receive the token, and it is a real token, not a sample. You must validate it — just as NHCX checks your token when you submit, you must check that a callback is a legitimate request from NHCX; otherwise someone in between could call your API with a dummy token. Validating it is a must.

Question 20

On the NHCX website there are many Postman collections and it isn’t as consolidated as ABDM. Is everything in one place?

Accepted Answer

(Taken as feedback.) Unlike ABDM — where the structure differs API to API — NHCX is straightforward: there is only one payload, and that payload has one bundle (a use-case bundle); the only thing that changes per use case is the domain object (the FHIR bundle), and the domain specifications / IG are already published. There are two Postman collections (sandbox onboarding and AWS/production onboarding), each organized into three sections: Onboarding API, Participant API, Use Case API. If something is still missing, give feedback and it will be incorporated and released.

Question 21

Who explains the FHIR bundle, and can you show a realistic insurance policy in FHIR format?

Accepted Answer

A detailed FHIR-bundle walkthrough needs a separate session planned with NRCeS. Sample bundles are available on the FHIR / NRCeS website, and once you start integration the integration team will help with exactly how these FHIR bundles are supposed to look for the insurance plan you request.

Question 22

When a patient registers, how does policy/patient data flow — do I push policy data or pull the profile back? Where does ABHA fit?

Accepted Answer

ABHA is the medium — it carries the KYC-approved patient details, so first connect the patient via ABHA. Workflow: when a patient enters the hospital, register them; move the file to the claim department; the operator enters the patient’s ABHA, mobile number and policy; on filling these, NHCX returns the payer, the processor (TPA), the patient’s ABHA/mobile and those details, while you fetch name, gender, date of birth etc. from your own registration table. (For a provider application you select the provider role; the payer/TPA is resolved after the request is processed — a TPA acts in the payer role.)

Question 23

How does a provider discover a patient’s policy in an emergency when they carry no documents?

Accepted Answer

NHCX maintains ABHA-linked policy data. Payers/TPAs link the ABHA number with the policy number and member ID (member ID matters because group policies share one policy number but differ by member). The provider calls a discovery / “get policies” API searching by one of mobile number, Aadhaar number, or ABHA number (policy number works too). It returns the list of policies for that identifier, including ABHA member ID, participant codes, product ID and policy number. Note that policy linking/de-linking is a payer-only capability — providers can only fetch already-linked policies.

Question 24

If get-policies already returned the policy, why run a separate coverage-eligibility check?

Accepted Answer

Because things change — policy suspension, upgrade or expiration may not be updated in real time by the TPA/insurer. So you call a Coverage Eligibility Request with purpose = “validation”, which returns whether the policy is in force. For PMJAY it also returns the family’s balance amount (up to ₹5 lakh, varying by state). To check a benefit sub-limit (e.g. once a year / ₹50,000 cap), call the Coverage Eligibility Request a second time with purpose = “benefit” (carrying policy number, member ID, benefit ID); the payer applies its own rules and returns the eligible amount — e.g. a ₹30,000 package where only ₹20,000 remains, so the hospital tells the patient the remaining ₹10,000 is cash. This prevents rejections.

Question 25

How do I know which documents a pre-authorization requires, and whether Aadhaar eKYC is needed?

Accepted Answer

From the insurance plan object — a hierarchy of coverage → benefits → per-benefit mandatory document requirements (as an extension). You pick a category (in PMJAY, categories are modelled as specialties, e.g. “general surgery”), then a benefit/procedure (e.g. “endoscopy”), and the required documents appear. Documents must be mapped from your HMIS records as structured FHIR-bundle documents, not PDFs. The same insurance-plan / policy-details API tells you if authentication is required: if it shows a Proof of Identity with Aadhaar, you must authenticate in real time (a scanned Aadhaar is not accepted); that call returns an access token to pass on all subsequent use cases. For PMJAY, Aadhaar eKYC is mandatory — claims can’t be processed without it.

Question 26

When and why is the Communication API used?

Accepted Answer

The Communication API is used when the payer has a doubt or query — either on the pre-auth (payer wants more documents/clarity after you submit) or on the claim (payer asks for more bills/clarity). It is started by the payer, who hits your server. Flow: provider initiates pre-auth/claim → payer receives it → payer initiates the communication query → provider receives and acknowledges → provider prepares and sends the response → payer executes and sends the final approval or rejection. When you receive the communication response you must return HTTP 200 for acceptance. Follow the “common mistakes implementation guide” and API-responses handling guide closely.

Question 27

What is predetermination and when do we use it?

Accepted Answer

Predetermination is where a provider wants to verify in advance whether the information they’re going to put on the claim is correct. Most integrators don’t use it because it’s just an extra request to the payer/server. If you do use it, use it before you submit the claim. It is an optional use case — you can avoid it.

Question 28

How do I test against a payer? On the dummy payer, how do I trigger a communication/query?

Accepted Answer

NHCX provides a dummy payer (documented as “Dummy payer implementation”) for provider testing; it supports all use cases. On the dummy payer: for coverage eligibility, send the payload with the check method and it responds. For pre-auth (PR), first submit/send the payload, then hit the process request API with access = approval / reject / query. If you send query, you then receive a communication request on your end; you prepare your payload and send it on on_request. The same applies to the claim case. If the payer raises no query, you simply get the approval status.

Question 29

After a claim is approved, how does the hospital know money was actually paid, and how do we contest a partial payment?

Accepted Answer

Claim approval ≠ payment. Once the payer pays and obtains the bank UTR number, it calls payment-notice/request to your system; you read it and update your records with the paid amount, UTR and TDS. This solves the pain point where insurers pay in bulk (e.g. ₹10 lakh for three patients) with no per-patient breakdown. To contest a partial approval, deduction or rejection, use a reprocess request (PMJAY calls appeals “erroneous claims”) — a Task resource carrying the claim number and reason; it goes to the payer, who reopens and re-adjudicates and responds via reprocess on-submit.

Question 30

Our HMIS is used by multiple hospitals dealing with multiple insurers. How can one application serve all of them?

Accepted Answer

NHCX is a standard protocol that manages all the communication. Two cases: (1) Get Policy — when a patient arrives you try to find their policy on NHCX, but it isn’t 100% guaranteed to be there because the payer must add the policy to NHCX when it’s released. (2) Fallback — the Participant List API returns participant code + name; the hospital selects the payer, fetches their certificate, builds the request bundle and sends it. Because everyone on NHCX follows the same FHIR structure, a bundle that works for one payer most likely works for others — though when you go to market you should check whether a given payer needs minor changes.

Question 31

Will there still be a need for TPAs once NHCX is at scale? Can hospitals drop the TPA desk?

Accepted Answer

NHCX provides a standard protocol/language; it is still up to the insurer whether to use a TPA or process in-house. The idea is not to eradicate TPAs but to make communication seamless and standardized — TPAs handle a large chunk of work (documents, communication) beyond just the money. But you won’t need multiple TPA desks, because the HMIS can speak to any TPA if all are NHCX-integrated. On the hospital side, if it’s a single entry from the system, you don’t need a separate TPA department — “your understanding is very much right.”

Question 32

Coders add ICD/CPT medical coding, and wrong coding causes rejections. Will NHCX help with coding accuracy?

Accepted Answer

NHCX embeds these codings in its FHIR standards; NHCX profiles use SNOMED CT and ICD-10. The coding/mapping issue is being worked on in parallel in collaboration with NRCeS. NHCX partially handles it via the insurance plan API — you get the list of all codes and procedures and how the insurance system uses them, giving integrators more clarity. HMIS applications often don’t enforce precise codes even while complying with M1/M2/M3, which causes rework — this known problem is being addressed.

Question 33

How does the payer share its list of services/benefits to providers, and which API is that?

Accepted Answer

Via the Insurance Plan use case — you fetch the insurance plan (in FHIR format) and receive the benefit/services information into your system in machine-readable form. When your patient arrives you fetch that information and list out the benefits and services. So the insurance plan is how you get the list of covered services, along with which documents are required and their limits.

Question 34

How will reimbursement claims work, and can I send documents to any insurer via a PHR?

Accepted Answer

Currently for reimbursement you print copies and send them to the insurer. In a future feature, via the PHR you’ll scan documents and send them to insurance companies. Every advanced insurer has its own PHR app, but you can’t send from (say) an HDFC Ergo PHR to another insurer — a PHR app enabled by NHCX will let you do that; it is currently being built. As of the webinar, no PHR apps had been integrated yet; the plan is to start with Aarogya.

Question 35

PMJAY is mostly northern India; southern states have their own schemes (Aarogyasri, Maharashtra’s Rajiv Gandhi). Will each state scheme need separate modification?

Accepted Answer

Right now only some state schemes are processed via NHCX, and only PMJAY is under the purview of NHCX today. Eventually, if all these state schemes also come onto NHCX, the implementation will be a similar sort of implementation — the same approach as PMJAY.

Question 36

PMJAY has complex billing logic (e.g. discounts on the 2nd/3rd procedure). Will NHCX APIs handle this? What extra APIs does PMJAY need?

Accepted Answer

For PMJAY you first fetch the insurance plan in FHIR format, which gives all scheme details in machine-readable form — for which procedure, which stratification, what documents are required and what to submit when — which should significantly ease these errors. Billing itself lies outside the purview of NHCX; NHCX provides APIs for coverage eligibility, pre-auth, claim, and payment notice. The APIs for PMJAY are the same as for private insurers — you might have one or two additional APIs — but the key difference is that PMJAY requires structured data exchange: you must build the native capability to send data in structured format. (PMJAY also requires mandatory biometric authentication of the beneficiary, vs OTP for private insurers, and defines ~2,700 procedures each with required pre-auth documents.)

Question 37

Where can I download the ~700 (or 2,700) PMJAY procedures, and what is the PMJAY family cover?

Accepted Answer

The health benefit packages are available online on the PM-JAY website itself. PMJAY provides a ₹5 lakh family cover (varying by state — e.g. Odisha, Maharashtra, Uttar Pradesh have different limits, derivable via the policy code from the first API), and its insurance plan lists 2,700+ benefits (packages bundling diagnostics, medication, consultation, bed fees, etc.). If you complete PMJAY integration successfully you can get your HTC (go-live) done with the PMJAY payer.

Question 38

How should GIPSA / PM-JAY standard treatment packages be represented when they don’t map to SNOMED CT?

Accepted Answer

GIPSA packages don’t map directly to SNOMED CT codes. The workaround for now is to list the individual services within a package as separate line items in SNOMED CT. NRCeS is working on a PM-JAY package-to-SNOMED CT mapping and will submit content requests to SNOMED International if needed.

Question 39

Are the v1.5.0 (FHIR 6.5) changes breaking? Will old code still run, and how do I update my validation tooling?

Accepted Answer

No — all changes are non-breaking / backward-compatible; old code continues to run. All new value-set bindings are example bindings (not mandatory), but NRCeS recommends adoption. New implementers on 6.5.0 can interoperate with 6.0 systems (backward compatible), but not vice-versa; adopt the latest for richer analytics. To update tooling, set the package identifier to ndm.in#NDHM version 6.5.0, and in programmatic validation change the package version 6.0 → 6.5.0. Published example artifacts are reference-only — do not use them directly as templates; adapt them to your scenario. A feedback form is on the IG website (error in examples / change request / comments / technical corrections).

Question 40

In the Task bundle, what value do I use for input/output type?

Accepted Answer

Rule: when the input/output is a complete FHIR resource, use type include; when it is a string identifier, use the exact type name (claim-number, policy-number, etc.); when it is a status acknowledgement, use type status. Examples: Reprocess → input claim-number (string), output include (ClaimResponse); Payment Notice → input include (PaymentNotice), output status; Insurance Plan → input policy-number (string), response is the InsurancePlan resource directly; Communication → input include (CommunicationRequest), output include (Communication).

Question 41

Can we see a comparative analysis of the new IG version vs the old — what changed in each FHIR bundle?

Accepted Answer

Those details are available on the IG page itself — the version-history / highlights page lists every change. The presentation walks each workflow (e.g. claim submission), the specific API used, the exact value-set binding, and the precise FHIR element where the change occurred; the published examples also illustrate the changes. Key profile changes recapped: Claim identifier cardinality 1..1 → 1..*; ClaimResponse adjudication.reason made optional 1..1 → 0..1; Claim request element made must-support; Task reasonCode made must-support (with its own value set); PM-JAY extensions claim-condition and claim-supporting-info-requirement added at benefit and plan level.

Question 42

We found an example where “ambulance” is listed as equipment rather than a service — an insurer copied it and sent it to us. What do we do about wrong examples?

Accepted Answer

If that’s the case it should definitely be corrected — please email it to NRCeS and it will be fixed in the next release. Important clarification: examples are for reference only and cover a single scenario. Many implementers take an example, just alter the values, and send it for validation — but an example only shows one instance; you may have other information that must be incorporated. Several implementers have reported such issues, which is why the “Other updates” already include refreshed examples — it’s a continuous process, updated immediately on feedback (a feedback form/label is on the IG site).

Question 43

We recommended adding form codes for enhancement approval, discharge, etc. Have those been taken up?

Accepted Answer

Currently the form-code element expects only two documents by scenario: an approval letter and a denial letter. For any additional scenario, email NRCeS the exact scenario. Rationale: ideally all information should be captured in structured FHIR resources; the form-code element is only for sharing a document, and NRCeS does not want everything going through as scanned copies because implementers would then stop filling structured data. So NRCeS first needs to understand whether the information in that document can instead be captured in a structured FHIR element — if it genuinely cannot, a form code can be considered. Share the exact need (a one-to-one call can be arranged) and it can be incorporated if justified.

Question 44

When a claim is rejected/partially approved and we build the Task bundle, do we also include the revised claim? And must we adopt v1.5.0 immediately?

Accepted Answer

Yes — for reprocessing you include the revised claim; you do it via the reprocess (repro) API. On adoption: there is no mandate — adoption is recommended, not forced (just as SNOMED CT use itself isn’t mandated). But the NHA team added: if you do not adopt it you stay on the older data set, and new implementers using the new code sets/structures will not pass validation against your system — it’s a versioning system (forward-compatible systems can consume data from backward-compatible ones, not vice-versa), so keeping up to date is strongly recommended.

Question 45

Is NHCX actually live, or not? (asked repeatedly)

Accepted Answer

“NHCX is very much live and is processing claims.” Production stats (as of the Aug-2025 webinar): 46 integrators on production; of 31 insurance companies, 28 live and 3 under development (~M1); 11 TPAs and 7 DSCs onboarded; 537 private hospitals processing claims; 90,000 insurance policies linked to unique ABHAs; 228 insurance products onboarded. Separately, the PM-JAY claims management system runs entirely on NHCX as the gateway — live in 34 states, processing more than 1 lakh claims daily, with 34,000 hospitals onboarded. (The Orientation Day-1 deck gave an earlier/different snapshot — 39 insurers/TPAs, 692 hospitals, ~118,000 ABHA-linked policies as of March 2026.)

Question 46

Is there any financial incentive for hospitals to onboard NHCX?

Accepted Answer

Yes. NHA is offering a cash incentive because mid/smaller providers need help (insurers had already spent ~18 months onboarding). The incentive is 10% of the claim value or ₹500, whichever is lower, for hospitals that submit claims via NHCX. (At the Innovation Meet, Dr. Nillesh Pandari called this ₹500/claim “the first time ever seeing a financial incentive for standardization.”) For details, contact the on-site NHA representative.

Question 47

What is NHCX in one line, and how much does it cost to process a claim today?

Accepted Answer

NHCX is like a router — a middle layer between provider and payer. Whichever payer you communicate with, you use one system of your choice, send your claim / pre-auth / status query to the exchange, and it relays it to the right payer and brings the response back — like sending email from Yahoo to Gmail, with standardization coming from a common protocol (as SMTP does for email). Processing a claim today costs an estimated ₹500–₹800 per claim (a figure from industry participants), which is why OPD is out of the question — the cause is non-standardization → manual processing. (At the Innovation Meet, ~₹7,800 per claim was cited for some segments.)

Question 48

Can NHCX/HFR help detect fraud (e.g. blacklisted facilities)? Should M3 be mandated?

Accepted Answer

Currently only M1 is mandated, but the team thinks M3 should also start being mandated. On fraud: whether a facility has been blacklisted can be checked via HFR. M3 matters because at policy issuance the insured often never shares their real health history and the insurer has no way to find out — so if insurers do M3, it would help identify potential fraud cases.

Question 49

Small hospitals fear ABDM/data transparency means losing patients to competitors — why comply?

Accepted Answer

Counter-argument offered at the Innovation Meet: there are incentives for data sharing, and quality of care — not data secrecy — is the real patient-retention factor (referencing the “7 touchpoints” paper). The broader adoption playbook, per Dr. Nillesh Pandari, is incentives → integrators → soft mandate → hard mandate (the arc UPI, GST and ABDM all followed).

Question 50

Under the DPDP Act, how can NHCX data be used for secondary purposes without violating privacy?

Accepted Answer

Through anonymization — effective anonymization may remove “data subject” status, enabling secondary use. IRDAI’s Mano Chhatlani added that DPDP compliance needs more than tick-box consent: an explicit declaration that the patient knows their claim data is being evaluated, with consent captured both at policy purchase and at claim time.

Question 51

Startups report ~6-month NHCX empanelment delays and doctors resist digital data entry — what’s being done?

Accepted Answer

The empanelment delay is acknowledged as a friction point (context: ~400 ABDM apps at M1/M2/M3 milestone, 1,700 in pipeline; an IRDAI + NHA joint working group was formed to resolve real-sector friction, meeting hospitals and insurers separately then jointly on Jan 17). On reluctant doctors (e.g. Rajasthan, J&K), the root cause is lack of awareness and the fix is training programs (NABH runs 96 awareness programs/month and IT-consultant training). For state adoption, a phased approach — voluntary → incentivize → mandate — is recommended; Andhra Pradesh made HP ID and HFR ID mandatory for hospital empanelment as a foundational step.

Question 52

What is the single remaining challenge for NHCX, and how is private-hospital onboarding going?

Accepted Answer

“Technology is solved — change management is the only remaining real challenge.” NHCX already routes PMJAY + CGHS pensioners + CAPF + an ESIC pilot + multiple state schemes. The challenge is onboarding private hospitals (~700 on NHCX vs 34,000 on PMJAY). New PMJAY impanelments now require an ABDM-enabled HMIS, used as an adoption lever. The next frontier is full digital claim settlement, not just submission. (Medi Assist’s Satish Gidugu noted only ~140 hospitals send via NHCX vs 14,000 via email/PDF, and recommended mandating digital service companies to push a copy of every transaction through NHCX.)

Question 53

Can standards move claim settlement from a dispute-driven to a data-driven process, and is going digital-first worth it?

Accepted Answer

Yes — through semantic interoperability (clinical coding), structured documentation (FHIR), API-based technical interoperability, workflow harmonization and common rejection/query codes. On the value: 3.26 crore private insurance claims were processed in 2025; if NHCX saves 30 min for the insurer + 15 min for the hospital per claim → ~20 lakh manhours saved → at ₹2,000/manhour → ₹300–400 crore in time savings alone. International proof point: Brazil’s TISS (2007–2010) succeeded because standards were co-created with the whole ecosystem plus a 12-month window after which insurers could reject non-compliant claims.

Question 54

Can claim adjudication be fully automated, and how far away is full NHCX maturity?

Accepted Answer

Non-medical adjudication can be automated; medical decisions require a human in the loop (HDFC Ergo’s Naman noted pre-existing-disease detection needs human review because the system can miss undisclosed conditions). On maturity, Care Quality India’s Vinod estimated the ecosystem is “3–4 years away from full NHCX maturity” for multi-system hospital groups, because diverse legacy HMS aren’t yet FHIR/HL7 compliant and some can’t even expose APIs. The biggest single adoption incentive cited was settlement certainty within 48 hours of submission.

Question 55

Who is already connected to NHCX, and what data formats can flow through it?

Accepted Answer

On the payer side, 51 entities were connected including 28 insurance companies (Bajaj was a front-runner); five workshops were run, including three-day pure-technical sessions in Delhi with insurers, TPAs and healthtech firms. Three data formats can flow through the exchange: (1) completely unstructured (scanned prescriptions — hard to OCR, not fully solved); (2) semi-structured (system-generated PDFs like diagnostic reports — easier, a solved problem); (3) fully structured (discrete values like RBC/WBC fed directly). Structured data is what enables auto-adjudication — reducing time, errors and cost.

Question 56

How is NHCX asynchronous / how does it not read the payload — and does it store adoption/surveillance data?

Accepted Answer

NHCX is asynchronous: the hospital sends a claim → NHCX routes to the payer → the payer sends a callback response. All payloads are wrapped in JWE (RFC 7516) using RSA-OAEP + A256GCM, with a JWS signature for integrity; the sender fetches the recipient’s public key from the participant registry before encrypting. NHCX does not decrypt payloads — the gateway is data-blind. A dummy payer supports all use cases (UC1–UC12) for provider testing. Because NHCX can’t read the claim data, it doesn’t hold much surveillance data — only header information.

Question 57

You said beneficiaries can also hook onto the platform — what’s in it for them?

Accepted Answer

The patient/beneficiary can hook onto the claims exchange via an ABDM PHR app and see, in real time on their phone, what is happening with their claim. If a patient is not getting discharged even after two hours, they can see what is actually happening — so they won’t trouble the hospital. The beneficiary becomes an additional monitoring party, completing the whole grievance cycle: if you leave the patient out and only connect payer and provider, the grievance cycle doesn’t get fully completed. (Note: ~4 minutes of this answer were lost to an audio dropout in the recording.)

Question 58

Adoption really depends on the HIS/health-informatics companies, not hospitals. Are you running a session to orient them and create urgency?

Accepted Answer

Health-informatics companies are exactly the entities NHA intends to nurture as part of the ABDM framework. When the claims-exchange integration started, the ones that could be contacted are those presenting today, but NHA intends to bring more in. NHA is planning a developers’ conference — something similar to what Google does — very soon, in July, concentrating not only on the ABDM APIs but also on the claims-exchange APIs, to disseminate this to every health-tech company; invites will be sent to all.

Question 59

Will the TAT be defined for the whole journey (pre-auth → settlement), and who sets it?

Accepted Answer

Who sets the TAT today? Mainly the insurance companies (e.g. for pre-approvals). Administratively, if the TAT requires reform, that is for IRDAI and GIC to come together and change. What NHCX does is ensure that whatever TAT is decided is encoded and can be measured in real time. The administrative/policy part is decided by the regulator; if the regulator sets a TAT for everything, that becomes part of this and gets monitored in real time.

Question 60

Can patients or hospitals raise grievances on the same platform?

Accepted Answer

As of now, NHA has not built a separate API for grievances — GIC would have to step in, and the existing grievance mechanism would have to be built separately, so grievance handling is not covered here yet. But NHCX can make all the data available for grievance handling — the full history: claim submission, response, query, and re-raise (RA) response — whether the grievance mechanism itself sits within this platform or outside it.

Question 61

[Posed by NHA] What are the five NHCX-hackathon problem statements?

Accepted Answer

PS1: convert a legacy HMIS into an NHCX/ABDM-compliant FHIR bundle (an open-source connector so hospitals don’t replace systems). PS2: turn scanned/PDF documents into a structured FHIR bundle (enables auto-adjudication for not-fully-digital hospitals). PS3: convert an insurer’s PDF product documents into a FHIR InsurancePlan object. PS4 (ideathon): how can NHCX reduce FWA — fraud, waste & abuse (context: 15%+ of claim cost is FWA; “abuse” is hardest to detect; 0% FWA is aspirational). PS5 (ideathon): what more can NHCX do to optimize claims processing time and cost (context: ~₹7,800 per claim today; OPD isn’t viable at that cost).

Question 62

For the ideathon PS4/PS5, do we need working code? Where and how must deliverables be submitted?

Accepted Answer

No code for the ideathon PS (PS4/PS5) — only a business case + approach + business value. For the technical PS, code must be uploaded to GitHub; the end-to-end demo video (max 5 min) plus a README.md (scope, architecture, setup, dependencies) must be zipped with an MD5 hash and uploaded to Google Drive, with the link shared to NHA’s Gmail ID. Process: download artifacts → initial screening → shortlisting → demo on the participant’s own environment → final evaluation. For PS2, create the FHIR DiagnosticReport bundle and optionally embed it in a pre-auth/claim bundle.

Question 63

What is the prize pool, is open-source required, and when is the jury demo?

Accepted Answer

Total prize pool ₹50 lakhs across PS1–PS5. PS1, PS2, PS3 must be open-source. The submission package (Masterclass 2 update) = README + video demo (max 5 min) + source code (zipped + MD5) + a sample FHIR output bundle + a FHIR mapping Excel sheet; PS4/PS5 = business case only. The jury/live demo is tentatively March 3rd for shortlisted teams; the final event is the NHCX Innovation Meet Grand Finale at IIT Hyderabad. NHCX is designed to evolve — suggestions on feature direction are welcome.

Question 64

What IRDAI SLAs must the solutions respect, and how much claim intimation still bypasses the portal?

Accepted Answer

IRDAI mandate: cashless pre-authorization within 1 hour; discharge approval within 3 hours. The SLA clock starts from the first document received; if the hospital is queried for more documents, that wait time still counts against the SLA. Currently about one-third of claims still reach insurers via email rather than the portal/NHCX — a business case targets automated claim intimation to improve portal compliance.

#	Session	Date	Answered by
S1	Functional Overview — Orientation Day 1	Mar 2026	NHCX functional team
S2	Technical Architecture — Part 1 (Day 2)	Mar 2026	Yagnesh (core architect)
S3	Technical — Part 2, Postman (Day 3)	Mar 2026	Yogendra (integration team)
S4	NHA Webinar	Aug 2025	Raghav, Meghna
S5	ABHA-M1 + Payer Workshop (NHA + GIC)	10–12 Aug	Narendra, TCS leads, Yagnesh, Pankaj (IRDAI)
S6	Bajaj Allianz Awareness Workshop, Pune	~2024	Kiran Gopal Vwaska (NHA)
S7 / S8	NHCX Hackathon Masterclass 1 & 2	Late 2025 / Jan 2026	Farukq, Dr. AJ (NHA), Chinmay (NRCeS)
S9	HFR ID Registration guide	16 Jun 2024	Dr. Harikrishnan
S10 / S11	NHCX Innovation Meet 2026 — Day 1 & 2, IIT-H	Jan 2026	NHA CEO, IRDAI, IIB, NABH, SHAs, industry
S12	NRCeS Webinar — FHIR IG v1.5.0	Jul 2025	Sonali (NRCeS), Raghav, Vishwajeet
H1–H5	ABDM PM-JAY Auto-Adjudication Hackathon	Apr 2026	NHA, NHIT, IISc, domain profs

Questions asked to & by the NHA / NHCX team.