medical-adverse-event-incident-card

Medical Adverse Event Incident Card Profile v0.1 draft. A healthcare-specific profile of the AI Incident Card spec — extends it with the three coexisting regulator-facing taxonomies (US FDA MedWatch + EU MDR vigilance + IMDRF terminology) and a CTCAE-aligned clinical-severity scale, so one Incident Card emits regulatory-ready evidence for both FDA and EU reporters from a single artifact.

Part of the Kinetic Gain Protocol Suite.

Status: v0.1 draft. The profile at profile.json, the canonical example at examples/rad-ai-missed-mass-lung-ct.json.

Why this exists

When an AI/ML medical device misbehaves — a triage model misses a finding, a dosing model recommends an over-dose, a vision-language model hallucinates a finding into a structured report — the people who need a record of it are spread across at least four offices:

1. The hospital's QMS owner. Needs a structured event for the next ISO 13485 / Joint Commission review.
2. The vendor's post-market surveillance group. Needs a MedWatch-shaped event to evaluate against 21 CFR §803 reporting thresholds.
3. The vendor's EU vigilance officer. Needs the same event in MDR Article 87–89 language for EUDAMED vigilance.
4. The buyer's procurement office. Needs a hash-chained audit-stream entry that their AI Procurement Decision Card cited.

Today each group fills in a different form, with different taxonomies, from the same underlying event. The Suite's AI Incident Card is the generic spec that the hospital/vendor emit once. This profile pins the healthcare-specific fields so the same Incident Card seeds the FDA MedWatch report, the EU MDR vigilance entry, and the IMDRF-coded record — without re-deriving them per-incident.

What the profile asserts

An Incident Card that conforms to this profile carries a top-level medical_extensions object with:

• A CTCAE-aligned clinical severity grade (1–5), reporter-assigned, anchored to the same scale used in oncology and infectious-disease clinical trials.
• A patient_contact sub-object stating whether the AI output reached the patient, what kind of human-in-loop existed, and whether a clinician override was taken.
• At least one of fda_medwatch or eu_mdr_vigilance (or both), depending on jurisdiction — each carries the regulator's category code, report ID once filed, and a rationale note tying the categorization to the regulation's threshold language.
• OPTIONAL but recommended: a list of imdrf_codes from the IMDRF Adverse Event Terminology (AE WG/N43 FINAL:2020), which is the cross-jurisdiction taxonomy regulators are converging on for machine-comparable reporting.

The profile does not:

• Define a new schema. Incident Cards conforming to this profile are valid against the AI Incident Card spec at v0.1. The extensions live inside a single medical_extensions object that downstream generic-tooling can safely ignore.
• File anything. An actual MedWatch 3500A or MDR vigilance report is submitted via FDA's MedWatch portal and EUDAMED respectively. This profile is the evidence artifact that seeds those reports.
• Establish FDA, EU MDR, or IMDRF compliance. Compliance is a posture established by the manufacturer's QMS and the regulator's review; this profile is readiness scaffolding.
• Substitute for the reporter's judgment. Severity grades, MedWatch categories, and MDR articles are reporter-assigned, not algorithmically derived.

The four taxonomies, side-by-side

Layer	Source	Code shape	Used by
Clinical severity	CTCAE v5.0 (NIH/NCI), 5 grades	1..5 integer	All reporters; aligns AI events with clinical-trial AE conventions
FDA MedWatch category	21 CFR §803.3 outcomes	death, life-threatening, hospitalization, disability, …	US-market manufacturers and user facilities
EU MDR vigilance	Reg (EU) 2017/745 Articles 87–89	serious-incident, fsca, trend-report, periodic-summary, public-health-threat	EU/EEA manufacturers via EUDAMED vigilance module
IMDRF terminology	IMDRF AE WG/N43:2020, six top-level categories	A device problem · B cause investigation · C–D health effects · E patient · F component	Cross-jurisdiction reporters and harmonized data exchange

A single incident can populate one, several, or all four — the profile encodes which combinations are conditionally required.

CTCAE-aligned severity grades

Grade	Label	When it applies
1	asymptomatic	AI output never reached the clinician, or a downstream control caught it. No intervention.
2	moderate	Minimal, local, or noninvasive intervention. Limiting age-appropriate ADL.
3	severe	Hospitalization or prolongation; disabling; limiting self-care ADL.
4	life-threatening	Urgent intervention indicated.
5	death-related-to-event	Death related to the event.

The mapping to CTCAE keeps AI-event severity in the same vocabulary clinicians already use to triage drug and device events. An adverse-event coordinator does not need a separate scale for AI.

How the four taxonomies compose in one card

The examples/rad-ai-missed-mass-lung-ct.json shows a single incident — a lung-nodule triage tool missing a finding — that is:

• CTCAE grade 2 (moderate; no patient harm; caught within the safety window)
• FDA MedWatch category other-serious (per 21 CFR §803.3 — important medical event), mandatory 3500A
• EU MDR trend-report under Article 88 (single-event false-negative below serious-incident threshold; aggregated as a periodic trend)
• IMDRF coded under A05 (software problem), C03 (no clinical effect at time of report), E01 (patient action not contributory)

The same JSON document seeds all four downstream filings.

Audit-stream emission

Every conforming Incident Card emits one event per state transition to the publisher's audit-stream:

• incident_card.medical.created — at first publication of the Incident Card.
• incident_card.medical.transition — on subsequent state changes (regulator acknowledged, FSCA issued, closed).

Events are ed25519-signed under the publisher's signing key (convention: /.well-known/keys/incident-signer.json). The convention matches the rest of the Kinetic Gain Protocol Suite's audit-stream spine — same hash-chain shape, same key publication path.

Composes with

Repo	Role
ai-incident-card-spec	The base spec this profile extends
phi-vault-contract-profile	Sibling HealthTech profile — pairs the Decision Card vault contract with HIPAA's 18 identifiers
fhir-resource-access-audit	Sibling HealthTech repo — the audit-stream FHIR-aware ledger that incident_card.medical events can be correlated against
hipaa-readiness-evidence-bundle	Sibling HealthTech repo — assembles the broader evidence bundle that a manufacturer's QMS package cites
patient-consent-audit-stream	Consent layer — an Incident Card may cite a patient_consent event when affected_systems include AI consented under a specific consent contract
trial-protocol-deviation-monitor	When the incident occurred during a registered clinical investigation, the deviation monitor consumes the same Incident Card

Compliance posture

Healthcare-readiness scaffolding for AI/ML medical device adverse-event reporting. The profile and its examples support a vendor's program toward US FDA Medical Device Reporting (21 CFR §803), EU MDR vigilance (Reg 2017/745 Articles 87–89), IMDRF AE harmonization (AE WG/N43), ISO 14971 risk-management readiness, and ISO 13485 QMS evidence collection — does not by itself establish compliance with any of them. Per the standing public-language guardrail: readiness · evidence · posture · controls · scaffolding — never "compliant" or "cleared" without an external attestation.

License

MIT — see LICENSE. Spec/profile repos in the Suite are MIT-licensed so adopters can implement freely; reference implementations are AGPL-3.0.