Three regimes, one boundary: MDR, MDCG 2019-11, and GDPR Article 9.

The notified body conducting the MDR audit will ask whether the device performs as the manufacturer claims. The MDCG-aligned reviewer will ask whether the software is qualified as a medical device under MDR/IVDR and, if so, what evidence supports classification and intended-use claims. The Data Protection Authority will ask whether the processing of health data is lawful under Article 9 and documented under the GDPR's accountability principle.

These three reviews do not run on the same calendar. They will not even be conducted by the same people. But they share a single artefact-source: the decision log of the AI system. If the log can answer each of their questions, the manufacturer has done its work once; if it can only answer one, the work happens three times in three formats.

A clinical AI stack worth running is built so that one log serves all three regulators. The shape that log has to take is the subject of the rest of this post.

Software that drives diagnostic decisions, triages cases, recommends treatments, or scores clinical risk is, in nearly every case, software-as-medical- device under MDR. The risk classification is rarely Class I (low risk, mostly self-certified) and rarely Class III (the highest, reserved for life-sustaining or implantable software). Most clinical AI sits at Class IIa or IIb — medium risk, requiring notified-body conformity assessment under Annex IX.

Annex IX is the regime that demands clinical evaluation, post-market surveillance, vigilance reporting, and periodic safety update reports. None of those are documents that one writes once. Each is a continuous evidence stream the manufacturer must keep current and produce on the notified body's request. The notified bodies operating in the DACH region for SaMD are well known — TÜV SÜD, TÜV Rheinland, DEKRA, and BSI Group's Munich office among them — and each will ask the same operational question on audit day: show us the evidence stream for the decisions the device made during the assessment window.

What the notified body wants is not a screenshot of a dashboard. They want a single, replayable artefact that contains every clinical decision the device made, with each decision's confidence score, the policy state at the time of decision, and the cryptographic anchor that proves the record has not been altered after the fact.

MDR Article 10(8) sets the retention obligation for technical documentation, EU declarations of conformity, and certificates: at least ten years after the last device covered is placed on the market. For implantable devices the obligation extends to fifteen years. This is the cleanest requirement of the three regimes, because retention is a configuration, not an architecture.

Adjudon's schema sets Organization.dataRetentionDays with a hard cap of 3,650 days — ten years exactly, enforced at the Mongoose layer with the validation message “Retention cannot exceed 10 years.” For Class IIa/IIb non-implantable devices, this satisfies Article 10(8) directly.

Implantable devices are the edge case. The schema cap is ten years; the regulation asks fifteen. The five-year shortfall is closed customer-side: run GET /api/v1/hash-chain/export periodically and preserve the bundle in the manufacturer's long-term archive. The chain bundle is replay-verifiable on its own — no Adjudon connection is required at the fifteen-year-out audit — so customer-side archival is a complete handover, not a degraded one. We document this honestly in the medtech doc rather than imply that “MDR retention” is universally covered without a class check.

MDCG 2019-11 is the Medical Device Coordination Group's guidance on the qualification and classification of software under MDR/IVDR. For a manufacturer placing a clinical AI system on the market, it is the document that sets the bar for what counts as evidence that the software functions as intended.

The phrase “functions as intended” sits awkwardly on top of probabilistic systems. A classification model that outputs a softmax score can self-report any number it likes. A large language model with a confidence prompt can produce a calibrated-looking number that has no relationship to its actual performance. MDCG-aligned evidence therefore cannot be the model's self-report alone. It has to be triangulated against signals the model is not the source of.

Adjudon's Confidence Engine is built on three pillars: a base probability derived from the decision context, a variance signal computed across a small ensemble of model calls or sampling passes, and a historical-precedent signal that compares the current decision to similar decisions in the organisation's past trace history. The engine's output is a single confidenceScore in the range 0.0–1.0, plus an array of tags raised by the pillars: LOW_CONFIDENCE when the final score falls below 0.6, HIGH_AMBIGUITY when the variance signal indicates the model disagrees with itself across passes.

The MDCG-aligned answer to “does your software function as intended?” is therefore not a single number. It is the score, the tags, the policy that fired against them, and the chain entry that binds the four together. Four pieces of evidence per decision; one log; one replay path.

GDPR Article 9 starts from the position that processing data concerning health is prohibited. That prohibition is then lifted by a closed list of exceptions in Article 9(2): explicit consent for specific purposes, processing necessary in the field of employment law, public-interest grounds in the area of public health, scientific-research grounds with appropriate safeguards, and a small number of others. The default is no; the exceptions are narrow.

The GDPR's recital 26 is also relevant: the Regulation does not apply to anonymous data, and pseudonymous data is treated as personal data with reduced risk. Pseudonymisation, in other words, does not exit the GDPR. It changes the risk profile of the processing and the kinds of safeguards the Data Protection Authority will accept.

For a clinical AI manufacturer, the practical consequence is that the AI call should never receive raw patient identifiers. Names, dates of birth, full-resolution biometrics, ICD codes that re-identify the individual in a small population, and free-text records that contain any of the above must be replaced with stable pseudonyms before the AI agent runs — let alone before any third-party processor sees the trace.

The architectural decision that resolves the three regimes simultaneously is the placement of pseudonymisation. It belongs on the customer side of the trace API, not the Adjudon side. The HTTPS request that crosses from the manufacturer's clinical pipeline to the Adjudon edge is the boundary at which special-category data has already been replaced with stable pseudonyms.

Adjudon's default PII scrubber removes generic patterns — email addresses, IBANs, credit-card numbers, US SSNs — from inputContext at ingestion. It does not ship health-specific patterns out of the box. Patient names are not scrubbed by default. ICD codes are not scrubbed. Biometric fields are not recognised. We document this explicitly in the medtech doc, because it is the question every notified body and every Data Protection Authority will ask in audit.

The honest answer to “does Adjudon process health data?” is therefore: only if you send health data, but the architecture expects you to pseudonymise first. The customer-side pipeline does the de-identification. Adjudon's side does the hashing. The boundary is the HTTPS call.

Once the trace arrives at the Adjudon edge with pseudonyms in place of identifiers, the rest is mechanical. The Confidence Engine evaluates. The Policy Engine evaluates. The decision is persisted as a DecisionTrace. The Decision Hash Chain appends a HashChainEntry whose payloadDigest is a SHA-256 of the canonical-JSON of the trace fields — pseudonyms included, patient identifiers absent.

A notified body who later asks for the decision log of an MDR audit window receives an export bundle whose hash chain replays against the published algorithm. The pseudonyms in the bundle are operationally meaningful to the manufacturer (they can be re-linked customer-side to clinical context when an investigation requires it) and operationally inert to the auditor (the auditor never needs to see the patient identity to verify the decision integrity).

A Data Protection Authority asking the same export bundle the same question gets the same answer. The chain stores the pseudonym. The chain hash proves the pseudonym was not altered after the decision was made. The architecture treats the patient and the pseudonym as fundamentally different artefacts — which is precisely what GDPR recital 26 and Article 9 expect a careful manufacturer to do.

Three regulators. One log. The boundary that makes that possible is six lines of pseudonymisation code on the manufacturer's side of the HTTPS call.