Consider a national ministry that needs to coordinate care across a large network of public and contracted facilities — primary care, secondary hospitals, and specialist centres. Patient referrals fall through the gaps, duplicate diagnostics drive cost, and the ministry has no live picture of capacity in the system. Use this playbook to frame the work, sequence the analysis, and avoid the common traps in that brief.
The consulting question
National digital health programmes typically arrive at one of two failure modes. Either the platform is technically excellent but adoption is patchy because no clinician has the bandwidth to learn yet another system; or the platform is rushed to deployment, adopted under pressure, and abandoned in practice as soon as the political attention moves on. The brief is to build something that does neither.
How to approach it
Anchor the architecture on three flows. Referral, results-return, and capacity-visibility are the high-value flows that justify the platform. Build those first. Everything else — appointments, billing, analytics — comes later and gets prioritised by what the clinicians actually use.
Open standards, no captive vendors. The platform interoperates with existing facility systems through standard healthcare data exchanges. The ministry does not get locked into a single vendor; existing investments are not stranded.
Adoption is the engineering work. Most of the team is not building the platform — they are building the local-adoption support: change agents in each facility, training that respects clinical time, and a quick-feedback loop so platform issues get fixed in days, not quarters.
Measure referral closure rates, not logins. The platform is working when a referral that goes in produces a closed-loop result at the originating facility. Logins are a hygiene metric, not a success metric.
Suggested workplan
Months 1–3: Architecture, standards alignment with regulators, and pilot-facility selection. The pilot set is chosen for diversity, not friendliness.
Months 4–9: Build the three core flows. Concurrent change-management buildout in the pilot facilities — typically 6 to 10 sites.
Months 10–18: Pilot operates live. The platform receives weekly fixes based on clinician feedback. Adoption is tracked by referral-closure rates, not registration counts.
Months 19+: Sequenced national rollout in waves of 50 to 100 facilities. Each wave gets a dedicated adoption team for the first ninety days. Self-service support comes later, not first.
Questions to pressure-test
- What are the three highest-value clinical flows in this system today?
- Which facility systems already exist, and what would it take to interoperate rather than replace?
- Where do referrals fail today — is it information, capacity, incentive, or accountability?
- Who owns the platform after the programme team is gone, and do they have the staffing to keep it?
- What is the political tolerance for the realistic timeline?
A strong answer includes
A platform that the clinicians actually open during their shift. Referrals that close loops, with the originating facility seeing the result. Visible capacity across the network so urgent transfers do not depend on phone calls. An adoption curve that climbs through the pilot wave and stays climbing through the national rollout — not a spike that collapses after the launch event. And a ministry that has a live view of the system it is responsible for, not a quarterly retrospective.
Common traps
Adoption is harder than architecture. Most national platforms fail at adoption, not technology. Budget accordingly.
The pilot set must be diverse. If you pilot in friendly facilities, you will learn nothing about the hard ones — and the hard ones are most of the network.
Closing the loop is the only metric that matters. Logins, registrations, and dashboards are not adoption. Loop closure is.
The ministry needs an internal product team, not a vendor contract. Long-term success depends on internal product capability — not on extending the external support model.
Use this playbook to frame a digital-health platform case around patient journeys, data ownership, product governance, and adoption rather than treating the brief as a software build alone.