<?xml version="1.0" encoding="UTF-8"?><?xml-stylesheet type="text/xsl" href="https://www.cloudtheapp.com/wp-content/plugins/rss-feed-styles/public/template.xsl"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	xmlns:rssFeedStyles="http://www.lerougeliet.com/ns/rssFeedStyles#"
>

<channel>
	<title>PMCF Archives | Cloudtheapp</title>
	<atom:link href="https://www.cloudtheapp.com/tag/pmcf/feed/" rel="self" type="application/rss+xml" />
	<link>https://www.cloudtheapp.com/tag/pmcf/</link>
	<description>Configurable Quality Management &#38; Regulatory Compliance SaaS built on our Validated &#34;No-Code&#34; platform.</description>
	<lastBuildDate>Thu, 16 Jul 2026 00:12:53 +0000</lastBuildDate>
	<language>en-US</language>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	<generator>https://wordpress.org/?v=7.0.1</generator>

<image>
	<url>/wp-content/uploads/3.svg</url>
	<title>PMCF Archives | Cloudtheapp</title>
	<link>https://www.cloudtheapp.com/tag/pmcf/</link>
	<width>32</width>
	<height>32</height>
</image> 
	<item>
		<title>Post-Market Clinical Follow-Up (PMCF): EU MDR Requirements and Implementation Guide</title>
		<link>https://www.cloudtheapp.com/post-market-clinical-follow-up-pmcf-eu-mdr-requirements-and-implementation-guide/</link>
		
		<dc:creator><![CDATA[Cloudtheapp Inc.]]></dc:creator>
		<pubDate>Fri, 10 Jul 2026 00:05:20 +0000</pubDate>
				<category><![CDATA[General]]></category>
		<category><![CDATA[clinical evaluation]]></category>
		<category><![CDATA[EU MDR]]></category>
		<category><![CDATA[MDR 2017/745]]></category>
		<category><![CDATA[PMCF]]></category>
		<category><![CDATA[PMCF plan]]></category>
		<category><![CDATA[Post-Market Clinical Follow-up]]></category>
		<category><![CDATA[Post-Market Surveillance]]></category>
		<category><![CDATA[QMS medical device]]></category>
		<category><![CDATA[Regulatory Compliance]]></category>
		<guid isPermaLink="false">https://www.cloudtheapp.com/post-market-clinical-follow-up-pmcf-eu-mdr-requirements-and-implementation-guide/</guid>

					<description><![CDATA[<p>What Is Post-Market Clinical Follow-Up? Post-Market Clinical Follow-Up is a systematic process that medical device manufacturers use to proactively collect and evaluate clinical data from marketed devices. It is one component of the broader post-market surveillance system required under EU MDR 2017/745, and it exists to confirm the ongoing clinical safety and performance of a [&#8230;]</p>
<p>This post created by and appeared first on <a href="https://www.cloudtheapp.com">Cloudtheapp</a></p>
]]></description>
										<content:encoded><![CDATA[<p><![CDATA[

<h2>What Is Post-Market Clinical Follow-Up?</h2>




<p>Post-Market Clinical Follow-Up is a systematic process that medical device manufacturers use to proactively collect and evaluate clinical data from marketed devices. It is one component of the broader post-market surveillance system required under EU MDR 2017/745, and it exists to confirm the ongoing clinical safety and performance of a device throughout its entire commercial lifetime, not just at the point of initial CE marking.</p>





<p>PMCF is not a regulatory afterthought. Under EU MDR, it is a mandatory, continuous process for all devices regardless of risk class, with the depth and frequency of activity scaled to the device&#8217;s risk profile, available clinical evidence, and any unresolved uncertainties identified during the conformity assessment. For Class III devices and implantables, PMCF is the primary mechanism through which manufacturers sustain the clinical evidence base required for continued CE marking.</p>





<p>The shift from the Medical Devices Directive (MDD) and Active Implantable Medical Devices Directive (AIMDD) to EU MDR brought a fundamental change in expectation. Under the directives, post-market clinical follow-up was required but enforcement was inconsistent. Under EU MDR, PMCF requirements are more detailed, the documentation is more structured, and notified bodies examine PMCF during surveillance audits with far greater scrutiny than they did under the old regime.</p>





<h2>The EU MDR Legal Framework for PMCF</h2>




<p>PMCF requirements under EU MDR 2017/745 are established in Article 83 and Annex XIV Part B. Article 83 sets the overall obligation for manufacturers to proactively collect and review clinical experience gained from placed devices. Annex XIV Part A covers the clinical evaluation plan and report; Part B covers the PMCF plan and PMCF evaluation report as a subset of post-market surveillance.</p>





<p>Annex XIV Part B specifies that the PMCF plan must address:</p>




<ul>


<li>The general methods and procedures of the PMCF activities, including whether systematic literature review, real-world data collection from registries, clinical investigations, or clinician surveys will be used</li>




<li>Specific methods such as evaluations in registries or post-market clinical investigations</li>




<li>A justification for the appropriateness of the methods selected</li>




<li>A reference to relevant parts of the clinical evaluation plan and the post-market surveillance plan</li>




<li>An evaluation of clinical data related to equivalent or similar devices</li>




<li>Identification of any residual risks or unresolved uncertainties from the clinical evaluation</li>


</ul>





<p>The PMCF evaluation report must summarize findings from all PMCF activities, draw conclusions regarding the continued clinical safety and performance of the device, identify any trends, and update the clinical evaluation report where new clinical evidence warrants it. The report must feed directly into the post-market surveillance report (PMSR) for Class I devices or the periodic safety update report (PSUR) for Class IIa, IIb, and III devices.</p>





<h2>PMCF vs. Post-Market Surveillance: Understanding the Distinction</h2>




<p>Post-market surveillance (PMS) is the broader system. It encompasses all activities a manufacturer uses to collect data about a marketed device, including complaint handling, vigilance reporting, literature surveillance, real-world performance data, and registry data. PMCF is the specifically clinical component of PMS, focused on clinical outcomes: device performance in actual patient populations, long-term safety, rare adverse events, and off-label use patterns.</p>





<p>A manufacturer&#8217;s PMS plan is the master document. The PMCF plan is a sub-document that addresses the clinical data collection activities within the PMS system. The PMCF evaluation report feeds into the PSUR. The PSUR feeds into the clinical evaluation report update. These documents are interconnected, and notified bodies review them as a system during technical documentation audits.</p>





<p>Where PMCF differs most from general PMS is in the requirement for proactive clinical data collection. Complaint handling and vigilance reporting are reactive: data arrives when something goes wrong. PMCF requires manufacturers to actively pursue clinical evidence even when no problems have been reported, because the purpose is to confirm ongoing safety and performance, not merely to respond to failures.</p>





<h2>PMCF Methods: What Counts as an Acceptable Activity</h2>




<p>EU MDR does not mandate a specific methodology for PMCF, but Annex XIV Part B and MDCG guidance documents (particularly MDCG 2020-7 on PMCF) identify several accepted approaches.</p>





<p><strong>Systematic literature review:</strong> A structured, documented search of published literature for clinical data on the device or equivalent devices. This is the most common and lowest-burden PMCF method for established devices with a substantial published evidence base. The review must follow a documented protocol with defined search terms, databases, inclusion and exclusion criteria, and a data extraction methodology. A search conducted without a protocol, or one that cherry-picks favorable results, does not meet EU MDR expectations.</p>





<p><strong>Registry data:</strong> Participation in an established device registry provides prospective, real-world clinical data at a population level. For orthopedic implants, cardiovascular devices, and certain ophthalmic devices, established national or specialty registries already collect the type of outcome data relevant to PMCF. Manufacturers document their participation and the data extraction and analysis process in the PMCF plan.</p>





<p><strong>Post-market clinical investigation (PMCI):</strong> A formal clinical study conducted on a CE-marked device to collect specific safety or performance data. PMCIs are required by Article 74 of EU MDR and must be conducted in accordance with clinical investigation requirements under Article 62 or Article 74. They are resource-intensive and are generally reserved for devices with significant unresolved safety questions, Class III devices with limited pre-market clinical data, or situations where literature review is insufficient.</p>





<p><strong>Clinician surveys and device evaluations:</strong> Structured surveys of clinicians who use the device in routine practice can provide real-world data on safety, performance, and user experience. Surveys must be designed prospectively, include a representative sample of users, and analyze results systematically. Ad hoc collections of clinician opinions do not constitute a valid PMCF activity.</p>





<p><strong>Patient registries and real-world evidence platforms:</strong> Manufacturer-sponsored patient follow-up programs collect outcome data directly from patients using an implanted or long-term use device. These are most commonly used for active implantable devices and high-risk Class III devices where long-term safety data is critical.</p>





<h2>What a PMCF Plan Must Contain</h2>




<p>The PMCF plan is a living document that must be maintained and updated as clinical evidence evolves. A compliant plan includes:</p>





<p><strong>Background and device description:</strong> The device name, classification, intended purpose, and a summary of the clinical evidence available at the time of initial CE marking. This establishes the baseline against which PMCF findings will be compared.</p>





<p><strong>Objectives:</strong> Specific, measurable objectives for the PMCF program, tied directly to any residual risks or uncertainties identified in the clinical evaluation. Objectives such as &#8220;confirm device safety in the intended patient population over a 5-year period&#8221; are acceptable; objectives such as &#8220;collect clinical data&#8221; are not.</p>





<p><strong>Methods and rationale:</strong> The specific PMCF activities selected, the rationale for why these methods are appropriate for the device and its clinical context, and the expected data outputs from each activity. If literature review is chosen as the primary method, the search protocol must be described or referenced.</p>





<p><strong>Timeline:</strong> A schedule for each PMCF activity, including frequency of literature searches, registry data extraction intervals, and clinical investigation milestones where applicable.</p>





<p><strong>Data evaluation criteria:</strong> The criteria against which PMCF findings will be evaluated, including what would constitute a safety signal, a performance concern, or a trend requiring investigation.</p>





<p><strong>Reference to related documents:</strong> Cross-references to the clinical evaluation plan, the post-market surveillance plan, and the risk management file, confirming alignment across the technical documentation.</p>





<h2>The PMCF Evaluation Report</h2>




<p>The PMCF evaluation report summarizes the findings from all PMCF activities conducted during the reporting period. It must be reviewed and updated at intervals appropriate to the device&#8217;s risk class and the frequency of PMCF activities, and at a minimum whenever new clinical information becomes available that may affect the benefit-risk determination.</p>





<p>The evaluation report must draw explicit conclusions. Notified bodies have consistently cited PMCF evaluation reports that summarize data without drawing conclusions as non-conformances. The report must state whether the clinical data collected confirms the device&#8217;s safety and performance profile, whether any new risks or adverse events have been identified, and whether the benefit-risk determination established in the clinical evaluation remains valid.</p>





<p>Where PMCF findings identify new safety signals, performance concerns, or previously unrecognized risks, the evaluation report triggers updates to the clinical evaluation report, the risk management file, and potentially the instructions for use. Significant new safety information may also trigger vigilance reporting obligations under EU MDR Article 87.</p>





<h2>PMCF Timelines and Notified Body Expectations</h2>




<p>For Class III devices and implantables, the PSUR must be submitted to the notified body at least annually. The PMCF evaluation report feeds into this submission. For Class IIa and IIb devices, the PSUR cycle is at least every two years, though PMCF activity itself may occur more frequently.</p>





<p>Notified bodies examine PMCF documentation during surveillance audits and at each PSUR review. Common findings include:</p>





<ul>


<li>PMCF plans that are generic and not tailored to the specific residual risks of the device</li>




<li>Literature review protocols that are not documented or not reproducible</li>




<li>PMCF evaluation reports that repeat plan information rather than presenting actual findings</li>




<li>Failure to update the clinical evaluation report when PMCF findings provide new clinical evidence</li>




<li>PMCF plans that have not been updated after changes to the device or its indications</li>


</ul>





<p>Manufacturers who transitioned from MDD to EU MDR without substantively updating their PMCF programs often receive notified body observations requesting more rigorous PMCF activity, particularly for older devices that were approved on clinical data from the 1990s or early 2000s.</p>





<h2>Integrating PMCF Into Your Quality Management System</h2>




<p>PMCF does not operate in isolation. It is integrated into the QMS through the post-market surveillance system, the risk management process, and the clinical evaluation maintenance procedure. Effective integration means that PMCF findings automatically feed into risk management reviews, that new safety signals are automatically assessed for vigilance reporting obligations, and that the PMCF evaluation report update cycle is tracked as a controlled quality event.</p>





<p>The <a href="https://www.cloudtheapp.com/glossary-audit-trail/">audit trail</a> in your QMS should capture every update to the PMCF plan, every literature search conducted, every data extraction from a registry, and every version of the PMCF evaluation report. When a notified body auditor asks to see the history of PMCF activity for a specific device over the past three years, the audit trail should provide a complete, timestamped record without manual reconstruction.</p>





<p>Cloudtheapp&#8217;s platform supports the full post-market surveillance and PMCF workflow through more than 60 integrated applications covering post-market surveillance record management, complaint handling, <a href="https://www.cloudtheapp.com/glossary-adverse-events/">adverse events</a> tracking, <a href="https://www.cloudtheapp.com/glossary-deviation-capa/">deviation CAPA</a>, and document control. PMCF plans, evaluation reports, and related clinical documents can be managed as controlled documents with version history, review workflows, and electronic signatures, providing the traceability notified bodies require during technical documentation audits.</p>





<h2>Building a Sustainable PMCF Program</h2>




<p>The companies that manage PMCF most effectively treat it as a rolling, scheduled program rather than a document they produce reactively before a notified body audit. A sustainable program has several characteristics.</p>





<p>It assigns clear ownership. A named individual, typically in regulatory affairs or clinical affairs, owns the PMCF plan and evaluation report for each device and is responsible for executing the activities on schedule and updating the documentation when new evidence arises.</p>





<p>It uses a structured evidence calendar. Literature searches are conducted at documented intervals, typically semi-annually or annually depending on the device. Registry data extractions follow the same rhythm. Clinical investigation milestones are tracked against the project plan. Nothing happens reactively.</p>





<p>It connects PMCF findings to the rest of the technical documentation. When a PMCF evaluation report identifies a new adverse event type, the link to the risk management file is explicit and documented. When the benefit-risk determination is updated as a result of PMCF findings, the clinical evaluation report is formally revised and version-controlled.</p>





<p>It anticipates regulatory evolution. EU MDR continues to develop through MDCG guidance documents, and notified body interpretation of PMCF requirements has become more rigorous with each passing year. A PMCF program built in 2021 may not satisfy current notified body expectations without updates.</p>





<h2>Conclusion</h2>




<p>Post-Market Clinical Follow-Up is one of the most substantive post-market obligations under EU MDR, and one of the areas where companies most commonly fall short during technical documentation audits. The gap is rarely in intent: most manufacturers understand that PMCF is required. The gap is in execution: PMCF plans that are generic, evaluation reports that present data without conclusions, and programs that produce documents rather than clinical evidence.</p>





<p>A compliant PMCF program is built on specific objectives, documented methods, regular execution, and a clear connection to the risk management and clinical evaluation processes that PMCF exists to support. When it works well, PMCF is the mechanism by which manufacturers maintain regulatory confidence in their devices long after initial approval, and avoid the costly corrective actions that follow when post-market clinical signals are missed.</p>





<p>To explore how Cloudtheapp supports EU MDR post-market surveillance and PMCF management with an integrated, validated quality platform, <a href="https://www.cloudtheapp.com/demo/">request a demo</a>.</p>

]]&gt;</p>
<p>This post created by and appeared first on <a href="https://www.cloudtheapp.com">Cloudtheapp</a></p>
]]></content:encoded>
					
		
		
			</item>
		<item>
		<title>How to Set Up a Post-Market Surveillance Program Under EU MDR</title>
		<link>https://www.cloudtheapp.com/how-to-set-up-a-post-market-surveillance-program-under-eu-mdr/</link>
		
		<dc:creator><![CDATA[Cloudtheapp Inc.]]></dc:creator>
		<pubDate>Tue, 07 Jul 2026 00:05:13 +0000</pubDate>
				<category><![CDATA[General]]></category>
		<category><![CDATA[EU MDR]]></category>
		<category><![CDATA[Medical Device Regulation]]></category>
		<category><![CDATA[PMCF]]></category>
		<category><![CDATA[Post-Market Surveillance]]></category>
		<category><![CDATA[Regulatory Compliance]]></category>
		<guid isPermaLink="false">https://www.cloudtheapp.com/how-to-set-up-a-post-market-surveillance-program-under-eu-mdr/</guid>

					<description><![CDATA[<p>Post-market surveillance under EU MDR is not a reporting exercise you complete once and file away. Article 83 of Regulation (EU) 2017/745 requires manufacturers to run an active, continuous system for collecting and analyzing data on devices already in the market. For many companies that transitioned from the Medical Device Directive (MDD), the scope and [&#8230;]</p>
<p>This post created by and appeared first on <a href="https://www.cloudtheapp.com">Cloudtheapp</a></p>
]]></description>
										<content:encoded><![CDATA[<p><![CDATA[



<p>Post-market surveillance under EU MDR is not a reporting exercise you complete once and file away. Article 83 of Regulation (EU) 2017/745 requires manufacturers to run an active, continuous system for collecting and analyzing data on devices already in the market. For many companies that transitioned from the Medical Device Directive (MDD), the scope and depth of what MDR now demands came as a surprise.</p>









<p>This guide covers what a compliant PMS system looks like, what documents you need to produce for each device class, what data sources MDR expects you to use, and how to build a program that functions as a real quality system, not just paperwork.</p>









<h2>What EU MDR requires for post-market surveillance</h2>









<p>EU MDR Articles 83 through 86 form the legal framework for post-market surveillance. Each article covers a distinct element:</p>









<ul>




<li><strong>Article 83</strong> defines the manufacturer&#8217;s obligation to plan, establish, document, implement, maintain, and update a post-market surveillance system for each device</li>








<li><strong>Article 84</strong> specifies what a Post-Market Surveillance Plan (PMSP) must contain</li>








<li><strong>Article 85</strong> requires a Post-Market Surveillance Report (PMSR) for Class I devices</li>








<li><strong>Article 86</strong> requires a Periodic Safety Update Report (PSUR) for Class IIa, IIb, and III devices</li>




</ul>









<p>The European Commission&#8217;s Medical Device Coordination Group published MDCG 2025-10 guidance providing updated interpretation of these PMS requirements, reflecting findings from notified body audits across the EU. The guidance confirms that PMS must be a living, data-driven process, not a static document produced at certification time.</p>









<h2>PMS plan vs PMS report vs PSUR: what each document is</h2>









<p>Many quality teams conflate these documents. They serve different purposes and have different update frequencies.</p>









<h3>Post-Market Surveillance Plan (PMSP)</h3>









<p>The PMSP, required under Article 84, describes how you will collect and analyze post-market data for a specific device. It must cover:</p>









<ul>




<li>The proactive and reactive data collection methods you will use</li>








<li>Performance indicators and thresholds that would trigger action</li>








<li>Reference to applicable standards and guidance documents</li>








<li>Specific timelines for data collection and review activities</li>








<li>How findings will feed back into your <a href="https://www.cloudtheapp.com/glossary-risk-register/">risk register</a>, clinical evaluation, and technical documentation</li>




</ul>









<p>The PMSP is part of your technical documentation and must be device-specific. A single generic PMSP for all products does not satisfy MDR.</p>









<h3>Post-Market Surveillance Report (PMSR), Class I devices</h3>









<p>For Class I devices, Article 85 requires a PMSR that summarizes the results of your PMS activities, states whether corrective or preventive measures are needed, and confirms the benefit-risk determination remains favorable. There is no mandatory update frequency stated in Article 85, the PMSR is updated when significant changes occur or when new information from PMS activities warrants it. Notified bodies have generally interpreted &#8220;when needed&#8221; to mean at least every two to three years.</p>









<h3>Periodic Safety Update Report (PSUR), Class IIa, IIb, and III</h3>









<p>The PSUR under Article 86 has defined update requirements. Class IIa devices: PSUR updated at minimum every two years. Class IIb and III devices: PSUR updated annually. For Class III and implantable Class IIb devices, the PSUR is submitted to the notified body and assessed as part of the conformity assessment process.</p>









<p>The PSUR must include: a summary of PMS data, conclusions of benefit-risk analysis, a summary of any FSCA/field safety corrective actions taken, results of post-market clinical follow-up (PMCF) if applicable, and proposed corrective and preventive actions.</p>









<h2>Data sources your PMS system must use</h2>









<p>Article 83 MDR specifies that the PMS system must gather, record, and analyze relevant data from the post-production phase. Article 84(a) provides a list of data sources. Your PMSP should address each of these explicitly:</p>









<h3>Complaints and feedback</h3>









<p>Your complaint handling process feeds directly into PMS. Every complaint, whether from users, patients, healthcare professionals, or distributors, is post-market data. The PMS system should analyze complaint trends, not just individual incidents, to identify signals that may not be visible at the single-event level.</p>









<h3>Vigilance and serious incident reporting</h3>









<p>Serious incidents and field safety corrective actions (FSCAs) reported under MDR Article 87 are both inputs to your PMS system and outputs from it. If your PMS data analysis identifies a pattern that meets the serious incident threshold, that triggers the vigilance reporting obligation. The two systems are connected.</p>









<h3>Literature surveillance</h3>









<p>Article 84(d) requires manufacturers to monitor scientific and technical publications relevant to their device, including equivalent devices. This means a structured, documented literature search, not an informal awareness of publications. The MDCG 2020-6 guidance on clinical evaluation describes the search methodology in detail, and the same methodology applies to ongoing PMS literature review.</p>









<h3>Registries and real-world data</h3>









<p>For implantable devices and Class III devices, MDR expects manufacturers to draw on device registries where they exist. In practice, this means monitoring national registries in EU member states where your device is marketed, and documenting what that monitoring showed.</p>









<h3>Social media and user feedback</h3>









<p>MDCG 2022-21 confirms that social media monitoring can be a PMS data source, specifically for identifying safety concerns that do not reach you through formal complaint channels. This is not a major burden for most manufacturers, but it should be addressed in your PMSP.</p>









<h3>Distributor and importer reports</h3>









<p>If you have authorized representatives, importers, or distributors in the EU, they have obligations under Articles 13 and 14 MDR to pass information relevant to PMS back to you. Your quality agreement with these parties should specify what they are required to report and how frequently.</p>









<h2>Post-Market Clinical Follow-Up (PMCF)</h2>









<p>PMCF is a specific subset of PMS. It covers the ongoing collection of clinical data on a device already on the market, to confirm continued safety and performance, identify emerging risks, and monitor long-term outcomes.</p>









<p>PMCF is required for all Class III devices and implantable devices by default. For other classes, PMCF is required unless the manufacturer can justify why it is not necessary, and that justification must be documented in the PMCF evaluation report.</p>









<p>PMCF activities include device registries, post-market clinical studies, surveys of users and patients, and systematic literature review. The plan for PMCF goes into Annex XIV Part B of your technical documentation. Results feed into the PSUR and the clinical evaluation report.</p>









<h2>How PMS connects to your broader QMS</h2>









<p>PMS does not operate as a standalone activity. The outputs of your PMS system are inputs to multiple parts of your quality management system:</p>









<ul>




<li>Risk management, PMS data may reveal new hazards or change probability/severity estimates for known risks. Your <a href="https://www.cloudtheapp.com/glossary-risk-register/">risk register</a> should be updated when PMS findings warrant it.</li>








<li>Clinical evaluation, the PSUR feeds back into the clinical evaluation report. Changes in the benefit-risk assessment must be reflected in both documents.</li>








<li>CAPA, when PMS identifies a trend or signal requiring action, that action is processed through your <a href="https://www.cloudtheapp.com/glossary-deviation-capa/">CAPA</a> system.</li>








<li>Design control, significant PMS findings may indicate that design outputs need to be revisited. This can trigger a design change review under your <a href="https://www.cloudtheapp.com/glossary-process-change-notification/">change management</a> process.</li>








<li>Labeling and IFU, if PMS reveals that users are misusing the device in ways that could cause harm, labeling changes may be required.</li>




</ul>









<p>This interconnection is exactly why MDR requires the PMS system to be fully integrated with the quality management system, not managed by regulatory affairs as a separate workstream with no links to quality events or risk files.</p>









<h2>Common gaps notified bodies find during technical documentation review</h2>









<h3>Generic PMS plans not tailored to the device</h3>









<p>A PMS plan that applies identical data sources, indicators, and review timelines to a Class I bandage and a Class IIb active implant will not satisfy MDR. Notified bodies flag this repeatedly. The PMSP must reflect the specific risk profile, intended use, user population, and regulatory history of the device it covers.</p>









<h3>No defined action thresholds</h3>









<p>Article 84 requires the PMSP to specify performance indicators and threshold values. Many manufacturers describe data collection activities but never state what result would trigger a response. If you collect complaint data but never defined the rate at which complaints become a signal, your PMS system cannot generate actionable output.</p>









<h3>Literature searches that are too narrow</h3>









<p>MDCG guidance confirms that literature surveillance must cover equivalent devices, not just your own device. A search limited to your own product name will miss clinical evidence on comparable devices that may be relevant to your benefit-risk assessment.</p>









<h3>PMSR and PSUR not updated after significant events</h3>









<p>If a serious incident occurred, an FSCA was issued, or a complaint trend was identified and resolved, the PMSR/PSUR should reflect it. Documents that look unchanged from the original submission despite real-world events in the interim draw immediate scrutiny from notified bodies and national competent authorities.</p>









<h3>No documented connection between PMS and risk management</h3>









<p>Notified bodies look for evidence that PMS outputs actually influenced risk management decisions. If your PMS reports are produced and filed but never change anything in your risk file or CAPA system, auditors will question whether the system is active or purely procedural.</p>









<h2>Building the PMS system in your QMS</h2>









<p>The practical challenge for most manufacturers is that PMS data flows in from multiple sources, the complaint system, vigilance reports, literature searches, registry monitoring, distributor reports, and needs to be consolidated, trended, analyzed, and documented in a format that produces the PMSR or PSUR on a defined schedule.</p>









<p>Paper-based PMS systems fail at this. Data sits in separate folders for each source, trending requires manual compilation, and producing the PSUR involves weeks of document assembly. By the time the document is ready, the analysis is already outdated.</p>









<p>Cloudtheapp&#8217;s <a href="https://www.cloudtheapp.com/glossary-supplier-quality-management-sqm/">quality management</a> platform connects complaint handling, <a href="https://www.cloudtheapp.com/glossary-deviation-capa/">CAPA</a>, <a href="https://www.cloudtheapp.com/glossary-adverse-events/">adverse event</a> tracking, and risk management in a single system. PMS data collected through complaints, deviations, and adverse event records feeds automatically into dashboards that support PMSR and PSUR preparation. When a CAPA is opened in response to a PMS finding, it is linked to the originating PMS record, giving you the audit trail MDR requires showing that findings drove action.</p>









<p>Want to see how Cloudtheapp handles post-market surveillance documentation for Class IIa, IIb, and III devices? <a href="https://www.cloudtheapp.com/demo/">Book a demo</a> to walk through the system with a specialist.</p>









<h2>Notified body and competent authority access to PMS data</h2>









<p>Under MDR Article 83(4), national competent authorities have the right to request access to post-market surveillance data. For Class IIb and III devices, the PSUR is submitted to your notified body and subject to formal assessment. This means your PMS records need to be retrievable, coherent, and complete, not reconstructed when a request arrives.</p>









<p>The EUDAMED database, as it reaches full functionality, will include modules for vigilance and post-market surveillance data. Manufacturers are expected to upload incident reports and summaries of safety and clinical performance (SSCPs) for implantable and Class III devices directly to EUDAMED. The timeline for full EUDAMED go-live has shifted several times; confirm current requirements with your notified body.</p>









<h2>Summary</h2>









<p>A compliant EU MDR post-market surveillance program has five elements that all need to work together: a device-specific PMSP with defined data sources and action thresholds, active data collection from complaints, vigilance, literature, registries, and distributor networks, a systematic analysis process that produces trend data and signals, PMSR or PSUR documentation produced on the correct schedule, and documented connections between PMS outputs and risk management, CAPA, and design changes.</p>









<p>The companies that struggle with MDR PMS compliance are generally those that treat it as a documentation obligation rather than a quality function. The regulation is designed for manufacturers that actually use post-market data to improve their devices. Build the system around that intent, and the documentation follows naturally.</p>









<p>Cloudtheapp&#8217;s 60+ quality and compliance applications cover complaint management, CAPA, adverse events, and risk management, all of the functions that feed your PMS system. <a href="https://www.cloudtheapp.com/demo/">Schedule a demo</a> to see how it all connects.</p>



]]&gt;</p>
<p>This post created by and appeared first on <a href="https://www.cloudtheapp.com">Cloudtheapp</a></p>
]]></content:encoded>
					
		
		
			</item>
		<item>
		<title>EU MDR Post-Market Surveillance: A Complete Compliance Guide</title>
		<link>https://www.cloudtheapp.com/eu-mdr-post-market-surveillance-a-complete-compliance-guide/</link>
		
		<dc:creator><![CDATA[Cloudtheapp Inc.]]></dc:creator>
		<pubDate>Mon, 01 Jun 2026 00:00:02 +0000</pubDate>
				<category><![CDATA[General]]></category>
		<category><![CDATA[EU MDR]]></category>
		<category><![CDATA[ISO 13485]]></category>
		<category><![CDATA[Medical Device]]></category>
		<category><![CDATA[Medical Device Regulation]]></category>
		<category><![CDATA[PMCF]]></category>
		<category><![CDATA[PMS Compliance]]></category>
		<category><![CDATA[Post-Market Surveillance]]></category>
		<category><![CDATA[PSUR]]></category>
		<guid isPermaLink="false">https://www.cloudtheapp.com/eu-mdr-post-market-surveillance-a-complete-compliance-guide/</guid>

					<description><![CDATA[<p>TLDR EU MDR Regulation (EU) 2017/745 transformed post-market surveillance from a passive reporting activity into an active, data-driven lifecycle obligation. Articles 83 through 86 define a mandatory system structure: a documented PMS system, a device-specific PMS plan, periodic PMS reports for Class I devices, and Periodic Safety Update Reports (PSURs) for Class IIa through III [&#8230;]</p>
<p>This post created by and appeared first on <a href="https://www.cloudtheapp.com">Cloudtheapp</a></p>
]]></description>
										<content:encoded><![CDATA[<h2>TLDR</h2>
<p>EU MDR Regulation (EU) 2017/745 transformed post-market surveillance from a passive reporting activity into an active, data-driven lifecycle obligation. Articles 83 through 86 define a mandatory system structure: a documented PMS system, a device-specific PMS plan, periodic PMS reports for Class I devices, and Periodic Safety Update Reports (PSURs) for Class IIa through III devices. The December 2025 MDCG 2025-10 guidance provides the most detailed official interpretation of these obligations to date, clarifying how to build, operate, and integrate a compliant PMS system within your QMS. This guide covers everything manufacturers need to know.</p>
<h2>What Is Post-Market Surveillance Under EU MDR?</h2>
<p>Post-market surveillance is the ongoing, proactive process of collecting and analyzing real-world performance data from medical devices once they are placed on the EU market. Under EU MDR (Regulation 2017/745/EU), PMS is not a reactive complaint-handling function. It is a systematic, proactive process integrated into the manufacturer&#39;s Quality Management System to continuously verify that devices remain safe, perform as intended, and meet general safety and performance requirements throughout their entire market lifetime.</p>
<p>Article 10(10) of the MDR mandates that every manufacturer establish, document, implement, maintain, update, and improve a PMS system appropriate to the risk class and type of device. This obligation applies regardless of device class, from Class I to Class III.</p>
<p>The critical shift from the predecessor Medical Device Directive (MDD) is one of intent. Under the MDD, PMS was often treated as a periodic reporting exercise. Under MDR, it is a living system that feeds back into clinical evaluation, risk management, design control, and technical documentation updates continuously.</p>
<h2>Why EU MDR Raised the PMS Bar</h2>
<p>The increased PMS rigor under MDR was a direct response to real-world device safety failures. The PIP breast implant scandal, metal-on-metal hip replacement complications, and surgical mesh problems all revealed a systemic failure: devices with deteriorating real-world performance stayed on the market too long because post-market data was not systematically collected, analyzed, or escalated to corrective action.</p>
<p>MDR&#39;s response was structural. Under the regulation:</p>
<ul>
<li>PMS plans are device-specific, not general system documents</li>
<li>Notified Bodies have expanded oversight access to PMS reports and PSURs during surveillance audits</li>
<li>PSUR update frequencies are defined by risk class with firm deadlines</li>
<li>Post-Market Clinical Follow-Up (PMCF) is required for most devices unless explicitly justified otherwise</li>
<li>Proactive data gathering from multiple defined sources is mandatory</li>
</ul>
<p>Manufacturers who build rigorous PMS systems gain a measurable advantage in Notified Body interactions and demonstrate the kind of proactive safety governance that regulators now explicitly expect.</p>
<h2>The 4 Core PMS Articles: 83 Through 86</h2>
<h3>Article 83: The PMS System</h3>
<p>Article 83 defines the foundational requirement: every manufacturer must establish, document, implement, maintain, and continuously improve a PMS system. This system must actively gather post-market data from defined sources, analyze it for safety signals and performance trends, and feed findings back into risk management, clinical evaluation, and QMS processes.</p>
<p>The PMS system is not a document. It is a connected operational process that links complaint handling, vigilance reporting, PMCF, field safety corrective actions, and CAPA into a coherent feedback loop.</p>
<h3>Article 84: The PMS Plan</h3>
<p>Article 84 requires a documented PMS plan for each device, specifying:</p>
<ul>
<li>What data will be gathered and from which specific sources</li>
<li>The methods and processes for data collection, storage, and analysis</li>
<li>Defined threshold criteria that trigger CAPA or field safety corrective action</li>
<li>Explicit reference to the clinical evaluation and risk management processes that PMS data feeds into</li>
</ul>
<p>The PMS plan is a living document. When PMS data generates new risk insights, the plan updates accordingly. Notified Bodies review PMS plans during initial certification <a href="https://www.cloudtheapp.com/glossary-audits/">audits</a> and at every surveillance audit, making plan quality a direct factor in certification outcomes.</p>
<h3>Article 85: The PMS Report (PMSR)</h3>
<p>Article 85 applies to Class I devices. Manufacturers must document PMS findings in a Post-Market Surveillance Report that summarizes results, analyzes conformity with general safety and performance requirements, presents a benefit-risk determination, and records any CAPA taken. The PMSR must be updated when PMS activities generate new relevant findings and must be available to competent authorities upon request.</p>
<h3>Article 86: The Periodic Safety Update Report (PSUR)</h3>
<p>Article 86 applies to Class IIa, IIb, and III devices and represents the most rigorous PMS reporting obligation under MDR.</p>
<p>PSURs must be updated at the following minimum frequencies:</p>
<ul>
<li><strong>Class IIa:</strong> At least every 2 years</li>
<li><strong>Class IIb and III:</strong> At least annually</li>
</ul>
<p>Each PSUR must include: the conclusions of the benefit-risk determination, main findings from PMCF, volume of sales and estimated population using the device, and a complete summary of PMS data analyzed with rationale for any corrective or preventive actions taken.</p>
<p>Class IIb and III PSURs must be submitted to the Notified Body. Class IIa PSURs must be available to the Notified Body on request. Both are reviewed during Notified Body surveillance activities.</p>
<h2>What Data Sources Feed a PMS System?</h2>
<p>A compliant PMS system draws from a defined, broad set of data sources. MDCG 2025-10 provides detailed guidance on the minimum expected inputs:</p>
<p><strong>Reactive data sources:</strong></p>
<ul>
<li>Customer complaints and device user feedback</li>
<li>Vigilance reports from competent authorities</li>
<li>Post-market <a href="https://www.cloudtheapp.com/glossary-adverse-events/">adverse events</a> reported by users, patients, or healthcare institutions</li>
<li>Field safety corrective action (FSCA) data from similar devices on the market</li>
</ul>
<p><strong>Proactive data sources:</strong></p>
<ul>
<li>Systematic literature searches covering the device type, equivalent devices, and relevant clinical areas</li>
<li>PMCF studies, device registries, and structured patient or user surveys</li>
<li>Market surveillance data from competent authorities and Notified Bodies</li>
<li>Analysis of returned, repaired, or scrapped devices</li>
<li>Feedback networks from distributors and healthcare providers</li>
</ul>
<p>Every data source must be described in the PMS plan, including search methodology, frequency, responsible person, and the process by which findings are assessed against defined threshold criteria.</p>
<h2>Post-Market Clinical Follow-Up (PMCF)</h2>
<p>PMCF is a subset of PMS activities focused specifically on post-market clinical data collection. Under EU MDR Annex XIV Part B, PMCF is required unless the manufacturer explicitly justifies why it is not applicable to a specific device.</p>
<p>PMCF activities include:</p>
<ul>
<li>Prospective clinical investigations using the device in its intended patient population</li>
<li>Clinically relevant data from literature reviews, device registries, or structured user surveys</li>
<li>Structured feedback programs with healthcare institutions using the device</li>
</ul>
<p>PMCF findings must feed directly into the clinical evaluation and Clinical Evaluation Report (CER), the technical documentation, and the risk management file. MDCG 2025-10 reinforces this closed-loop requirement: PMCF is not a standalone project but a continuous input into the full technical documentation ecosystem that sustains the device&#39;s CE marking.</p>
<h2>Vigilance: Serious Incidents and FSCAs</h2>
<p>Vigilance reporting under EU MDR (Articles 87-90) operates in parallel with PMS but responds to specific triggering events. Manufacturers must report to the competent authority of the relevant Member State:</p>
<ul>
<li><strong>Serious incidents</strong> (events that led or could lead to patient death, serious deterioration in health, or serious public health threat): within 15 days of becoming aware</li>
<li><strong>Field Safety Corrective Actions (FSCAs):</strong> reported through a Field Safety Notice (FSN) before implementation wherever possible</li>
</ul>
<p>An <a href="https://www.cloudtheapp.com/glossary-adverse-event-investigation/">adverse event investigation</a> that identifies a device-related root cause must trigger both a vigilance report and a CAPA. MDCG 2025-10 makes clear that the PMS system must define explicit processes for identifying potential serious incidents within complaint and feedback data streams, with documented escalation criteria and named responsible persons.</p>
<p>Vigilance data is also a required input into the PSUR. Unreported or delayed incidents create gaps not only in vigilance compliance but in the accuracy of the periodic safety update analysis itself.</p>
<h2>MDCG 2025-10: What the December 2025 Guidance Adds</h2>
<p>The Medical Device Coordination Group published MDCG 2025-10 in December 2025, providing the most comprehensive official interpretation of EU MDR PMS requirements to date. Key guidance elements that manufacturers must address:</p>
<ul>
<li><strong>QMS integration:</strong> MDCG 2025-10 reinforces that PMS must be embedded within and connected to the full QMS, with defined interfaces to <a href="https://www.cloudtheapp.com/glossary-risk-register/">risk register</a> processes, clinical evaluation, CAPA, and technical documentation. Standalone PMS binders do not meet MDR intent.</li>
<li><strong>Active, not reactive, surveillance:</strong> Guidance emphasizes that waiting for complaints to arrive does not satisfy the MDR&#39;s proactivity requirement. Manufacturers must design systems that actively seek real-world performance data.</li>
<li><strong>Quantified thresholds and triggers:</strong> MDCG 2025-10 expects manufacturers to define quantitative or qualitative threshold criteria that trigger CAPA or FSCA initiation when breached. Vague assessment language is not sufficient.</li>
<li><strong>IVD applicability:</strong> The guidance covers both MDR (2017/745) and IVDR (2017/746), applying the same PMS framework to in vitro diagnostic devices.</li>
<li><strong>Proportionality:</strong> PMS plans, reports, and PMCF scope should be proportionate to the device&#39;s risk class, intended population, and complexity of clinical use.</li>
</ul>
<p>Manufacturers who have not yet reviewed and updated their PMS plans in light of MDCG 2025-10 face potential major findings at their next Notified Body surveillance audit.</p>
<h2>Integrating PMS Into Your QMS</h2>
<p>A PMS system that operates in isolation produces compliance artifacts but not compliance outcomes. True MDR conformity requires PMS to function as a connected element within the full QMS.</p>
<p>PMS findings must have documented pathways to:</p>
<ul>
<li><strong>Risk management:</strong> New safety signals and threshold breaches update the risk file and the benefit-risk determination in the CER</li>
<li><strong>Clinical evaluation:</strong> PMCF data and real-world evidence feed into the CER on the cadence defined in the PMS plan</li>
<li><strong>CAPA:</strong> Identified trends or threshold breaches initiate formal <a href="https://www.cloudtheapp.com/glossary-root-cause-investigation/">root cause investigations</a> and <a href="https://www.cloudtheapp.com/glossary-deviation-capa/">deviation CAPAs</a> with defined timelines</li>
<li><strong>Technical documentation:</strong> Updated risk files and clinical evaluations require corresponding updates to the technical documentation supporting CE marking</li>
<li><strong>Management review:</strong> PMS trend data and PSUR conclusions should appear as standing agenda items</li>
</ul>
<p>Managing these connections across disconnected spreadsheets, email threads, and shared drives creates version control failures, traceability gaps, and missed escalation windows. An integrated QMS platform that connects PMS data to CAPA, clinical evaluation, risk management, and document control removes these gaps structurally.</p>
<h2>How Cloudtheapp Supports EU MDR PMS Compliance</h2>
<p>Building a compliant EU MDR PMS system on manual tools is both time-consuming and structurally fragile. Cloudtheapp&#39;s AI-powered QMS platform provides medical device manufacturers with an integrated environment for every PMS obligation:</p>
<ul>
<li>Complaint and adverse event capture linked directly to PMS analysis workflows and threshold monitoring</li>
<li>PMCF data collection modules connected to clinical evaluation and CER management records</li>
<li>CAPA initiation triggered automatically from PMS threshold breaches with full traceability</li>
<li>PSUR and PMSR report generation with audit-ready traceability back to underlying PMS data</li>
<li>Risk management integration: PMS findings update risk assessments in real time</li>
<li>Management review dashboards surfacing PMS trends alongside CAPA performance and audit results</li>
</ul>
<p>Because Cloudtheapp is validated per FDA QMSR, ISO 13485:2016, and ISO 9001, every PMS record generated in the platform meets both EU MDR and global QMS standards. Manufacturers operating in EU and US markets maintain a single compliant record set rather than parallel systems.</p>
<p>Ready to build a PMS system that holds up under MDCG 2025-10 and Notified Body scrutiny? <a href="https://www.cloudtheapp.com/demo/">Request a demo</a> to see how Cloudtheapp connects every EU MDR PMS obligation end to end.</p>
<h2>Conclusion</h2>
<p>EU MDR post-market surveillance is a mandatory, proactive, and deeply interconnected compliance obligation. Articles 83 through 86 define the structural requirements. MDCG 2025-10 clarifies what &quot;good&quot; looks like in practice. And an integrated QMS is the only architecture that sustains these requirements without creating unsustainable manual overhead.</p>
<p>Manufacturers who treat PMS as a living system rather than a periodic reporting task produce better safety outcomes, pass Notified Body scrutiny more consistently, and build the real-world evidence base that the next generation of clinical evaluation demands.</p>
<p>This post created by and appeared first on <a href="https://www.cloudtheapp.com">Cloudtheapp</a></p>
]]></content:encoded>
					
		
		
			</item>
	</channel>
</rss>
