NHCX has to be able to reach you. Responses arrive as inbound requests to a callback URL you register, minutes after you submit. That is a straightforward requirement for a cloud product and a genuine problem for the way most Indian hospital software is actually deployed: on a server inside the hospital, behind a firewall, with no inbound path from the internet.
This constraint is under-discussed and it is worth deciding early, because it shapes the deployment story you sell and it affects every existing customer rather than only new ones.
Why this is not optional
Two facts combine into the requirement. First, the exchange is asynchronous — you get an acknowledgement immediately and the actual answer later, over a separate connection. Second, the acknowledgement of that inbound message is time-bounded, and repeated failure to receive has consequences for the conversation. So the endpoint has to be reachable and it has to stay up.
A related detail that catches teams during rollout: the callback URL is registered against your participant record, and updating it takes roughly an hour to propagate. That is not a value you can flip during a maintenance window and expect traffic to follow immediately — plan an overlap where both old and new endpoints work.
The four options
1. Reverse tunnel
An agent inside the hospital network dials out and holds a persistent connection; callbacks come back down it. Nothing inbound is opened on the hospital firewall, which is what makes this the easiest conversation to have with a hospital IT team — outbound-only is a far smaller ask than an inbound rule.
Trade-off: you now run an agent on someone else's infrastructure and you own its lifecycle — restarts, upgrades, certificate renewal, monitoring across every site. Cheap to start, and the ops burden accumulates with each customer.
2. Hosted relay
You run a receiver in your own cloud. It is the registered callback endpoint for every hospital, and it forwards each message inward to the right site — or holds it until that site polls.
Trade-off: it is centralised, so you control uptime and upgrades in one place, and the per-hospital footprint stays small. But claim payloads now transit your infrastructure, which changes your data-protection posture and will come up in hospital security review. It is a real design decision, not a deployment detail.
3. Cloud front-end
The claims module itself moves to your cloud. The on-premise HMIS keeps registration, EMR and billing; claims run as a hosted service that talks to the on-premise system through whatever integration you already have.
Trade-off: architecturally the cleanest — the asynchronous machinery lives where asynchronous machinery belongs, and you get one deployment to operate instead of many. It is also the largest change to your product and your commercial model, and it puts clinical and claim data in your cloud, which some hospitals will decline.
4. Per-site gateway
A small appliance or VM per hospital, sitting in the DMZ, holding the callback endpoint and the encryption keys for that site.
Trade-off: the most defensible in a security review and the most expensive to run. Each site has hardware or a VM, keys, patching and monitoring. This is a reasonable answer for a small number of large hospitals and an unreasonable one for fifty mid-sized customers.
How to choose
The deciding variables are your customer count, your appetite for handling their data, and how much operational capacity you have.
- Many small customers, thin ops team: hosted relay. Centralised operations is the only thing that scales, and the security conversation is worth having once properly.
- Few large hospitals with strict security: per-site gateway or reverse tunnel. Large hospitals have the IT capability, and they usually prefer data not leaving.
- Already moving to SaaS: cloud front-end. Do not build a tunnel estate you will dismantle in eighteen months.
- Need something running this quarter: reverse tunnel — while being honest that the ops burden grows per site.
Whichever you pick
Three things are common to all four and are worth building once:
- Health-check the path continuously. A callback endpoint that silently stopped receiving looks identical to a quiet day. Synthetic checks, alerting on absence, not just on errors.
- Per-facility identity. Each hospital has its own participant identity and its own endpoint, so your provisioning has to handle that per customer — it is part of onboarding, not configuration.
- Certificate rotation with an overlap window. Given the propagation delay, rotation is a planned change with both keys valid, not a swap.
The wider point: this is one of the two areas where NHCX turns into a product decision rather than an integration task. The other is the insurance desk. Both are worth deciding deliberately rather than by default.
If you are scoping NHCX for a hospital information system, our healthcare interoperability team has built the full flow end to end against the sandbox. For the architectural half — the asynchronous layer, the callback path, the claim state model — see our healthcare software product engineering practice. Talk to our team to walk through your product.
