Software in Medical Devices, a blog by MD101 Consulting

To content | To menu | To search


Software as a Medical Device (SAMD): clinical evaluation

The FDA released a guidance on clinical evaluation of standalone software medical device (a.k.a SAMD) in October 2016. This guidance is the same text and has the same presentation as the International Medical Device Regulatory Forum (IMDRF) guidance on SAMD clinical evaluation published in August 2016.

FDA and IMDRF guidance

If you want to compare the two guidances:

The only difference is the front page added by the FDA.
This reference of the FDA to a document issued by the IMDRF has consequences outside the scope of this guidance. It gives strength to other guidances already issued by the IMDRF. This is also a positive sign that the MDSAP program is going to be successful and adopted by the FDA.

A unique document of its kind

This document is a gem. There is no equivalent guidance on clinical evaluation of standalone software medical device, either in the US (of course), or the European Union. The MEDDEV 2.7/1 revision 4 of June 2016 on clinical evaluation is for all medical devices and doesn't focus on software.
As such, even if this guidance is still a draft, it is de facto the state-of-the-art for clinical evaluation of standalone software.

Content

This guidance is 45 pages long, but only the section 6 is on the clinical evaluation method itself. Chapters 1 to 5 put the reader in the picture, to understand the content of chapter 6.

The method

Chapter 6, the heart of the document, is 10 pages long and describes the clinical evaluation method. I won't paraphrase the guidance but just mention that it is divided into:

  • Scientific evidence: the scientific basis for using the SAMD,
  • Analytical evidence: the V&V process,
  • Clinical performance evidence: the "real" clinical assessment.

Chapter 7 modulates the level of clinical evidence based on the profile of risk of the SAMD. For example, clinical performance evidence is required for high risk profiles only. Chapter 8 gives some insightful examples.

References to other guidances

While this guidance can be read without knowing other IMDRF guidances, it references them throughout the document. Thus reading these other guidances helps understanding the content of this one. This represent a lot of pages to read eventually (yes, I'm lazy). See other guidances on IMDRF website and some comments on these guidances.

Agile clinical evidence

Yes, you read it right: the guidance on SAMD clinical evaluation talks about agile clinical evidence!

If you come form the software world, you'd say that the word "agile" is abused and distorted. But I prefer saying "welcome" to the clinicians. Sure, clinicians won't perform any clinical evaluation every week. "Agile" here means something else and the transposition of the agile concept to clinical evaluation is interesting.

  • The first reason of the use of the word "agile" stems from the idea that standalone software has the capability of communicating, compared to physical medical devices. As such, data use to set the ground of the clinical evidence can be easily and continuously acquired form the field (either in clinical evaluation or in post-market clinical follow-up) to confirm or adjust the clinical performance and safety of the device.
  • The second reason stems from the capability of software to be continuously enhanced, thanks to the agile methods. As such, a standalone software in a first version can be used with a set of clinical claims, usually low risk, which will be extended in further version to newer, and more risky clinical claims, as feedback coming form the field can be used to:
    • Implement new functionalities, and
    • Demonstrate the clinical performance of these new functionalities.

This is typical of software to have simple functions at the beginning, and to evolve with advanced functions based on user feedback. This close interaction between software versions and user feedback requires to continuously reevaluate the clinical performance of software medical device. Through the lens of clinical evaluation and its timeframe, this is a kind of agility.

Regulations

This guidance carefully avoids binding its recommendations to any regulation. When the guidance recommends clinical performance evidence doesn't mean that regulations recommend clinical performance evidence, and vice-versa.

US regulations

Clearance of medical devices rarely requires clinical data for class I and class II devices with predicate. Thus it won't change the clinical data required in 510k files. Class III devices require clinical assays, making the guidance not very helpful for this kind of devices. The De Novo process is probably the best candidate to make an intensive use of this guidance. Low or medium risk devices without predicate may or may not require clinical data. The guidance will give a substantial assistance in this case.

EU regulations

CE marking of medical devices always require clinical data, expected if bulletproof rationale is given. Thus this document will be significantly helpful to design the clinical evaluation plan of standalone software medical device.
On top of that, standalone software medical device will be more subject to be in a high regulatory class with the new Medical Device Regulation. Thus making it much harder to define rationale to skip clinical evaluations.

Conclusion

This guidance document is still a draft but can already be considered as the state-of-the-art in the field of clinical evaluation of standalone software medical device (or SAMD as defined in the guidance). It has no equivalent and will be of great help to design a clinical evaluation plan for standalone software.



Add a comment

Comments can be formatted using a simple wiki syntax.

This post's comments feed