Every question asked to and by the NHA and NHCX team.

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.

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.

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.

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.

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).

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.

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).

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.

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.)

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.

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.

For KYC only two documents are currently allowed. In the mobile-OTP flow, if you already have an ABHA an OTP is sent to your ABHA-linked mobile, you log in, and you still ultimately give Aadhaar; an OTP is sent to your Aadhaar-linked mobile, the Aadhaar system authenticates it, and you get an ABHA back. The preferred route is Aadhaar mobile OTP or biometric, because the IRDAI circular requires collecting an ABHA for each and every person. (The V3 ABHA-creation API is the current, faster process.)

Yes — use Demographic Auth (demo auth), which takes four fields: Aadhaar number, name, DOB and gender. It verifies against the Aadhaar database; if no ABHA exists it creates the ABHA number and returns it. It creates without taking consent from the beneficiary, but a notification/communication must be sent to the beneficiary, who then confirms on the system.

No — de-duplication is done on the Aadhaar number. Demo auth first verifies that the passed name/DOB/gender match the Aadhaar record; if they match, the ABHA system checks whether that Aadhaar already has an ABHA — if so, you get the same ABHA number back, not a new one. The same check applies for driving licence.

You can use the same mobile number for all your family members / multiple ABHAs — this is allowed in the ABDM system, just as families share one mobile number on insurance policies.

No multiple ABHA numbers — one Aadhaar connects to one ABHA number. However, one person can have multiple ABHA addresses. The ABHA address is like a UPI handle (e.g. narendra.singh1743), used when a person doesn’t remember/carry their number and for linking of health records across systems. It has nothing to do with a communication/postal address.

Name, gender and DOB are taken as per the Aadhaar card. When you do the mobile-OTP workflow you get the ABHA address along with the name — you must validate it’s the same individual and only allow the name that matches the ABHA. On a CKYC-vs-Aadhaar name conflict: as of now there is no provision to resolve it (“not there as of now”) — guidance is to go by the Aadhaar name; IRDAI noted the regulation should permit issuing per the ABHA/Aadhaar name even if CKYC used PAN, but that clarity has to be brought in.

Yes — the edit-profile option allows it. Once you log in with your previous mobile number, after validation you can update your mobile number.

ABHA creation is for beneficiaries, not payers. The login/edit/download actions belong to the beneficiary — as a payer you create the ABHA, keep it as a record, and it is sent to the beneficiary by SMS; what the beneficiary does with the login (e.g. changing the alias name) is their choice. You create the ABHA number; the customer provides the input to create their own ABHA address(es) via the portal.

Yes, currently you require OTP. You submit the mobile number; an SMS OTP goes to that mobile; when entered, an API exchange returns the details. In the agent journey, the beneficiary receives the OTP (or a link) and shares it with the agent, who enters it on the platform to complete the journey. For existing users, once the OTP is validated the back end returns the ABHA number(s) linked to that mobile, shown with the member name so you pick the right one.

Every individual must have an ABHA — ABHA is not a family construct. You create an ABHA for each and every beneficiary, like the unique UHID per member in existing health-insurance policies. You can add multiple policies/products at one go, but only for one individual at a time (the process runs at ABHA-creation time per beneficiary).

Via a link-policy API (with a corresponding de-link API), already on the portal — this is part of the M1 phase. During testing you keep the ABHA and also report/link it with NHCX; once tested and production keys are issued, the actual linking happens in production. It is prospective only, not retrospective.

It’s at your convenience — NHA is not mandating. You can build a separate bridge software instead of disturbing your core system; ultimately the data should also sit in your core system. How you do it is up to you.

Either the ABHA ID or ABHA address can be used; the ABHA ID generally verifies a valid user, while the address can target documents tied to a specific address. When fetching health records, the person must give consent and selects which documents to share — not everything comes automatically. For testing there is an ABHA app you use when you integrate M3 APIs (M3 = data share); the consent must be captured (available from the site).

You should not allow capture without verification — if the customer has no ABHA, the insurer must be able to create one. Technically, NHCX will not even accept the claim request unless you send the ABHA number. It won’t stop service for the beneficiary (NHCX itself is optional), but without an ABHA they cannot leverage the ABDM/NHCX ecosystem benefits (consent-based digital exchange of records). ABHA is the identifier used to validate the beneficiary.

