Topic 9.2 — Global & International Digital Health

In one sentence: The principles in this book travel across borders, but the systems, laws, and social contracts they land in do not — so your job is to learn deliberately from other health systems, adopt the shared global standards, and adapt everything else to context rather than copying it.

Why this matters in health and care#

Digital health is not a British invention, and the United Kingdom is not its centre of gravity. The hardest, most instructive work in the field is happening in Estonia, India, Rwanda, Brazil, and Kenya as much as in London or Leeds. If you lead digital delivery in the NHS, an Integrated Care System, or an arms-length body and you look only inward, you will re-solve problems that others solved a decade ago, and you will miss the standards, tools, and cautionary tales that would have saved you years.

This matters for reasons that go beyond efficiency. Health is a global commons: pathogens, evidence, clinical guidelines, and — increasingly — the software that runs care systems all move across borders. The same clinical-safety, equity, and public-trust concerns that define how you work at home reappear, amplified, when data and technology cross jurisdictions. A remote-monitoring tool that is safe in a well-connected English city may be unsafe when deployed where connectivity fails; a consent model that is lawful under one country's regime may be unlawful under another's; an algorithm trained on one population may quietly harm a different one.

There is also a duty of humility. The UK both learns from and contributes to global health, and the flow runs in both directions. Low- and middle-income countries (LMICs) have pioneered mobile-first care, community health worker platforms, and open-source national infrastructure that richer systems now study. Treating international digital health as charity, or as a menu of models to lift and drop into England, is the fastest route to failure. Treating it as a discipline of careful, reciprocal learning is how you make this book's claim of "internationally transferable principles" honest rather than hollow.

Core concepts#

Global health and digital health. Global health is the study and practice of improving health and achieving health equity for all people worldwide. Digital health is the use of information and communication technologies — records, apps, devices, analytics, and artificial intelligence — to deliver and improve care. The intersection is the subject of this topic: how digital tools and ways of working move, or fail to move, between health systems that differ in wealth, law, infrastructure, and culture.

The WHO global strategy and digital public goods. The World Health Organization (WHO) published a Global Strategy on Digital Health that frames digital health as an enabler of universal health care — often called universal health coverage (UHC), the goal that everyone can use the services they need without financial hardship. A central idea is the digital public good: open-source software, open data, open standards, and open content — sometimes called "global goods" — that any country can adopt and adapt rather than buying proprietary systems it cannot own or afford. WHO-endorsed tools such as DHIS2 (a health information platform used in more than seventy countries) and OpenMRS (an open-source medical record) are canonical examples.

International interoperability and terminology standards. Borders are crossed not by moving whole systems but by sharing a common language. Three standards do most of the work: HL7 Fast Healthcare Interoperability Resources (FHIR) for exchanging structured clinical data; SNOMED CT, the international clinical terminology governed by SNOMED International; and WHO's ICD-11, the eleventh revision of the International Classification of Diseases, used for mortality, morbidity, and reimbursement coding worldwide. These are the shared vocabulary that lets an English record, an Estonian record, and a WHO statistical return mean the same thing. (See Topic 4.3 — Interoperability & Data Standards.)

mHealth and leapfrogging. mHealth — mobile health — is the delivery of health services and information through mobile phones. In many LMICs, mobile-first care is not a downgrade but the primary channel, and it illustrates leapfrogging: skipping a generation of infrastructure (here, fixed-line connectivity and paper-heavy hospital IT) to move straight to newer technology. The lesson for richer systems is not that phones are cheap, but that constraint breeds designs — offline-first, low-bandwidth, SMS-fallback — that are more resilient than many "advanced" alternatives.

Data sovereignty and cross-border data flows. Data sovereignty is the principle that data is governed by the laws of the jurisdiction in which it is collected or stored. Health data is among the most tightly controlled categories, and legal regimes diverge sharply: the UK and EU General Data Protection Regulation (GDPR) rests on lawful bases and data-subject rights; the US Health Insurance Portability and Accountability Act (HIPAA) protects a narrower set of "covered entities"; the EU's Artificial Intelligence Act and the EU Medical Device Regulation (Regulation (EU) 2017/745) impose risk-tiered controls on software as a medical device. A tool that is compliant in one regime can be unlawful in another, and cross-border data flows require an explicit legal transfer mechanism, not an assumption.

Learning across health systems. Countries run natural experiments you cannot run at home. Estonia built a whole-of-government data exchange layer and near-universal digital records; India built a set of open digital "stack" components for identity, payments, and health that private and public actors build on top of; Rwanda scaled drone-delivered blood and community health platforms. Each is a source of transferable lessons and non-transferable specifics — and telling the two apart is the core skill this topic teaches.

