Topic 8.4 — AI & Emerging Technology Governance

In one sentence: Artificial intelligence in health and care is a learning, data-dependent, and often opaque technology that can scale both benefit and harm faster than any system you have governed before, so you must govern it as a clinical-safety, equity, and public-trust matter throughout its whole lifecycle — not treat it as ordinary software you buy once and forget.

Why this matters in health and care#

Most of the software you have deployed behaves the same way tomorrow as it does today: its logic is written down, its behaviour is testable, and when it is wrong it tends to be wrong in a visible, repeatable way. Artificial intelligence breaks all three of those comforts. It learns statistical patterns from data rather than following rules a person wrote; its behaviour depends entirely on the data it was trained on and the data it now meets; and its reasoning is frequently opaque even to the people who built it. That combination is why AI needs its own governance discipline rather than being folded into a generic software checklist.

In health and care the consequences are not abstract. A model that under-detects disease in a group who were under-represented in its training data does not make an isolated error — it makes the same error, silently, thousands of times, entrenching and scaling health inequalities. A generative model that fabricates a plausible-sounding clinical detail can mislead a stretched clinician at exactly the wrong moment. A tool that works beautifully in the population it was validated on can quietly decay when the population, the care pathway, or the upstream data changes. AI can scale good decisions and it can scale bias, error, and harm with equal efficiency.

This topic is about governing that risk without either breathing the hype or banning the technology. It deliberately does not repeat the foundations laid elsewhere: clinical safety (see Topic 1.6 — Clinical Safety & Risk Management), information governance, data protection and cyber security (see Topic 1.7 — Information Governance, Data Protection & Cyber Security), and evidence-driven decision-making (see Topic 1.3 — Evidence-Driven Decisions). It anchors to them, and adds what is specific to learning systems. Treat it as the AI-shaped extension of your existing assurance, and as the governed sibling of phasing in innovation (see Topic 8.0 — Phasing in Innovation).

Core concepts#

Artificial intelligence and machine learning. For a leader, the practical distinction is this: most AI in health and care today is machine learning — systems that infer patterns from examples rather than executing hand-written rules. This is why the data is the product as much as the code: change the training data and you change the behaviour. It also means a model does not "know" anything; it estimates, and it can be confidently wrong. Understanding this at a conceptual level is enough to ask the right governance questions; you do not need to read the mathematics.

Software as a Medical Device (SaMD) and the MHRA. When software has a medical purpose — diagnosing, screening, triaging, calculating a dose, predicting deterioration — it is very often a medical device in law, regardless of whether it runs on a phone or a server. Medical software of this kind, known as Software as a Medical Device (SaMD), is regulated in the United Kingdom by the Medicines and Healthcare products Regulatory Agency (MHRA). If you are commissioning or building an AI tool with a clinical purpose, the first governance question is whether it is a regulated device and, if so, whether it holds valid conformity marking. Getting this wrong is not a technicality; deploying an unregistered medical device is unlawful and unsafe.

The AI Airlock. The MHRA has established a regulatory sandbox called the AI Airlock to work through how AI as a medical device should be regulated in a controlled, monitored setting. A regulatory sandbox lets a regulator and a small number of developers examine hard, novel questions — for example how to validate a model that updates over time — under supervision, before general rules are set. Be sober about what this is: the Airlock is a learning environment for the regulator and a handful of participants, not a fast-track approval route, and being associated with it does not mean a product is approved for general clinical use.

Algorithmic bias and fairness. Algorithmic bias is the tendency of a system to produce systematically unfair outcomes for particular groups. In health and care its most common source is the training data: if a group is under-represented, mislabelled, or measured with a biased instrument, the model learns to serve that group worse. Because the model then applies this at scale and with an air of objectivity, biased AI can widen the very inequalities your organization is statutorily obliged to reduce.

Explainability and the black box. Explainable artificial intelligence concerns whether a human can understand why a model produced a given output. Many high-performing models are effectively "black boxes": accurate in aggregate but unable to give a clinician a trustworthy reason for an individual decision. In a clinical setting this matters for accountability, informed consent, and the clinician's duty to exercise judgement — a doctor cannot meaningfully take responsibility for advice they cannot interrogate.

Model drift and post-market surveillance. A model's accuracy is not fixed. Concept drift — a change over time in the relationship between inputs and the thing being predicted — means a model validated last year can silently degrade this year as populations, pathways, or upstream data change. This is why AI requires ongoing post-market surveillance and monitoring, not just a one-off validation at go-live.

