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 record in the export package is made at that export. The HTML and a PDF downloaded later 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. These sections follow in this order. A section marked "when recorded" is printed only when its condition holds.
| 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.2. 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, the SHA-256 of the CSV the last export produced and the name and SHA-256 of each XML file it produced. Where rows were imported instead of uploaded as a file, it says "Rows were received on <time> in an import marked as coming from <source>. Their SHA-256 is <hash>, taken over the rows as EUDAMate received them." For each XML file the record gives its legislation, its part, the number of devices it holds and its size in bytes, and with several senders the sender SRN. Up to five files are listed here. For more, one line gives the count and the evidence appendix lists each file under "XML files made at export". The record says that the XML files passed the EUDAMED XSD format check, which covers their format only and does not show that EUDAMED accepts the data. It says that the XML hashes apply to the files made at that export and cannot be rebuilt from the audit trail, because every file carries a new message identifier and creation time. Where devices with rule errors were exported anyway, it says that the XML files include them and that EUDAMED may reject them. Each value that was not recorded, such as a hash from before version 2.0, is named as not recorded.
Printed when the last export made XML files. For each XML file of that export it gives the result the account recorded with who recorded it and when. It also gives the date and the reference the account recorded as EUDAMED's. A line reads for example "jana.becker@example.com recorded on 2026-11-20 09:14:05 UTC that EUDAMED accepted the file `xml/mdr-part-1-of-1.xml` from the export on 2026-11-18 16:02:41 UTC, with the date 2026-11-19 and the reference `<ref>`. EUDAMate did not perform or observe the upload." A rejected file has the same line with "rejected the file". A file accepted except for some devices has "accepted the file `<path>` from the export on <time> except for N devices". Where the recorded result names devices, a line says "The result lists N devices EUDAMED named. The evidence appendix names them under "EUDAMED results recorded"." Where the account recorded the fingerprint of the reply EUDAMED gave, a line says "A EUDAMED response with the SHA-256 <hash> was recorded with this result." A result that replaces an earlier one says "This result replaces one recorded on <time>." A result that replaces several says "This result replaces the results recorded on <time> and <time>." A file with no result reads "No result is recorded for the file `<path>` of the export on <time>." Where several results are recorded for one file and none replaces another, the line reads "N results are recorded for the file `<path>` of the export on <time> and none replaces the others. The evidence appendix lists each." The record the export itself makes prints "No EUDAMED result is recorded yet for the files of this export. A record made after a result is recorded shows it."
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 section names the account that made the export with "The exporting account is <email>." It prints that line after a name was deleted on request too. Where the record does not know the account, it says "The email of the exporting account is not known to this record."
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. For a residual code the line says "This is a residual code. A more specific leaf may exist." before the section reference. |
| 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. |
| EUDAMED result | The result the account recorded for the XML file that holds the device. It reads "The account recorded that EUDAMED accepted the file `<path>`, reference `<ref>`. EUDAMate did not perform or observe the upload. Statement, EUDAMED results." For other results "accepted the file `<path>`" becomes "rejected the file `<path>`", "accepted the file `<path>` except for this device", "accepted the file `<path>` except for this device and N other devices" or "accepted the file `<path>` except for N other devices". Where several results are recorded it reads "Several results are recorded. Statement, EUDAMED results." With no result it reads "No result recorded." Printed when the export recorded which devices each XML file holds. |
| 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.
Each XML file the last export produced, with its legislation, part, number of devices, size in bytes and SHA-256 (and the sender SRN when the export has several senders). Printed only when the export produced more than five files. The statement lists up to five.
Every result an account recorded, results a later one replaces included. The section opens with "Every result an account recorded, oldest first, including results a later one replaces. EUDAMate does not check a result with EUDAMED." Each result has its line as the statement prints it and "The SHA-256 of the file is <hash>." Under it stands one line per device the result names, "A device the account recorded as rejected is <device>." or for a rejected file "A device the account recorded as named by EUDAMED is <device>." The reply hash, the result it replaces or the result that replaces it and the event number follow. Where the account added a note, a line says "The account added a note in its own words, which EUDAMate does not check. It reads <note>." Printed when a result is recorded.
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.
The sentence "What the confidence printed with an EMDN code means depends on how the code was found, which the source beside it states." followed by a table that gives for each way a code can be found what the number printed with it is. The table says 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. For imported rows it names the source followed by "(import, N rows), imported <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. Fields whose only recorded change is an approval in a bulk review are counted in one line per review at the end. That line reads "<time>. <account> approved N fields in bulk review <review>. Section 3.5 shows each value." One line under it names each field with its identifier, such as "Device Name (FLD-UDID-22)". The event number follows.
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. Groups with no entry in any state shown are counted in one line, "Not given. N groups have no entry in <the states shown> and none is in the export. They are <names>."
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.
Anchoring the chain head
A record's producer should anchor the chain head when the record is made, with any RFC 3161 timestamp authority or a public anchor such as EUDAMate's. An anchor shows that the head existed at that time. The format does not depend on any one anchor. EUDAMate's anchor is one option and never a requirement. The page How to check a record says how to check an anchor.
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.2. 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". "Not required" marks a field a rule says the device does not need. Its source and confidence in section 3.5 read "-".
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. |
Export package
Every export is delivered as one ZIP file. It holds the clean CSV, the record made at that export, a folder xml with the EUDAMED XML files, the file checksums.sha256 and a README.txt. The XML files are named <leg>-part-<n>-of-<m>.xml, or <leg>-<srn>-part-<n>-of-<m>.xml with the SRN in lowercase, for example xml/mdr-de-mf-000012345-part-1-of-1.xml, when the export holds devices of several manufacturers. If two SRNs would give the same name, a six character suffix is added to tell them apart. Each file holds the devices of one legislation and one manufacturer, at most 300 devices.
Every hash is a lowercase hexadecimal SHA-256 over the exact bytes delivered. The hash of the CSV includes its UTF-8 byte order mark. The hash of an XML file cannot be rebuilt from the audit trail, because every file carries a new message identifier and creation time. It applies to the file made at that export.
Anyone can check the files without EUDAMate. On macOS or Linux, run shasum -a 256 -c checksums.sha256 in the folder with the unpacked files. On Windows, run certutil -hashfile <file> SHA256 and compare the result with the line in the record or in checksums.sha256.
The page www.eudamate.eu/verify also answers the SHA-256 of the CSV, of each XML file, of the record and of the whole package an export made. A match shows that an export made the file. It does not show who holds it or that EUDAMED accepted it.
The page How to check a record lists these checks in order.
Versioning
Every record prints its format version in the header and in its last line. The current version is 2.2. 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, version 1.1, version 2.0 and version 2.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.
The same specification is available as a machine-readable specification in JSON. It carries the format version.
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.