Healthcare AI Learning

Reference

Sources & methodology

How Healthcare AI Learning sources, checks and reviews learning material. Exact references for each lesson live inside that lesson’s collapsed Sources & evidence panel, so this page stays a concise overview rather than a full bibliography.

How we source this material

Content is built from primary legal and official texts, recognised consensus and reporting guidance, scholarly literature, and vendor technical documentation where we are explaining a specific product behaviour or specification. We do not rely on news articles, press releases or marketing claims as evidence of safety or effectiveness.

This material is educational: it is not patient-specific medical advice and not legal advice.

Evidence hierarchy / what we trust first

  1. Primary law and official texts — e.g. EUR-Lex for the EU AI Act, MDR/IVDR, GDPR and EHDS; national statutes and official implementation guidance.
  2. Standards and public-body guidance — e.g. NIST publications, HL7/FHIR specifications and WHO guidance. These are authoritative guidance, not peer-reviewed research.
  3. Consensus and reporting guidance — e.g. FUTURE-AI, TRIPOD+AI, DECIDE-AI, CONSORT-AI and PROBAST+AI. Compliance with a guideline is not by itself proof of safety or effectiveness, but it signals that the evidence has been reported transparently.
  4. Scholarly literature — especially independent validation, prospective or live-service evaluations, and implementation studies that report operational outcomes, not only model metrics. We prefer peer-reviewed work; where we cite preprints (e.g. arXiv), they are early-stage scholarly work that has not completed peer review.
  5. Vendor technical documentation — used only for vendor-specific behaviour, specifications, API schemas or intended-use statements, not as independent evidence of clinical utility.
  6. Synthetic teaching cases — clearly labelled fictional scenarios designed to practise judgement, not to represent real patients or real evidence.

How the material is reviewed

Review here means internal editorial review plus an external blind review. Neither is a certification, and the two are deliberately described separately.

  • Internal content review — released lesson prose has undergone internal semantic review for factual errors, misleading statements, overclaims and source mismatches, and released graded quiz, case and lab items have been reviewed for ambiguity: whether the keyed answer is uniquely defensible, distractors are genuinely wrong, and explanations agree with the key. This is our own review of our own material, carried out in defined passes rather than as a guarantee that every sentence is re-examined after every edit.
  • External initial review (not a certification) — an external reviewer examined the platform across several passes, including browser-based testing, and noted that its coverage was partial. Its findings were triaged and used to drive a remediation programme.
  • External blind audit and delta verification — an independent blind audit of the released material first returned an amber result with a bounded list of material findings. The resulting remediation was independently re-verified in two further delta audits of frozen release candidates. The final delta verification, on 14 September 2026, returned a green result: all remaining release conditions were closed and no new critical, high or medium findings were raised. That is an audit opinion on the material as it stood on that date. It is not a certification, accreditation, regulatory determination, clinical safety case or evidence of compliance, and it does not mean the material is permanently correct or future-proof.
  • Browser and runtime testing — released routes and interactive exercises are exercised in a real browser on desktop and mobile sizes, including progress persistence, data export/import handling and legacy redirects. External links cited in the material are resolved, distinguishing genuine dead links from sites that block automated access.
  • Deterministic release checks (internal, not the audit) — automated integrity commands can be run at any time and are re-run as part of release QA, including for this release. They apply structural checks over the released content: that every keyed assessment, case and lab item resolves to a real option or category and carries a stem and rationale, that catalogue release state matches what is actually rendered, that regulatory dates and version pins match the texts we teach from, and that source links are neither duplicated nor malformed. For this release that is 660 keyed or graded structures inspected across 4,486 deterministic checks, plus an answer-cue simulation in which all 28 of 28 completion-gated assessment sets score below their pass threshold for an “always pick the longest option” strategy. These are our own internal checks, separate from the independent audit, and they are structural: they can tell you whether the material is internally consistent, not whether a statement is true.

Versioning and checked dates

Healthcare AI regulation and the underlying technical standards are moving quickly. We mark regulatory content with an “as of” date where it matters, and where a module teaches from a fast-moving technical specification, its reference list pins the exact version or revision used — for example specific protocol revisions, standard releases and dated framework editions. Pinning applies to those module reference lists, not to every glossary entry or visual guide. Regulatory and legal summaries were checked against the primary texts between 25 August and 10 September 2026.

Sources themselves can change after that date. Before you act on a legal or regulatory statement — especially conformity, classification or notification questions — verify the current text and any national transposition or guidance.

Key primary sources: EU AI Act, MDR, IVDR, GDPR and EHDS.

What this review does not mean

  • The review process above reduces risk; it does not prove the absence of all errors, and it is not a certification, accreditation or independent validation of Healthcare AI Learning.
  • The green result of the 14 September 2026 delta verification is an audit opinion on a frozen release at that point in time. It is not certification, not a regulatory determination and not evidence of compliance, and it does not guarantee that later edits, or changes in the underlying law and evidence, leave the material correct.
  • Our deterministic checks are structural. A passing run does not prove that any teaching statement or keyed answer is semantically correct.
  • Nothing here is medical advice for a specific patient, or legal advice for a specific product or organisation.

Corrections and ongoing review

Regulatory texts, technical standards and the evidence base evolve, and this material is reviewed and version-pinned on an ongoing basis rather than treated as finished. If you believe something is factually wrong or out of date, treat the primary source as authoritative and flag the discrepancy so it can be corrected.

Synthetic teaching cases

Several exercises use fictional patients, hospitals, vendors and datasets. They are labelled as synthetic or illustrative and are designed to let you practise assessment and decision making without exposing real patient data or relying on real product claims. Do not treat any synthetic case as clinical guidance for an actual patient.

Key source families

EUR-Lex / European Commission

Primary EU legal texts: AI Act, MDR, IVDR, GDPR and EHDS. We link directly to the official versions rather than secondary summaries.

WHO / FUTURE-AI

World Health Organization guidance and the FUTURE-AI international consensus on trustworthy AI in healthcare.

TRIPOD+AI / DECIDE-AI / CONSORT-AI / PROBAST+AI

Reporting and evaluation guidance for clinical prediction models, AI interventions and diagnostic/prognostic studies.

HL7 / FHIR

Healthcare interoperability standards, FHIR resources, terminologies and implementation guides.

NIST AI Risk Management Framework

Voluntary US framework and technical guidance for managing AI risks, useful alongside regional regulatory requirements.

Vendor documentation

Product-specific technical specifications, API schemas and intended-use statements only where we are explaining how a named tool behaves — not independent evidence of clinical value.

Module-level sources