Best practices#

1. Adopt the global standards before you invent local ones. Default to HL7 FHIR, SNOMED CT, and ICD-11 for exchange, terminology, and classification, because these are the shared language that makes any future international comparison, collaboration, or supplier switch possible. Every bespoke local code system you create is a wall you will later have to demolish. Where a national profile exists — the UK Core FHIR profiles, for instance — use it, and contribute back rather than forking quietly.

2. Prefer digital public goods and open standards over proprietary lock-in. When you procure or build, weight open-source, openly-specified, and independently-governed options heavily, because they preserve your ability to own, audit, and exit. Digital public goods such as DHIS2 and OpenMRS are proven at national scale and free of licence rent; even where you choose a commercial product, insist on open standards and data portability so you are never a hostage. (See Topic 9.0 — Collaborating with Partner Organizations on designing against vendor lock-in.)

3. Learn from other systems as a discipline, with named owners and honest translation. Treat international learning as real work: assign someone to study a comparator system, understand why it works there — its laws, funding, digital identity, and social trust — and separate the transferable principle from the local specific. A study visit that returns with "we should copy Estonia" has failed; one that returns with "here is the identity and consent problem Estonia solved, and here is how our constraints differ" has succeeded.

4. Never lift and shift a national model. Estonia's success rests on a small population, a mandatory national digital identity, and a high-trust settlement built over two decades; India's health stack rests on a particular public-private architecture and a billion-person identity system. Extracting one component and dropping it into England ignores the scaffolding that makes it safe. Adopt the pattern and rebuild the implementation for your legal, demographic, and trust context.

5. Map the legal regime before any data crosses a border. Establish, in writing, the lawful basis, the transfer mechanism, and the controller relationships before health data leaves a jurisdiction — do not assume a UK-lawful flow is lawful onward. Where you operate across GDPR, HIPAA, the EU AI Act, and the EU Medical Device Regulation, treat the strictest applicable regime as your floor, and record how data sovereignty is respected for every population whose data you hold.

6. Design for the harshest realistic conditions, not the demo. Borrow the LMIC discipline of offline-first, low-bandwidth, and graceful degradation, because it produces services that survive the connectivity failure, the old device, and the rural notspot at home too. A tool that only works on fast fibre in a clinic is not resilient; equity and clinical safety both improve when you assume the network will fail.

7. Anchor everything in equity and universal coverage, and check who is excluded. Ask, for every deployment, whether it narrows or widens the gap — across countries and within your own population — because a digital service that serves the connected and confident while leaving others behind is a step away from universal coverage, not towards it. Measure uptake by group, not just in aggregate. (This connects to Topic 1.9 — Digital Inclusion & Accessibility.)

8. Govern AI and emerging technology to the highest applicable international bar. Algorithms trained in one population can harm another, and the regulatory ground is shifting fast under the EU AI Act and comparable frameworks. Document training data provenance, validate on your own population, and align governance to the strictest regime you touch rather than the most permissive. (See Topic 8.4 — AI & Emerging Technology Governance.)

Questions to discuss with your team#

1. When we admire another country's digital health system, can we articulate exactly which parts are transferable to our context and which depend on conditions we do not share? This question guards against the most common and most expensive error in international learning: mistaking a specific implementation for a general principle. Estonia's near-frictionless data exchange depends on a mandatory national digital identity and a high-trust social settlement; India's health stack depends on a particular public-private architecture and a population-scale identity system; both took many years and specific political conditions. Your team should be able to name the underlying problem each system solved — secure identity, consented data exchange, reaching remote populations — and then describe honestly how your legal regime, funding, demographics, and public trust differ. The discussion should surface what scaffolding a borrowed model would need to be safe here, and whether that scaffolding is realistic. A mature answer separates the pattern worth adopting from the implementation that cannot travel, and it treats "we should just copy them" as a red flag rather than a plan. It also asks the reciprocal question: what does our system do that others could learn from, which sharpens the humility the whole exercise requires.

2. Before any health data crosses a border — including to a cloud region, a supplier, or a research partner in another country — do we know the lawful basis, the transfer mechanism, and which regime governs it? Cross-border data flows are where good intentions meet hard law, and the failure is usually silent: data moves through a cloud region or a supplier's overseas support desk without anyone establishing a legal transfer mechanism. Your team should distinguish clearly between the UK and EU GDPR world of lawful bases and data-subject rights, the US HIPAA model that protects a narrower set of covered entities, and the emerging controls of the EU AI Act and Medical Device Regulation for clinical software. The discussion must cover data sovereignty concretely: for each population whose data you hold, which nation's law governs it, and are you honouring that? It should also confront the practical traps — a "global" SaaS product with support staff on another continent, an AI vendor whose model is retrained on your data, a research collaboration that assumes reciprocity the law does not grant. A strong answer treats the strictest applicable regime as the floor, records the transfer mechanism in writing before data moves, and can name who is accountable when a regulator asks.

