Techical Document
To sell medical devices in the EU under MDR 2017/745, manufacturers must provide thorough clinical evaluations and documentation. This clinical evaluation for medical devices must remain proportionate to the device's risk and intended purpose. This post breaks down the compliance process and shows you exactly how to meet these regulatory standards.
Clinical Evaluation For Medical Devices: Clinical Documentation Requirements For Regulatory Compliance
When you look at clinical evaluation you have to run through five core actions all the time. First you need to plan and keep updating your clinical evaluation plan then you do a systematic scientific literature review to find your clinical data and see where your evidence has gaps. After that you appraise the data to make sure it actually proves safety and performance and if you still have gaps you have to run proper clinical investigations to get new data. Finally you analyze everything to get your conclusions on safety and clinical benefits. The whole thing has to be totally objective including both good and bad data and it needs to match the risk and classification of your device.
Mandatory Elements Of The Clinical Evaluation Plan
The clinical evaluation plan (CEP) is your basic roadmap and it needs specific things so the regulators accept it. You have to know exactly which general safety and performance requirements need clinical data support and clearly state the device purpose target groups indications and contraindications. You also need to describe the actual clinical benefits for patients with specific outcome parameters and write down the qualitative and quantitative methods you use to check safety risks and side effects. Manufacturers must list parameters based on the state of the art to show the benefit risk ratio is acceptable, address things like tissues or pharmaceuticals if you use them and map out your development plan from early studies all the way to post market clinical follow up.
Technical Criteria For Demonstrating Equivalence
If you decide to use clinical data from an existing device to prove equivalence you have to justify it across three categories so there is no clinically significant difference in safety and performance. For technical equivalence you need similar design conditions of use specifications like tensile strength energy intensity viscosity wavelength or software algorithms plus similar deployment methods and operation principles. For biological equivalence you must use the exact same materials or substances touching the same tissues or fluids with similar contact duration and release or degradation characteristics. For clinical equivalence the devices must be for the same clinical condition severity and stage of disease at the same body site in a similar population and used by the same type of user to get a similar effect. Also you have to prove you actually have sufficient access to the equivalent device data to back up your claim.
Clinical Evaluation For Medical Devices: Clinical Evaluation Report, Documentation Integration And Technical File Maintenance
You have to compile all your results and clinical evidence into a formal clinical evaluation report to support your conformity assessment. This clinical evidence and your non clinical testing data must be fully integrated into your main technical documentation to show total GSPR conformity. It is a strict rule that you must include both favorable and unfavorable data inside these files. The clinical evaluation report should remain linked to the supporting evidence and risk documentation.
Post Market Clinical Follow Up Execution
Post market clinical follow up (PMCF) is a continuous proactive process that you have to include in your post market surveillance plan to keep updating your clinical evaluation. You are required to actively collect and evaluate clinical data from real human use of your CE marked device to confirm safety over its lifetime, monitor side effects, spot new risks and check that the benefit risk ratio stays acceptable. You must follow a documented PMCF plan that details general methods like user feedback and literature screening and specific methods like registers or PMCF studies. You have to give a technical justification for your methods, cross reference your CER and risk files, evaluate equivalent devices and give a justified detailed schedule for data analysis and reporting. The results go into a PMCF evaluation report that feeds straight back into your CER and risk management and you are mandated to fix any issues with corrective actions immediately.
Clinical Evidence For Medical Device Software
For medical device software you have to specify and justify your clinical evidence level based on the software characteristics and purpose and manage it as a continuous QMS process across its lifecycle. Your compliance relies on three main pillars:
Valid clinical association: You must prove your software outputs are legitimately linked to the targeted clinical condition using technical standards guidelines literature or real world data.
Technical performance: You must validate that the software reliably and consistently generates the right technical output in real world environments covering availability confidentiality integrity precision sensitivity limits of detection specificity linearity cut off values generalizability cybersecurity and usability.
Clinical performance: You have to show the software gives clinically relevant outputs for your target population and users using metrics like diagnostic sensitivity specificity predictive values likelihood ratios odds ratios confidence intervals number needed to treat and number needed to harm. You have to evaluate this at every single new software release and if you skip it you must record an explicit justification in your technical file.
Software Study Design Mandates And Exceptions
Your software study design depends on risk and operational models so Class III and implantable devices need data from a formal clinical investigation unless you meet specific exemption rules. Under IVDR you need software performance studies for all device classes unless you can heavily justify using other data sources. You absolutely must use prospective studies if your software determines a patient's future state like a prognosis or prediction or if the output directly drives clinical outcomes or patient management decisions. Retrospective studies are only allowed if there is zero impact on patient management and no risk to the patient.
Conformity without clinical data: If you claim clinical data is totally inappropriate you must explicitly prove in your technical documentation how non clinical methods like bench testing verification and usability are enough. This exception must come straight from your risk management process, evaluate the clinical state of the art, look at alternative options in literature and assess specific device body interactions but you still have to put this whole justification inside a formal CER or performance evaluation report.
Data sufficiency and real world performance: When reviewing evidence you have to clear explicit checklists. Your data amount must cover all indications risks and software characteristics like algorithms and inputs while factoring in how innovative the software is. Your data quality must ensure statistically appropriate designs, current validation datasets, valid statistical approaches and regulatory compliance. Plus you have to actively use real world performance data through PMS and post market clinical follow up (PMCF) loops to catch malfunctions, spot user misuse, understand usability and track clinical performance against your original clinical development plan.
How Morulaa Can Help: Medical Device Regulatory Consulting Services
Through its medical device regulatory consulting services, Morulaa HealthTech manages your regulatory shift from CDSCO compliance to EU MDR 2017/745 standards. We write and update technical documentation to align with Notified Body requirements and avoid non-conformities (NCs). These medical device regulatory consulting services support clinical evaluation for medical devices and help keep clinical records aligned with Notified Body expectations.
What We Do
Our medical device regulatory consulting services include:
Clinical Evaluation Plan (CEP): Define the device lifecycle roadmap, clinical endpoints, and State of the Art (SOTA) benchmarks.
Systematic Literature Review: Search, filter, and appraise scientific data using PRISMA standards.
Frequently Asked Questions
Can you skip clinical data if you have good bench testing and non clinical data?
Generally no unless you qualify for a specific exception where clinical data is completely inappropriate. This exception must come straight from your risk management process to evaluate the clinical state of the art and device body interactions. If you do this you still have to put this whole non clinical justification inside a formal clinical evaluation report.
Do you need an independent clinical evaluation if your software drives or influences a hardware device?
If the software has an independent medical purpose and clinical benefits it needs its own independent clinical evidence. If it drives or influences a medical device for a medical purpose your evaluation scope must cover both the software and the device. But if it has no independent medical purpose or benefit of its own you just evaluate it as a component within the parent hardware context.
What specific data barriers do you face when trying to establish equivalence to a competitor device?
Besides proving technical biological and clinical criteria are completely similar you face a big data access barrier. You must clearly demonstrate you have sufficient levels of access to the data of the equivalent devices. This access is mandatory to legally and scientifically justify your equivalence claims inside your technical documentation.
Are retrospective clinical studies enough for registering predictive or prognostic software?
No retrospective studies alone are not enough if your software determines a patient's future state like a prognosis or prediction. Prospective studies are strictly required if the software output directly drives clinical outcomes or patient management decisions. You can only use retrospective studies if there is zero impact on active patient management and no risk to patients.
Do you need to perform a new clinical validation every time you update your software?
Yes you have to evaluate clinical performance at every single change of the software to a new release. If you choose to skip this you must formally record an explicit technical justification straight inside your technical documentation. If your software uses a modular design you can run validation at the individual module level as long as they are completely independent.