MED.01
MDR Technical Files
MDR Annex II and III technical documentation drafted and cross-checked: GSPR evidence mapped, IFU, risk and clinical files compared. Conflicts are raised; the RA team signs.
Open pageIndustry
Medical device AI,
a person signs.
Drafted by a model, signed by a person. Technical files, post-market surveillance and risk and usability records under MDR 2017/745, ISO 14971 and IEC 62366-1. The model drafts and cross-checks; a qualified person reviews and signs every regulatory document.
Last reviewed 30 October 2026 · Engineering guidance, not legal or regulatory advice.
In context
AI for medical device companies means using models to draft and cross-check regulatory documentation, such as MDR technical files, post-market surveillance reports and risk and usability files, from the records already in the quality system. It is a documentation tool, not a medical device, and a qualified person signs every document.
Where it breaks today
01
The technical file never stands still
Under MDR 2017/745 the technical documentation is a living set: design changes, new clinical data, updated standards and PMS findings all ripple through the GSPR checklist, the risk file and the labelling. Keeping every cross-reference consistent is most of the regulatory team’s year.
02
Complaints arrive as prose
Complaints, service reports and literature arrive as free text in many languages. Trending them for PMS and spotting what might be a reportable serious incident depends on people reading every one, under a vigilance clock.
03
Risk and usability drift apart
The ISO 14971 risk file and the IEC 62366-1 usability engineering file describe the same hazards in different documents. When one is updated and the other is not, a notified body finds it before you do.
OUR APPROACH
AI in medical devices, on the documentation side
Most writing about AI in medical devices is about AI inside the device: imaging algorithms, cardiac monitoring, the FDA list of AI-enabled devices. That is regulated product development with its own pathway. We work on the other side: the documentation and quality work that every device manufacturer carries, AI-enabled or not.
The rule we design to is simple. The model drafts, extracts, cross-references and flags; it never approves. The technical documentation, PMS reports, PSURs, risk management file and usability engineering file are signed by the qualified people your quality system names, and the person responsible for regulatory compliance under MDR Article 15 stays responsible. Every draft carries citations to the controlled records it came from, so a reviewer checks evidence rather than prose.
A tool used inside your quality system is itself in scope: ISO 13485 clause 4.1.6 requires software used in the QMS to be validated for its intended use. We supply the validation evidence, including intended use, test sets and results; approving the validation is your QMS’s call. If any system we build moved toward clinical decision support, it could become a device in its own right, and that determination is for your regulatory function.
HOW IT DEPLOYS
PHASE 01
Map the controlled records
We trace where design history, risk, usability, complaints and clinical data live: eQMS, PLM, spreadsheets, document control.
PHASE 02
Validate for intended use
Intended use is written first, then tested on documents your team has already approved, and the evidence is packaged for your QMS.
PHASE 03
Draft, cite, sign
Drafts and cross-checks arrive with citations; a qualified person reviews, edits and signs inside your document control.
What we build
01
MDR technical documentation
Annex II and III documentation drafted and cross-checked: GSPR evidence mapping, consistency between labelling, risk file and design records, and completeness checks before submission.
SEE MDR TECHNICAL FILES →02
Post-market surveillance
Complaint intake, coding and trending, literature screening and draft PMS reports and PSURs, with possible serious incidents routed to a person immediately.
SEE POST-MARKET SURVEILLANCE →03
Risk and usability files
ISO 14971 and IEC 62366-1 records kept in step: hazards, use errors, risk controls and verification traced across both files.
SEE USABILITY & RISK →04
Inside your perimeter
Design history and complaint data contain patient information and trade secrets, so models run on infrastructure you control, with access scoped by role and every read logged.
SEE SECURE PIPELINES →Controls we implement
CITATION ON EVERY DRAFTED STATEMENT
SIGNATURE BY A QUALIFIED PERSON
VALIDATION EVIDENCE FOR YOUR QMS
NO TRAINING ON YOUR DATA
VERSIONED, AUDIT-LOGGED DRAFTS
PATIENT DATA INSIDE YOUR PERIMETER
These are engineering controls we build into the architecture, not certifications. QQuantum.ai holds no ISO 13485 or other certification, and conformity assessment, notified body review and QMS validation remain yours — see our trust centre.
Medical device use cases
-
-
MED.02
Post-Market Surveillance
Complaint coding, trending and draft PMS reports and PSURs under MDR, with an incident screen that runs first and sends any possible serious incident to a person at once.
Open page -
MED.03
Usability & Risk Documentation
The IEC 62366-1 usability engineering file and ISO 14971 risk file kept traceable: proposed links, gaps and study synthesis. Risk estimation and acceptability stay with engineers.
Open page
Questions
Questions about Medical Devices.
How is AI used by medical device companies?
In two different ways. Some companies build AI into the device itself, such as imaging or monitoring software, which is regulated as part of the product. Many more use AI for the work around the product: drafting technical documentation, trending complaints, screening literature and keeping risk and usability files consistent. We build the second kind, where a qualified person still signs every regulatory document.
Can AI write an MDR technical file?
It can draft much of it from records you already hold, and check it for consistency and completeness against Annexes II and III. It cannot take responsibility for it. The technical documentation is the manufacturer’s, reviewed by its regulatory team and assessed by a notified body. We build drafting with a citation on every statement, so reviewers verify evidence instead of rewriting prose.
Does an AI documentation tool need validating under ISO 13485?
Usually yes. ISO 13485 clause 4.1.6 requires software used in the quality management system to be validated for its intended use, proportionate to risk. We write the intended use, test the tool on documents your team has already approved, and hand over the validation evidence. Approving that validation, and deciding the level of rigour, is for your quality function.
How does the EU AI Act interact with MDR?
AI that is itself a medical device, or a safety component of one, requiring notified body assessment under MDR is classed as high-risk under the AI Act, adding obligations on data, logging, transparency and human oversight. A documentation tool used by your regulatory team is generally not in that category. Whether a particular system is, is a determination for your regulatory function.
What does MDR mean in this context?
In the EU, MDR is the Medical Device Regulation, (EU) 2017/745, which sets the requirements for placing devices on the market. In the US the same letters mean Medical Device Reporting under 21 CFR 803, the FDA’s adverse event reporting rules. Post-market systems serving both markets have to keep the two straight, and ours label each requirement by regime.