MLOps and the model lifecycle. MLOps is the operational discipline of deploying, monitoring, versioning, and retraining models reliably in production. It is the machinery that makes lifecycle governance real: knowing which model version is live, on which data, with what performance, and being able to roll back.

Human-in-the-loop. A human-in-the-loop design keeps a person — usually a clinician — meaningfully in the decision, with the authority and the information to override the model. Done well it preserves accountability; done as a rubber stamp it provides only the illusion of oversight.

Generative AI and large language models. Generative artificial intelligence, including large language models (LLMs), produces fluent text and other content. Its realistic near-term value in health and care is largely administrative — drafting documentation, summarizing, easing paperwork. Its defining risk is hallucination: the confident generation of false but plausible content, compounded by confidentiality risks when patient data is entered into third-party services.

Digital therapeutics and health apps. Digital therapeutics (DTx) are software-driven, evidence-based interventions that prevent, manage, or treat a condition — distinct from general wellness apps precisely because they make a clinical claim, which means many are Software as a Medical Device and demand the same evidence and assurance as any other intervention you prescribe or recommend.

Best practices#

1. Classify the tool before you do anything else. Establish, in writing and with clinical and regulatory input, whether the AI has a medical purpose and is therefore a regulated medical device, and whether it holds valid MHRA conformity marking. This single determination governs everything downstream — the assurance route, the liabilities, the lawfulness of deployment. When in doubt, seek regulatory advice rather than assuming an administrative tool is out of scope.

2. Run AI through your existing clinical-safety and IG machinery, extended not bypassed. Every clinical AI deployment needs the clinical risk management of DCB0129/DCB0160 (see Topic 1.6) and a Data Protection Impact Assessment under your information governance framework (see Topic 1.7). Do not let novelty or supplier enthusiasm create a parallel, lighter process. AI-specific hazards — bias, drift, opacity, automation bias — should be added to the hazard log, not substituted for it.

3. Interrogate the training data for representativeness and bias. Ask who is in the data and who is missing, how outcomes were labelled, and whether the measuring instruments were themselves biased across groups. Require the supplier to report performance broken down by relevant subgroups — age, sex, ethnicity, deprivation — not just headline accuracy. A tool that cannot demonstrate equitable performance is a health-inequality risk however impressive its average.

4. Demand clinical validation appropriate to the risk, and prefer prospective evidence. Retrospective accuracy on curated data is the weakest form of evidence. For anything influencing clinical decisions, seek validation in a population and workflow like yours, ideally prospective, and route the claim through the appropriate assurance framework — the NICE Evidence Standards Framework for digital health technologies and the Digital Technology Assessment Criteria (DTAC) as baseline assurance. Match the strength of evidence to the magnitude of potential harm.

5. Insist on meaningful human-in-the-loop and clear accountability. Define who is accountable for a decision the AI informed, and ensure the human has both the authority to override and the information to do so. Guard actively against automation bias — the tendency to defer to the machine — through training, interface design, and audit of override rates. If overrides never happen, your "human in the loop" is decorative.

6. Treat go-live as the start of monitoring, not the end of assurance. Stand up post-market surveillance from day one: monitor real-world performance, watch for concept drift, and define the thresholds and process for retraining, pausing, or withdrawing the model. Establish model versioning and rollback through sound MLOps so you always know what is live and can revert safely. A model that is never re-checked is a slowly failing safety control.

7. Govern generative AI to its realistic uses and against its real risks. Permit LLMs where the value is genuine and the risk is contained — administrative drafting, summarization, documentation support with human review — and prohibit unmanaged entry of patient-identifiable data into third-party services. Assume any generative output may be fabricated until a human verifies it, and never let unverified generated content enter the clinical record. Clear, enforced policy beats both a blanket ban that drives shadow use and a free-for-all that leaks data.

8. Apply information governance to the whole data lifecycle, including training. The data used to train, fine-tune, and evaluate a model is subject to the same lawful-basis, minimization, and transparency obligations as any other use (see Topic 1.7). Be explicit about the basis for training on patient data, whether it is de-identified adequately, and what the supplier may do with it. Contracts should forbid re-use of your data to train products for others without a lawful basis and your agreement.

9. Keep a human-readable model register and demand transparency from suppliers. Maintain an inventory of AI in use: purpose, regulatory status, training data provenance, validation evidence, monitoring plan, and accountable owner. Require suppliers to be transparent about how a model works, its limitations, and its failure modes; opacity from a vendor is itself a risk signal. You cannot govern what you have not written down.

