Skip to main content

MDR Class IIa/IIb for clinical AI

The chain hashes the pseudonym, not the patient. That single sentence resolves the apparent collision between MDR Article 10(8) retention, MDCG 2019-11 software qualification, MDR Annex IX clinical evaluation, and GDPR Article 9 special-category-data prohibition. Adjudon does not process health data on its side of the HTTPS boundary; the manufacturer pseudonymises before the trace call, and Adjudon hashes whatever the trace contains. We document this honestly so procurement does not arrive expecting Adjudon-side health-pattern scrubbing that does not exist out of the box.

Scope​

This page applies to medical-device manufacturers placing software-as-medical-device on the EU market under the Medical Device Regulation (Regulation (EU) 2017/745) — including manufacturers of in vitro diagnostics under IVDR (Regulation (EU) 2017/746) where the device contains AI-driven decision logic.

Per MDCG 2019-11 Rule 11 of MDR Annex VIII, software intended to provide information used to take decisions with diagnostic or therapeutic purpose is classified at minimum as Class IIa, with most clinical-AI software landing at Class IIa or IIb depending on the harm profile. Class III is reserved for life-sustaining or implantable AI; Class I is reserved for low-risk, non-decision-driving software.

Out of scope: non-medical AI (handled at EU AI Act Compliance for Annex III deployers where applicable), and devices that do not qualify as MDSW under MDCG 2019-11 (administrative software, marketing tools, lab-management inventory).

Roles​

RolePartyMDR / GDPR basis
ManufacturerYour medical-device companyMDR Art. 10
Pseudonymisation operatorThe manufacturer's clinical pipelineGDPR Art. 9, Recital 26
ICT third-party service providerAdjudonDORA Art. 3(19) (where applicable)
Notified bodyTÜV SÜD, TÜV Rheinland, DEKRA, BSI Group, et al.MDR Annex IX
Audit-trail evidence supplierAdjudonMDR Annex IX clinical-evaluation file

The notified body conducts the conformity assessment under MDR Annex IX. Adjudon does not interact with the notified body directly — the manufacturer hands the export bundle and the published verify algorithm to the auditor on audit day.

Article-by-article mapping​

Article / ReferenceRequirementWhat Adjudon shipsWhat you do
MDR Art. 10(8)Manufacturer retention: 10 y non-implantable, 15 y implantableOrganization.dataRetentionDays cap 3,650 days (10 y exactly)Configure retention; for implantable devices, archive the bundle customer-side for years 11–15
MDR Class IIa/IIbConformity assessment per Annex IXDecisionTrace + HashChainEntry per AI decision; replay-verifiable bundleHand the bundle to TÜV / DEKRA / BSI on audit day
MDR Annex IXClinical evaluation, vigilance, PSURsPer-decision: confidenceScore, tags, matchedPolicy.name, policyResult.reason, chainHashRun the evaluation; file the PSUR cycle
MDR Art. 87Vigilance / serious-incident reportingMulti-Clock Hub via IncidentClockFile the vigilance report with the competent authority
MDCG 2019-11Software qualification under MDR/IVDR3-pillar Confidence Engine (base / variance / historical) — not the model's self-reportDocument the intended-use claim and the evidence chain
GDPR Art. 9Special-category-data prohibitionPII scrubber (email / IBAN / card / SSN / phone) — no health-specific patternsPseudonymise patient data customer-side before POST /api/v1/traces
GDPR Recital 26Pseudonymous data is personal data with reduced riskChain hashes the pseudonym, not the patientMaintain the linkage table on your side, never on ours

The audit trail Annex IX expects is a single replayable artefact, not a screenshot of a dashboard. The chain export bundle delivers that artefact; see Evidence below.

The pseudonymisation boundary​

The architectural answer to the procurement question "does Adjudon process health data?" is a clean responsibility-split at the HTTPS boundary. The manufacturer's clinical pipeline does steps C1–C4 on its side; Adjudon does steps A1–A4 on its side; the API call is the boundary between them.

