Registration Decision Record
The Registration Decision Record (RDR) is the document EUDAMate produces with every EUDAMED export. For each device it states how every registration value was derived, who approved or changed it, what was checked, and whether the audit trail behind it verifies. This page is the specification of that document, so a reviewer, an auditor or a notified body can read one without an EUDAMate account.
This page describes format version 1.0 and is kept for records that print that version. The current specification describes the version EUDAMate produces today.
What the record is
One record covers one project. It opens with a project part and continues with one part per device. It is generated from the project's audit trail, the append-only log EUDAMate writes while the data is prepared, together with the device data and the review log as they stand at generation. It describes the values as they stood at that moment. It can be generated again at any time and then shows the state at that time.
The record is delivered as Markdown, as HTML and as an A4 PDF, each rendered from the same generator. The Markdown delivered with an export is made at that moment. The HTML and the PDF are made when they are opened, so each is a new record with its own generation time.
The sample linked above is a synthetic twelve-device project made for this purpose. It shows exceptions, a bulk review, overrides, warnings and removed devices. No customer data is in it.
What the record claims, and what it does not
A decision record is only useful if its limits are stated as plainly as its content. These two lists are the contract. The record itself opens its ISO 13485 section with the sentence: "This record supports the manufacturer's QMS. It does not by itself demonstrate conformity with ISO 13485:2016 or any regulation."
The record states
The record never claims
Structure: the project part
The header names the project and the record. The sections follow in this order. A section marked "when recorded" is printed only when its condition holds. The other sections are always printed. Where one can be empty, it says so in a short sentence.
| Header field | Meaning |
|---|---|
| Project | The project name as the account named it, where one was given. |
| Project ID | The identifier of the project in EUDAMate. |
| Legislation | Each regime (MDR, IVDR, MDD, AIMDD or IVDD) with its device count, followed by "determined per device" where the regime was set per device. Where no device has a regime recorded, the project's regime or the words "not yet determined". |
| Devices | How many device sections the record holds. |
| Generated | When the record was made, in UTC. Every time in the record is UTC. |
| Generated by | The account that requested the record. |
| Record format version | The version of the specification the record follows. It is printed in the header and repeated in the last line. |
The rule errors that remained at export and the warnings recorded then, with who confirmed the export anyway where that is recorded and which section of which device holds the detail. A category with nothing in it is not listed. A sentence says so when no rule error and no warning remained or when no export is recorded.
EMDN codes whose confidence is below the review threshold, values a reviewer deliberately left empty, and values with no recorded reviewer approval, as they stood when the record was made.
One row per device: reference number, UDI-DI, name, legislation and the result at the last export. Each device section starts with the same three identifiers.
From when the audit trail records every saved change to a device field. Where there are earlier events, what the record can and cannot show for changes made before that time.
Each bulk approval: who confirmed it, when it started and ended, how many devices and fields were selected and how many were approved.
Devices taken out of the project after upload, with who removed them and the event number.
The result of verifying the project's hash chain at the moment the record was made. One of four verdicts, described below.
Whether the last export passed the EUDAMED XSD format check, per legislation, or that no export has been recorded yet.
The project-wide declaration about substances, where one was made, with who made it and when.
The language chosen for free-text fields, or the decision that it differs per device.
A fixed explanation of what the printed confidence means depending on how the code was found, and why a search match is not a probability.
The clauses the record can support, in "supports" wording only. Quoted in full below.
Structure: each device part
Each device opens with the same identifiers the device index used, so a reader can move between the two without ambiguity:
The uploaded file, its type, its row count and the upload time.
How many columns were mapped, by which method, and which mandatory fields had no source column at upload.
The EMDN code and whether a reviewer confirmed or changed it, with the reason for a change. Where the classifier proposed a code, that code with its confidence, the AI reasoning and the other codes it listed with their search match.
One row per field with Field, Value, Status, Source, Confidence and Reasoning. The source column, rule, reviewer action or AI rationale that produced each value. An empty value reads "(empty)". A confidence or reasoning that was not recorded reads "-" or "(none)". Printed when the device data is available.
The declarations about medicinal product substances and the substances recorded for them, with their type and their INN or name. The CMR substances with their category and the endocrine-disrupting substances, each with its name and CAS# or EC#. Whether each entry was complete enough for the export.
Each storage or handling condition and each critical warning recorded for the device, with its code and description and whether it was complete enough for the export.
Every override with the field, the value before and after where recorded, the reason or the words "none recorded" and who changed it where the trail names them.
Each saved change to the device since change capture started, grouped by field and oldest first within each field, each with its position in the audit trail. It also lists review log entries the audit trail did not record and those written before change capture started.
Each validation run and export check: errors, warnings, the rule and field each one names, and the XSD result.
The snapshots taken at upload, at export, after review and at final approval, with who took them and when.
Certificate entries and other repeating groups: what was added, removed, declared absent or copied from a sibling device.
Every recorded event for the device plus the project's uploads, column mapping and validation runs, each with its time, its type and a one-line summary.
The audit trail check
Every event EUDAMate records for a project stores a hash over its own content and the hash of the event before it. When a record is generated, the chain is walked from the first event to the last and the verdict is printed in the project part. There are exactly four verdicts.
The sentence printed with an intact verdictThe application's database refuses changes to audit events and deletes them only when the project's data is deleted under the retention policy. The stored hashes link each event to the one before it. The check found no event that was altered or reordered since it was written, as far as the stored hashes show.
The verdict is bounded by what stored hashes can show. The database refuses updates and deletions of audit events. The one exception is the deletion of a whole project's data under the retention policy. Before that deletion, a seal is written that records the first and last event hashes, the event count, the verification result and a digest over the whole chain, so that the chain's existence and state remain on record after the events themselves are gone.
Where a project runs on chain version 2, the hashed content also includes the event's sequence number, its device identifier and its creation time, and a head pointer lets the check detect a deleted newest event. The record does not state which chain version a project runs on; the verdict wording is the same for both.
Events a device timeline can list, by their printed name
Vocabulary
The record uses a closed set of words for the state of a value, where it came from, why a reviewer changed it and which snapshot was taken. These are the complete lists for version 1.0. A record never uses a word outside them, and a new word is a new version of this specification.
Status of a value
The three readiness words describe a value nobody has looked at yet. Once a reviewer has acted, the status says what they did. A row a reviewer approved never reads "Needs review".
Source of a value
Reason for a change
Milestones
How the record relates to ISO 13485:2016
This table is printed in every record, verbatim. The wording is deliberately limited to "supports". The record is evidence the manufacturer may use under its own procedures, never proof of conformity.
| ISO 13485:2016 clause | How this record supports it |
|---|---|
| 4.2.5 Control of records | Supports your control of records. This record can be kept under your procedure for control of records. Identification, storage, protection, retention time and disposal stay under that procedure. |
| 4.2.3 Medical device file | Supports your medical device file. It can be referenced there as the record of how the EUDAMED registration data for these devices were prepared and reviewed. |
| 7.5.8 Identification | Supports the documentation of how UDI-related identifiers (Basic UDI-DI, UDI-DI, EUDAMED DI) and their registration data were derived from your source data and reviewed. |
| 4.1.6 Validation of software used in the QMS | Supports your validation of EUDAMate as software used in your QMS processes. Validation proportionate to risk is your responsibility. The validation results recorded here can be used as evidence in that validation. |
Versioning
Every record prints its format version in the header and in its last line. This page describes version 1.0. A record states the format version of the generator that made it. Generating a record again makes a new record in the version current at that time, which the current specification describes.
The headings, the vocabulary, the ISO rows, the intact-verdict sentence and the version number on this page were checked against the generator in EUDAMate's test suite while version 1.0 was current.
Reading a record as an auditor
Every EUDAMate export includes one
The record is not an add-on. It is generated from the same audit trail as the export, for every project, in Markdown, HTML and PDF. Download the sample and show it to the person who will audit your technical documentation.