Technical documentation and design controls

The situation

A notified body has quoted and wants the technical documentation. A distributor has asked for CE marking and the file consists of test reports in a shared drive. A device is moving from the US to the EU, or the reverse, and someone has to say what the existing file does and does not do for the new market. A design change has to be documented and nobody is sure what "design change" means in the file. Each of these is a technical-documentation problem, and each starts with the same question: what do we have, where does it belong, and what is missing?

What goes wrong when this is handled late

Files assembled under notified-body deadline pressure share the same faults. The GSPR checklist is filled in rather than built, with every requirement marked "complies" and a document reference that, when opened, does not say what the checklist claims. Evidence contradicts itself across documents because nobody cross-read them. The intended purpose in the IFU, the clinical evaluation and the risk file are three different sentences. Labelling was translated before the symbols were checked against ISO 15223-1. The UDI structure was decided by the printer.

A reviewer finds the first of these within an hour, and the review becomes a search for the rest.

What Authentcare does

Assess. Inventory what exists. Map it to Annex II and III, the GSPRs and the relevant harmonised standards or common specifications. Cross-read the documents for contradictions in intended purpose, claims, classification and risk. Grade every gap by severity and name which pillar closes it.

Develop. Build the file structure and write what Authentcare writes directly: the device description and specification, the GSPR checklist with real traces, the design-control records and the design history, the UDI logic and EUDAMED data, the labelling and IFU review, the verification and validation summaries, the traceability matrices. Plan the packaging and reprocessing validations with the partners who execute them.

Coordinate. Bring the evidence from the other pillars and from laboratories and clinical collaborators into the file in the right place. Prepare the file for the notified body's structured review, rehearse the questions, and support the responses to deficiency letters.

Medical device file, design file and the QMSR

Under ISO 13485:2016 the medical device file (clause 4.2.3) holds or references the device's specifications, manufacturing, packaging, storage, handling, measurement and monitoring procedures, installation and servicing documents, and the records that demonstrate conformity; the design and development file (7.3.10) holds the design records; production records (7.5.1) show what was made. Since 2 February 2026 the FDA QMSR incorporates these clauses and no longer retains the DHF, DMR and DHR record-type requirements by name. The obligations behind them remain and are met across those ISO clauses and the QMSR's own record provisions. The mapping is of obligations, not of titles, and FDA has cautioned against treating the medical device file as the device master record renamed. Authentcare builds the records to the clauses and shows the mapping for teams migrating from the older vocabulary.

What you receive

• Technical documentation gap report against MDR or IVDR Annex II and III and the GSPRs, graded by severity with a closure plan
• GSPR checklist with the applicable requirement, the standard or method applied, the evidence document and section, and the status
• Technical documentation structure and content to Annex II and III, built or remediated
• Medical device file and design and development file to ISO 13485 clauses 4.2.3 and 7.3.10 and the FDA QMSR record provisions
• Design-control records — inputs, outputs, review, verification, validation, transfer, changes — and the design history they form
• UDI assignment logic, Basic UDI-DI and UDI-DI structure, and EUDAMED device data prepared for the manufacturer's own submission
• Labelling and IFU review to ISO 20417:2021 and ISO 15223-1:2021 and market-specific labelling rules
• Traceability matrices across requirements, risk, verification, clinical and post-market evidence
• Packaging and shelf-life validation plan and reprocessing documentation requirements (coordinated)

Frameworks and editions

Applicability is device-specific. Which of these apply, and in what combination, depends on device type, intended purpose, classification and target market; the applicability assessment at the start of every engagement settles it in writing.

What this engagement excludes

• Generating the underlying evidence — tests, clinical data, validations — which other pillars and partners produce
• Submitting in EUDAMED, FURLS or SUGAM with the manufacturer's credentials, unless authorised in writing
• Notified-body fees and the notified body's own review
• Translation of labelling and IFU into national languages