The Global Centre for Risk and Innovation (GCRI)
Health systems now depend on digital infrastructure for records, laboratory results, imaging, prescribing, supply logistics and surveillance, and increasingly on algorithms that support clinical and public health decisions. These dependencies bring their own failure modes: outages, cyberattacks, data breaches and models that perform unevenly or drift. This page sets out how digital risk develops in health, how it is measured, and what the evidence serves for those who govern health data and technology.
Digital health risk is the risk to patient care and privacy from the failure or misuse of health information technology: outages, cyberattacks, data breaches and algorithms that perform unevenly or drift. Hospitals depend on digital systems for records, results, prescribing and logistics, so an outage can stop clinical work.
The working screen behind this subject: its structure, terms and states. Names are placeholders and values illustrative.
Digital health risk · Province B · Month 6
| Oral rehydration salts | 2.1 | 3 | 5 | Low |
| First-line antibiotic | 1.5 | 11 | 14 | Low |
| Insulin | 2 | 1 | 13 | Adequate |
| Rapid diagnostic tests | 0.8 | 13 | 6 | Critical |
Data, AI safety and digital infrastructure. The dossier below sets out how the risk develops, what is measured, where the data come from, how it is modelled and who decides.
When electronic records, laboratory systems or imaging archives go down, care continues on paper only if downtime procedures have been rehearsed. Shared suppliers and cloud services mean one failure can reach many hospitals at once.
Attackers encrypt systems and exfiltrate data because health providers cannot tolerate downtime. Diverted ambulances, delayed diagnostics and cancelled procedures follow, and full recovery can take weeks.
A health data breach exposes sensitive information that cannot be revoked. Weak consent, re-identification of shared datasets and secondary use beyond the original purpose erode trust, and with it the willingness to share data in an emergency.
Clinical and public health models trained on unrepresentative data can perform worse for some groups and degrade as practice, populations or data systems change. Without monitoring after deployment, drift and bias go unnoticed.
Each term as this page uses it. Where a standard-setting body defines the term, the wording follows that body.
| Term | Definition |
|---|---|
| Ransomware | Malicious software that encrypts an organisation's data or systems and demands payment to restore them. |
| Interoperability | The ability of health information systems to exchange data and use it with the same meaning, using standards such as HL7 FHIR. |
| Downtime procedure | The manual process a hospital uses to keep caring for patients when clinical systems are unavailable. |
Each indicator carries its unit, its cadence, the kind of source behind it and the evidence label a value would carry. No values are shown: a programme supplies them under its own authority.
| Indicator | Unit | Cadence | Source type | Label |
|---|---|---|---|---|
| Reported health data breaches | incidents; records affected | monthly | Regulatory breach notification registers | OFFICIAL |
| Ransomware incidents affecting health providers | incidents | quarterly | Sector threat reports and incident disclosures | REPORTED |
| Unplanned clinical system downtime | hours | monthly | Hospital IT service records | OBSERVED |
| Known exploited vulnerabilities on health technology | open vulnerabilities on deployed assets | weekly | Vulnerability catalogues matched to asset inventories | OBSERVED |
| Use of agreed exchange standards | percent of registered systems | annual | National digital health architecture registries | REPORTED |
| Adverse event reports for AI-enabled devices | reports | quarterly | Medical device adverse event databases | REPORTED |
| Digital health maturity | phase across the monitor's indicators | periodic | Global Digital Health Monitor self-assessment | DECLARED |
The topic as a computational graph: named sources feed the methods, an evidence review gates the outputs, and the decisions stay with the authorities that hold them.
Fig. 02Nodes carry their type, two metric rows and a state; connectors show what feeds what; dashed frames name the owners; the timeline is the cadence. Design of the pipeline, not a record of a run.
Named public datasets and institutional records, each with its licence class. Sources by agreement are used only under their terms and never republished.
| Source | What it gives | Licence class |
|---|---|---|
| Global Digital Health Monitor | Country digital health maturity across governance, workforce, standards and infrastructure | Open, attribution, terms of use |
| US HHS Office for Civil Rights breach portal | Public records of reported breaches of protected health information | Public records |
| ENISA threat landscape for the health sector | Analysis of cyber incidents affecting European health organisations | Public report, ENISA terms of use |
| CISA Known Exploited Vulnerabilities catalogue | Vulnerabilities with evidence of active exploitation | Public domain |
| US FDA MAUDE and the list of AI-enabled medical devices | Device adverse event reports and authorised AI-enabled devices | Public domain |
| AI Incident Database | Documented incidents involving AI systems, health included | Open, attribution |
Health Nexus prepares evidence. The decisions below are taken by the authorities named, under their own rules, and never by the platform.
| Who decides | The question | Evidence this page serves |
|---|---|---|
| Hospital boards and chief information officers | Which systems need offline fallback, network segmentation or redundant suppliers | Dependency maps; downtime scenarios with their clinical consequences stated |
| Data protection authorities | Whether health data sharing and secondary use meet legal and consent requirements | Data flow inventories; re-identification risk assessments |
| Medical device regulators | Whether an AI-enabled device needs further evidence, restrictions or post-market study | Performance by subgroup; drift monitoring; adverse event reports |
| Ministries of health and digital health agencies | Which standards and architectures national systems must adopt | Interoperability and maturity evidence; continuity requirements |
Digital health risk is a patient-safety question as much as a technical one.
Health organizations run many interconnected systems, often including legacy software and medical devices that are hard to update. A cyber incident or major outage can force a hospital onto paper processes, delay results, divert ambulances and cancel treatment. Recovery can take weeks because systems must be rebuilt and verified.
AI tools learn from historical data and can perform worse for groups underrepresented in that data, or degrade when clinical practice or equipment changes. Concentration on a few vendors and cloud platforms creates shared points of failure across many organizations at once.
| Method or data | What it shows | Limits |
|---|---|---|
| Incident analysis and after-action reviews | How outages and attacks affected care | Many incidents are unreported or reported without clinical detail |
| Dependency and recovery-time mapping | Which systems support which services | Requires internal information that organizations hold closely |
| Clinical AI evaluation and monitoring | Accuracy, calibration and fairness across groups | Performance can drift after deployment |
| Privacy and governance review | Whether data use meets legal and ethical standards | Rules differ by jurisdiction and change over time |
The current service level is R0: information and enquiries. An enquiry receives a reference and names the next step; applications, payments, compute allocations and registrations open only when their team, terms and review capacity exist.