ABHA is not mandatory on the proposal/renewal form — you must facilitate and educate customers to give ABHA (and consent for records), but it is entirely optional and cannot be made mandatory; neither the policy nor the claim is prejudiced by not having it. However, to be part of NHCX the ABHA is a must — the claim will not move to NHCX without it. Since there’s a time gap between issuance and claim, you can nudge the user to create/give ABHA later, even during hospitalization.

No. NHA is not syncing data with CERSAI — you will not get the ABHA from the CERSAI response. (A suggestion to link the ABHA journey with the KYC journey to reduce the ~3 OTPs was taken as a suggestion, with no committed solution.)

You’ll have to find ways — e.g. for a group of policyholders you have the contact of the person in charge; ask them for the ABHA numbers, citing the IRDAI circular, and ask the banks (PSUs, HDFC, ICICI) to start creating/ providing the ABHA IDs. IRDAI clarified it is the insurance company’s responsibility to ensure ABHA regardless of channel — agent, bank/corporate agent, or direct.

You consume what they pass; you don’t have to re-verify (re-verification would be very difficult given the automation). NHA will also reach out to aggregators (and via IRDAI) to ensure they do their part, and will prepare a short SMS insurers can send customers with a link to create ABHA; once M1-integrated you can send your own policy-specific link.

You cannot go directly to M2 — you wouldn’t even have the ABHAs in your system. M1 is the starting point (identification of a person). On the TPA role: it is defined in the regulatory framework and you must get clarity from your insurer; TPAs were invited because PSU general insurers said all their claims are handled by TPAs.

If your system, while issuing the policy / capturing the buyer’s details, has the feature to create an ABHA or verify whether an ABHA is correct, it is M1 compliant. For the deadline (12th August) the scope is only the M1 process — ABHA creation/verification + linking the policy — not the other NHCX use-case APIs (those need insurance plans and more to be published). The accelerated integration workshop runs 10th–12th August; go-live gating = functional testing + a VAPT security test by a CERT-empanelled agency → a 3-member committee sees a live ABHA-generation demo → production keys.

No bulk provision — neither bulk ABHA creation nor bulk linking. The link-policy / link-ABHA-by-ID API exists and, if you’re M1-compliant and already have the ABHA, you call it — but it takes one at a time (you can run a scheduler calling it repeatedly). NHA acknowledged the cost/performance concern for millions of transactions but said it’s a design choice; for a bulk kit, send the request in writing (what is needed and why) for consideration in a second phase.

For NHCX there is only one released version — version 1. For ABHA creation, the documentation being shared is for the V3 API (a faster/easier process) and that is what’s available now — but whatever version you’re already developing on, you can continue with that if you’re mid-development.

Sandbox registration is good enough — once registered you get a client ID; but for NHCX you additionally need to register as a participant in the NHCX participant registry via the enabled APIs (linking ABHA with the policy through NHCX is also part of the M1 journey). For any NHCX query (including the UID header parameter during participant creation), send it to PM.adoption@nha.gov.in (M1 tech contact: Vishal Vishwakarma); NHA also proactively calls each company’s tech SPOC.

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.

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.

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.

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.

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).

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).

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.

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.

(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.

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.

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).

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).

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.

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).

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.

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.

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.)

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.

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.

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.

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.

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.

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.

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.

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.

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.”

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.

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.

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.

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.

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.)

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.

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.

“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.)

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.

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.)

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.

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).

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.

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.

“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.)

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.

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.

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.

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.

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.)

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.

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.

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.

Audience: “Yes.” Used to illustrate information asymmetry — the hospital doesn’t know what’s covered/allowed, and the citizen doesn’t know where the delay sits (hospital, TPA or insurer). NHA also posed a DPI-speed question: an economist predicted 47 years to reach 80% bank-account saturation for adults; via Jan Dhan/Aadhaar/eKYC it took ~5 years — the point being DPIs like NHCX solve population-scale problems far faster than predicted.

Every participant (provider or payer) registers in the NHCX registry and uploads a public certificate. A provider bundles the claim per RFC 7516, fetches the recipient’s public certificate from the registry using the participant/provider code, encrypts, and sends. Only the intended recipient can decrypt using their private key — so NHCX transports but never reads health data.