10. Horizon-scan deliberately and phase in through controlled evaluation. Beyond today's AI, watch emerging technologies — ambient documentation, foundation models, and further out, quantum and novel sensing — with structured horizon-scanning rather than reactive procurement. Introduce anything genuinely novel through the controlled, reversible, evaluated approach of phasing in innovation (see Topic 8.0), starting small, measuring honestly, and retaining the ability to stop.

11. Treat digital therapeutics and health apps as interventions, not consumer downloads. When an app makes a clinical claim — to treat, manage, or prevent a condition — it is an intervention that patients will act on, and it deserves the same scrutiny as a drug or a device before you prescribe or recommend it. Establish whether it is Software as a Medical Device with valid conformity marking, demand evidence proportionate to its claim, and complete a clinical safety assessment (see Topic 1.6) rather than trusting an app-store rating or a supplier's enthusiasm. An unassured app that a clinician endorses carries your organization's name and your accountability if it harms.

12. Route health apps through existing assurance and keep a curated, safe library. Assess digital therapeutics through the same machinery you already run — DTAC as baseline, the NICE Evidence Standards Framework matched to the clinical claim, and clinical safety and IG review — and build the real-world evaluation evidence over time (see Topic 8.6). Maintain a curated library of apps you have assured and stand behind, with each app's regulatory status, evidence, and owner recorded, so clinicians recommend from a safe, governed shortlist. The alternative — an uncontrolled sprawl of unassessed apps recommended informally across teams — is unmanageable and unsafe.

Questions to discuss with your team#

1. For each AI tool we are considering or already using, do we actually know whether it is a regulated medical device — and can we produce the evidence? This sounds like a compliance formality but it is the load-bearing question, because the answer determines what is lawful, who is liable, and what assurance you owe the public. It is easy to assume a tool that "just helps with triage" or "just summarizes notes" is harmless administrative software when its medical purpose in fact makes it a regulated device requiring MHRA conformity marking. The discussion should force you to name each AI tool in use or in the pipeline, state its intended purpose in plain clinical terms, and identify who made the device-classification call and on what basis. It should surface the uncomfortable cases where a tool was procured through an ordinary IT route with no regulatory check at all. Be honest about whether you could, today, produce the conformity documentation and validation evidence if a regulator or a coroner asked. The value of the conversation is that it converts a vague sense that "someone must have checked" into a documented, owned position — and reveals the tools where nobody has.

2. Have we demanded to see how this model performs for the groups most likely to be harmed, or have we accepted a headline accuracy figure? Average accuracy is the number suppliers lead with and the number that hides algorithmic bias, because a model can be highly accurate overall while performing markedly worse for an under-represented group. In health and care that is not a statistical curiosity; it is a mechanism for widening the inequalities you are legally and morally bound to reduce, applied silently and at scale. The team should discuss what subgroup evidence you have actually seen — performance broken down by age, sex, ethnicity, and deprivation — and whether you know who was in the training data and who was missing. It is worth naming the discomfort here: pressing a supplier on fairness can feel like obstructing an exciting innovation, and the honest question is whether you are willing to say no to a tool that cannot demonstrate equitable performance. Consider also how you would even detect inequitable outcomes after deployment, since bias that was invisible at procurement will be invisible in production unless you monitor for it. A good discussion ends with a concrete evidentiary bar for fairness that applies before any clinical AI goes live, and a plan to keep watching afterwards.

3. When this model is wrong — and it will be — who is accountable, will a human really catch it, and how will we even know? Every model fails sometimes, and learning systems can drift into failing more often over time, so the mature question is not whether errors occur but whether your safeguards are real. The team should test whether the human-in-the-loop is meaningful or decorative: does the clinician have the authority and the information to override, and if you looked at override rates, would you find they ever actually override, or has automation bias set in? Discuss who is named as accountable for a decision the AI informed — the clinician, the organization, the supplier — because "the algorithm did it" is not a defensible position to a patient or a coroner. Confront your monitoring honestly: do you have post-market surveillance that would detect concept drift, defined thresholds for pausing or withdrawing the model, and the MLOps machinery to know which version is live and to roll it back? For generative tools, add the hallucination question — what stops fabricated content entering the clinical record, and who verifies output before it is trusted? The most useful version of this conversation exposes the gap between the reassuring diagram of "human oversight" and what would genuinely happen at 3am on a busy ward.