3. Are we designing for the connectivity, devices, and literacy of everyone we serve, or only for the confident, connected user in the demo? Much of the world's most resilient health technology was built under constraint — intermittent power, low bandwidth, shared or basic phones, multiple languages — and that discipline produces services that also serve the excluded within a wealthy system. Your team should examine whether its designs assume fast connectivity, modern devices, and high digital literacy, and what happens to a patient when those assumptions fail. The equity stakes are direct: a service that works only for the well-connected widens the gap it was meant to close, both between countries and within your own population, moving away from universal coverage rather than towards it. The conversation should look at offline-first behaviour, graceful degradation, SMS or voice fallback, language and reading-level accessibility, and whether uptake is measured by group rather than only in aggregate. It should also ask whether you are borrowing proven LMIC design patterns or ignoring them out of a sense that they are "not for us". A good answer can point to specific design choices that protect the hardest-to-reach user and to metrics that would reveal exclusion early.

4. When we build or buy, are we choosing digital public goods and open standards that we can own, audit, and exit — or quietly accepting proprietary lock-in because it is convenient today? The choice between an open, independently-governed platform and a polished proprietary one is where a system's long-term sovereignty is won or lost, and the pressure almost always runs towards the closed option because it demos better and asks less of you now. Your team should be able to say why it weighted open-source, openly-specified, and portable options in a specific recent decision — or admit honestly that it did not. Digital public goods such as DHIS2 and OpenMRS are proven at national scale and free of licence rent, but they demand in-house capability and a maintenance commitment that a commercial contract appears to remove; that trade-off is real and should be argued, not assumed away. The discussion must also cover exit concretely: if this supplier doubled its price or left the market in three years, could you move your data and your service, and have you tested that claim rather than trusted a contract clause? A mature answer treats data portability and a documented exit as non-negotiable even when the chosen product is commercial, and it can name what the organization would have to build or fund to make the open option viable.

5. Are we treating lower-income partners as sources of proven design and genuine collaborators, or as recipients of our charity — and can we say clearly what we contribute back? International digital health carries a persistent power asymmetry, and the charity framing — where a wealthy system "helps" an LMIC by donating technology — is both patronizing and a reliable route to failure, because it ignores that mobile-first care, community health worker platforms, and open national infrastructure were often pioneered in exactly those systems. Your team should examine a real or proposed partnership and ask who owns the result, who maintains it, and whether the flow of learning genuinely runs both ways. The tensions are concrete: a donated platform that becomes an unfunded dependency, a "collaboration" that extracts data or validation from a partner population without reciprocal benefit, a study visit that takes lessons but offers nothing in return. It should also confront the reciprocal humility the topic demands — what does your own system do that others could learn from, and are you sharing it as openly as you expect them to share with you? An honest answer can point to co-ownership arrangements, contributions back to shared open cores, and a partnership that would still make sense if the funding direction were reversed.

6. For any algorithm or AI model we deploy, can we show it was validated on the population it will actually serve, and governed to the strictest regime we touch rather than the most permissive? A model trained and validated on one population can quietly harm a different one, and international digital health multiplies this risk because tools, training data, and vendors cross borders faster than the evidence of their safety does. Your team should be able to distinguish a model's provenance — where its training data came from, which population it was validated against — from the population it is now being asked to serve, and treat any gap as a live clinical-safety concern rather than a paperwork detail. The regulatory ground is shifting fast and unevenly: the EU AI Act imposes risk-tiered controls on high-risk clinical software, the EU Medical Device Regulation treats many algorithms as software as a medical device, and UK law is lighter in places, which creates a temptation to govern to the most permissive regime you can defend. The discussion should surface who is accountable for revalidation, how model updates and vendor retraining are controlled, and whether the organization documents training-data provenance at all. A strong answer revalidates on the local population before deployment, aligns governance to the highest applicable international bar to keep options open, and can explain that choice to a regulator without embarrassment.

In practice: a health & care example#

A fictional English arms-length body, the "National Remote Monitoring Service", is asked to procure a platform for home monitoring of long-term conditions, with an option to collaborate on a shared open-source core with health ministries in two partner countries — one a high-income EU neighbour, one an LMIC scaling community health workers.

