Direct answer
The extended WHO Global Strategy on Digital Health tells product teams to design for health-system adoption, not just user adoption. Through 2027, the important signals are governance, interoperability, equity, evidence and sustainable country capacity. A product that cannot explain those dimensions will struggle to move from pilot to infrastructure.
The World Health Assembly endorsed a two-year extension of the Global Strategy on Digital Health in May 2025 and asked WHO to begin the next phase for 2028-2033. WHO's updated publication keeps the substance of the 2020-2025 strategy but extends the timeline to 2027. That sounds administrative. For product teams, it is more useful than that: it confirms that the next cycle of digital health will judge tools by how they fit into real systems.
This article is educational analysis, not clinical, regulatory or procurement advice. Teams building medical devices, clinical decision support, remote monitoring or AI-enabled tools still need qualified legal, clinical safety and regulatory review in each market. The strategic point is simpler: the bar for digital health products is moving away from "does the app work?" and toward "does the product strengthen the health system that must live with it?"
What changed in 2025
The WHO extension did not rewrite the strategy's foundations. It reaffirmed them. The strategy still centers national digital health strategies, governance, person-centered services, appropriate architecture, workforce capacity and cooperation across public and private actors. The extension matters because countries and vendors now have a longer transition runway before the next 2028-2033 strategy.
For product teams, that means the current language is not stale. It is the active frame for tenders, donor programmes, national roadmaps and health-system conversations. If your roadmap treats privacy, interoperability or workforce adoption as later implementation details, it is out of step with the strategy's operating logic.
The product lesson: adoption is institutional
Consumer software teams often optimize for individual activation: sign-up, first action, return visit, conversion. Health technology needs that discipline, but it is not enough. A clinician may like the interface while the procurement team rejects the data terms. A patient may appreciate reminders while the programme lead cannot integrate adherence data into reporting. A pilot may show promise while the national architecture cannot absorb another proprietary data silo.
Institutional adoption asks different questions. Who owns the data? Who maintains the configuration? What happens when donor funding ends? Which workforce role is expected to change? What local policy, standard or reporting obligation does the product support? Product discovery that excludes those questions produces attractive pilots with weak futures.
Governance is a product feature
Governance is often treated as paperwork outside the product. In digital health, it is part of the product experience. Consent flows, audit trails, role-based access, escalation rules, model monitoring, clinical sign-off and data retention are not back-office concerns. They shape whether a ministry, hospital group or accountable care organization can trust the product.
Good teams now build governance evidence into the roadmap. They keep a living clinical safety file. They maintain a data map that non-engineers can understand. They document how algorithmic or rules-based outputs are reviewed. They can explain what happens when connectivity fails, when a patient changes facility, when a clinician overrides a prompt, or when a dataset proves less representative than expected.
The point is not to make every startup behave like a regulator. It is to make trust inspectable. Health systems cannot scale what they cannot inspect.
Equity is product quality
Equity is sometimes framed as a values statement. The WHO strategy treats it as central to whether digital health improves health outcomes. Product teams should translate that into testable design work: language access, disability access, low-bandwidth behavior, shared-device realities, digital literacy, rural coverage, affordability and the risk of excluding patients who need care most.
A feature is not finished when it works for the easiest user. It is finished when the team has identified who it may leave behind and what mitigation is realistic. That can mean SMS fallback, offline workflows, proxy access, printable summaries, phone-based enrollment, community health worker interfaces or simply a decision not to digitize a step that is safer in person.
Interoperability decides whether pilots scale
Interoperability is not a standards badge. It is the difference between a tool that becomes part of care and a tool that becomes another tab. Product leaders should understand the data standards relevant to their category, but they should also study workflow standards: who needs the information, at what moment, in what system, with what legal basis and what clinical accountability.
The failed pilot pattern is familiar. A product creates useful data but delivers it as a PDF, a dashboard no one opens or an export that cannot be reconciled with the source of truth. The better pattern is boring: structured data, clear patient identity logic, event histories, API documentation, integration test environments and implementation support that does not assume every buyer has a spare informatics team.
How product teams should respond
Start with a strategy review. Map the product against five questions: what policy or system priority does it support, what evidence proves it improves a workflow, what data leaves or enters the product, what workforce burden changes, and what happens after the pilot budget ends. If the answers are thin, the roadmap needs less novelty and more operating model.
Second, create an evidence ladder. Early usability data is useful, but it should lead to workflow metrics, safety monitoring, equity checks and economic analysis where appropriate. Avoid claiming clinical impact before the evidence supports it. For regulated products, align claims with actual clearance, authorization or local legal status.
The evidence ladder should also name the decision it is meant to support. A pilot report for a hospital chief information officer is different from evidence for a clinical safety committee, a ministry buyer or a payer. When teams know the decision audience, they stop collecting vanity metrics and start collecting implementation evidence.
Third, involve implementation users before procurement. Nurses, community health workers, schedulers, data managers and patients will find failure points a product demo misses. Their feedback is not "change management" after the fact. It is product design.
Finally, keep the WHO documents close without turning them into decoration. Link features to governance, equity, interoperability and capacity. The extended timeline to 2027 is not a pause. It is a reminder that the digital health winners of the next cycle will be the products that can be governed, integrated and trusted.
FAQ
Did WHO create a completely new digital health strategy?
No. WHO's updated publication reflects the extension of the 2020-2025 strategy timeline to 2027, while WHO also begins work on the 2028-2033 phase.
Does the strategy apply only to governments?
No. Governments are central, but vendors, providers, researchers and funders all influence whether digital health strengthens or fragments care.
What should an early-stage team do first?
Document governance, data flows and implementation assumptions before scaling a pilot. Those artifacts often reveal product risks earlier than another feature sprint.
Primary sources: WHO's Global Strategy on Digital Health 2020-2027 and WHO's WHA update on the extension to 2027.