4. What is happening to our patients' data when we train, fine-tune, and run these models — and what has the supplier reserved the right to do with it? AI concentrates data-governance risk precisely because the data is the product: a model is only as trustworthy as the lawful basis, minimization, and transparency behind every dataset it touched, including the training and evaluation data that predates go-live. The team should be able to state, for each tool, the lawful basis for any use of patient data, whether de-identification is adequate rather than merely asserted, and where the data physically flows once it leaves your control. A recurring trap is the contract that quietly permits the supplier to re-use your data to improve products it will sell to others; discuss whether your agreements forbid that without a lawful basis and your explicit consent, and whether anyone has actually read those clauses. This connects directly to your information governance framework (see Topic 1.7), and it is where enthusiasm for a capable tool most often outruns due diligence. An honest answer names who owns the DPIA, what the supplier may and may not do, and where you are currently exposed — rather than assuming that because the demo was impressive the paperwork must be sound.

5. How do we decide what NOT to adopt, and can we resist the pressure to buy the thing everyone is excited about? The hardest governance discipline with a fast-moving technology is saying "not yet" or "not this", and a team that cannot articulate its criteria for declining will end up adopting by drift and hype rather than by evidence. Discuss what would make you walk away from an otherwise attractive tool — weak subgroup evidence, an unclear regulatory status, a use case where the realistic benefit is thin relative to the risk — and whether those red lines are written down or merely felt. There is a real tension here between the cost of missing a genuine improvement and the cost of a scaled failure that damages public trust, and reasonable people will weigh them differently. It is worth naming the political reality that pressure to adopt often comes from a board, a supplier relationship, or a national mandate, not from the clinical need itself. The topic's stance is to horizon-scan deliberately and phase in through controlled, reversible evaluation (see Topic 8.0), so an honest answer describes how a promising-but-unproven tool enters as a small, measured, stoppable pilot rather than a wholesale rollout — and who holds the authority to stop it.

6. Can we explain what this model does to the clinicians who must trust it and the patients affected by it — and have we been honest about its limits? A model that a clinician cannot interrogate and a patient cannot understand corrodes the informed judgement and informed consent that clinical care depends on, however accurate it is in aggregate. The team should discuss how much explainability this particular use actually requires: a queue-prioritization aid demands less than a tool that influences a diagnosis or a treatment decision, and matching the explanation to the stakes is a governance choice, not a technical afterthought. Consider what you tell the clinicians expected to use it — its purpose, its known failure modes, the groups for whom it is less reliable — and whether that briefing is candid or a marketing summary. Patient-facing honesty matters too: are people told when AI is involved in their care, and in language they can act on? This is also a workforce question, because trust that is too low means a useful tool is ignored while trust that is too high produces the automation bias that hollows out oversight. An honest answer confronts whether your training and communication are building calibrated trust or merely selling the tool.

In practice: a health & care example#

An integrated care system is offered an AI tool that reads chest X-rays and flags likely abnormalities to prioritize the radiology reporting queue. The clinical safety officer and the medical director resist the pressure to procure it quickly and instead put it through proper governance.

First, classification: the tool has a clear medical purpose, so it is confirmed as Software as a Medical Device, and its MHRA conformity marking and intended-use statement are verified — the intended use is triage support, not autonomous diagnosis, which shapes everything that follows. Next, assurance: the tool is taken through DTAC as baseline, its clinical claims are checked against the NICE Evidence Standards Framework, a DCB0160 clinical risk assessment is completed, and a DPIA covers the imaging data (see Topics 1.6 and 1.7). The team asks for subgroup performance and discovers the validation population under-represented a local demographic; they require additional local validation before proceeding, treating potential bias as a health-inequality risk rather than a footnote.

At deployment the design keeps a human in the loop: every image is still reported by a radiologist, and the AI only reorders the queue, so a missed flag cannot by itself cause a missed diagnosis. Post-market surveillance is stood up from day one — monitoring detection rates, discordance between the model and reporting radiologists, and any drift as scanner hardware and case-mix change — with pre-agreed thresholds to pause the tool and a rollback path through the supplier's versioned deployment. Separately, when a ward asks to paste patient histories into a public LLM to draft discharge summaries, the same governance forum says no to that unmanaged route and commissions an approved, contained tool with human verification instead. A year on, the queue-prioritization tool has modestly improved reporting turnaround, its monitoring has caught one episode of drift after a scanner upgrade, and — crucially — the organization can show exactly how it is governed.