The temptation is to buy a polished commercial platform and treat the international angle as a diplomatic courtesy. The team resists. It starts from standards: any platform must exchange data as HL7 FHIR, code observations in SNOMED CT, and classify conditions to ICD-11, so that data means the same thing across all three countries and the service is not locked to one vendor. It shortlists a digital-public-good core (an OpenMRS-derived stack) alongside two commercial options, scoring each on data portability and exit as heavily as on features.

On the law, the team maps the regimes before a byte moves. Data for English patients stays under UK GDPR in a UK cloud region; the EU partner's collaboration runs under EU GDPR with a documented transfer mechanism; no personal data flows to or from the LMIC partner at all — only de-identified aggregate indicators and the open-source code itself, which is a digital public good and carries no sovereignty risk. The monitoring algorithm is treated as software as a medical device and validated against the English population separately, because a model tuned elsewhere cannot be assumed safe here; its governance is aligned to the EU AI Act's high-risk expectations even where UK law is lighter, to keep options open.

The design borrows from the LMIC partner rather than lecturing it. The community-health-worker platform there is offline-first with SMS fallback, and the English service adopts the same pattern — which turns out to matter for rural notspots and older patients at home. Eighteen months on, the shared open-source core is maintained jointly, each country runs its own lawful deployment, and no partner has copied another's model wholesale. The English team can show a regulator exactly which data sits under which law, and the LMIC ministry has a co-owned platform rather than a donated dependency.

Sector lenses#

Startup#

A digital-health startup often reaches international markets before it is ready for the legal complexity they carry. The upside is real — global standards mean a FHIR-native, SNOMED-coded product can, in principle, sell anywhere — but each new country brings a different regime (GDPR, HIPAA, the EU AI Act, national medical-device rules) and a different data-sovereignty expectation. Build to the strictest regime you plausibly intend to enter, keep personal data in-region by design, and treat digital-public-good compatibility as a market advantage rather than a threat. Founders who leapfrog into LMIC markets should partner genuinely and localize honestly, because a tool parachuted in without local ownership rarely survives contact with real infrastructure.

Small business#

An established small provider — a GP practice, a community pharmacy, a care home, a single-site clinic, or a small health-tech supplier past the startup stage — carries the same cross-border and standards duties as a national body but with a fraction of the capability to meet them. It rarely has dedicated IT or information-governance staff, yet it may still use a cloud-hosted product whose data sits in another jurisdiction, or a diagnostic tool built on a model validated elsewhere. The practical protection is to lean on the standards and the strictest-regime-as-floor discipline rather than trying to reason each case from scratch: ask suppliers to show FHIR and SNOMED CT support, in-region data residency, and a documented lawful basis before signing, and treat data portability as a survival matter because you cannot afford to be locked into a vendor that fails. Borrowing proven offline-first, low-bandwidth patterns is often a better fit here than chasing the polished enterprise product, because resilience matters more than features when there is no one to call when the network drops. Where a national profile or a digital public good already exists, adopt it rather than commissioning anything bespoke you could never maintain.

Enterprise#

A large NHS body, integrated care system, or multinational supplier has the scale to shape standards rather than merely follow them, and the obligation to do so responsibly. The enterprise risk is a global procurement that quietly centralizes data across jurisdictions, creating sovereignty and lock-in problems that surface years later at a regulator's desk. Mandate open standards and data portability in every contract, insist on clear in-region data residency, and use your purchasing weight to strengthen the digital-public-good ecosystem rather than starve it. When you learn from other systems, resource the learning properly — study visits with named owners and honest write-ups — instead of collecting anecdotes.

Government#

A national or supranational body sets the rules everyone else works within, so its choices about standards, sovereignty, and openness echo for a decade. Governments should mandate the international standards (FHIR, SNOMED CT, ICD-11), invest in and contribute to digital public goods as a matter of resilience and value, and legislate clear, workable regimes for cross-border data and AI rather than leaving them to case-by-case negotiation. They also hold the diplomatic role: aligning with the WHO Global Strategy on Digital Health, supporting LMIC systems as partners rather than recipients, and advancing universal health coverage as a shared goal. The accountability is public and international, so decisions must be transparent and defensible, not merely expedient. (See Topic 9.1 — Working with Local & National Governments.)

Common failure modes#

