--- title: How PMS Data Updates Your Clinical Evaluation: The Lifecycle Approach description: MDR requires PMS and PMCF data to update the clinical evaluation report on a lifecycle cadence. Here is how the CER-PMS loop actually closes. authors: Tibor Zechmeister, Felix Lenhard category: Post-Market Surveillance & Vigilance primary_keyword: PMS data clinical evaluation update MDR canonical_url: https://zechmeister-solutions.com/en/blog/pms-data-updates-clinical-evaluation source: zechmeister-solutions.com license: All rights reserved. Content may be cited with attribution and a link to the canonical URL. --- # How PMS Data Updates Your Clinical Evaluation: The Lifecycle Approach *By Tibor Zechmeister (EU MDR Expert, Notified Body Lead Auditor) and Felix Lenhard.* > **MDR Article 61(11) of Regulation (EU) 2017/745 requires the clinical evaluation and the clinical evaluation report to be updated throughout the lifecycle of the device with clinical data obtained from the manufacturer's post-market surveillance plan under Article 84 and, in particular, from the post-market clinical follow-up plan referred to in Annex XIV Part B. Article 83(3) names updating the clinical evaluation as a required use of PMS findings. The loop closes when PMS intake (complaints, trends, vigilance, literature) and PMCF outputs (structured clinical data gathering post-launch) both feed the same CER revision cadence — scheduled by device class under Article 86 and event-driven by any new signal that changes the clinical benefit-risk picture. A CER that was signed at CE marking and has not been touched since is an open finding waiting for the next notified body visit.** **By Tibor Zechmeister and Felix Lenhard. Last updated 10 April 2026.** --- ## TL;DR - MDR Article 61(11) explicitly requires the clinical evaluation and CER to be updated throughout the device lifecycle using PMS data and PMCF data — the loop is written into the Regulation, not a best practice. - Article 83(3) of Regulation (EU) 2017/745 names updating the clinical evaluation as a required use of PMS findings, alongside updating the benefit-risk determination and the design and manufacturing information. - Annex XIV Part B defines the PMCF plan as the structured proactive channel for gathering clinical data post-launch — the outputs feed directly into the CER. - Annex III ties the PMS plan to the CER update cadence and requires the plan to describe how findings are used. - Class IIa, IIb, and III devices run the CER update on the PSUR rhythm under Article 86 at minimum — plus event-driven updates whenever a signal changes the clinical picture. - A closed-loop CER shows which PMS and PMCF inputs drove which revisions, with traceable dates, authors, and evidence. --- ## Why the CER is not a pre-market deliverable A pattern we see in almost every first audit of a small manufacturer: the clinical evaluation report sitting in the technical file is dated within a week of the CE certificate. Thick, signed, archived. Twelve months of post-market data has flowed in since then — complaints, PMCF survey responses, a literature hit on a similar device — and the CER is still the launch version. The team assumed the CER was a notified body deliverable. They did the work once, passed the audit, and moved on. This is the single most expensive misunderstanding in post-market compliance. The MDR does not treat clinical evaluation as a pre-market deliverable. Article 61(11) of Regulation (EU) 2017/745 is explicit: the clinical evaluation and its documentation shall be updated throughout the lifecycle of the device concerned with clinical data obtained from the implementation of the manufacturer's PMS plan and, in particular, the PMCF plan. The verb is "shall." The scope is "throughout the lifecycle." The sources are named. There is no ambiguity and no exemption for small manufacturers. The notified body reads this the same way. On surveillance audits, one of the standard walk-throughs is: show me the CER revision history, show me the PMS Report or PSUR that drove each revision, and show me what changed in the clinical conclusion. If the revision history is empty, the system is not running. If the revision history exists but does not trace back to specific PMS or PMCF inputs, the integration point is broken. This post walks the loop that Article 61(11), Article 83(3), Annex III, and Annex XIV Part B of the MDR jointly require — and shows how a small team actually runs it without drowning in documentation. ## The closed loop between CER and PMS The CER-PMS loop is four operations performed on every clinically relevant signal that arrives from the field. Collect, assess for clinical relevance, update the clinical evaluation, verify the update stuck. Each operation maps to a specific MDR provision. Collect is Article 83(2), which requires the manufacturer to actively and systematically gather, record, and analyse relevant data on the quality, performance, and safety of a device throughout its lifetime. The data includes both reactive signals (complaints, incidents, service records) and proactive signals (PMCF outputs, literature, similar-device monitoring, registries). The same intake that feeds the risk management loop feeds the clinical evaluation loop. See [how PMS feeds back into risk management](/blog/pms-feedback-risk-management) for the parallel loop into the risk file. Assess is the clinical-relevance review. Not every PMS signal changes the clinical picture. A shipping damage complaint is not a clinical signal. A user-interface confusion that leads to misinterpretation of an output is. The assessment is performed by the person responsible for regulatory compliance under Article 15 together with the clinical evaluator, and the decision is written down — including the "not clinically relevant" decisions. A signal that was assessed and dismissed with a documented rationale is defensible at audit. A signal that never reached the assessment is a systemic gap. Update is Article 61(11) and Article 83(3) working together. When clinically relevant PMS or PMCF data arrives, the clinical evaluation is revised. The CER update may be a minor amendment (new evidence supporting an existing conclusion) or a major revision (new hazard, new contraindication, new patient population, revised benefit-risk). MDCG 2020-5 on equivalence remains relevant here for manufacturers who relied on equivalence at CE marking — post-market clinical data from the subject device progressively replaces the equivalence argument, which is exactly the direction Article 61(11) intends. Verify is the effectiveness check that closes the loop. If the CER update produced a change in the IFU, the labelling, the intended purpose statement, or a risk control, the change has to actually reach the device shipped to users — and the follow-up data has to show the change worked. Verification is the step startups forget, and it is the step auditors focus on. ## What PMS data actually triggers a CER update Not every PMS data point reaches the CER. The question is always "does this change the clinical picture," and the answer maps to specific categories of finding. New or reclassified hazards with clinical consequences. When the production and post-production clause of EN ISO 14971:2019+A11:2021 drives a risk-file revision that recognises a new hazard affecting patients or users in the clinical sense, the CER has to absorb that hazard into the benefit-risk narrative. The risk file and the CER are not the same document, but they move together. Trend signals from Article 88 of Regulation (EU) 2017/745. When the reporting of trends produces a statistically significant increase in the severity or frequency of non-serious incidents or expected side effects that could significantly impact benefit-risk, the clinical evaluation is part of what gets reassessed. Serious incidents and FSCAs under Article 87. Vigilance events almost always trigger a CER review — either confirming the existing clinical conclusion is still valid under the new information, or modifying it. PMCF outputs under Annex XIV Part B. This is the designed, proactive channel. The PMCF plan defines specific clinical questions (residual uncertainties, rare complications, long-term performance, new populations), the study methods to answer them, and the timeline. Every PMCF data pull feeds directly into the CER as part of the scheduled update cycle. For the PMCF mechanics, see [PMCF under MDR — a startup guide](/blog/pmcf-mdr-guide-startups). Literature surveillance findings that identify new evidence, new comparator data, new published adverse events on similar devices, or revised clinical guidelines that change the state of the art for the intended purpose. Similar-device recalls, FSCAs, and safety notices that affect the plausibility of clinical performance claims or hazard estimates used in the original CER. Changes to applicable clinical standards or guidance documents — for example, an update to MDCG guidance on clinical evaluation that materially changes the expected methodology or evidence threshold. A signal in any of these categories triggers at minimum a documented clinical-relevance assessment, and typically a CER revision. ## How PMCF data flows into the CER PMCF is the structured spine of the proactive PMS programme, and Annex XIV Part B of Regulation (EU) 2017/745 is the regulatory anchor. The PMCF plan is a required part of the technical documentation for most devices where residual clinical uncertainties exist at CE marking. Its outputs are not optional supporting evidence — they are the data Article 61(11) names when it says the clinical evaluation "in particular" uses PMCF data. The flow in practice: the PMCF plan defines the clinical questions and the method (registry, survey, prospective cohort, real-world data pull). The PMCF runs on a defined timeline. Data pulls happen at scheduled intervals. Each pull produces a PMCF evaluation report. The PMCF evaluation report feeds the next CER revision. The CER revision updates the clinical conclusion, the benefit-risk statement, and any downstream items in the technical file. The PSUR under Article 86 summarises the outcome for the notified body and for Eudamed in due course. A PMCF that produces data nobody integrates into the CER is a PMCF that does not exist for audit purposes. The integration is the point. ## Update cadence — scheduled and event-driven Two cadences drive the CER update, and both have to run. The scheduled cadence for Class IIa, IIb, and III devices is tied to Article 86 of Regulation (EU) 2017/745, which requires the Periodic Safety Update Report. The PSUR rhythm is at least annually for Class IIb and Class III devices and at least every two years for Class IIa devices; Class III and implantable devices also feed the Eudamed summary of safety and clinical performance. Each PSUR cycle is the natural checkpoint for a CER revision — the PSUR cannot credibly conclude "benefit-risk remains acceptable" without the clinical evaluation underneath it being current. For Class I devices, the cadence is set in the PMS plan under Annex III and typically runs annually at minimum, bound to the PMS Report. The event-driven cadence is the trigger that bypasses the schedule. A serious incident under Article 87, a trend signal crossing the Article 88 threshold, a new hazard identification with clinical consequences, a literature hit that changes the state of the art, or a similar-device FSCA with direct relevance — any of these forces an unscheduled CER review. The PMS plan names the trigger criteria. The clinical evaluator runs the review. The outcome is either "no change required, rationale documented" or a formal CER revision. Both cadences update the same document. A PMS plan that names only one of the two is incomplete. For the update mechanics on the CER side, see [updating the clinical evaluation report across the lifecycle](/blog/update-clinical-evaluation-report-lifecycle). ## A lifecycle scenario Consider a Class IIa software-as-a-medical-device for symptom tracking that ships with equivalence-based clinical evaluation at CE marking. Twelve months in, the reactive channel logs a cluster of user reports about a specific symptom category being consistently under-flagged. The trend crosses the Article 88 threshold. The PMCF survey running on the annual cycle confirms the pattern in a larger sample. The loop runs. Clinical-relevance assessment: yes, this affects the clinical performance claim. Risk file update: the hazard of under-recognition is re-scored. CER revision: the clinical conclusion is modified to acknowledge the limitation, the intended purpose is tightened, and a new risk control is added in the form of a user prompt. IFU and labelling update downstream. PSUR entry reflects the revision and the effectiveness verification. Next PMCF data pull confirms the prompt reduces the under-flagging to the target threshold. One signal, one intake, one clinical assessment, one CER revision, one effectiveness verification. That is the closed loop Article 61(11) and Article 83(3) together require. The work is not glamorous. It is the reason the device is still safely on the market a year later. ## The update-cadence playbook — Ship Run the scheduled cycle on the PSUR rhythm your device class requires. Name the date. Name the owner. The clinical evaluator is usually the person responsible for regulatory compliance under Article 15 in a small team, or a named external clinical consultant. Define the event-driven triggers in writing in the PMS plan — serious incidents, Article 88 trend signals, new hazard identifications, similar-device FSCAs, literature hits on residual uncertainties. When any trigger fires, a clinical-relevance assessment runs within a defined timeline, and the outcome is documented whether or not the CER is revised. Bind the CER update checklist to the PMS Report or PSUR cycle so the two documents cannot move independently. The PSUR cannot conclude "benefit-risk remains acceptable" without a current CER beneath it. Integrate PMCF data pulls into the CER update checkpoint. The PMCF evaluation report is dated before the CER revision; the CER revision cites the PMCF evaluation report as a source. Propagate every CER change into the downstream documents. A changed intended purpose reaches the labelling. A new contraindication reaches the IFU. A modified risk control reaches the risk file and the design change-control process. A CER update that does not propagate is a finding waiting to happen. Run a one-page "CER revision register" that lists every revision, the trigger, the PMS or PMCF inputs used, the clinical evaluator's signature, and the downstream propagation status. This is the single document the notified body will ask for first. ## Reality Check — where do you stand? 1. Open your CER. What is the date of the last signed revision? If it is older than your most recent PSUR or PMS Report, the loop has broken. 2. Does your PMS plan name the CER update cadence and the event-driven triggers in writing, or does it only mention "findings will be reviewed"? 3. For the most recent serious incident, trend signal, or similar-device FSCA you are aware of, can you produce a written clinical-relevance assessment? 4. Does your PMCF plan produce evaluation reports on a defined timeline, and are those reports cited as inputs in your latest CER revision? 5. When the CER was last revised, did the change actually propagate into the IFU, the labelling, and the risk file? 6. If a notified body auditor asks to walk one signal from intake to CER revision to effectiveness verification, would every step produce a record? 7. Are "not clinically relevant" decisions documented with a rationale, or do they exist only in the clinical evaluator's head? ## Frequently Asked Questions **Does MDR require the clinical evaluation to be updated after CE marking?** Yes. MDR Article 61(11) of Regulation (EU) 2017/745 requires the clinical evaluation and its documentation to be updated throughout the lifecycle of the device with clinical data from the PMS plan and, in particular, from the PMCF plan referred to in Annex XIV Part B. Article 83(3) names updating the clinical evaluation as a required use of PMS findings. **How often does the CER need to be updated?** The Regulation does not set a fixed calendar for every device, but Article 86 sets the PSUR rhythm — at least annually for Class IIb and Class III devices and at least every two years for Class IIa — and the CER must be current at each PSUR cycle. Event-driven updates are required whenever a PMS or PMCF signal changes the clinical picture. **What PMS data sources feed the clinical evaluation?** Complaints and user feedback assessed as clinically relevant, serious incident and FSCA data under Article 87, trend signals under Article 88, PMCF outputs under Annex XIV Part B, literature surveillance, similar-device recalls, registry data where applicable, and the outputs of the risk management loop under EN ISO 14971:2019+A11:2021. **What is the role of PMCF in updating the CER?** PMCF is the structured proactive clinical data channel required under Annex XIV Part B. Its evaluation reports feed directly into the CER at every scheduled update cycle, and the PMCF is specifically how the clinical evaluation moves away from an equivalence argument toward subject-device data over the lifecycle. **Can a small startup keep the CER updated without a full clinical team?** Yes, if the loop is designed for the team size. A three-person regulatory team can run a closed CER-PMS loop by binding CER revisions to the PSUR or PMS Report cycle, defining event triggers in the PMS plan, integrating PMCF data pulls into the checkpoint, and maintaining a single CER revision register. What does not work is a parallel clinical workstream that re-invents the process. ## Related reading - [How PMS feeds back into risk management under MDR](/blog/pms-feedback-risk-management) — the parallel loop into the risk file that runs on the same signals. - [Updating the clinical evaluation report across the lifecycle](/blog/update-clinical-evaluation-report-lifecycle) — the CER-side mechanics of the revision process. - [PMCF under MDR — a startup guide](/blog/pmcf-mdr-guide-startups) — how to design and run the PMCF plan whose outputs feed this loop. - [What is post-market surveillance under MDR?](/blog/what-is-post-market-surveillance-mdr) — the pillar post for the PMS framework this loop sits inside. - [The PMS plan under MDR Annex III](/blog/pms-plan-mdr-annex-iii) — the technical documentation requirements for the plan that names this loop. ## Sources 1. Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices, Article 61(11) (lifecycle update of clinical evaluation with PMS and PMCF data), Article 83 (post-market surveillance system, including Article 83(3) on required uses of PMS findings), Article 86 (Periodic Safety Update Report), Article 87 (reporting of serious incidents), Article 88 (trend reporting), Annex III (technical documentation on post-market surveillance), Annex XIV Part B (post-market clinical follow-up). Official Journal L 117, 5.5.2017. 2. MDCG 2025-10 — Guidance on post-market surveillance of medical devices and in vitro diagnostic medical devices. Medical Device Coordination Group, December 2025. 3. MDCG 2020-5 — Clinical Evaluation: Equivalence. A guide for manufacturers and notified bodies. Medical Device Coordination Group, April 2020. 4. EN ISO 14971:2019+A11:2021 — Medical devices — Application of risk management to medical devices. --- *This post sits inside the Post-Market Surveillance & Vigilance series in the Subtract to Ship: MDR blog. Authored by Felix Lenhard and Tibor Zechmeister. The CER-PMS loop is what turns the clinical evaluation from a pre-market checkbox into a live representation of what the device actually does in the field — the companion posts in this cluster walk the risk management loop, the PMCF mechanics, and the PSUR rhythm that all depend on the same signals.* --- *This post is part of the [Post-Market Surveillance & Vigilance](https://zechmeister-solutions.com/en/blog/category/pms-vigilance) cluster in the [Subtract to Ship: MDR Blog](https://zechmeister-solutions.com/en/blog). For EU MDR certification consulting, see [zechmeister-solutions.com](https://zechmeister-solutions.com).*