IIB collects policy/member/claims data from all 58 insurers (real-time from 32 health insurers daily). Variability is categorized: operational (different settlement ratios for same product/location/condition — easiest, non-clinical), provider-behavior (same PIN code/hospital group/condition, wide variation in length of stay and bill), geographical (culture/politics — harder), and medical-condition (India becoming a “capital of NCDs”). Proposed synergizing IIB’s 75,000 validated-hospital registry with NHCX’s HFR to avoid a duplicate national registry.

Aarogyasri digitized ahead of the industry — starting ~2007 — and now runs nearly paperless, “more like an IT office than a government office.” It is digitized but not yet automated; claim automation is targeted within a few months, the challenge being to bring adjudicators/doctors on board so they don’t feel threatened. Hospital resistance has three roots: (1) parallel cash economy (low GST, habit of paper); (2) heavy IT capex that may not show ROI; (3) trust in data usage — cited a state that used data for tax notices, driving merchants back to “cash only.”

Of ~1 lakh private hospitals, ~60–70% have <50 beds, and ~60% of those have no digital ID. Interventions: (1) a progressive maturity framework — Silver/Gold/Platinum (Silver = foundational digitization + a cybersecurity/privacy layer); (2) an entry-level certification; (3) empaneling IT consultants via a 3-day training to run gap assessments and build ROI-aligned digital roadmaps; (4) ~96 awareness programs/month plus “digital mitras.” Result: a 30-bed hospital in Manipur and small hospitals in J&K signed up; 1,800+ hospitals applied in ~1.5 years. A KPI-first approach works even for a 20-bed hospital.

Providers send bundles following the NRCeS IG profiles, but there are discrepancies in where resources are placed within bundles, creating ambiguity — a published blueprint telling all stakeholders exactly what to send where would minimize this. On billing: the US uses proprietary CPT codes (~10,000) unusable in India; SNOMED CT can serve both — clinical coding and billing (SNOMED codes exist for procedures) and can map procedures to ICD diagnoses. The “invoice record” HI type in ABDM (Milestone 2) can be used by providers for billing. For scalability, prefer structured FHIR JSON over Base64 payloads, and adopt unified procedure codes nationally (CGHS/SHAs each use different codes today).

Standardization is “the key-lock for AI-based claim applications.” FHIR-based setups shift the process from document validation to data validation, making exchange far faster, and with ABHA/ABDM, AI makes fraud/abuse/waste identification much faster while adding clinical context and shrinking turnaround. IIB’s 2-year roadmap targets five dimensions: policyholder value (public comparison dashboards), industry growth (50+ use cases; real-time new-hospital alerts to all 32 insurers), affordability (build a medical-inflation metric for India, which doesn’t exist centrally), governance, and FWA — where >15% of claim cost is fraud/waste/abuse (abuse is hardest; 0% FWA is aspirational).

You “cannot enforce, but cannot ignore” — the sweet spot is where standardization brings efficiency without creating friction. Clinical decisioning cannot be standardized (two orthopedic surgeons will treat the same case differently); you can only standardize “primary boundary” checks (is he really an orthopedic surgeon? does the case require replacement?). Among the 32 insurers some are decentralized PSUs, some real-time digital insurers — one standard can’t fit all. IIB’s practical lever is motivation, not enforcement: give daily claims data, get back a complete hospital profile.

NABH: start with KPIs first — a 20-bed J&K hospital now submits all KPI data online because it defined ~5 KPIs, broke them into functions, and identified 3 mandatory data elements each — no sunsetting of legacy apps needed. IIB: data quality is “not a technology issue as much as a human issue” (a very common error is wrong ICD codes from untrained coders) — so prefer brownfield enhancement, prioritizing super-impactful fields from the human angle. NRCeS: the systems problem is “not bigger than the process and people problem”; NRCeS handholds startups to standardize (coding systems, FHIR).

