The platforms a policy needs to actually run on.
A national scheme and a state insurance programme don't run on the same system — and building either well means designing for the government that comes after this one, not just the one that commissioned it. This is architecture, build, and integration for public health systems, from state data centres down to a facility-level tablet.
Every state health system already has an IT estate — legacy HMIS instances, district-level databases nobody fully trusts, procurement contracts with three different vendors, and at least one system that "can't be touched" because nobody remaining understands how it was built. A greenfield architecture diagram that ignores all of that isn't ambitious, it's naive: it will not survive contact with a real state's infrastructure.
This is the delivery arm that designs and builds inside that reality — architecture that assumes the mess is permanent and works with it, rather than proposing to replace it in one procurement cycle.
Six ways we build inside a mandate.
Most public health infrastructure isn't a clean slate. These are the problems that show up once a system has to survive contact with a real state's IT estate.
Systems architecture
Designing the data model, infrastructure, and standards a programme will run on for the next decade, not the next budget cycle — and not just the next vendor contract.
HMIS & registry integration
Connecting state HMIS to national registries — ABDM, PM-JAY, HFR, HPR — without breaking what already works in production.
Facility-level tooling
Interfaces frontline health workers actually use: built for patchy connectivity, shared devices, and a workday that doesn't allow for a 15-minute app timeout.
Legacy system integration
Most state health infrastructure isn't greenfield. We design around what's already running, migrating data and workflows deliberately, not instead of it overnight.
Security & data protection
Infrastructure built to handle citizen health data to the standard a sovereign programme requires, audited the way a government auditor — not just a vendor — would check it.
Change management & rollout
The training, support, and phased deployment plan that gets a system adopted at district and facility level — not just installed and left to a usage report nobody reads.
One state system, four national interfaces it has to speak to.
A simplified illustration of the interoperability map — actual architecture varies by state, legacy estate, and scheme. This is the shape of the problem, not a specific client's system.
State HMIS — Integration Layer
PM-JAY / claims
Eligibility and claims interfaces a state's own systems have to speak to directly.
A system, not a diagram of one.
- A data model and systems architecture checked against ABDM and HMIS standards before build begins
- A build-vs-integrate decision for every component of your existing IT estate
- Offline-first facility-level tooling, designed for real connectivity, not a demo environment
- A phased rollout plan sequenced by district readiness, not administrative convenience
- A security and data-protection posture built to a sovereign programme's audit standard
- Adoption tracking live from week one, so a stalling rollout is visible in weeks, not a year later
A state has three separate district-level HMIS instances, none of which talk to each other, inherited from three different procurement cycles over a decade. The instinct — and the vendor pitch that usually follows — is to replace all three with one new platform.
A Tech Infra Advisory engagement starts with an audit of what those three systems actually do well, badly, and not at all, and a component-by-component build-vs-integrate decision. In practice, that usually means one legacy system gets a proper ABDM-compliant interface bolted on because rebuilding it would cost more than it's worth; a second gets replaced because it was never built to survive contact with real facility-level connectivity; and a shared integration layer sits above both, so a district office finally sees one picture instead of three.
The state doesn't pay to rebuild what already worked, and doesn't inherit a fourth disconnected system a decade from now when this government changes.
Stages two and three of the Mandate-to-Ground Framework.
This is where a specification becomes a running system: Stage 02, Architecture — designing the data systems and interoperability standards a programme will run on, built to outlast the government that commissioned it — and Stage 03, Deployment, rolling it out across state, district, and facility levels with the change management to get frontline health workers actually using it. More engagement hours go here than anywhere else in the framework, because this is the stage where most public health technology actually fails.
Everything we build starts with a mandate and ends with money moved.
Financial Technology →
Disbursement rails and treasury infrastructure that move funds traceably.
Training & Enablement →
Building lasting technical capability into the people who run these systems.
Before you write a scope of work.
We already have vendors and legacy systems. Do you replace them?
Rarely, and never as a first move. Most engagements start with an audit of what's already running and a build-vs-integrate decision for each component — replacing a working system wholesale is usually the wrong call, both financially and politically.
How do you handle facility-level connectivity that's genuinely unreliable?
Offline-first design as a default, not an afterthought: local data capture that syncs when connectivity returns, rather than tooling that simply fails when the network does. This is scoped explicitly during Architecture, not discovered during Deployment.
What does "change management" actually involve, concretely?
Training built around a frontline worker's real workflow and time constraints, phased rollout by district readiness rather than administrative convenience, and adoption tracking from week one — so a stalling rollout is visible in weeks, not discovered a year later in an audit.
Can this run without engaging Technology Advisory first?
Yes, if your government already has a clear specification and KPI framework from internal planning or a prior engagement. We'll still sanity-check it against Stage 01 of the framework before build begins — that check is quick if the groundwork is genuinely solid.
Have a system that's live, but not really working?
A lot of what we do is inherited infrastructure — a scheme that's technically deployed but not adopted at the facility level. Tell us where it's stuck.
Start a conversation