• Lift and shift. Copying another country's model without its legal, identity, and trust scaffolding. Fix: adopt the pattern, rebuild the implementation for your context.
• Inventing local standards. Building bespoke code systems instead of using FHIR, SNOMED CT, and ICD-11. Fix: adopt global standards first and use national profiles where they exist.
• Silent cross-border data leakage. Data moving through overseas cloud regions or support desks with no transfer mechanism. Fix: map the regime and record the lawful basis before any data moves.
• Proprietary lock-in dressed as convenience. Buying a closed platform you cannot own, audit, or exit. Fix: weight digital public goods and mandate data portability.
• Charity framing of LMIC work. Treating lower-income partners as recipients rather than sources of proven design. Fix: partner reciprocally and adopt their resilient, offline-first patterns.
• Assuming an algorithm travels. Deploying a model validated on another population. Fix: revalidate on your own population and govern to the strictest applicable regime.
• Designing only for the demo. Assuming fast connectivity, modern devices, and high literacy. Fix: design offline-first with graceful degradation and measure uptake by group.

Maturity model#

Checklist#

• Exchange, terminology, and classification use HL7 FHIR, SNOMED CT, and ICD-11, with national profiles where they exist.
• Digital-public-good and open-standard options were weighted heavily in build-or-buy decisions.
• Every product and supplier contract guarantees data portability and a documented exit.
• The lawful basis, data residency, and transfer mechanism are recorded before any health data crosses a border.
• The applicable regimes (UK/EU GDPR, HIPAA, EU AI Act, EU Medical Device Regulation) are identified, with the strictest treated as the floor.
• Any AI model is validated on your own population and governed to the highest applicable international bar.
• International learning has a named owner who separates transferable principles from non-transferable specifics.
• No national model has been copied wholesale without rebuilding its implementation for local context.
• Services degrade gracefully — offline-first, low-bandwidth, fallback channels — for the hardest realistic conditions.
• Uptake and outcomes are measured by group to detect exclusion, in service of universal coverage and equity.

Key sources#

• World Health Organization — Global Strategy on Digital Health 2020–2025 (who.int).
• World Health Organization — Classification of digital health interventions and ICD-11 (who.int).
• Digital Public Goods Alliance — DPG Standard and registry (digitalpublicgoods.net).
• HL7 International — FHIR specification (hl7.org/fhir); SNOMED International — SNOMED CT (snomed.org).
• Estonia — e-Estonia and X-Road / Nordic Institute for Interoperability Solutions (e-estonia.com; niis.org).
• Ministry of Health & Family Welfare / National Health Authority (India) — Ayushman Bharat Digital Mission (abdm.gov.in).
• European Commission — Regulation (EU) 2017/745 on medical devices; Regulation (EU) 2024/1689 (Artificial Intelligence Act).
• Information Commissioner's Office — international transfers guidance under UK GDPR (ico.org.uk).
• The Lancet & Financial Times Commission — Governing health futures 2030 (thelancet.com).

References#

1. Global health — Wikipedia — https://en.wikipedia.org/wiki/Global_health
2. Digital health — Wikipedia — https://en.wikipedia.org/wiki/Digital_health
3. World Health Organization — Wikipedia — https://en.wikipedia.org/wiki/World_Health_Organization
4. Digital public goods — Wikipedia — https://en.wikipedia.org/wiki/Digital_public_goods
5. Universal health care — Wikipedia — https://en.wikipedia.org/wiki/Universal_health_care
6. Fast Healthcare Interoperability Resources (FHIR) — Wikipedia — https://en.wikipedia.org/wiki/Fast_Healthcare_Interoperability_Resources
7. SNOMED CT — Wikipedia — https://en.wikipedia.org/wiki/SNOMED_CT
8. ICD-11 — Wikipedia — https://en.wikipedia.org/wiki/ICD-11
9. mHealth — Wikipedia — https://en.wikipedia.org/wiki/MHealth
10. Leapfrogging — Wikipedia — https://en.wikipedia.org/wiki/Leapfrogging
11. Data sovereignty — Wikipedia — https://en.wikipedia.org/wiki/Data_sovereignty
12. Artificial Intelligence Act — Wikipedia — https://en.wikipedia.org/wiki/Artificial_Intelligence_Act
13. Regulation (EU) 2017/745 (EU Medical Device Regulation) — Wikipedia — https://en.wikipedia.org/wiki/Regulation_(EU)_2017/745
14. Health Insurance Portability and Accountability Act (HIPAA) — Wikipedia — https://en.wikipedia.org/wiki/Health_Insurance_Portability_and_Accountability_Act
15. General Data Protection Regulation — Wikipedia — https://en.wikipedia.org/wiki/General_Data_Protection_Regulation
16. Global Strategy on Digital Health 2020–2025 — World Health Organization — https://www.who.int/publications/i/item/9789240020924
17. The DPG Standard — Digital Public Goods Alliance — https://www.digitalpublicgoods.net/standard
18. Ayushman Bharat Digital Mission — National Health Authority, Government of India — https://abdm.gov.in/