IIB: data quality is the serious challenge — until last year IIB struggled just to get data; now it gets real-time data from all 32 insurers and the new challenge is quality, worsened by the separate TPA industry generating claims data and the barriers between insurers and TPAs. Prof. Nagarajan: work in interdisciplinary teams — hospitals, insurers and tech teams must sit together so it feels collaborative rather than enforced. (Also raised: the problems are “not well defined” — SHA agreed requirement-gathering is the hardest part, which is exactly where innovators come in.)

Move from a broad-brush average to an equitable, evidence-based model. Today a “standard” life gets an average premium with no medical info collected — a “data void” at the moment of a lifelong promise. AI can plug it via non-intrusive app-based scanning (e.g. a face scan capturing vitals at point of sale) to set a health baseline, and with standardized data from NHCX, ABDM and IIB, move from age-based pools to evidence-based risk groups. Caveat: many ML models are black boxes lacking explainability — “incompatible with actuarial principles of accountability, explainability, and regulatory requirements.”

“You’ve hit it very right.” Differential charging exists not only insured-vs-uninsured but between private insurers and PSUs — the four PSUs via GIPSA negotiated harder rates (some hospitals give maternity at ~₹30,000 as a package). Charges are unpredictable (same ailment ₹50,000 for one, ₹75,000 for another); insurers apply “reasonable & customary” limits. The GI Council, regulator and government have started discussing hospital price regulation. A big underlying factor is the missing medical-inflation data — nobody knows why medical inflation runs ~14–15%/yr; a working party is building a medical-inflation index.

We don’t see NHCX as merely a compliance mandate — it’s a powerful platform. Three pillars enable the transformation: (1) Transparency — today we integrate separately with many TPAs/DHS providers/hospitals at huge cost; NHCX changes that; (2) Standardization — every hospital/TPA sends different data points; standardizing (EHR/PHR/FHIR) speeds claim processing; (3) Fraud/claims analytics — transparency plus standardization lets us analyze customer data/behaviour. Net goal: interoperability across the whole ecosystem.

Regulatory TAT pressure pushes speed, which increases risk in an unstructured ecosystem (tariffs and bill formats differ per hospital). Rule-based works for defined procedures like cataract or maternity. Risk splits into non-medical (manageable with AI) and medical (needs a human in the loop — only the treating doctor knows the real condition; over-automation risks paying illegitimate claims or missing undisclosed pre-existing disease). On timing: a morning-suggested discharge typically takes 5–6 hours; the regulator’s 3-hour window only starts when the document reaches the insurer. Cost is the risk at the epicenter.

Tech investment spans 7–8 workflow streams from patient-identity validation to reimbursement, with intermediary communication layers for pre-auth/enhancement/discharge and per-insurer requirement checklists (an area NHCX could standardize). These cut submission timelines from upwards of 45 days to under 15 days. Apollo did its first NHCX sandbox test in 2022. Internally, creating discharge summaries from day two and appending daily shrinks final-day time; the biggest remaining sink is medication reconciliation, which needs more automation.

Quality Care India runs three brands with huge heterogeneity — itself proof there’s no standardization. The challenge is broad (diverse legacy HIS often not FHIR/HL7-compliant, needing custom connectors) and deep (no data-model standardization; some systems can’t even expose APIs), with evolving DPDP (2023→2025) compliance on top. NHCX is a fantastic step but can’t solve all of it yet — we’re probably 3–4 years away from maturity. For a 10–20-bed hospital it’s an investment case; the enablers are the ABHA ID (value depends on record-linking) and possibly certification/enforcement of standards hospital systems must support.

Lack of data standardization is not new (same complaint since ~2005). What’s different now is the financial hook: you get reimbursed if your data is standard through NHCX — the first time there’s a financial incentive to adopt standardized data. AI + the hackathon connectors convert legacy PDFs/Excel into FHIR bundles (far more realistic than replacing legacy systems). India has a 10–12-year-old DPI playbook (UPI, GST, ABDM): start with incentives (₹500 extra per claim), get ~15–20–25 HMIS integrated, then apply slight mandate nudges. Plus 91 is a certified early NHCX integrator.

