Strategic clarity, before a single system gets built.
Before any platform gets procured, someone has to decide what the health system actually needs to do, for whom, and how success will be measured. That's Technology Advisory — the analysis and decision-support layer underneath every other decision a government makes about its public health infrastructure.
Most public health technology doesn't fail in the server room — it fails in a meeting three months earlier, when "digitise the scheme" got treated as a procurement decision instead of a design one. Someone had to decide what the system should actually optimise for: enrollment speed, fraud resistance, frontline usability, auditability, or some explicit trade-off between all four. When no one makes that decision on purpose, the vendor makes it by default, usually in favour of whatever is fastest to build.
Technology Advisory is where a government makes that decision on purpose — with enough technical fluency in the room to know what it's actually trading off, and enough distance from any vendor's roadmap to trust the answer.
Six ways we work inside a mandate.
Not a generic strategy retainer — each of these ties directly to a decision a health department or ministry actually has to make.
Programme & scheme design
Translating health policy goals into a workable technical and operational model before procurement begins — the specification a vendor gets held to, not the one they wrote themselves.
Data & business intelligence
Turning enrollment, disbursement, stock, and outcome data into decision-grade intelligence for health ministries and the finance departments that fund them.
Digital health strategy
Sequencing what to build first, what to integrate, and what to retire, across a multi-year public health technology roadmap that survives a change in government.
Vendor & procurement advisory
Independent, technically literate evaluation of system vendors and RFP responses — so decisions aren't made on the vendor's own terms, or on price alone.
Interoperability assessment
Auditing how, or whether, existing state systems can actually talk to national registries such as the Ayushman Bharat Digital Mission — before that assumption gets written into a contract.
Performance & outcomes measurement
Defining the KPIs a programme will be judged on before it launches — not after an audit finds the gap the KPIs should have caught.
From policy intent to a specification a vendor is held to.
A trade-off made without a name is still a trade-off — it just gets made by default, usually in favour of whatever's fastest to build. This is the sequence that makes it explicit instead.
Policy intent
The mandate as written — what the scheme is meant to achieve, for whom.
Trade-off analysis
Enrollment speed vs. fraud resistance vs. frontline usability vs. auditability, made explicit.
KPI framework
The metrics the programme will be judged on, agreed before launch, not inferred after.
Technical specification
The document a vendor gets held to — not the one they wrote themselves.
Concrete artifacts, not a strategy deck.
- A technical specification tied line-by-line to the policy document and budget allocation
- A KPI framework agreed before launch, not inferred from an audit afterward
- An interoperability assessment against ABDM and any relevant national registries
- A vendor evaluation methodology, if procurement is the next step
- A data & business-intelligence baseline for the finance department funding the scheme
- Sign-off from every stakeholder who could otherwise claim later they weren't consulted
A state health department has budget approval for a new maternal health tracking scheme, and a March deadline to go live. The draft brief given to three prospective vendors describes "a mobile app for ASHA workers" — nothing about how success will be measured, whether the app needs to work offline, or how it should integrate with the state's existing HMIS.
A Technology Advisory engagement starts before any of those three vendors is chosen. The trade-off conversation the department hasn't had yet — frontline usability versus a faster, less field-tested build — gets made explicitly, in the room, with the district-level realities the brief currently ignores on the table. The KPI framework that comes out of it isn't "the app is installed," it's a district-by-district adoption rate the department can actually track from week one.
The state still picks its own vendor. What's different is that the specification the vendor is bid against was written by people accountable to the state, not the vendor's own roadmap — and the KPI the Health Secretary reports against six months later measures something real.
The first stage of the Mandate-to-Ground Framework.
Technology Advisory is where most of our engagements begin — at Stage 01, Mandate, translating policy intent and budget into a technical specification funders, auditors, and implementers can all read the same way. It's also where we stay involved throughout, since the data and outcomes questions we help answer at the start are the same ones a programme has to keep answering at Stage 04, Accountability.
Advisory decides what to build. These build it.
Tech Infra Advisory →
Architecture, build, and integration of the platforms a programme runs on.
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.
How long does a Technology Advisory engagement typically take?
Scoping and mandate work usually runs 6–12 weeks depending on how many stakeholder departments have to sign off, and whether the scheme already has an approved budget or is still being negotiated. A cross-state national scheme review takes longer than a single state's HMIS strategy.
Do you replace our existing planning or IT department?
No — we work embedded alongside it. The specification and KPI framework we produce are meant to be owned and defended by your own team long after our engagement ends, not held as a consultant's private deliverable.
What do we actually walk away with?
A technical specification tied to your budget line, a KPI framework agreed before launch, a vendor evaluation methodology if procurement is next, and an interoperability map showing exactly what your system needs to talk to. All of it usable independently of whether you engage us for Tech Infra or Financial Technology afterward.
Can this run as a standalone engagement, without moving into the other two delivery arms?
Yes. Some governments only need the strategic and data-intelligence layer, and take the resulting specification to their own implementation team or an existing vendor. That's a legitimate outcome, not a smaller version of the "real" engagement.
Not sure where your programme sits in this?
Tell us what stage you're at — policy still on paper, or a system already struggling to be used — and we'll tell you honestly whether Technology Advisory is the right starting point.
Start a conversation