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.
What the record is
One record covers one project. It opens with a statement on the first page and one decision card per device, followed by the evidence appendix, which holds a project part and one part per device with every detail. 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, removed devices, file hashes and an approval. No customer data is in it. Its hashes are not in EUDAMate's audit trails, so the verify page answers "No match" for them.
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: three parts
A record has three parts. The statement, one decision card per device and the evidence appendix. In the PDF each part starts on a new page. The statement and the cards summarise. The appendix holds every detail and is what the summaries point to.
The statement
The header names the project and the record. Three sections follow, always in this order.
| 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 this specification the record follows. Currently 2.0. It is printed in the header and repeated in the last line. |
How many devices the record covers, when the last export ran and how many devices passed, did not pass or have no export result. Then one line per category of exception, counted from the evidence appendix, which lists each one. A sentence says so when there is none.
Whether the audit trail verifies, and when it does, the hash of its newest event, a link to check it at www.eudamate.eu/verify and what a match there does and does not show. The file name, upload time and SHA-256 of each uploaded file, and the SHA-256 of the CSV the last export produced. Each value that was not recorded, such as a hash from before version 2.0, is named as not recorded.
The name and role the exporting account gave for the person who approved the last export, whether the account confirmed them on the export screen of that export, and the time of the export. The record says that EUDAMate does not verify the name or the role. The audit trail holds only a salted fingerprint of the name and role, which the record prints with its salt. Where none was recorded or the name was deleted on request, a sentence says so and why.
The decision cards
One card per device, in the order of the device list. The card is titled with the device's reference number, UDI-DI and name. Its lines are these, each naming the appendix section that holds the detail.
| Line | What it says |
|---|---|
| EMDN code | The code with its term, the source of the code and who approved it, or that a reviewer chose it and why. |
| Risk class | The value and its status. |
| Legislation | The regime and how it was settled. |
| Inferred values | Values the pipeline inferred rather than took from the file, and how many a reviewer approved. Printed when there are any. |
| Source not kept | Approved values that no longer record where they came from, because they were approved before the source was kept with an approval. Printed when there are any. |
| Changed by a reviewer | The values a reviewer changed, with the reason and who changed them where recorded. Printed when there are any. |
| Values decided together | One counted line for values approved in a bulk review or with "Approve all green", copied from a sibling device or filled for many devices at once. Printed when there are any. |
| Items still open | Values with no recorded approval, values left empty and an EMDN code below the review threshold, or "None recorded". |
| Result at export | The result of the last export for the device, as section 5 records it. |
| Previous record | The earlier record of the same UDI-DI in the account, where one is linked, with its last export or the date its data was deleted under the retention policy. Where it could not be read or was not checked, the line says so. |
Structure: the evidence appendix
The appendix is the complete record. Its project part has these sections 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.
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.
The hash of the newest audit event and the number of recorded events when the record was made. Printed only when the audit trail check returns Intact. A sentence says so otherwise.
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 of the appendix
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 2.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. The current version is 2.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. The specifications of version 1.0 and version 1.1 are kept for records that print them.
The headings, the vocabulary, the ISO rows, the intact-verdict sentence and the version number on this page are checked against the generator in EUDAMate's test suite.
Checking the approval fingerprint
The audit trail never holds the approver's name. The event of each export holds the SHA-256 of a JSON array of four strings, rdr-approval/1, the salt, the name and the role. The salt is the 64 hexadecimal characters the record prints. The name and role are the text between the backticks, in Unicode NFC with single spaces. They never hold a backtick or a control character.
The array is written without spaces. Inside the strings only a double quote and a backslash are escaped, each with a backslash. Every other character is written as itself and the whole array is encoded as UTF-8 before hashing. JavaScript's JSON.stringify writes exactly this. In Python it is json.dumps(array, ensure_ascii=False, separators=(",", ":")).
For the sample record the array is ["rdr-approval/1","3701e7f83f80eaeeec799f24f61fd6250d9c1eb6566ccceb645e0ac60b6eaa71","Dr. Jana Becker","Head of Regulatory Affairs"] and its SHA-256 is 84d8d94cce065e20dfd6dbe93d39082bac3562f0c04a22481aa55ec0be843030.
Recomputing it from the record shows that the printed name, role and salt belong together. That the same fingerprint stands in the export event under the audit chain head the record prints can be checked with the audit trail file, which EUDAMate sends on the customer's written request.
When a person asks for their name to be deleted, EUDAMate deletes the name, the role and the salt. The fingerprint stays and every hash of the audit trail still checks. Without the salt it identifies no one. A record made after that says the name was deleted on request.
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.