For sub-100-bed hospitals: (1) most of their patients come via government policies (Ayushman Bharat / state cards), and their systems capture those IDs, not ABHA — so pushing NHCX requires making state schemes ABDM-enabled; (2) most have outsourced the TPA desk to a company managing ~50 hospitals, whose staff just scan and upload — causing duplication, wrong-patient documents and missing data. NHCX standardization (FHIR structure, HI types, required parameters) helps. ~70% of sub-100-bed hospital revenue relies on government policies, and the biggest levers are awareness plus incentives (cost isn’t the barrier since the desk is already outsourced).

Data reaches the insurer encrypted (keys held by hospital and insurer), so NHCX may not see transit data. Data used to process the claim is primary consent; using it later for promotional activity is not allowed without prior explicit consent. For health-improvement programs where data is passed to third-party experts, the DPDP Act requires consent beforehand. And under the 2023 Act, if you do effective anonymization the data effectively ceases to be personal data — a viable path.

On data-sharing fear: the widely-cited health-systems research (a patient needs ~seven touchpoints) suggests that if the provider gives enough quality of care, interoperability fear doesn’t enter the patient’s mind. The Digital Health Incentive Scheme (DHIS) already incentivizes on linking records — and the point about the duration/long-term stability of DHIS (so vendors can confidently sell ABDM-compliant systems) is very important and was noted by the CEO.

Andhra runs its scheme in trust mode (no insurer), spending ~₹3,600 crore/year, settling 16.5–17 lakh claims/yr (~5,000–5,500/day, ~₹12 cr/day) with ~300–400 specialist doctors adjudicating (~40 claims/day each). Claims upload as unstructured JPG/PDF/video and ~30% go back for referrals. AP is making all HMIS (public and private) ABDM-compliant for structured data and using better OCR/AI; ~25% (₹900 cr) of spend goes to public facilities to attract specialists. AP mandates HPR ID and HFR ID for empanelment as a foundational step.

IRDAI is a co-host/enabler. A well-designed digital cash-flow needs three parameters: (1) policyholder protection (reduce settlement-delay uncertainty); (2) market conduct (reduce payer–provider friction via standardized, interoperable, trusted data); (3) monitoring (live trend monitoring and quick outlier detection) — with data privacy/security non-negotiable. On consent: a tick-box is a “dark pattern”; a separate, comprehensive declaration should be taken from the policyholder — that records are being taken and may be evaluated for settlement — at both policy-purchase and claim time. Live data is itself a guardrail because outliers can be caught proactively.

Medi Assist’s day-one problem in Oct 2013 was “the fax machine is broken”; today ~85% of cashless is an electronic workflow, but the private side still has 35–40% reimbursement by volume needing manual understanding. “Almost all inefficiency comes from lack of standardization” — most insure-tech bandwidth is wasted converting unstructured to structured data; Medi Assist spent six years digitizing bills from 80,000 hospitals → 3 crore SKUs. The single best move: get out of the HMS — “just give the Excel/CSV of the bill, not the PDF” — and mandate all digital-service companies to post a copy of every interaction through NHCX (today only 140 hospitals send via NHCX vs 14,000 by email; avg discharge TAT is a published 36 min; ~40,000 patients/month walk out on trust estimates before bills).

Honestly all three exist, but technology is not the issue — most tertiary/quaternary/premium hospitals already have an HIS, and the RCM department is now emerging. The clue for adoption: the incentive to a hospital should be that after NHCX implementation, settlement happens in 48 hours — bringing cash flow (money back not after 90 days), the most important thing for any hospital. NHCX isn’t the payer, but can facilitate quicker settlement if documents and adjudication are digital.

Successful — Brazil (a like-to-like example): started 2007–2010 with standardization first — a standard called TISS, co-created over 2–3 years with the whole ecosystem, plus a clear 12-month roadmap after which insurers had the right not to pay non-compliant claims (rolled out transparently over ~2 years). Less successful — USA: digitized ~97% of EHRs but it is largely not interoperable — once grants died it wasn’t self-sustaining. A thought for India: since NHCX is double-blinded/federated with no central data, build federated fraud analytics for the whole ecosystem.

Andhra (Sorab Gore): benchmark public facilities against private practice and apply the same standardization/EHR paradigm to the public sector; integrate bidirectional LIS/equipment data into the PHR. IRDAI (Chhatlani): payers and providers must come together — grade hospitals and use a common empanelment with standardized billing instead of 3,000×70 bilateral negotiations. Medi Assist (Gidugu): publish a common set of service codes (like GST), standardize the discharge summary into three boxes, and rethink products for payability. CAHO (Koli): reform through awareness. BCG (Chatterjee): put AI on top of NHCX with a responsible-AI framework.