Sector lenses#

Startup#

A digital-health startup often is the AI, so its governance maturity is its market access. Founders should treat regulatory classification, clinical validation, and bias evidence as core product work, not as a compliance tax bolted on before a sale, because a buyer's clinical safety officer will ask for exactly these and a "no" ends the deal. Engaging early with the MHRA — potentially through mechanisms like the AI Airlock for genuinely novel questions — and designing for DTAC and the NICE Evidence Standards Framework from the outset turns assurance into a competitive advantage. The characteristic startup risk is over-claiming: marketing that outruns the evidence, or a demo of average accuracy that hides poor subgroup performance. The disciplined founder builds monitoring and post-market surveillance into the product early, because a single scaled failure at a reference site is an existential event for a small company.

Small business#

An established small provider — a GP practice, a community pharmacy, a care home, a single-site clinic — is usually a buyer of AI rather than a builder, yet it carries the same duties as a large trust with none of the dedicated clinical-safety, IG, or informatics staff to discharge them. The practical risk is adopting a tool on a supplier's assurances because there is no in-house capacity to demand device classification, subgroup evidence, or a DPIA, and no one to notice when a model drifts. Lean hard on the assurance others have already done: prefer tools that clearly hold MHRA conformity marking and have passed DTAC, buy from suppliers who publish their evidence, and recommend health apps only from a curated library your ICS or a national body has assured rather than assessing each one yourself. Where you cannot personally verify a tool's safety, that is a reason to defer to the shared assurance of your system, not to skip the check. Keeping even a lightweight register of which AI tools you use, for what, and who owns them turns an unmanageable duty into a proportionate one.

Enterprise#

A large trust or ICS has the apparatus to govern AI properly and the scale that makes getting it wrong serious. Its job is to extend existing clinical-safety, IG, and assurance functions to cover AI — a model register, subgroup-fairness bars, post-market monitoring, MLOps for versioning and rollback — rather than letting AI arrive through unscrutinized IT or research routes. The enterprise's real danger is fragmentation: dozens of pilots, ambient-scribe trials, and departmental LLM experiments proliferating with no central inventory, no consistent DPIA, and no one accountable when a tool drifts. Change fatigue and supplier pressure push towards fast adoption, so leadership must hold the line that novelty does not earn a lighter process. Done well, the enterprise can also generate the prospective, local validation evidence that smaller players cannot, and share it across the system.

Government#

National and local government bodies — the MHRA, NHS England, DHSC, NICE, devolved administrations, and local authorities — set the conditions under which everyone else deploys AI. Their instruments are regulation, standards, assurance frameworks (DTAC, the Evidence Standards Framework), safe-harbour mechanisms like the AI Airlock, and the funding and guidance that steer safe adoption across a federated system they do not directly line-manage. Accountability runs to ministers, Parliament, and the public, so a scaled AI failure or a demonstrable bias in a national tool is a public-trust event with a long shadow. Government's proper role is to make the safe path the easy path — clear rules, reusable assurance, honest public communication about what AI can and cannot do — while resisting both hype-driven mandates and reflexive prohibition. Getting the balance wrong in either direction costs years of trust.

Common failure modes#

• Skipping regulatory classification. Deploying a clinical AI as if it were ordinary software. Avoid it by determining device status and conformity marking first, with regulatory input.
• Headline-accuracy blindness. Accepting an average figure that hides poor performance for under-represented groups. Avoid it by requiring subgroup evidence before go-live and monitoring for inequity after.
• Validate once, forget forever. Treating go-live as the end of assurance while the model silently drifts. Avoid it by standing up post-market surveillance with thresholds and rollback.
• Decorative human oversight. A "human in the loop" who rubber-stamps under automation bias. Avoid it by auditing override rates and designing genuine authority to intervene.
• Ungoverned generative AI. Staff pasting patient data into public LLMs and trusting fabricated output. Avoid it by clear policy plus an approved, contained tool with human verification.
• Parallel light-touch process. Letting AI bypass clinical-safety and IG because it is "innovation". Avoid it by extending existing DCB and DPIA machinery to AI.
• No inventory. Nobody knowing which models are live, on what data, owned by whom. Avoid it by maintaining a model register.

Maturity model#

Checklist#

