Early access registrations are open for Headstart, a predictable, fixed-price program for becoming compliant.

February 14, 2021

Template: Clinical Evaluation Report

Dr. Oliver Eidel
Clinical Evaluation

This is a free template, provided by OpenRegulatory.

A preview of the template is shown below. You can download it as Word (.docx), PDF or markdown file.

The template license applies (don't remove the copyright at the bottom).

Download as:
Beginning of template

Clinical Evaluation Report

The Clinical Evaluation Report states the clinical benefits and safety characteristics of the device, based on clinical data. It is the output of the Clinical Evaluation Plan.

While the content of the Clinical Evaluation is simple, writing it, coming up with the right structure and forming a sensible line of reasoning (equivalence) can be a bit tricky.

These are the guidance documents on Clinical Evaluation. If you’re the person writing it, you should read them:

  • MDCG 2020-1, 2020-5, 2020-6
  • MDCG 2020-13: Quite helpful as it gives you an idea of the structure.
  • MEDDEV 2.7.1 rev. 4. (mostly for MDD, but still a good starting point; especially the list of proposed headings for a report at the end of the document).


1. Relevant Documents

2. Scope of the Clinical Evaluation

Note: This section is copy-pasted from the Clinical Evaluation Plan.

2.1 Device Description

Copy-paste your Device Description (which includes the Intended Use) here. If it’s not done yet, remember to do it later :)

2.2 Clinical Benefits, Outcome Parameters

Describe the clinical benefits you expect from your product. Define how you’ll measure those (outcome parameters). You’ll probably be planning to do a literature search to prove them - as you know the literature, it makes sense to select outcome parameters which were already established in prior studies.

2.3 Clinical Safety, Methods for Analysis

Describe your safety parameters, i.e. which things should you product fulfil so that you consider it safe? And your methods, i.e. how will you prove that your product fulfils those safety parameters? A method could be literature search for past studies, but you could additionally do a Post-Market Clinical Follow-Up to double-check whether that’s actually true for your device.

2.4 Acceptability of Benefit-Risk-Ratio

After you’ve defined your benefits and safety parameters, which combination of those is acceptable to you? In the case of most software devices (and apps), you’ll probably have subtle benefits (e.g. better disease management, early detection of relapses) while low safety concerns (e.g. disease progression unlikely, not killing anyone).

3. Clinical Background, Current Knowledge, State of the Art

3.1 Clinical Background & Current Knowledge

Describe the clinical context of the disease you’re treating: How are patients currently treated? Which symptoms do they have, which diagnostic modalities are being used to establish a diagnosis, which treatment options exists? What are the benefits and drawbacks of current treatment options?

3.2 State of the Art incl. Alternative Treatments

Given the current treatment options, what is the preferred, “state of the art” treatment? What are its benefits and drawbacks? Are there recent scientific achievements (studies, new technologies, software) which may be promising to improve this state-of-the-art treatment? Also, what are alternative treatments?

4. Type of Evaluation

Note: This section is copy-pasted from the Clinical Evaluation Plan.

5. Equivalence

5.1 Equivalent Device

Describe the equivalent device you’re comparing yourself to, mainly its Intended Use.

5.2 Demonstration of Equivalence (Technical, Biological, Clinical)

Here you have to demonstrate that your device is equivalent to the Equivalent Device. You accomplish that by creating a table in which you list certain characteristics, and describe those characteristics both for the Equivalent Device and for your device. The idea is that your device is mostly the same in most characteristics.

The tables are split into general stuff (first table), then Clinical, Technical and Biological equivalence as per the guidance documents. I pre-filled some of the table rows for you as they should be universal, e.g. Intended Use, Medical Indication(s) and Programming Language. But definitely feel free to add additional rows which are useful for comparing your device to the equivalent one. Maybe you’re using recurrent neural networks and the equivalent device is, too? Then add that.

  Equivalent Device This Device
Intended Use    
Medical Indication(s)    
Device Classification    
Principle of Operation Stand-alone Software Stand-alone Software

Clinical Equivalence

Note: The MDR doesn’t explicitly state that the device needs to be used for the same medical indication, gender and duration of use. But it should be used for the same clinical condition or purpose including similar severity and stage of disease.

  Equivalent Device This Device
Clinical Condition    
Disease Stage    
Site in Body    
User: Age, Anatomy, Physiology    
Clinical Effect    
Duration of Use    

Technical Equivalence

  Equivalent Device This Device
Software Algorithm    
Programming Language    
Graphical User Interface (GUI)    
Web-based Application    

Biological Equivalence