To the startup reporting a 6-month empanelment struggle, and to the plea for a dedicated doctor training program (doctors do WhatsApp daily but resist data entry): both were acknowledged, with the team to reach out and the training gap flagged. Closing (CEO Banwal): NHCX uses the PMJAY lever — for new PMJAY empanelment, an ABDM-enabled HMIS is now mandatory; today three integrators were certified as NHCX-integrated; ABDM enablement is smooth with ~400 apps already M1/M2/M3 and ~1,700 in pipeline; the Brazil model (give time, then allow rejection) sends a huge signal even without a formal mandate. IRDAI Chairman announced a combined CII meeting of payers and providers on the 17th and a new “PPP — Public Payer & Provider”, noting ABHA is the largest ID after Aadhaar (~80 crore).

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).

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.

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.

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.

For PS1 & PS2 you may only use the ~5 provided open LLMs; for PS3 no LLMs at all (it’s a pure computer-vision problem — deep learning allowed, no LLMs). Other non-LLM open models (YOLO, CNN, vision transformers, Apache-2.0 pretrained) are allowed if you declare them and NHA hosts them — raise a request. VLM fine-tuning is not possible (they’re hosted on AWS via the cloud provider’s LLM hosting; a fine-tuned VLM can’t be hosted privately, and it protects a level playing field). You can upload your own model weights (e.g. an H5 file) to your private Jupyter notebook via drag-and-drop, and you must disclose data sources, model architecture and training code via a form. No Hugging Face imports and no proprietary/external hosted LLMs — if detected at evaluation you’ll be flagged. Your own model must have no external dependency. There is no limit on the number of models (only resource limits). If you create a unique model it will only be shared with everyone if it is open source.

No GPU is provided for participant custom models on any problem statement (there’s a market GPU shortage, and it would have to be allowed for everyone) — the provided LLMs run on NHA’s GPUs, but you don’t get GPU for your own models; compute is CPU-only. RAM/compute limits can be raised via request and are generally increased for all participants. Inference throughput / token usage / RAM are tiebreakers only, not primary criteria — the primary metric is the F1 score (F1 for PS1 & PS3; F1 + subjectivity for PS2). There are reasonable runtime limits (this isn’t real-time; per-claim timeout can be 10–20 minutes). This is a prototype — once selected, your model is hosted on bigger infra.

Your solution must run entirely on the NHA platform as a Jupyter (Python/R/Julia) notebook — like Kaggle in usability (but it is not Kaggle or AI Kosh; it’s fully NHA-hosted). You cannot use external cloud compute or call external MCP servers. The sandbox is firewalled with no internet, so you can’t install from the internet inside it or use Hugging Face — you install dependencies via pip inside the sandbox, and if you need a library not present, tell the team and it’s made available for everyone. Pre-installed: OpenCV, ONNX, PyTorch, TensorFlow, the SciPy stack, scikit-learn. You’ll be given the Python stack in the template to replicate locally. Access hosted open models via metered APIs (input/output tokens counted).

No labels are provided for any problem statement — you get output guidelines with one sample per category showing the expected format, and you define/label/train yourself. You can work locally (withhold part of the sample, or use another open labeled dataset), but the leaderboard is based only on evaluation on the platform. There are two back-end datasets: one populates the leaderboard, another (the rest of the full data) is never exposed. NHA runs your code on the unknown dataset to check there’s no hardcoding / no dataset-specific markers. The redacted sample data on the platform is small (just to test your solution); the full dataset is never downloaded by you.

You can compute locally and only hit “Evaluate” on the platform — tokens spent during development are not counted for evaluation, and token limits are reset at evaluation time (the dev-time limit is just a rate-limit to prevent abuse, and it’s comfortable — you likely won’t cross it). Token usage is still recorded and used for tie-breaking / subjective scoring. Set the problem-statement metadata field correctly (e.g. “1” for PS1) — it’s used to count LLM credits, and a wrong PS deducts that PS’s credits. Get your client ID & secret from Profile → Security and Access → Get Credentials, and enter them in the notebook to access LLMs.

