Most teams size NHCX as a billing project. That estimate is wrong before it is written, and the reason is structural: of the seven areas of a hospital information system that NHCX touches, five sit outside billing entirely — and the two heaviest are the two that most products do not have at all.
This is a module-by-module scope. It is written from building a complete NHCX integration against the sandbox — participant registration, the encrypted envelope, every use-case API, a callback receiver, and a library that generates conformant FHIR bundles from hospital data. The intent is that a product owner can read it and know, module by module, what the work actually is.
The short answer
NHCX touches seven areas of an HMIS. Two are new construction rather than modification, and those two are where estimates break.
1. Patient registration
Flows it touches: policy discovery, coverage eligibility (validation).
Registration becomes the point where insurance identity is captured. The exchange looks up policies by ABHA number, member id or mobile number, so those fields have to be collected and stored where the claim process can reach them. Member id matters more than teams expect: a group policy shares one policy number across many members, so the policy number alone does not identify the patient.
The part that is routinely missed is the fallback. A policy lookup can legitimately return nothing — a policy only appears on the exchange once the payer has pushed it there, and a valid, in-force policy may simply not have propagated. Teams tend to build this as an error state and stop. It needs to be a first-class path: the operator selects the payer from the participant registry and the claim proceeds normally. That is a screen, with a searchable payer list behind it.
One detail for that list: the registry has three participant roles, not two — payers, providers and TPAs. For cashless claims the counterparty is very often a TPA rather than the insurer, so a payer picker built only on insurers is quietly incomplete.
Effort: moderate. New fields, one new screen, one new master.
2. Doctor and staff master
Flows it touches: every claim-family flow.
Every practitioner referenced in a claim needs an HPR ID — the Healthcare Professional Registry identifier. NHCX validates it server-side, and it correlates the practitioner's registered specialty against the procedure being claimed. A cardiology package claimed under a doctor whose registry specialty is something else is a question you will have to answer.
This is the item to start on first, and it is worth being blunt about why: it is not an engineering problem. It is a data-collection problem across every doctor already in your system, and it moves at the speed of people responding to requests, not at the speed of your sprint. A vendor with fifty hospital customers is looking at months of operational follow-up. Starting it two quarters before you need it costs nothing; starting it the week you need it is the thing that delays go-live.
Effort: small in code, large in operations.
3. EMR and clinical
Flows it touches: pre-authorization, claim submission, supporting documents.
Diagnoses and procedures have to leave the EMR as coded, structured data — not free text that a human later transcribes onto a form. If your clinical modules capture diagnoses as typed strings, that is the gap to close, and it affects clinical UX, not just the integration layer.
Supporting documents are the second half of this, and the common mistake is expensive. Your HMIS already produces a discharge summary as a PDF, and the exchange accepts an attachment, so it is tempting to base64 the PDF and move on. It goes through — and it defeats the purpose. The payer cannot read a PDF programmatically, and programmatic reading is precisely what enables automated adjudication, which is where turnaround time actually improves. Structured supporting data travels as an encoded FHIR bundle, which means your discharge summary has to exist as structured content and not only as a print layout.
Effort: heavy. This is document generation, not document attachment.
4. The insurance desk — the module most products do not have
Flows it touches: plan retrieval, coverage eligibility (benefits), pre-authorization, enhancement, query response.
This is the largest single finding in the whole exercise, and it is the one that changes estimates.
The procedure a clinician performs and the package a payer pays for are two different objects. A surgeon records an angioplasty. The payer has a benefit package, inside a category, with its own code, its own limits and its own document requirements. Mapping one to the other is real domain logic — it is a decision a trained person makes, with rules, and it has to be captured somewhere.
Most HMIS products have no home for it. Billing knows tariffs; the EMR knows procedures; nothing owns the correspondence between a clinical act and a payer's product. That is why the work reads as a new module rather than a change to an existing one, and why it needs its own screens, its own ownership and its own maintenance as payers revise their catalogues.
Two things live here that are easy to miss:
- The second eligibility check. There is an eligibility call at registration to confirm the policy is active, and a second one after the package is selected. Only the second returns the amount actually available — because only the payer can evaluate benefit-level rules such as annual limits and sub-limits already consumed. Skipping it is a documented cause of avoidable rejections.
- The gap conversation. If the package is worth a certain amount but part of it is already consumed, the balance is payable by the patient — and they must be told before treatment, not at discharge. That is a consent flow, a printed estimate and an audit record. It is a product feature, not a field in a message.
Also here: the query work queue. A payer can raise a query mid-claim, and it arrives asynchronously on its own reference rather than against the message you sent. Without an inbox and a named owner, those queries land in somebody's email and quietly age past their deadline.
Effort: new build. Plan for it as a module.
5. Billing
Flows it touches: claim submission, final bill, payment notice.
Billing is the part teams expect, and it is genuinely the more contained half. Itemised charges map to benefit lines, and settlement notifications reconcile against what was submitted. The work is real but it is the kind of work a billing module is already shaped for.
The one structural change: a claim is not a single status. It moves through pre-authorization, query, enhancement, discharge, final claim, reprocessing, cancellation and payment, each as a distinct protocol state. A status column with six values will not survive contact with the exchange.
Effort: moderate.
6. Discharge
Flows it touches: discharge submission, claim, discharge correction.
Discharge produces the structured summary discussed above, and it is also where enhancement lives. If a patient's treatment escalates mid-stay, the additional approval references the original claim explicitly — so your data model needs a link from the enhancement back to the claim it extends. Products that treat each submission as independent cannot express this.
Effort: moderate.
7. Platform and infrastructure
Flows it touches: every inbound response.
The second area that is new construction, and the one most often discovered late.
Your HMIS is request/response. The exchange is asynchronous. You submit, you receive an acknowledgement, and the actual answer arrives later — over a separate inbound connection, carrying its own reference. That needs a durable outbox and inbox, correlation, idempotency and retry handling. It is an architectural change, not a client library.
Then the constraint that is under-discussed in Indian health software: most HMIS installations are hospital-hosted, behind a firewall, with no inbound path. Callbacks have to reach you. Every option — a reverse tunnel, a hosted relay, a cloud component in front of on-premise installs — has a cost, an owner and a security review, and it affects every existing customer rather than only new ones. This deserves a decision early, because it shapes the deployment story you sell.
Three more that belong to this layer: acknowledgements are time-bounded, so your receiver's uptime becomes a contractual concern rather than a best-effort background job; encryption certificates need a rotation process, and registry updates take roughly an hour to propagate, so rotation needs a planned overlap window; and because every message travels encrypted, you need a message-level audit trail — when a payer disputes what was sent, you need the exact payload and its reference. Build that before the first dispute.
If you have already been through ABDM integration, some of this is familiar ground — the callback problem in particular. The asynchronous claim state machine is not.
Effort: heavy.
The scope table
| Module | NHCX flows | What changes | Effort |
|---|---|---|---|
| Patient registration | Policy discovery, eligibility (validation) | Insurance identity capture; payer-picker fallback | Moderate |
| Doctor master | All claim flows | HPR ID per practitioner | Data effort, not code |
| EMR / clinical | Pre-auth, claim, documents | Coded diagnoses and procedures; structured documents | Heavy |
| Insurance desk | Plan, eligibility (benefits), pre-auth, enhancement, query | Procedure-to-package mapping, eligible-amount screen, query queue | New build |
| Billing | Claim, final bill, payment notice | Benefit-line mapping; multi-state claim model | Moderate |
| Discharge | Discharge, claim, correction | Structured summary; enhancement linked to original claim | Moderate |
| Platform | All inbound responses | Reachable callback, async outbox/inbox, certificate lifecycle, audit trail | Heavy |
How to scope it, in order
- Start the HPR ID collection now. It is the longest-lead item and it needs no code to begin.
- Decide the callback architecture before anything else technical. It constrains deployment for every existing customer, so it is the decision other decisions depend on.
- Treat the insurance desk as a module with an owner, not as screens bolted onto billing.
- Stand up profile validation before writing bundle code. Validating every generated bundle against the published profiles catches an entire class of problems in minutes rather than in a payer's rejection queue — and acceptance by the exchange is not the same thing as conformance.
- Model the async state machine early. Retrofitting correlation and idempotency into a synchronous codebase is materially harder than designing for it.
Where the estimate usually goes wrong
The two heaviest areas — the insurance desk and the platform layer — are the two most products do not have at all. An estimate built by asking "how long to add claim messages to billing" will miss both, and it will miss them by more than it includes.
The encouraging half: the parts that sound hardest are not. The encrypted envelope, the participant registry, the API surface itself — these are well specified and, once understood, straightforward. The cost sits in the product, not the protocol.
If you are scoping NHCX for a hospital information system, our healthcare interoperability team has built the full flow end to end and can help you size the work honestly. For the architectural side — the async layer, the callback path for on-premise installs, the state model — see our healthcare software product engineering practice. Talk to our team to walk through your product module by module.
