For EU medtech

The chain hashes the pseudonym, not the patient.

MDR Class IIa/IIb, MDCG 2019-11, GDPR Article 9 — the chain sees the pseudonym; your pipeline keeps the patient identity.

Start free See the boundary

Pseudonym-hashed·3,650-day retention·Notified-body export

Evidence pointers · per framework

{
  "audit_target": "EU medtech compliance",
  "scope": {
    "MDR Art. 10(8)":    "Organization.dataRetentionDays · 3,650-day cap",
    "MDR Class IIa/IIb": "HashChainEntry per AI decision · notified-body bundle",
    "MDCG 2019-11":      "Confidence Engine 3-pillar score + suggestedStatus",
    "GDPR Art. 9":       "Customer-side pseudonymization · Adjudon hashes pseudonym"
  }
}

Each pointer links to a backend artefact verified in §02. The GDPR Article 9 row is the one with two responsibilities — yours (pseudonymize) and ours (hash whatever arrives).

What the notified body actually verifies.

Four medtech-relevant references, four rows. Each row pairs the obligation as the notified body or Data Protection Authority reads it (not as a US-vendor paraphrases) with the Adjudon artefact that satisfies it. Concrete citations: MDR Article 10(8), MDR Class IIa/IIb, MDCG 2019-11, GDPR Article 9.

Framework	Obligation	Adjudon artefact	Plan tier
MDR Art. 10(8) Manufacturer retention	Manufacturer must retain technical documentation, EU declaration of conformity, and certificates for at least 10 years after the last device is placed on the market — 15 years for implantable devices.	Organization.dataRetentionDays configurable up to 3,650 days (10 years exactly). For implantable-device 15-year retention, customer-side archival is required — the schema cap is 3,650 days.	Governance+ > 365 d retention: Enterprise+
MDR Class IIa/IIb SaMD conformity	Manufacturer of Class IIa/IIb medical-device software must provide audit-trail and post-market-surveillance evidence per MDR Annex IX (clinical evaluation, vigilance, periodic safety update).	HashChainEntry per AI decision, exportable as bundle for notified-body review. matchedPolicy.name + audit-log entry on every blocked decision; per-decision confidenceScore + tags persisted on DecisionTrace.	Governance+
MDCG 2019-11 Software qualification	Software qualified as a medical device under MDR/IVDR must demonstrate functionality and risk-management per the "Qualification and Classification of Software in Regulation (EU) 2017/745" guidance.	3-pillar Confidence Engine score + suggestedStatus + flags persisted per trace. Per-decision evidence supports the manufacturer's claims about software behaviour and triggers a Review Queue entry on flagged decisions.	Sandbox+ Full Review Queue: Scale+
GDPR Art. 9 Special-category data	Processing of data concerning health is prohibited unless an Article 9(2) exception applies (explicit consent, employment, public interest, etc.). Pseudonymization is strongly recommended to reduce processing-risk.	PII scrubber strips email, IBAN, credit-card from inputContext at ingestion. Customer-side pseudonymization before the trace-call is the architecture for Article 9 — Adjudon does not ship health-specific scrubbing patterns out of the box; the chain hashes whatever the customer sent.	Sandbox+ Pseudonymization: customer-side

The MDR/MDCG mapping detail and the GDPR Article 9 pseudonymization architecture live in docs.adjudon.com/compliance/medtech.

Where the patient data stops. Where the chain begins.

GDPR Article 9 prohibits processing health data unless the customer has a 9(2) basis. The architectural answer is a clean responsibility-split at the HTTPS boundary: your clinical pipeline pseudonymizes patient data before the trace-call; Adjudon hashes whatever arrives. We do not magically de-identify on ingestion — we hash, chain, and replay what you sent.

Customer side · Your responsibility

Patient-management system holds raw data — names, IDs, biometrics, ICD codes.

Pseudonymization layer strips identifying patient fields, replacing them with stable pseudonyms.

Clinical AI agent reasons over the pseudonymous record — never the raw patient identity.

Agent calls POST /api/v1/traces with inputContext already de-identified by step 02.

Adjudon side · Our responsibility

HTTPS-receive the trace at the Frankfurt eu-central-1 edge.

PII scrubber strips generic patterns (email, IBAN, credit-card) — does not strip health-specific identifiers.

Confidence Engine + Policy Engine evaluate; suggested status is computed; policy gate fires HTTP 201 / 202 / 403.

HashChainEntry appended with chainHash over payloadDigest of the trace fields.

The patient stays pseudonymous. The chain stays auditable.

You've seen four medtech-relevant references and the pseudonymization boundary spelled out step by step. Next: wire one trace from a sandbox clinical pipeline, watch the chain build, and hand the bundle to your notified body when the audit is scheduled. The first call lands at the engineer who wrote the architectural-split — not at an SDR.

Talk to engineering Read medtech docs

Primary sources

The text the regulator actually wrote.

MDR 2017/745Annex VIII Rule 11

Software intended to provide information which is used to take decisions with diagnosis or therapeutic purposes is classified as class IIa, except if such decisions have an impact that may cause serious deterioration of a person's state of health, in which case it is in class III.

GDPRArt. 9(1)

Processing of personal data revealing data concerning health shall be prohibited save where one of the specific lawful bases under Article 9(2) applies.

EU AI ActAnnex III §5(a)

AI systems intended to be used for the evaluation of access to essential private services and essential public services, including healthcare services, are classified as high-risk.