One account/registration per team — one member registers on behalf of the whole team and shares the single credential; there is no restriction on team size. You can participate in more than one problem statement, but must submit one final solution per statement. You can submit as many times as you want, subject to a rate limit (roughly once an hour / half hour, communicated on Discord); only the latest version is considered at close, and you can revert to a previous Git commit and submit. There are three winners per problem statement. Screening is code-based; end-to-end demos come only if you win. The “register as organization” option is not applicable (it will be hidden).

No UI — just the model/pipeline as notebook code that outputs the exact format in the output guidelines (no front-end, no back-end, no queuing system for the competition; a demo comes only if you win). On IP: through the hackathon and prize-distribution phase, IP rights remain with the creator (individual/company). Once NHA onboards you as a long-term partner, NHA claims the IP of the solution (because it’s trained on the full NHA dataset) — but for this hackathon, till evaluation and prize distribution, IP stays with the creator.

Yes — you may use ChatGPT/AI to code and for R&D, but outside the platform (for PS3 you get no on-platform AI access at all). You may use open-source / research-mode datasets if you disclose which dataset the model was trained on and provide links/access (via a form); ideally the data is of Indian domicile. Your own dataset must be a public dataset available for research and get approved.

Portal/sandbox access rolls out by end of Master Class 3 / ~17th (register via the Google Sheet so accounts can be created). The submission deadline is 29th April (originally 30th; a push was announced to compensate for delayed data — updated on the website/Discord). On cutoff, all evaluation is frozen and solutions run against the entire master dataset; final winners are decided with subjective analysis. The finals are likely in the first week of May. Use Discord (not WhatsApp) for queries; STGs and guidance docs are on the NHA auto-adjudication hackathon website.

The published benchmarks are aspirational, not hard cutoffs. If no one reaches them, NHA sets some lower-side thresholds and evaluates the top three per problem statement on that basis (there is a lower limit too). For ties, throughput, token usage, resource usage and pipeline time come into play.

NHA has redacted information not needed for the task (names, PII of hospital/beneficiary). False positives on PII-masked regions are ignored in evaluation — even if your model flags forgery/extraction issues in a masked area, that is not counted; the focus is on the actual content. If you can’t extract something because of redaction, that won’t be counted against you.

Use the PMJAY ID (which has Aadhaar as a linked, validated ID) as the unique identifier — beneficiaries cannot be duplicate; there is no fraud with respect to Aadhaar/PMJAY IDs. The forgery that PS3 addresses is duplicate/manipulated documents, not duplicate beneficiaries. For PS1 (classifying reports and identifying STGs) the Aadhaar ID may not be an issue at all.

Yes — PS1 (document classification + rules), PS2 (radiological image understanding & correlation) and PS3 (structural/forgery check) together enable auto-adjudication. On re-runs: the hospital has 45 days to respond to a query; if it doesn’t, it’s deemed answered and returns to the system. In auto-adjudication, if the hospital responds within 45 days but the engine isn’t satisfied, it goes back to the hospital once more; after the second response, remaining issues go to manual adjudication. Under PMJAY, everything comes through NHCX only — that is the platform.

You’ll be given data for only three or four procedures/STG packages (four each for PS1 & PS2). “Agnostic” means the solution must generalize: you upload an STG and the model derives all the rules, checks the documents and flags abnormalities — so if tested on a fifth or sixth STG it still works. E.g. dialysis might need five mandatory documents and cataract a different five; the model must identify the mandatory conditions from whatever STG is provided. Don’t hard-tune only to the four packages. If your solution is genuinely out-of-the-box, NHA may consider long-term engagement to extend it to all procedures.

There will be a mix of handwritten and printed, and majorly handwritten — that is exactly why LLMs are provided to help. Both are required. The data has high variability: scanned/photographed/photocopied/black-and-white/blurred images, multiple languages (English, Hindi, regional), stamps and signatures — and full explainability is required (why + where in the STG the inference comes from), not just OCR. Extract specific admission/investigation/procedure/discharge dates and validate chronology; do not expose raw PII to LLM APIs (mask/de-identify first).