Customer side — your responsibilityAdjudon side — our responsibility
C1 Patient-management system holds raw clinical data: names, dates of birth, biometrics, ICD codes, free-text records.A1 HTTPS receive: trace lands at the Frankfurt eu-central-1 edge, inside the EU residency perimeter.
C2 Pseudonymisation layer strips identifying fields and replaces them with stable pseudonyms before any AI call runs.A2 Default PII scrubber strips email / IBAN / credit card / SSN / phone — does not strip health-specific identifiers (that work happened at C2).
C3 Clinical AI agent reasons over the pseudonymous record, never the raw patient identity.A3 Confidence Engine (3 pillars) + Policy Engine evaluate; HTTP 201 / 202 / 403 returned per the matched policy.
C4 POST /api/v1/traces with inputContext already de-identified by C2.A4 HashChainEntry appended with chainHash over payloadDigest of the trace fields — pseudonyms in, patients absent.

Adjudon's side is mechanical: it hashes whatever it received. The manufacturer's side is the de-identification: pseudonymisation happens before the trace ever leaves the clinical pipeline.

Evidence​

The notified-body audit on the manufacturer's MDR Annex IX cycle uses the chain export as the single replayable artefact. The bundle covers every clinical AI decision the device made during the assessment window:

curl
curl https://api.adjudon.com/api/v1/hash-chain/export \
  -H "Authorization: Bearer $ADJUDON_API_KEY"
Python
import requests, os
r = requests.get(
    "https://api.adjudon.com/api/v1/hash-chain/export",
    headers={"Authorization": f"Bearer {os.environ['ADJUDON_API_KEY']}"}
)
bundle = r.json()

The auditor recomputes each row's chainHash against the published algorithm at Audit Log & Security:

chainHash = sha256(prevHash || payloadDigest || sequence || createdAt)

No Adjudon login, no Adjudon endpoint, no Adjudon network is required for the verification step. The chain is tamper-evident, not tamper-proof: any modification to a stored entry breaks the next entry's prevHash link. Tampering is loud.

Per-decision artefacts the manufacturer hands to the auditor on the clinical-evaluation file:

  • confidenceScore (0.0–1.0, three-pillar triangulated)
  • tags (engine-flags raised: LOW_CONFIDENCE, HIGH_AMBIGUITY)
  • status (success, flagged, escalated, blocked, approved)
  • matchedPolicy.name and policyResult.reason (for blocked decisions)
  • The full chainHash chain (proof the audit log itself has not been altered)

Retention: 10 years (with the implantable edge case)​

Device classRetention obligationAdjudon sideCustomer side
Class IIa / IIb non-implantable10 years (MDR Art. 10(8))Organization.dataRetentionDays: 3650Configure retention; nothing else
Class IIa / IIb implantable15 years (MDR Art. 10(8) extended)dataRetentionDays: 3650 (10 y cap)Periodic chain-export archival for years 11–15
Class III implantable AI15 yearsSame 3,650-day capSame customer-side archival

The schema cap is enforced at the Mongoose layer ("Retention cannot exceed 10 years."). For implantable devices the 5-year shortfall is closed customer-side via periodic export. The chain bundle is replay-verifiable on its own — no Adjudon connection is required at the year-15 audit — so customer-side archival is a complete handover. We document this honestly so procurement does not assume "MDR retention covered" without checking the device class.

Multi-Clock for MDR Art. 87 vigilance​

When a serious medical-device incident or a field safety corrective action is recognised, the Multi-Clock Incident Hub creates clocks for the regulatory timelines applicable to the incident type. MDR Art. 87 serious-incident reporting timelines (immediate, 10-day, periodic trend) sit alongside the GDPR Art. 33 (72 h), EU AI Act Art. 73 (2 d / 10 d / 15 d), DORA Art. 19, and NIS2 Art. 23 clocks where each applies. See Multi-Clock Incidents.

A breached checkpoint stays in the index with status: 'breached' so the post-incident audit can replay which deadline was missed and when.

Honest disclosures​

  • Adjudon does not ship health-specific PII patterns out of the box. ICD-code regex, patient-name recognition, and biometric-field classification are the manufacturer's responsibility in the C2 pseudonymisation layer. Custom regex patterns can be added on Governance and above plans; the default scrubber covers only generic patterns.
  • The 15-year implantable retention obligation exceeds our 10-year schema cap; the gap is closed customer-side via periodic export.
  • The OpenAI sub-processor (USA, GDPR Chapter V SCCs) is the one documented residency exception. See Data Residency & GDPR.
  • There is no Adjudon-shipped "MDR audit pack" feature. The manufacturer assembles the Annex IX evidence from the chain export, the per-decision artefacts, and the retention configuration.

What this page does NOT cover​

See also​