• Each AI tool's medical-device status and MHRA conformity marking are determined and documented.
• Clinical AI has passed DTAC, been checked against the NICE Evidence Standards Framework, and has a DCB clinical risk assessment and a DPIA.
• Subgroup performance (age, sex, ethnicity, deprivation) has been seen and meets an agreed fairness bar.
• Clinical validation matches the risk level and prefers prospective, local evidence.
• A meaningful human-in-the-loop is designed, with authority and information to override.
• Named accountability for AI-informed decisions is written down.
• Post-market surveillance, drift thresholds, and a pause/rollback plan are live from go-live.
• MLOps gives model versioning and safe rollback; the live version is always known.
• Generative AI policy permits realistic uses, forbids patient data in unmanaged services, and requires human verification.
• Information governance covers training, fine-tuning, and evaluation data, with contractual limits on supplier re-use.
• A human-readable model register records purpose, provenance, evidence, monitoring, and owner.
• Emerging technologies are horizon-scanned and phased in through controlled, reversible evaluation.

Key sources#

• MHRA — Software and Artificial Intelligence (AI) as a Medical Device, and the AI Airlock regulatory sandbox (gov.uk).
• NICE — Evidence Standards Framework (ESF) for digital health technologies (nice.org.uk).
• NHS England — Digital Technology Assessment Criteria (DTAC) for baseline assurance of digital health technologies.
• NHS England / former NHSX — A Buyer's Guide to AI in Health and Care, and the AI Ethics Initiative.
• DCB0129 and DCB0160 — clinical risk management standards for health IT (see Topic 1.6).
• MHRA / IMDRF — Software as a Medical Device (SaMD) framework and good machine learning practice.
• The King's Fund and the Health Foundation — analysis of AI, data, and inequalities in health and care.
• See also Topic 1.3 — Evidence-Driven Decisions; Topic 1.6 — Clinical Safety & Risk Management; Topic 1.7 — Information Governance, Data Protection & Cyber Security; Topic 8.0 — Phasing in Innovation.

References#

1. Artificial intelligence — Wikipedia — https://en.wikipedia.org/wiki/Artificial_intelligence
2. Machine learning — Wikipedia — https://en.wikipedia.org/wiki/Machine_learning
3. Medical software (including Software as a Medical Device) — Wikipedia — https://en.wikipedia.org/wiki/Medical_software
4. Medicines and Healthcare products Regulatory Agency — Wikipedia — https://en.wikipedia.org/wiki/Medicines_and_Healthcare_products_Regulatory_Agency
5. Algorithmic bias — Wikipedia — https://en.wikipedia.org/wiki/Algorithmic_bias
6. Explainable artificial intelligence — Wikipedia — https://en.wikipedia.org/wiki/Explainable_artificial_intelligence
7. Concept drift — Wikipedia — https://en.wikipedia.org/wiki/Concept_drift
8. MLOps — Wikipedia — https://en.wikipedia.org/wiki/MLOps
9. Human-in-the-loop — Wikipedia — https://en.wikipedia.org/wiki/Human-in-the-loop
10. Generative artificial intelligence — Wikipedia — https://en.wikipedia.org/wiki/Generative_artificial_intelligence
11. Large language model — Wikipedia — https://en.wikipedia.org/wiki/Large_language_model
12. Hallucination (artificial intelligence) — Wikipedia — https://en.wikipedia.org/wiki/Hallucination_(artificial_intelligence)
13. Software and AI as a Medical Device — MHRA, GOV.UK — https://www.gov.uk/government/publications/software-and-artificial-intelligence-ai-as-a-medical-device
14. AI Airlock: the regulatory sandbox for AI as a Medical Device — MHRA, GOV.UK — https://www.gov.uk/government/collections/ai-airlock-the-regulatory-sandbox-for-aiamd
15. Evidence standards framework (ESF) for digital health technologies — NICE — https://www.nice.org.uk/about/what-we-do/digital-health/evidence-standards-framework-for-digital-health-technologies
16. Digital Technology Assessment Criteria (DTAC) — NHS England — https://transform.england.nhs.uk/key-tools-and-info/digital-technology-assessment-criteria-dtac/
17. A Buyer's Guide to AI in Health and Care — NHS Transformation Directorate — https://transform.england.nhs.uk/ai-lab/explore-all-resources/adopt-ai/a-buyers-guide-to-ai-in-health-and-care/
18. Software as a Medical Device (SaMD): Key Definitions — International Medical Device Regulators Forum (IMDRF) — https://www.imdrf.org/documents/software-medical-device-samd-key-definitions
19. Digital therapeutics — Wikipedia — https://en.wikipedia.org/wiki/Digital_therapeutics