# MDRpilot: full product description Last updated: 2026-10-05 ## What it is MDRpilot is an AI-assisted regulatory workspace for medical device manufacturers. It helps teams structure the EU MDR 2017/745 technical file, map GSPR evidence, maintain ISO 14971 risk files, prepare clinical evaluation and PMS/PMCF documentation, and run ISO 13485 quality records in one place, so gaps are visible before an audit. Category: AI-assisted medical device regulatory software. Positioning: Make your MDR technical file audit-ready. An end-to-end MDR compliance and documentation workspace, not a stand-alone AI document generator. ## What it is not MDRpilot is documentation and workflow software. It is not a medical device, not a notified body and not a regulatory authority. It does not certify devices or guarantee compliance; AI-generated drafts must be reviewed and approved by qualified people in the manufacturer's organisation. ## Company - Legal name: NAVİCORE TEKNOLOJİ VE YAZILIM LİMİTED ŞİRKETİ - Address: Çamtepe Mah. Mahmut Tevfik Atay Blv. Gaziantep Teknopark No: 4 C İç Kapı No: 31 Şahinbey / Gaziantep - Website: https://mdrpilot.com - Sales: sales@mdrpilot.com - Support: support@mdrpilot.com - Privacy: privacy@mdrpilot.com ## Who it is for - Medical device manufacturers preparing or maintaining EU MDR technical documentation - Regulatory affairs and quality assurance teams - Small and medium-sized manufacturers without a large in-house regulatory department - Regulatory consultants who manage several client files - Persons responsible for regulatory compliance (PRRC) who need an overview of open gaps ## Regulations and standards - EU MDR 2017/745 (Regulation (EU) 2017/745 on medical devices) - ISO 13485:2016 quality management systems - ISO 14971:2019 risk management - MDCG guidance structures for clinical evaluation, PMCF and PSUR - Referenced standards tracked per product, e.g. ISO 10993, ISO 11607, ISO 11135, IEC 62304, IEC 62366-1 ## Out of scope - IVDR (Regulation (EU) 2017/746) in vitro diagnostic devices - Direct submission to EUDAMED (UDI device data can be exported for manual preparation) - Registration tracking for non-EU markets - Supplier-provided validated computer system packages ## Workflow Requirements -> Evidence -> Documents -> Risk -> Clinical -> PMS -> QMS -> Audit ## Modules ### MDR technical documentation Product-level technical file structured along MDR Annex II and Annex III, with section status (missing, draft, approved), AI-assisted drafts, manual editing and evidence attachments. More: https://mdrpilot.com/technical-file-software ### Annex VIII classification assistant Question-based helper that suggests a device class and the applicable Annex VIII rule with a written rationale. The manufacturer confirms the class. More: https://mdrpilot.com/mdr-technical-documentation ### GSPR checklist and evidence matrix Annex I General Safety and Performance Requirements with applicability, justification for non-applicable items, linked standards and linked evidence files. More: https://mdrpilot.com/gspr-compliance ### ISO 14971 risk management file Risk management plan, hazard analysis and FMEA-style risk items with risk controls and verification of control effectiveness. More: https://mdrpilot.com/iso-14971-software ### Clinical evaluation Clinical evaluation plan and report structure, literature search in PubMed and Europe PMC with PRISMA-style screening counts, equivalence data, a clinical gap matrix and a review and approval step. More: https://mdrpilot.com/clinical-evaluation-software ### Post-market surveillance PMS plan, PMCF plan and survey, and PSUR or PMS report outlines based on device class, connected to complaints and CAPA records. More: https://mdrpilot.com/pms-pmcf-software ### Design control traceability Design input, output, review, verification, validation and transfer records with a traceability matrix (ISO 13485 clause 7.3) that can reference risk and clinical items. More: https://mdrpilot.com/medical-device-qms ### Instructions for use IFU drafting from product data, structured around the information supplied with the device (MDR Annex I, Section 23). More: https://mdrpilot.com/technical-file-software ### ISO 13485 QMS documentation Quality manual wizard, procedures (SOPs), forms and instructions with document control, revision and approval workflow and a controlled document register. More: https://mdrpilot.com/iso-13485-software ### Quality records CAPA, complaints, internal audit, FSCA, vigilance, change control, management review, supplier evaluation, traceability, calibration and training matrix records. More: https://mdrpilot.com/capa-software ### Evidence files Upload of test reports and other evidence; automated analysis suggests links to GSPR rows, risk controls and clinical evidence, which a user confirms before they are applied. More: https://mdrpilot.com/gspr-compliance ### Change impact flags When product data such as class, sterilisation or intended purpose changes, documents that depend on it are flagged for review. More: https://mdrpilot.com/mdr-gap-analysis ### Audit readiness and audit simulator Readiness score with a list of missing actions across technical file, QMS and CAPA, plus an audit simulator (MDR, ISO 13485, ISO 14971 or combined scope) that records findings as major, minor, observation or positive. More: https://mdrpilot.com/audit-readiness ### Exports Technical file DOCX and full ZIP, GSPR and risk XLSX, IFU DOCX, label PDF, PMS/PMCF DOCX, QMS package ZIP and document register XLSX, plus UDI device data XML for manual EUDAMED preparation. More: https://mdrpilot.com/technical-file-software ### Document translator Translation of regulatory documents between the supported languages with medical terminology handling. More: https://mdrpilot.com/regulatory-affairs-software ## AI controls - AI drafting runs on the server; provider API keys never reach the browser. - When live AI is used, relevant excerpts are sent to configured AI providers (for example OpenAI or Anthropic) only to produce the requested output. - A company owner can turn off external AI processing for the whole workspace in Settings. - Without a live AI provider the platform runs on a deterministic built-in engine, so non-AI workflows keep working. - Controlled templates lock document headings; AI fills section bodies, and statements that cannot be confirmed from company data are marked [TO BE CONFIRMED] instead of being invented. ## Interface languages Türkçe, English, Deutsch, Français, Español, Italiano, Nederlands ## Pricing - Starter: free. Free. Document Studio access with starter credits; does not include the regulatory Suite. - Basic: EUR 250 per month. Suite access for 1 product and 1 seat, live AI and export center. - Plus: EUR 450 per month. Suite access for up to 3 products and 3 seats, live AI and export center. - Pro: EUR 750 per month. Suite access for up to 5 products and 5 seats, live AI and export center. - Enterprise: custom pricing. Custom limits and terms. Contact sales. Prices are listed in EUR per month. Annual billing charges 10 months for 12. A 3-day demo of the Suite can be requested at sign-up. Start a demo: https://mdrpilot.com/register?intent=demo ## Solution pages ### MDR software that keeps your technical file, evidence and quality records connected https://mdrpilot.com/mdr-software MDR software is software that helps medical device manufacturers meet the documentation and process obligations of the EU Medical Device Regulation (EU) 2017/745. It typically covers the technical documentation in Annex II and III, the General Safety and Performance Requirements in Annex I, risk management, clinical evaluation, post-market surveillance and the quality management system. MDRpilot is an AI-assisted regulatory workspace that keeps these pieces in one product record, so a change in one place shows up wherever it matters and open gaps are visible before an audit. Q: What is MDR software? A: Software that helps medical device manufacturers prepare and maintain the documentation and processes required by Regulation (EU) 2017/745, such as the technical file, GSPR checklist, risk file, clinical evaluation and PMS documents. Q: Does MDRpilot replace a notified body? A: No. MDRpilot is documentation and workflow software. Conformity assessment, certificates and final decisions stay with your notified body and your own qualified people. MDRpilot helps you arrive with a complete, traceable file. Q: Can MDRpilot generate a technical file? A: It can draft the sections of an Annex II and III technical file from your product data and evidence, and export them as DOCX, PDF or ZIP. The content still has to be reviewed, completed with your own evidence and approved by your team. ### Software for the obligations in Regulation (EU) 2017/745 https://mdrpilot.com/eu-mdr-software EU MDR software maps the concrete obligations of Regulation (EU) 2017/745 to daily work. The regulation applies to medical devices placed on the EU market and, through Article 10, requires manufacturers to run a risk management system, a quality management system, clinical evaluation, post-market surveillance and up-to-date technical documentation. MDRpilot organises these obligations per device, ties each one to evidence, and shows which parts are still missing. It supports the work; conformity assessment remains with your notified body. Q: What is EU MDR 2017/745? A: Regulation (EU) 2017/745 is the EU law on medical devices. It has applied since 26 May 2021 and replaced the Medical Devices Directive and the Active Implantable Medical Devices Directive. Q: Does MDRpilot cover IVDR? A: No. MDRpilot is built for medical devices under Regulation (EU) 2017/745. In vitro diagnostic devices under Regulation (EU) 2017/746 have different classification rules and performance evaluation requirements. Q: Does MDRpilot guarantee MDR compliance? A: No software can guarantee compliance. MDRpilot makes the requirements, evidence and gaps visible; compliance is demonstrated by your documentation and assessed by your notified body. ### Technical file software for MDR devices https://mdrpilot.com/technical-file-software Technical file software helps a manufacturer assemble and maintain the technical documentation required by MDR Annex II and Annex III for each device or device family. In MDRpilot every product has its own technical file with sections for device description, information supplied by the manufacturer, design and manufacturing, GSPR, benefit-risk and risk management, verification and validation, and post-market surveillance. Each section shows whether it is missing, in draft or approved, and can hold drafts, edits and evidence files. Q: What is an MDR technical file? A: It is the technical documentation described in MDR Annex II and Annex III. It shows how a device meets the General Safety and Performance Requirements and how its post-market surveillance is organised. Q: Can MDRpilot generate a technical file? A: It drafts the sections from your product data and evidence and exports them. It cannot create test results or clinical data, and the drafts must be reviewed and approved by your team. Q: Is one technical file per device enough for device families? A: A technical file can cover a device and its variants when they share the same intended purpose and design basis. MDRpilot stores variants in the product description; how you group devices is your regulatory decision. ### MDR technical documentation under Annex II and Annex III https://mdrpilot.com/mdr-technical-documentation MDR technical documentation is the set of documents a manufacturer must draw up and keep up to date to show that a device conforms to Regulation (EU) 2017/745. Annex II lists the content: device description and specification, information supplied by the manufacturer, design and manufacturing information, the GSPR, benefit-risk analysis and risk management, and product verification and validation. Annex III adds the technical documentation on post-market surveillance: the PMS plan and the PSUR or PMS report. This page maps each part to the place it lives in MDRpilot. Q: What is the difference between Annex II and Annex III? A: Annex II covers the technical documentation of the device itself. Annex III covers the technical documentation on post-market surveillance, namely the PMS plan and the PSUR or PMS report. Q: Is the technical documentation the same as the design history file? A: No. The design history file is a design control record. The MDR technical documentation draws on it, especially in section II.3 and II.6, but has a wider scope. Q: Must the technical documentation be in a specific language? A: The language is agreed with the notified body and must be acceptable to it. Labels and IFU must be in the languages required by the Member States where the device is made available. ### GSPR compliance with evidence you can trace https://mdrpilot.com/gspr-compliance GSPR compliance means showing, for every General Safety and Performance Requirement in MDR Annex I, whether it applies to the device, how it is met and which evidence proves it. The GSPR checklist is part of the technical documentation (Annex II, Section 4) and is usually the first place a notified body reviewer looks. In MDRpilot each requirement is a row with applicability, justification for non-applicable items, the method and harmonised or other standards used, and the linked evidence documents. Q: What does GSPR stand for? A: General Safety and Performance Requirements, set out in Annex I of Regulation (EU) 2017/745. They replaced the Essential Requirements of the Medical Devices Directive. Q: Can MDRpilot manage GSPR evidence? A: Yes. Each GSPR row can hold linked evidence files, and uploaded test reports are proposed as evidence when their standard and verdict match. You confirm every link. Q: Do I need a justification for non-applicable GSPRs? A: Yes. The technical documentation should explain why a requirement does not apply. MDRpilot provides a field for this justification on every row. ### ISO 14971 risk management software connected to your evidence https://mdrpilot.com/iso-14971-software ISO 14971 risk management software helps manufacturers run the process defined in ISO 14971:2019: plan risk management, identify hazards and hazardous situations, estimate and evaluate risks, implement and verify risk controls, evaluate overall residual risk and keep the risk file updated with production and post-production information. MDR Annex I Sections 1 to 9 make this process mandatory for every device. In MDRpilot the risk file sits next to the GSPR matrix and the evidence files, so a verified test report can close a risk control directly. Q: Is ISO 14971 mandatory under MDR? A: MDR requires a risk management system (Article 10 and Annex I). EN ISO 14971:2019 with amendment A11:2021 is the harmonised standard most manufacturers use to demonstrate it. Q: Does MDRpilot support FMEA? A: Yes. Risk items can be recorded in an FMEA-style table with severity, probability and controls. Q: Can a test report close a risk control? A: A passing test report that you confirm against a risk item is recorded as verification of the control. A failing report is not linked. ### Clinical evaluation software for the CEP, literature and CER https://mdrpilot.com/clinical-evaluation-software Clinical evaluation software supports the process required by MDR Article 61 and Annex XIV Part A: planning the clinical evaluation, identifying and appraising clinical data, analysing whether the data are sufficient to confirm safety, performance and the benefit-risk ratio, and documenting the result in a clinical evaluation report (CER). MDRpilot holds the clinical evaluation plan, runs literature searches in PubMed and Europe PMC, records PRISMA-style screening counts and equivalence data, keeps a clinical gap matrix and produces a CER draft that goes through review and approval. Q: Can MDRpilot help with clinical evaluation? A: Yes. It structures the CEP, runs literature searches in PubMed and Europe PMC, records screening counts and equivalence, keeps a clinical gap matrix and drafts the CER for your review. Q: Does MDRpilot write the CER for me? A: It drafts the CER from your plan, data and confirmed evidence. The evaluator must review, complete and sign it. Q: What is the difference between a CEP and a CER? A: The CEP plans the clinical evaluation before data are collected. The CER documents the data, their appraisal and the conclusion on safety, performance and benefit-risk. ### PMS and PMCF software that feeds back into risk and clinical evaluation https://mdrpilot.com/pms-pmcf-software PMS and PMCF software helps a manufacturer run post-market surveillance as MDR Articles 83 to 86 require: a PMS plan for each device, proactive post-market clinical follow-up (Annex XIV Part B), and periodic reporting in a PMS report for Class I devices or a periodic safety update report (PSUR) for Class IIa, IIb and III devices. MDRpilot generates these documents from the product record, schedules the PSUR by class and keeps complaints, CAPA and the risk file in the same workspace, so post-market findings can update risk and clinical evaluation. Q: What is the difference between PMS and PMCF? A: PMS is the overall system for collecting and analysing post-market data. PMCF is the part of PMS that proactively collects clinical data on the device in use, described in Annex XIV Part B. Q: Does every device need a PSUR? A: Class IIa, IIb and III devices need a PSUR. Class I devices need a PMS report instead. Q: Can MDRpilot help with PMCF? A: It drafts the PMCF plan, provides a PMCF survey and links the plan to clinical gaps found in the clinical evaluation. ### Medical device regulatory software: what the category covers https://mdrpilot.com/medical-device-regulatory-software Medical device regulatory software is a category of tools that help manufacturers plan, document and maintain the regulatory status of their devices. It overlaps with electronic quality management systems (eQMS), which focus on QMS processes and records, and with document management systems, which focus on versioning and approval. MDRpilot sits between them: it is product-centred like a regulatory tool, includes the QMS documents and records an ISO 13485 system needs, and adds AI-assisted drafting with controlled templates. Q: What is medical device regulatory software? A: Software that helps manufacturers plan, document and maintain the regulatory compliance of their devices, such as technical documentation, risk management, clinical evaluation, post-market surveillance and QMS records. Q: Is MDRpilot an eQMS? A: It includes eQMS functions such as document control, CAPA, complaints, internal audits, training and supplier evaluation, and combines them with MDR technical documentation. Q: Is MDRpilot itself a medical device? A: No. MDRpilot is documentation and workflow software for manufacturers. It is not intended for diagnosis or treatment of patients. ### ISO 13485 software for quality manuals, procedures and controlled records https://mdrpilot.com/iso-13485-software ISO 13485 software helps a medical device manufacturer create, control and use the documentation required by ISO 13485:2016, the quality management system standard for medical devices. That includes the quality manual, documented procedures, forms, records and the medical device file (clause 4.2.3). MDRpilot provides a quality manual wizard, procedure drafting in controlled templates that build on each other, document control with reviewer, approver and release steps, and a document register, together with the operational records the procedures call for. Q: Does MDRpilot support ISO 13485? A: Yes. It covers the quality manual, procedures, forms, document control, a document register and the quality records ISO 13485:2016 requires. Q: Will using MDRpilot make us ISO 13485 certified? A: No. Certification requires an audit by a certification body. MDRpilot helps you build and run the documented system that is audited. Q: Can we import our existing procedures? A: You can upload existing documents as files and keep working in MDRpilot's document control for new revisions. ### A medical device QMS that is connected to your devices https://mdrpilot.com/medical-device-qms A medical device quality management system (QMS) is the set of processes, responsibilities and records a manufacturer uses to design, produce and monitor devices consistently and in line with regulation. MDR Article 10(9) lists the aspects the QMS must address, from the regulatory compliance strategy and GSPR identification to risk management, clinical evaluation, PMS, vigilance and CAPA. ISO 13485:2016 is the standard most manufacturers use to meet these requirements. The QMS is not a separate binder: its outputs feed the technical documentation of every device. Q: Is ISO 13485 certification required under MDR? A: MDR requires a QMS that covers Article 10(9). ISO 13485 certification is not legally required, but EN ISO 13485 is the harmonised standard most manufacturers use, and the notified body assesses the QMS as part of conformity assessment. Q: What is the medical device file? A: ISO 13485 clause 4.2.3 requires a file for each device type or family with its description, specifications, procedures and records. Under MDR it overlaps with the technical documentation. Q: Can MDRpilot manage design control? A: Yes. Design control records from input to transfer are kept per product with a traceability matrix. ### CAPA software that closes the loop with complaints, audits and risk https://mdrpilot.com/capa-software CAPA software manages corrective and preventive actions, the process ISO 13485:2016 clauses 8.5.2 and 8.5.3 require for eliminating the causes of nonconformities and preventing them from occurring. A CAPA record covers the source, the investigation and root cause, the actions, verification that actions do not adversely affect device conformity, and a check of effectiveness. MDR Article 10(9) also lists CAPA as a QMS element. In MDRpilot CAPA records sit alongside complaints, internal audits and the risk file, with due dates and status that feed the audit readiness view. Q: What is CAPA in medical devices? A: Corrective and preventive action: the QMS process for finding and removing the causes of nonconformities (corrective) or potential nonconformities (preventive), required by ISO 13485 clause 8.5. Q: Can MDRpilot write our CAPA procedure? A: It drafts a CAPA SOP from your company profile and the CAPA-specific decisions you enter. Undecided points are marked [TO BE CONFIRMED]. Q: Does every complaint need a CAPA? A: No. Complaints are evaluated and investigated; a CAPA is opened when the investigation shows a nonconformity or a risk that needs corrective or preventive action, according to your procedure. ### Medical device compliance software for the whole device lifecycle https://mdrpilot.com/medical-device-compliance-software Medical device compliance software helps manufacturers keep their devices, documentation and quality processes in line with the regulations that apply to them throughout the lifecycle: design, conformity assessment, placing on the market, post-market surveillance and change. For the EU that means Regulation (EU) 2017/745 and the standards used to demonstrate conformity, such as ISO 13485 and ISO 14971. Compliance is demonstrated by evidence and assessed by notified bodies and authorities; software can make that evidence complete, consistent and easy to find. Q: Does MDRpilot guarantee compliance? A: No. It organises your documentation and shows gaps. Compliance is demonstrated by your evidence and assessed by your notified body and the competent authorities. Q: Does MDRpilot ensure CE certification? A: No. CE marking of devices that need a notified body follows a successful conformity assessment by that notified body. MDRpilot helps you prepare the documentation that is assessed. Q: Can management see compliance status? A: Yes. The executive and audit readiness views summarise open items across products and the QMS. ### Audit readiness for MDR and ISO 13485 audits https://mdrpilot.com/audit-readiness Audit readiness is the state in which a manufacturer can show an auditor, without scrambling, that its QMS and device documentation are complete, current and supported by evidence. For MDR this applies to notified body QMS audits, technical documentation reviews and unannounced audits. MDRpilot measures readiness from the actual state of your workspace: technical file sections, GSPR evidence, QMS document status and open or overdue CAPAs. It lists the missing actions and lets you rehearse with an audit simulator before the real audit. Q: Can MDRpilot help prepare for audits? A: Yes. It shows a readiness score, lists missing actions across the technical file, QMS and CAPA, and offers an audit simulator for rehearsal. Q: What is an unannounced audit? A: Notified bodies must carry out unannounced audits of manufacturers at least once every five years (MDR Annex IX, Section 3.4). Readiness therefore needs to be continuous, not a project before each planned audit. Q: Does a high readiness score mean we will pass? A: No. It means the documents and records are in place. Whether they are adequate is judged by the auditor. ### MDR gap analysis that turns findings into actions https://mdrpilot.com/mdr-gap-analysis An MDR gap analysis compares a manufacturer's current technical documentation and quality system with the requirements of Regulation (EU) 2017/745 and lists what is missing or insufficient. It is the usual starting point when moving a device from the MDD to the MDR, after a significant change, or before a notified body review. MDRpilot performs a continuous gap analysis from the data in your workspace: missing sections, GSPR rows without evidence, failed test reports, clinical gaps, missing QMS documents and documents flagged by product changes. Q: What is an MDR gap analysis? A: A comparison of current documentation and processes with the requirements of Regulation (EU) 2017/745, resulting in a list of missing or insufficient items. Q: How long does a gap analysis take in MDRpilot? A: It depends on how much existing documentation you upload and link. Gaps are calculated from the workspace as soon as data is entered. Q: Can MDRpilot analyse our existing MDD file? A: You can upload existing documents; they are analysed for standards and verdicts and proposed as evidence. Converting the Essential Requirements checklist into GSPR rows is done in the GSPR module. ### AI for medical device regulatory work, with guardrails https://mdrpilot.com/ai-for-medical-device-regulatory AI in medical device regulatory work means using language models to draft, summarise, translate and cross-check regulatory documents. The risk is that a model writes plausible but untrue statements, such as a retention period, an authority or a test result, into a controlled document. MDRpilot uses AI as an assistant inside a regulatory workspace: templates lock document headings, company facts come from the profile, unconfirmed points are marked [TO BE CONFIRMED], and every draft must be reviewed and approved by a person. A company owner can switch external AI off for the whole workspace. Q: Does MDRpilot use AI to make regulatory decisions? A: No. AI drafts and proposes. Classification is rule-based with visible reasoning, and approvals are always made by people. Q: Can we turn AI off? A: Yes. A company owner can disable external AI processing for the workspace in Settings. Q: Is our data used to train AI models? A: Excerpts are sent to the configured providers only to generate the output you request. Where providers offer contractual options, MDRpilot configures them not to use customer data for training public models, as described in the privacy policy. ### Regulatory affairs software for medical device teams https://mdrpilot.com/regulatory-affairs-software Regulatory affairs software supports the people who decide and document how a device reaches and stays on the market: classification, conformity assessment route, technical documentation, labelling, UDI and registration, and communication with notified bodies. In MDRpilot the regulatory affairs role works on the same product record as quality and engineering: it documents the Annex VIII classification rationale, owns the technical file structure, prepares UDI device data for EUDAMED, confirms the company's own SRN, and translates documents into the languages of the target markets. Q: What does a medical device regulatory affairs team do? A: It determines and documents the regulatory strategy for each device: classification, conformity assessment route, technical documentation, labelling, UDI and registration, and it manages communication with notified bodies and authorities. Q: Can MDRpilot submit to EUDAMED? A: No. It prepares UDI device data XML for manual use and helps you confirm your own SRN. Q: Does MDRpilot help with classification? A: Yes. The Annex VIII assistant suggests a class and rule from your answers and stores the rationale. Your team confirms the class. ## Guides ### What Is EU MDR 2017/745? https://mdrpilot.com/resources/what-is-eu-mdr (MDR, updated 2026-10-05) EU MDR is Regulation (EU) 2017/745, the European Union law that governs medical devices and their accessories. It replaced the Medical Devices Directive (93/42/EEC) and the Active Implantable Medical Devices Directive (90/385/EEC) and has applied since 26 May 2021. Because it is a regulation, it applies directly in every Member State and sets requirements for manufacturers, authorised representatives, importers, distributors, notified bodies and authorities. ### EU MDR Technical Documentation: Complete Guide https://mdrpilot.com/resources/mdr-technical-documentation-guide (MDR, updated 2026-10-05) EU MDR technical documentation is the evidence package a manufacturer draws up under Article 10(4) and Annexes II and III to demonstrate that a device meets the General Safety and Performance Requirements. It must be kept up to date, made available to authorities on request, and retained for at least 10 years after the last device is placed on the market, or 15 years for implantable devices. For devices that need a notified body, it is assessed as part of conformity assessment. ### MDR Annex II and Annex III Explained https://mdrpilot.com/resources/mdr-annex-ii-and-iii-explained (MDR, updated 2026-10-05) MDR Annex II lists the content of a device's technical documentation in six sections: device description, information supplied by the manufacturer, design and manufacturing, GSPR, benefit-risk analysis and risk management, and verification and validation. Annex III adds the technical documentation on post-market surveillance: the PMS plan and the PSUR or PMS report. Together they define what a notified body expects to find when it reviews a technical file. ### What Is GSPR Compliance? https://mdrpilot.com/resources/what-is-gspr-compliance (GSPR, updated 2026-10-05) GSPR compliance means demonstrating that a medical device meets each applicable General Safety and Performance Requirement in Annex I of the EU MDR. Manufacturers document this in a GSPR checklist, part of the technical documentation under Annex II Section 4, which states for every requirement whether it applies, how it is met, which standards or other solutions are used and where the evidence is held. ### How to Build an MDR Technical File https://mdrpilot.com/resources/how-to-build-an-mdr-technical-file (MDR, updated 2026-10-05) Build an MDR technical file by fixing the intended purpose and classification first, then working through the GSPR checklist, the risk management file, verification and validation evidence, the clinical evaluation, labelling and the PMS documentation, and finally cross-checking everything for consistency. Order matters: almost every later document depends on the device description and intended purpose. ### MDR Gap Analysis Guide https://mdrpilot.com/resources/mdr-gap-analysis-guide (Audit, updated 2026-10-05) An MDR gap analysis compares existing documentation and processes against Regulation (EU) 2017/745 and produces a prioritised list of what is missing or insufficient. Run it per device against Annexes I, II, III and XIV and against Article 10(9) for the QMS, rate each gap by its impact on safety and on certification, and convert the result into actions with owners and dates. ### Clinical Evaluation Report (CER) Guide https://mdrpilot.com/resources/clinical-evaluation-report-guide (Clinical evaluation, updated 2026-10-05) A clinical evaluation report (CER) documents the clinical evaluation required by MDR Article 61 and Annex XIV Part A: which clinical data were identified, how they were appraised and analysed, and whether they are sufficient to confirm the device's safety, performance and benefit-risk ratio for its intended purpose. It is based on a clinical evaluation plan (CEP) and must be updated with post-market data throughout the device lifecycle. ### PMS and PMCF Explained https://mdrpilot.com/resources/pms-and-pmcf-explained (PMS / PMCF, updated 2026-10-05) Post-market surveillance (PMS) is the system a manufacturer uses to collect and analyse data on its devices once they are on the market and to act on what it finds (MDR Articles 83–86). Post-market clinical follow-up (PMCF) is the part of PMS that proactively collects clinical data on the device in use, to confirm safety and performance and detect emerging risks (Annex XIV Part B). PMS outputs feed the risk file, the clinical evaluation and the PSUR or PMS report. ### ISO 13485 for Medical Device Manufacturers https://mdrpilot.com/resources/iso-13485-for-medical-device-manufacturers (ISO 13485, updated 2026-10-05) ISO 13485:2016 is the international standard for quality management systems of organisations involved in the design, production, installation and servicing of medical devices. It specifies requirements for regulatory purposes, so it emphasises documented processes, risk-based controls, design control, traceability and feedback handling. In the EU, EN ISO 13485 is the harmonised standard most manufacturers use to meet the QMS obligations in MDR Article 10(9), although MDR adds requirements the standard does not cover. ### ISO 14971 Risk Management Guide https://mdrpilot.com/resources/iso-14971-risk-management-guide (ISO 14971, updated 2026-10-05) ISO 14971:2019 defines the process for managing risks of medical devices throughout their lifecycle: plan risk management, analyse and evaluate risks, control them, evaluate overall residual risk, review the process before release and monitor production and post-production information. Under the EU MDR, EN ISO 14971:2019 with amendment A11:2021 is the harmonised standard used to demonstrate the risk management requirements in Annex I Sections 1 to 9. ### MDR Audit Preparation Checklist https://mdrpilot.com/resources/mdr-audit-preparation-checklist (Audit, updated 2026-10-05) Prepare for an MDR audit by confirming that your QMS procedures cover Article 10(9), that records show the procedures are followed, that each device's technical documentation is complete and consistent, that CAPAs are current and effective, and that the people who will be interviewed know where evidence is. Because notified bodies perform unannounced audits at least once every five years, readiness has to be continuous. ### Medical Device CAPA Guide https://mdrpilot.com/resources/medical-device-capa-guide (CAPA, updated 2026-10-05) CAPA, corrective and preventive action, is the QMS process for eliminating the causes of existing nonconformities (corrective action, ISO 13485 clause 8.5.2) and of potential nonconformities (preventive action, clause 8.5.3). A good CAPA records the problem, investigates the root cause, takes proportionate actions, verifies that they do not adversely affect device conformity and checks that they were effective. MDR Article 10(9) requires CAPA as part of the QMS. ### AI in Medical Device Regulatory Affairs https://mdrpilot.com/resources/ai-in-medical-device-regulatory-affairs (AI & Regulatory, updated 2026-10-05) AI can help regulatory affairs teams draft structured documents, extract information from test reports, support literature screening and translate documentation, which saves time on repetitive work. The main risk is plausible but false content in controlled documents. Teams that use AI successfully restrict it to confirmed inputs, keep fixed templates, mark unknowns explicitly, review every output and record AI use in the document history. ### MDR Technical Documentation Software Comparison https://mdrpilot.com/resources/mdr-software-comparison (Choosing software, updated 2026-10-05) Compare MDR technical documentation software on how well it keeps requirements, evidence and documents connected, not on feature counts. The criteria that matter most are product-centred data, GSPR and risk traceability, evidence handling, change impact, controlled AI use, document control, export formats, data protection and fit for your team size. This article gives a neutral framework and describes MDRpilot against it; it does not rate other vendors. ### MDR Software for Small and Medium-Sized Medical Device Manufacturers https://mdrpilot.com/resources/mdr-software-for-smes (Choosing software, updated 2026-10-05) Small and medium-sized medical device manufacturers usually have one or two people covering quality, regulatory affairs and post-market work, often supported by an external consultant. MDR software for SMEs should reduce cross-checking work, keep documentation consistent without a large team, support consultant access, and be priced per product and seat rather than as an enterprise programme. It cannot remove the need for qualified people, including a PRRC. ## Glossary - MDR (Medical Device Regulation, Regulation (EU) 2017/745): The EU regulation that governs medical devices and their accessories. It has applied since 26 May 2021 and replaced the MDD and AIMDD directives. - IVDR (In Vitro Diagnostic Medical Devices Regulation, Regulation (EU) 2017/746): The EU regulation for in vitro diagnostic devices such as reagents, analysers and specimen containers. It has its own classification rules and performance evaluation requirements. - GSPR (General Safety and Performance Requirements): The requirements in MDR Annex I that every device must meet, covering general safety and performance, design and manufacture, and information supplied with the device. - Technical documentation: The documents described in MDR Annexes II and III that demonstrate a device's conformity: description, labelling, design and manufacturing, GSPR, risk, verification and validation, and PMS. - Notified body: An organisation designated by an EU Member State to assess the conformity of devices before they are placed on the market. Designated bodies are listed in the European Commission's NANDO database. - CER (Clinical evaluation report): The report documenting the clinical evaluation of a device: the clinical data identified, their appraisal and analysis, and the conclusion on safety, performance and benefit-risk. - Clinical evaluation: The systematic and planned process to continuously generate, collect, analyse and assess clinical data on a device to verify its safety and performance, including clinical benefits (MDR Article 2(44)). - PMS (Post-market surveillance): All activities a manufacturer carries out to collect and review experience from devices on the market, to identify the need for corrective or preventive action (MDR Articles 83–86). - Post-market surveillance system: The system required by MDR Article 83, integrated into the QMS and proportionate to the device risk class, that gathers, records and analyses data on quality, performance and safety throughout the device's lifetime. - PMCF (Post-market clinical follow-up): The continuous process, described in MDR Annex XIV Part B, of proactively collecting and evaluating clinical data on a CE-marked device used within its intended purpose. - PSUR (Periodic safety update report): A report required by MDR Article 86 for Class IIa, IIb and III devices that summarises PMS data, conclusions and actions. Class IIb and III devices update it at least annually, Class IIa at least every two years. - CAPA (Corrective and preventive action): The QMS process to eliminate the causes of existing nonconformities (corrective) and potential nonconformities (preventive), required by ISO 13485 clauses 8.5.2 and 8.5.3. - QMS (Quality management system): The organisational structure, responsibilities, procedures, processes and resources a manufacturer uses to achieve quality and regulatory compliance. MDR Article 10(9) lists the aspects it must cover. - ISO 13485 (ISO 13485:2016 Medical devices — Quality management systems — Requirements for regulatory purposes): The international QMS standard for organisations involved in the medical device lifecycle. It was confirmed in its 2025 systematic review and remains the current edition. - ISO 14971 (ISO 14971:2019 Medical devices — Application of risk management to medical devices): The international standard that specifies the risk management process for medical devices across the lifecycle, from planning to post-production. - Risk management: The systematic application of management policies, procedures and practices to analysing, evaluating, controlling and monitoring risk (ISO 14971). MDR Annex I Section 3 requires a risk management system for every device.