Industries/Healthtech/Clinical decision support (CDS)
Clinical decision support (CDS)
AI-driven clinical decision support is dual-regulated: MDR Annex VIII rule 11 classifies most CDS software as Class IIa or higher, which routes it into AI Act Art. 6(1) high-risk via Annex I. Notified bodies are demanding per-decision evidence for post-market surveillance + technical documentation. Promethean ships the audit-trail substrate that satisfies both regulatory regimes.
What this is
Clinical decision support (CDS) is AI software intended to provide information used to take decisions for diagnostic or therapeutic purposes. Typical features in healthtech SMBs: symptom triage scoring, differential-diagnosis suggestion, alert prioritisation in EHR workflows, lab-value flagging, mental-health risk scoring.
Under MDR (Reg. 2017/745) Annex VIII rule 11, CDS software is Class IIa or higher — clinical evaluation, technical documentation (Annex II), post-market surveillance (Art. 83), and CE marking via notified-body conformity assessment all apply. Class IIb attaches when decisions could cause serious deterioration; Class III when life-threatening.
MDR-classified CDS routes into AI Act Art. 6(1) automatically: AI Act Annex I lists MDR; Class IIa+ devices require third-party conformity assessment; the combined effect is that AI-incorporating CDS software is high-risk under the AI Act regardless of Annex III. Art. 9 (risk management), Art. 10 (data governance), Art. 12 (record-keeping), Art. 14 (human oversight), Art. 15 (accuracy + robustness) apply.
Promethean is not an FDA-cleared device or a CE-marked component itself. It's the per-decision evidence substrate that sits alongside your CDS software, recording each clinical recommendation as an L12 entry: spec hash (which rubric / algorithm version was active), input hash, output canonical hash, reviewer verdict (where clinician sign-off applies), model identity, fallback flag.
Regulatory pressure specific to Clinical decision support (CDS)
MDR Annex VIII rule 11 — software classification
Software intended to provide information used to take decisions for diagnostic or therapeutic purposes is Class IIa unless decisions could cause serious deterioration (IIb) or life-threatening outcomes (III).
Official source ↗EU AI Act Art. 6(1) — high-risk via product legislation
An AI system is high-risk under Art. 6(1) when it is (or is a safety component of) a product covered by Annex I harmonisation legislation requiring third-party conformity assessment. MDR is on Annex I.
Official source ↗MDR Art. 83 — post-market surveillance
Manufacturers must plan + document + implement a post-market surveillance system proportionate to risk class. CDS at Class IIa+ requires a Periodic Safety Update Report (PSUR) for Class IIa every two years, annually for IIb/III.
Official source ↗FDA SaMD guidance (US) — Software as a Medical Device
For US deployments, FDA's SaMD framework + the 2024 Final Guidance on Predetermined Change Control Plans (PCCPs) apply. PCCPs allow planned model updates within a pre-approved envelope — auditable change history is the underlying evidence.
Official source ↗How Promethean addresses this
MDR Art. 10 + Annex II technical documentation
Per-decision L12 entries are evidence-generating artifacts that feed the Annex II technical documentation — specifically the design + manufacturing information section + post-market surveillance plan. The substrate's spec definition serves as a structured component of the system description.
MDR Art. 83 post-market surveillance
L12 chain is the operator's tamper-evident audit trail. Fallback rate, schema-validity rate, reviewer-override rate (where clinician sign-off exists) are surveillance metrics computable directly from the chain. Trend changes are early-warning signals.
AI Act Art. 12 record-keeping
Article 12 demands logging proportionate to the system's risk + intended purpose. The L12 chain is the technical mechanism: per-decision Ed25519-signed entries with model identity + spec hash + input/output hashes. Retention is operator-controlled; substrate doesn't force a window.
AI Act Art. 14 human oversight (clinician sign-off)
Reviewer-gate primitive captures the override or approval per decision. The chain's reviewer-verdict distribution is the empirical evidence that 'a clinician is in the loop' is meaningful — high override rate = real intervention; near-zero = rubber-stamping (regulator-worrying signal).
FDA PCCP — model-update audit trail
When the model is updated within the PCCP envelope, the new spec gets a new specHash. The chain shows the transition timestamp, the version pair, and the post-update fallback / accuracy metrics. PCCP audits demand exactly this kind of versioned evidence.
What this looks like in practice
Hypothetical: notified-body conformity assessment for a Class IIa triage CDS
A telehealth SMB submits its Class IIa symptom-triage CDS for notified-body conformity assessment. The notified body asks: 'demonstrate post-market surveillance evidence (Art. 83), evidence of human oversight (AI Act Art. 14), evidence the system falls back safely under adverse conditions (Art. 15).' Without Promethean: 18 months of clinician sign-off PDFs + Excel exports + a narrative document — and gaps where the notified body's auditor pushes back. With Promethean: a single handoff packet referencing the L12 chain export with concrete metrics — reviewer-verdict distribution shows 12% physician override (meaningful oversight); fallbackTriggered over 90 days = 3.2% (within risk-management plan); specHash sequence shows no silent model swaps. The notified body's auditor runs verify.mjs against the chain export. Conformity decision: positive.
Frequently asked
Is Promethean itself a medical device that needs CE marking?
No. Promethean is the audit-trail substrate underneath your CDS — it doesn't make medical decisions itself; it records the decisions your CDS makes. The substrate is regulated like any compliance / observability tooling, not as a medical device. Your CDS software is the device that needs CE marking; Promethean provides the evidence layer that supports the manufacturer's MDR + AI Act obligations.
We're at Class IIa, looking at Class IIb expansion. What changes?
Class IIb means decisions could cause serious deterioration of the patient's health. Risk-management requirements (Art. 10 + Annex I) get stricter; technical documentation expands; PSUR cadence becomes annual; notified-body scrutiny increases. The substrate's role doesn't change structurally — what changes is the depth + frequency of evidence the substrate's chain feeds into. Most healthtech SMBs growing into Class IIb find the existing substrate continues to fit; what gets harder is the operator-side risk-management documentation around it.
Does Promethean integrate with our EHR / clinical workflow tool?
Promethean integrates at the model-call layer (where your CDS invokes the AI) — typically a single-line code change in your service. The EHR side is unchanged. Your CDS's output flows back into the EHR via your existing integration; Promethean records the decision into the L12 chain as a side effect of the call. No new EHR adapter needed.
PHI never enters the chain — but what about the upstream LLM provider?
Promethean stores SHA-256 hashes of inputs / outputs, not the raw content. Whether your upstream LLM provider (Anthropic, OpenAI, Azure OpenAI Service, Google Med-PaLM, etc.) sees raw PHI is governed by your BAA + the provider's data-residency + retention terms. Most healthtech SMBs use a HIPAA-compliant LLM endpoint (Azure OpenAI BAA, AWS Bedrock + BAA, or a self-hosted model). Promethean's PII-safe-by-construction design is orthogonal to that decision; it complements the BAA layer.