Four stages. One line of sight, top to bottom.
Every ONRAV engagement moves through the same sequence — Mandate, Architecture, Deployment, Accountability — so a programme never loses the thread between what a government promised and what a clinic actually delivers. This is the Mandate-to-Ground Framework.
Most public health technology doesn't fail because of one bad decision — it fails because the people who wrote the mandate, the people who architected the system, the people who deployed it, and the people now trying to audit it were never actually working from the same document. Each stage below produces something concrete that the next stage inherits, so nothing gets re-litigated four times by four different teams.
Each stage inherits something concrete from the one before it.
Not a soft handover meeting — a specific artifact one stage produces and the next is built directly on top of.
Mandate
Produces: technical specification + KPI framework.
Architecture
Produces: data model + interoperability map.
Deployment
Produces: adoption data + trained frontline capability.
Accountability
Produces: the live layer the original KPI framework is measured against.
Mandate
Translate policy intent and budget into a technical specification funders, auditors, and implementers can all read the same way.
- A technical specification tied line-by-line to the policy document and budget allocation.
- A KPI framework — the metrics the programme will actually be judged on, agreed before launch.
- Sign-off from every stakeholder who could otherwise claim, later, that they weren't consulted.
Architecture
Design the data systems and interoperability standards the programme will run on — built to outlast the government that commissioned it.
- A data model and system architecture checked against national standards — ABDM, HMIS — before a line of code is written.
- An interoperability map: what talks to what, and what happens when a state's existing system doesn't want to.
- A build-vs-integrate decision for every component, so a state isn't paying to rebuild what already works.
Deployment
Roll out across state, district, and facility levels, with the change management to get frontline health workers actually using it.
- A phased rollout plan sequenced by district readiness, not administrative convenience.
- Training and support built around the frontline worker's actual workday — not a one-time onboarding session.
- Adoption tracking from week one, so a stalling rollout is visible before it's a year old.
Accountability
Public dashboards and audit trails that let citizens, legislators, and auditors see whether the programme is doing what it promised.
- A live accountability layer — reporting completeness, funds traced, sync delay — visible to the ministry as it happens, not on a yearly audit cycle.
- An audit-trail architecture built to answer "where did the money go" before an auditor has to ask.
- A public-facing reporting layer, wherever the programme's design allows for one.
What an accountability layer actually looks like.
Not a report delivered once — a layer a ministry, an auditor, and a citizen can each open and check for themselves.
State labels and figures above are illustrative of the interface, not a live client dataset.
About the framework itself.
Do we have to start at Stage 01, even if our programme is already partway built?
No. Most engagements start honestly at Stage 02 or 03 — a mandate that already exists on paper, or a system that's already deployed and struggling. We still map the existing work against the framework's four stages so nothing gets missed retroactively, but that's a diagnostic step, not a restart.
How is this different from a generic "digital transformation" methodology?
Most digital transformation frameworks are sector-agnostic and treat accountability as a reporting feature added near the end. The Mandate-to-Ground Framework is built specifically for public health delivery in federal systems, and Stage 04 — Accountability — is designed in from Stage 01, not bolted on once Deployment is finished.
Does every engagement move through all four stages?
Not necessarily in one contract. A government might engage us for Stage 01 alone through Technology Advisory, or for Stages 02–03 through Tech Infra Advisory on a mandate someone else wrote. The framework describes the full sequence a programme needs to pass through eventually — not a package every client has to buy at once.
Who owns the framework's outputs once the engagement ends?
You do. The technical specification, architecture, KPI framework, and accountability layer are built to be run and extended by your own team — or a successor vendor — without ongoing dependency on ONRAV, unless you choose to keep us engaged.
What happens if the KPI framework agreed at Stage 01 turns out to be wrong once the system is live?
It gets revised, deliberately and visibly, not quietly abandoned. Because Stage 04's accountability layer reports against the same framework Stage 01 defined, a KPI that isn't actually measuring the right thing becomes obvious fast — and revising it is a documented decision, not a silent drift away from what was promised at launch.
How long does the full sequence typically take, start to finish?
It varies enormously by scheme scale and how much legacy infrastructure Stage 02 has to work around — a single state HMIS modernisation might move through all four stages in 12–18 months, while a national scheme rolling out across every state runs considerably longer. Each capability page lists typical timelines for its own stage of the work.
Where does your programme sit in this sequence?
Most conversations start honestly at Stage 02 or 03 — a mandate that already exists, a system that's already struggling. That's a perfectly good place to start.
Start a conversation