← Industries/Healthtech
Promethean for Healthtech
Telehealth, clinical decision support, digital therapeutics, and mental-health SMBs running LLM-driven triage, note structuring, or risk scoring. HIPAA §164.312(b) audit controls + MDR Annex VIII rule 11 software classification + EU AI Act Art. 6(1) high-risk classification via the MDR pathway all want the same thing: a tamper-evident per-decision log of what the AI did, who reviewed it, and whether the system fell back to safe defaults.
Who this is for
Compliance + engineering teams in healthtech SMBs (telehealth · digital therapeutics · clinical-decision-support · medical-records). Typically:
- Seed–Series B healthtech with 5–60 engineers; 1–6 LLM-in-the-loop features in production.
- Subject to HIPAA (US ops) and/or MDR (EU device approval) — typically both for transatlantic operators.
- Clinical-decision-support software classified Class IIa or higher under MDR Annex VIII rule 11.
- Patient-facing AI volume: 10k–1M decisions per month per active product.
- Existing observability + EHR integrations; needs the audit-trail layer on top, not a replacement.
The regulatory pressure
EU AI Act Art. 6(1) — high-risk via MDR pathway
An AI system is high-risk under Art. 6(1) when it is a safety component of (or itself is) a product covered by Annex I Union harmonisation legislation requiring third-party conformity assessment. MDR (Reg. 2017/745) is on Annex I — so Class IIa+ medical-device software incorporating AI is high-risk under the AI Act regardless of Annex III.
Deep-dive →MDR Annex VIII rule 11 — software classification
Software intended to provide information used to take decisions for diagnostic or therapeutic purposes is Class IIa or higher. Class IIa+ triggers clinical evaluation, technical documentation, post-market surveillance — and bridges into AI Act Art. 6(1) for AI-incorporating devices.
Deep-dive →EU AI Act Annex III §5(d) — emergency-triage AI (where applicable)
Distinct path for symptom-triage / emergency-dispatch products: AI 'used to dispatch, or to establish priority in the dispatching of, emergency first response services, including emergency healthcare patient triage systems' is independently high-risk under Annex III §5(d).
HIPAA §164.312(b) — audit controls
Covered entities must implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems containing ePHI. AI decisions touching ePHI fall under this.
Deep-dive →MDR Art. 83 — post-market surveillance
Manufacturers must plan, establish, document, implement, maintain and update a post-market surveillance system proportionate to the risk class. L12 chain provides the per-decision surveillance data.
Where LLMs typically run in Healthtech
Symptom triage / clinical decision support
Closed-enum classifier suggesting urgency level + recommended next step from patient-reported symptoms. Always-human reviewer gate (clinician sign-off mandatory) for any high-acuity output.
Clinical note structuring
Extractor that takes a clinician's free-text note + structures it into the EHR's schema (ICD-10 codes, medication entities, problem-list items). Reviewer gate on schema violations + low-confidence extractions.
Prior-authorisation drafting
Drafter producing the narrative justification for prior-auth requests. Reviewer gate always-human (revenue-cycle specialist signs each submission).
Mental-health risk screening
Classifier flagging crisis-risk indicators in chat or intake forms. Always-human reviewer gate (clinician escalation); deterministic fallback to the highest-risk default when the model can't decide.
How the substrate maps to your audit
| Your LLM feature | What the regulator asks | Promethean evidence |
|---|---|---|
| Symptom triage | What did the AI recommend; who approved; was there a fallback? | specHash + reviewerVerdict + fallbackTriggered per L12 entry. |
| Note structuring | Did the LLM hallucinate codes? Schema-valid output? | outputCanonicalHash + schemaValid; spec's closed-enum schema bounds the output. |
| Prior-auth drafting | Reviewer engagement per submission. | Always-human gate forces reviewerVerdict per entry; identifier captured. |
| PHI protection in the chain | Is PHI ever stored raw? HIPAA Min-necessary rule. | inputHash + outputCanonicalHash are SHA-256; raw PHI never enters the chain by design. |
| MDR post-market surveillance | Continuous per-decision evidence retained for the device lifetime. | Operator keeps the L12 chain; substrate doesn't auto-delete. |
Which Promethean tier fits
Recommended for typical SMBs in Healthtech
Enterprise€2,499 / month flat
Unlimited · 15-min Bitcoin-anchored OTS · framework handoff templates (all 7) · SSO · HSM custody + on-prem (roadmap).
Healthtech SMBs need Enterprise for the framework-handoff templates (MDR Annex VIII rule 11 evidence; HIPAA §164.312(b) audit-control mapping; AI Act Annex III handoff). 15-min Bitcoin-anchored OTS matters because clinical incidents need short attestation latency on the chain head. HSM custody + on-prem deployment are commonly required by hospital IT contracts — both currently on the Enterprise-tier roadmap. Scale (€1,199/mo) is the fallback for early-stage healthtech without active hospital contracts yet — higher allowance + SSO + 7y retention.
Larger Healthtech operators with multi-tenant or framework-template needs upgrade to Scale (€1,199 / month flat).
What this looks like in practice
Hypothetical: a US-EU telehealth SMB during MDR conformity assessment
A telehealth platform with a Class IIa clinical-decision-support feature is in conformity-assessment review with a notified body. The body requests: 'evidence of post-market surveillance (Art. 83), evidence of human oversight (AI Act Art. 14), evidence the system fell back safely under adverse conditions (Art. 15).' Without Promethean: 18 months of clinician sign-off PDFs + Excel exports + a narrative document. With Promethean: a single Markdown handoff packet generated from the workspace, referencing the L12 chain export and the reviewer-verdict + fallback counts directly. The notified body runs verify.mjs against the chain. The conversation moves from 'do you have evidence' to 'does this evidence support your conformity claim'.
Frequently asked
Is PHI ever stored on Promethean infrastructure?
No. The substrate's PII-safe-by-construction design means raw inputs and outputs never enter the L12 chain — only SHA-256 hashes (inputHash, outputCanonicalHash). Whether the upstream LLM provider (Anthropic, OpenAI, Azure) sees raw PHI is governed by your direct BAA with that provider; Promethean does not proxy LLM calls and does not store PHI.
Does Promethean satisfy HIPAA §164.312(b) audit controls?
It satisfies the audit-controls requirement for AI-decisioning events involving ePHI. The L12 chain provides hardware-and-software-enforced recording of activity (the substrate emits per-decision entries; the operator cannot disable emission), and per-entry Ed25519 attestation provides integrity. Your wider SIEM for non-AI ePHI access patterns (database queries, API calls) is operator-side; Promethean is the AI-decisioning slice.
How does Promethean map to MDR Annex VIII rule 11 classification?
Rule 11 classifies software intended to provide information for diagnostic or therapeutic decisions as Class IIa or higher. The substrate doesn't classify your software — that's the manufacturer's responsibility — but the L12 chain provides the post-market-surveillance evidence (MDR Art. 83) that Class IIa+ classification mandates, plus the technical-documentation contribution (Art. 10 + Annex II) for the AI-decisioning subsystem.
Can a clinician override the AI? Is that captured?
Yes. The substrate's reviewer-gate primitive captures the override explicitly. When a clinician reviews the AI's recommendation, the L12 entry records the verdict (approved / rejected / amended) and optionally the reviewer identifier. Override-rate aggregates are computable directly from the chain — a regulator asking 'how often does the clinician override?' gets a query result, not an estimate.
What about FDA — is Promethean approved by the FDA?
Promethean is not an FDA-cleared device and doesn't replace your own FDA clearance process if applicable. The substrate provides the audit-trail and post-market-surveillance evidence layer that FDA-cleared SaMD products (Software as a Medical Device) often need to demonstrate ongoing compliance after clearance. Your FDA pathway is your own; Promethean's job is to give you the evidence layer that simplifies the post-market and adverse-event reporting workflows.
Drill into a specific use case
Each Healthtech use case has its own page with the regulation-specific evidence mapping + hypothetical scenario:
Definitions used on this page
The substrate primitives referenced above (L12 receipt chain, spec hash, reviewer gate, fallback behaviour, OpenTimestamps anchor, tenant ID) all have canonical definitions in the glossary: