Sector guidance
Healthcare extension
Verified orientation snapshot: 19 August 2026. This operational overlay is not medical, legal, regulatory, or conformity-assessment advice.
Healthcare changes the meaning of a “good result.” Speed matters only after clinical safety, intended purpose, population coverage, professional accountability, and continuity of care are protected.
Start by naming the role
| Role | Example | Default boundary |
|---|---|---|
| Administrative support | Summarize a non-clinical policy or prepare an appointment draft | A0–A1; no clinical inference |
| Clinical support | Retrieve evidence or draft a note for a qualified professional | A1; professional verifies source, patient, and conclusion |
| Patient-facing support | Explain approved information or route a request | A1–A2 only with escalation and accessible non-AI channels |
| Clinical decision or triage | Diagnose, prioritize, recommend treatment, or alter care | Treat as R3; formal clinical, legal, and product qualification before any pilot |
| Medical-device function | Software with an intended medical purpose | Determine applicable medical-device status before architecture or procurement |
Calling a system a “copilot” does not remove a medical intended purpose. Qualification follows what the system is intended and actually used to do.
Healthcare gates
H0 — Intended purpose and authority
- state the clinical or administrative purpose, users, patients, setting, and exclusions;
- identify who is professionally accountable for every downstream decision;
- determine whether the system or software may be a medical device or part of one;
- identify applicable Swiss, EU, cantonal, professional, research, and institutional rules;
- preserve a safe non-AI path.
Stop: the purpose is ambiguous, the accountable professional is absent, or experimental use is being presented as routine care.
H1 — Population, data, and harm model
- map source systems, consent or other authority, secrecy, retention, transfers, and secondary use;
- define the intended population and clinically meaningful subgroups;
- model delayed care, false reassurance, missed escalation, over-triage, bias, disclosure, and automation bias;
- separate evidence generated for research, product validation, and local deployment.
H2 — Product and supplier evidence
- document product qualification, classification, version, claims, and change policy;
- require evidence for data provenance, clinical evaluation, cybersecurity, human factors, and post-market monitoring where applicable;
- verify who performs regulatory, quality, vigilance, and incident duties;
- prohibit silent model or knowledge-base changes in the evaluated configuration.
H3 — Clinical evaluation
- preregister endpoints, reference standard, sample, sites, subgroups, missing-data treatment, and severe-error limits;
- compare against current care, not an idealized clinician;
- test workflow fit, alert burden, abstention, uncertainty communication, and override behavior;
- obtain independent clinical and methodological review for material use.
An aggregate accuracy score cannot release a system that misses a critical subgroup or creates an unacceptable patient-safety event.
H4 — Shadow and supervised pilot
- begin with retrospective or prospective shadow use that does not alter care;
- freeze the evaluated system and record every recommendation, correction, escalation, and downstream effect;
- train users on limitations, uncertainty, escalation, and reporting;
- move to supervised influence only after H0–H3 pass.
H5 — Controlled operation
- monitor clinical outcomes, near misses, subgroup drift, overrides, latency, and unavailable-system behavior;
- connect AI incidents to clinical safety, data-protection, cybersecurity, vigilance, and continuity procedures;
- rehearse withdrawal and restoration of the safe clinical process;
- reassess after any material change of model, data, intended purpose, interface, population, or integration.
Minimum evidence pack
- intended-purpose and product-qualification record;
- clinical owner, escalation map, and safe-care fallback;
- data lineage and patient/population impact assessment;
- locked evaluation protocol and results by subgroup;
- human-factors, cybersecurity, and workflow tests;
- signed release decision, monitoring thresholds, and incident routes.
Transfer boundary
Evidence does not automatically transfer across hospitals, specialties, languages, prevalence, equipment, workflows, or patient populations. Revalidate every material difference and distinguish product evidence from proof that the local care pathway is safe.
See the dated primary-source register, the accessibility assessment, and the fundamental-rights impact assessment.
To print or save as PDF: Ctrl+P (⌘P on Mac).
Source and history · GitHub