Which Data Should We Collect In Our Post-Market Surveillance?

Question

We are an established manufacturer of a class IIb medical device software. Our software is a mobile app intended to analyze a user’s heartbeat, detect abnormalities and inform a physician. The notified body wants us to come up with a PMS plan and report and we need to collect data. How do we do that and when?

Short Answer

Read my ultimate guidance on PMS and my article about trend analysis.

Long Answer

Let’s start with the regulatory background. I know it’s boring, but helpful to keep an overview on the relevant MDR references.

The post-market surveillance requirements are described in Articles 83 through 87, and Annex III of the MDR. Other important documents include:

  • MDCG 2019-9 SSCP A guide for manufacturers and notified bodies  
  • MDCG 2022-21 PSUR Template and concepts
  • MDCG 2023-3 Vigilance terms and concepts
  • ISO/TR 20416 Medical devices: Post-market surveillance for manufacturers

Consider the  ISO/TR 20416 as your personal PMS bible and I recommend reading the guidelines first. In a nutshell, you need to set up an SOP according to Annex III of the MDR, a PMS plan for each of your devices, do stuff and write a report about that. Let’s walk through it, step by step.

Step 1 Collect data according to the PMS plan

In your case, it is one software, so you need one PMS plan and one Periodic Safety Update Report (PSUR) because your software is risk class IIb. In case of a Class IIb SaMD, you need to summarize your PMS activities annually (check out the overview in our ultimate PMS guide).  Suitable PMS activities are:

  • Collection of serious and non-serious incidents
    • Summarize what went wrong in the last year (e.g. your app crashed) and what went terribly wrong (e.g. a patient was hurt by a misdiagnosis based on your SaMD). 
  • Pro-actively gathered feedback
    • That means, you summarize feedback about your software from sales calls or when visit a conference. Keep it brief and focus only on safety relevant feedback!
  • Trending
    • The MDR wants you to check if there is a safety issue arising among the non-serious incidents. According to Article 88 you need to identify trends and of course they don’t tell you how. We published a separate blog post on this topic. Spoiler: No statistician needed 😛
  • Soup Incidents
    • Check your device SOUP list and research incident reports from the last 12 months. Done.
  • Registries and databases
    • Broad terms. You need to update the literature search of your Clinical Evaluation Report. Address the search strategy (PubMed, time frame, literature search protocol) here briefly. Alternatively, you can place this task in the PMCF plan (see below).
  • Similar devices
    • You are not alone on this planet, and the likelihood is that there is no other software with a similar purpose. Analyse the market and identify similar devices, search them in relevant safety databases (BfArm, FDA Maude etc.) and summarize the results. That means you need to cross-check if the described risks are already considered in your risk assessment.
  • Technical, specialist and regulatory information
    • Once per year, you scroll through the list of applicable standards, guidances and common specifications and look for updates. If there is an update, evaluate the changes and document it.

Step 2 PMCF activities

You can include the post-market clinical follow-up (PMCF) activities in the PMS plan, or you create a separate one (Annex III, 1b). I personally prefer to keep the plans separate, because the results of your activities will end up in separate reports: the PSUR and the CER. Anyhow, you will not be able to circumvent this step. The regulatory background information is provided in Annex XIV of the MDR (together with the clinical evaluation). 

You need to actively gather information on your device from the field. That means you can:

  • Update the literature
    • Sounds rather passive. You need to update your CER and the literature search on clinical performance and safety of your device. Maybe a research group used your software and wrote a publication about it. Great, include this in your CER.
  • Conduct a survey
    • Ask your users for feedback. In your specific case you have two users: the patient and the physician. Create two separate questionnaires, focussing on the usability, the safety and performance of your device. You can reach out to them via your app directly. I recommend reading the ISO/TR 20416 for more information and reaching out to your marketing manager, he probably knows how to set up a good customer survey.
  • PMCF study
    • Premium class information. Conduct a systematic clinical study with your device. The aim is to confirm your clinical claims, the benefits and clinical performance of the software. The MDCG published several guidelines on clinical investigations.

Step 3 Write reports and update the risk management as well as the clinical evaluation

The PMS activities described in step 1 will be summarized in the Periodic Safety Update Report (PSUR). Use our PSUR template and read the MDCG 2022-21 for more background information. You will update this report with a summary of your annual PMS activities. Make sure that newly identified risks will be entered into your risk assessment. Evaluate the influence on the risk-benefit evaluation. 

In parallel, you need to summarize the PMCF activities (survey, literature review and/or PMCF study) in the PMCF evaluation report. This report is basically the missing link to update the clinical evaluation. I recommend including the results in the CER directly and not setting up a separate report, it will only cause unnecessary extra work and confusion. You can add additional chapters to summarize the survey and reference the original data. 

Summary

First, read the MDR, the guidelines and get a copy of the ISO/TR 20416.

Second, identify gaps in your risk management and in the clinical evaluation. Is there a “blind spot” in your data set that you would like to investigate? Do you need more information on a specific risk-probability? Are you aware of any unintended misuse of your software? Third, summarize the activities in separate reports, link them and align the surveillance periods of both PMS and PMCF. 

On a slighty different note: You want to get your medical software certified under MDR but don’t know where to start? No worries! That’s why we built the Wizard. It’s a self-guided video course which helps you create your documentation yourself. No prior knowledge required. You should check it out.

Or, if you’re looking for the most awesome (in our opinion) eQMS software to manage your documentation, look no further. We’ve built Formwork, and it even has a free version!

If you’re looking for human help, did you know that we also provide consulting? We’re a small company, so we can’t take on everyone – but maybe we have time for your project? We guide startups from start to finish in their medical device compliance.

Comments

Leave the first comment