Biological equivalence doesn’t apply to software. I added a sentence below which describes that.

Not applicable. The device doesn’t come in contact with human tissue or body fluids.

5.1 Literature Search Methods

Copy-paste from Clinical Evaluation Plan.

5.2 Literature Appraisal Criteria

Copy-paste from Clinical Evaluation Plan.

5.3 Literature Search Protocol

A table which lists your actual literature search results. For each entry, you should decide whether it’s acceptable (based on your appraisal criteria) or not. I pre-wrote some tables to give you an idea of the structure below. You could separate the tables based on the database where you did the search (PubMed, Google Scholar).

Here are some bullet points from the guidance:

  • Literature search protocol provided
  • Literature search reports provided
  • Full list of retrieved articles provided
  • Full list of excluded articles provided, with reasons for exclusion Full text copies of relevant documents available

Database: PubMed

Title Author Year Summary Acceptable?

Database: Google Scholar

Title Author Year Summary Acceptable?

5.4 Literature Search Report

Briefly summarize how many studies you reviewed, how many you deemed acceptable and why you didn’t include the unacceptable ones (probably because they didn’t conform to the appraisal criteria).

5. Clinical Data

5.1 Clinical Data From Literature

List all the clinical data you got from studies which matched your appraisal criteria.

5.2 Summary and Appraisal of Clinical Data

Summarize all the clinical data from above :)

5.3 Analysis of the Clinical Data

Analyze the clinical data with a focus on whether your targets of clinical benefits and safety were fulfilled.

6. Post-Market Activities

Summarize your post-market activities. You can copy-paste a lot of those here. At the minimum, you’ll have a Post-Market Surveillance Plan and Report. If this is your initial certification, your report may be empty as you haven’t brought your device to market yet.

Additionally, you may have a Post-Market Clinical Follow-Up (PMCF) Plan and Report which essentially has the content of “we’ll be tracking some data to make sure that our claims of clinical benefits and safety are actually true”.

Here’s what the guidance states about it: Describe how the manufacturer will verify the presumption that there would be no clinically significant difference in the safety and clinical performance of the device under evaluation compared with the equivalent device by post market surveillance or post market clinical follow-up?

  • PMS Plan
  • PMS Report
  • PMCF Plan
  • PMCF Report
  • PSUR (if relevant)

6. Conclusions

Your conclusion whether the clinical data shows that your goals (benefit and safety) are fulfilled.

7. Date of the Next Clinical Evaluation

When will you be doing the next clinical evalulation and updating this report?

8. Dates and Signatures

Date and sign the report. If your document management system supports it, you can digitally sign by typing e.g. your initials in the “Signature” field.

Activitiy Name Signature

9. Qualification of the Responsible Evaluators

Attach CVs of the people who were involved in writing the Clinical Evaluation. They must fulfil some critieria (it’s complicated), so I’ll just copy-paste MEDDEV 2.7.1 rev. 4 here:

  • The manufacturer defines requirements for the evaluators that are in line with the nature of the device under evaluation and its clinical performance and risks.
  • The manufacturer should be able to justify the choice of the evaluators through reference to their qualifications and documented experience, and to present a declaration of interest for each evaluator.

As a general principle, the evaluators should possess knowledge of the following:

  • research methodology (including clinical investigation design and biostatistics); MEDDEV 2.7/1 revision 4 page 14 of 65
  • information management (e.g. scientific background or librarianship qualification; experience with relevant databases such as Embase and Medline);
  • regulatory requirements; and
  • medical writing (e.g. post-graduate experience in a relevant science or in medicine; training and experience in medical writing, systematic review and clinical data appraisal).

With respect to the particular device under evaluation, the evaluators should in addition have knowledge of:

  • the device technology and its application;
  • diagnosis and management of the conditions intended to be diagnosed or managed by the device, knowledge of medical alternatives, treatment standards and technology (e.g. specialist clinical expertise in the relevant medical specialty).

The evaluators should have at least the following training and experience in the relevant field:

  • a degree from higher education in the respective field and 5 years of documented professional experience; or
  • 10 years of documented professional experience if a degree is not a prerequisite for a given task.

There may be circumstances where the level of evaluator expertise may be less or different; this should be documented and duly justified.

10. References

Papers and other references which you cite go here.

Template Copyright openregulatory.com. See template license.

Please don’t remove this notice even if you’ve modified contents of this template.

End of template


Regulatory compliance is not rocket science.

But finding a good consultant is.

No Cookie For You Privacy Policy Imprint
No QMS on this planet will save you from creating crappy software.