Safety levels
Entries can show two different safety scales. Each badge names its scale, and the two scales are never converted into each other: a safety level and a runtime risk tier answer different questions.
Safety level
A safety level says how much independent evidence stands behind a genomic AI system's safety claims. The more directly a system can affect patients, the higher its level and the more demanding the evidence. Levels are defined by the GA4GH Safety Certification Level scheme, a GA4GH AI Work Stream draft (version 0.10.0) that may still change.
A system takes the level of its riskiest characteristic: one that reads individual-level data is GASL-3 even if its outputs are research-only. When in doubt the higher level applies, and the level has to be reassessed when the system is used in a new setting. The scale has four levels, GASL-1 to GASL-3 plus GASL-3E; there is no GASL-0 or GASL-4 on it (those numbers belong to the separate runtime risk tier).
GASL-1 Research use
What it means. The system works only with aggregate, published or synthetic genomic data, and its outputs are used for research alone. Nothing it produces feeds into decisions about a patient.
Evidence required.
- A self-assessment by the developer, written up as an evaluation report. At a minimum it covers consent and data-use compliance and whether the system stays within its declared purpose; the other evaluation areas are recommended.
- A signed statement from named people at the developer vouching that the evaluation is complete and accurate.
- Valid for up to 24 months, or until a change that requires re-evaluation.
What to expect.
- A documented safety baseline you can read, but no one outside the developer has checked it.
- An annual self-review is recommended, not required.
GASL-2 Clinical decision support
What it means. The system uses aggregate data, or individual-level data protected by differential privacy, and its outputs may influence clinical decisions indirectly: for example research that later shapes practice, or recommendations a clinician reviews.
Evidence required.
- The developer's evaluation across all six evaluation areas: re-identification risk, consent boundaries, fairness across ancestry groups, clinical safety, staying within declared scope, and robustness to attack.
- A review by a qualified reviewer who is independent of the development team and has no conflict of interest, with a written review report and the developer's response to it.
- Valid for up to 18 months, or until a change that requires re-evaluation.
What to expect.
- Safety claims that someone independent has examined, though not re-run.
- Runtime monitoring and a post-deployment review every quarter are required.
GASL-3 Autonomous clinical action
What it means. The system uses individual-level genomic data (for example VCF files or individual genotypes) and its outputs directly drive diagnosis, treatment choice or risk stratification, or it acts without a clinician reviewing each output.
Evidence required.
- An audit by an independent, accredited third-party organisation that re-runs the evaluation across all six areas, with a machine-readable audit trail.
- Clinical validation by an accredited clinical laboratory (for example under CLIA or ISO 15189).
- Fault-injection testing showing that safety controls fail safely when the services they depend on go down.
- A post-deployment monitoring plan and an incident response plan. Valid for up to 12 months, or until a change that requires re-evaluation.
What to expect.
- The strongest independent evidence this scale offers, with continuous monitoring and monthly surveillance required.
- It is not a regulatory approval: it can support, but does not replace, a medical-device or AI Act conformity assessment.
GASL-3E Clinical AI inside an electronic health record
What it means. A GASL-3 system that is also built into an electronic health record, for example through CDS Hooks, FHIR or HL7 v2, so its outputs reach clinicians inside their everyday workflow.
Evidence required.
- Everything required for GASL-3.
- A medical-device-grade software lifecycle (IEC 62304 Class C), and clinical validation on prospective or gold-standard clinical data.
- Integration testing for slow responses, missing or malformed record data and many simultaneous users, plus tested behaviour when the model or the record system is unavailable.
- A usability study with clinicians, an assessment of alert fatigue where the system raises alerts, and a post-market surveillance plan.
What to expect.
- The same assurance as GASL-3, extended to the risks that come from living inside a clinical record system.
- A GASL-3 system that is later connected to a health record has to be re-evaluated at this level first.
Reading a level in this registry
- The registry records a level; it does not award one. Each badge says where the level came from (reported by the submitter, checked by a maintainer, or read from the system's own endpoint). No GA4GH body currently runs a certification service for these levels, so check the evaluation documents themselves before relying on one.
- A level applies to the exact artefact that was evaluated. A quantised, converted or fine-tuned version is a different artefact, so evidence about the original does not carry over to it.
- An entry with no badge simply has no level recorded. That is not the same as a low level.
Runtime risk tier
A runtime risk tier describes how tightly an agent has to be isolated while it runs, on a scale from 0 to 4, and is reported live by the agent's own endpoint. It is an operational setting, not an assessment of evidence, and it has no fixed relationship to the safety level above. Scheme:GA4GH Runtime Safety Tier (draft).
| Tier | Used for | Minimum isolation |
|---|---|---|
| 0 | Informational | Standard container isolation; outbound network access is not restricted. |
| 1 | Research | Containers with reduced privileges; network access only to declared endpoints; a read-only system image. |
| 2 | Diagnostic support | Containers with kernel security profiles; network access only to approved services, all of it logged. |
| 3 | Clinical-adjacent | A lightweight virtual machine or equivalent sandbox; no direct internet access; nothing kept between runs. |
| 4 | Clinical-direct | Hardware-backed isolation, including a trusted execution environment for memory; an air-gapped or strictly allow-listed network. |
Tiers 3 and 4 may be relaxed in documented development and test settings, but a relaxed agent must not touch production clinical data.