Two validity checks: intra-report — understand the two parts (observation/description vs impression/summary) and flag any inconsistency within the report; and inter-report — whether the radiological image matches the overall written report. The easiest (“lowest-hanging”) tasks are modality concordance with the report (is there a PCNL report for a PTCA patient?) and internal consistency; harder are report-image consistency, side errors (right vs left) and stenosis-location concordance. Files are provided as PDF or JPEG, not DICOM (as received from hospitals). The four PS2 packages are PCNL, cholecystectomy, PTCA and acute exacerbation of COPD, each with detailed mandatory documents and IT pop-up rules. Output is at the case level for PS2 (page level for PS1 and PS3), with a structured JSON row plus a neutral, non-diagnostic textual summary; dates in DDMMYYYY.

Three reasons to automate adjudication: (A) reduce cognitive burden for reviewing doctors (verify the correct documents were submitted); (B) ensure documents aren’t mixed up between patients at upload; (C) tackle intentional fraud & abuse — plus, since public funds (AB-PMJAY) are used, documents must be placed in the policy context for transparency. This is explicitly assistive, not a replacement for experts — the output interprets the image and arranges documents chronologically so the reviewer can focus on policy-important points. AI-assisted radiological interpretation is very much available in India; even honest clerical error can attach one patient’s X-ray to another’s.

NHCX caters to a broader population (SNOMED, ICD), but PMJAY has a lot of unstructured data, so customization may be needed; NRCeS currently classifies into ~eight health-information types, and STGs largely follow that framework (requirements vary per STG). The coding is ICD-10 (mapped with the system); ICD-11 is not yet mapped. The DRG pilot is not aligned with this hackathon and is not currently happening (that was old information).

Category 2 (overwriting) = text was already there, removed and rewritten over existing text; Category 3 (adding) = adding a stamp/signature/text on blank/white space. Distinguishing overwriting from newly-added text on now-white background is part of the problem — hint: the font differs from surrounding text. Two outputs required: a JSON (link, file name, page number, category ID) and per-page YML files with bounding boxes (same file name, .yml). Categories C1–C10 (C1 copy-paste; C2 overwriting; C3 added stamp/signature/text; C4 removing/erasing; C5 merging documents; C6 watermark removal; C7 irregular spacing; C8 fully AI-generated page; C9 partial AI edits; C10 no discrepancy). Multiple categories on a page use a double-pipe || separator, most dominant first. C8 and C10 need no YAML. Invalid JSON = automatic rejection; missing bounding boxes for C1–C7/C9 invalidate the submission.

Both visual/text forgery and metadata manipulation — though scanned documents usually lose metadata, so if you can identify timestamp/GPS-tag manipulation you can comment on it. LLMs/GenAI are not allowed for PS3 because NHA has seen accuracy discrepancies with them — they want a more traditional-ML/algorithmic approach (noise/consistency analysis, contour/shape, colour/intensity, texture anomaly, font comparison, baseline alignment) and no external APIs (no third-party OCR/vision APIs). The model should be document-type-agnostic — for all document forgery, not medicine-only — though the dataset is ~95% medical. You’ll get ~50–70 documents per category (originals not provided separately; a mix of original and fake to identify), a mix of good/bad quality including low-res mobile photos and photocopies. For a multi-page PDF, assign a category per page (untouched pages = C10).

They are unrelated hackathons. The claims here are unstructured. You may make them structured if you want (a diagnostic-report → FHIR-JSON microservice was shown as an example) — nobody’s stopping you, and building lightweight, scalable, transparent microservices (target ~50,000 claims/day) earns additional points.

The detailed evaluation criteria (with all parameters and weightages) are published on the website — refer to those for the balance of cycle-time reduction vs automation. Regardless of automation level, regional languages and handwritten documents all need to be comprehended, so translation/handwriting handling remains necessary. A non-coder can still contribute domain expertise — teams benefit from a clinician (for PS2, having a doctor on the team gives an edge).

A specific market number can’t be quoted, but this is hardcore fraud that can be proven in court — someone manually manipulating documents (human intervention) — and the impact is very big. NHA is looking for a deployable, production-level solution, which is why the dataset deliberately mixes good- and poor-quality images.