Best Practices For a SaMD MDR Application

Software as a medical device (SaMD) is a rapidly evolving field, posing opportunities and challenges for device organizations and regulators. We would like to dedicate this post to recent learnings with several U.S. SaMD manufacturers who are pursuing MDR designations. We will delineate each of the five best practices in the three main aspects of a SaMD MDR application; namely the General Report Requirements, Clinical Requirements, and the Software Requirements. 

Best Practices related to the General Report Requirements 

1. Version and iteration of device submitted for evaluation should be clearly mentioned
2. Often manufacturers ignore identifying the development basis of the SaMD: This can be mitigated by:
   • Referencing to the previous generation(s) of the device, or
   • Referencing to the similar generation(s) of the device.
   • If no such device exists, it should also be clearly mentioned.
3. It is important to clearly list all the applicable general safety and performance requirements (GSPRs).
4. If there are any common specifications or applicable harmonized standards, it shall be clearly mentioned in the technical file. In the event that there is no such common specification or applicable harmonized standard, the technical file shall clearly highlight this fact.
5. Being a SaMD, the manufacturer often ignores the ‘lifetime’ of the software. It can be easily mitigated by providing: 
   • The duration up to which the manufacturer plans to support the software.
   • The user action once the intended lifetime is over.  

Best Practices related to the Clinical Requirements 

1. One of the most common mistakes manufacturers make is not following the available guidance document(s) or templates:
   • MDCG 2020-13 Clinical evaluation assessment report template is a must to follow.
   • Manufacturers can also take guidance from MEDDEV 2.7/1 revision 4.
2. A systematic and well-constructed clinical evaluation plan and report is very important:
   • Often, manufacturers pay less attention to it.
   • Simply putting an overview of some random published articles is not appropriate.
   • If equivalency is claimed, detailed comparison of biological (if applicable), clinical, and technical specifications between the device under evaluation and identified equivalent device must be present.
3. Another common mistake is referring to relevant documentation instead of providing the vital information inside the report. CER is a complete document, and necessary. Information relevant for the evaluation must be completely present there, rather than merely referenced.
4. Identifying the applicable GSPRs is important.
5. Identifying the Safety and Performance indicators is equally important.

Best Practices related to the Software Requirements 

1. SOUP requirements and versions need to be traced back to the SDD for each software release 
   • Software architecture related to the requirements including interfaces, specification of functional and performance requirement of SOUP (Software Of Unknown Provenance), and hardware and software required by SOUP
2. Release practices is very important
   • Regression reports of software units and software items are often missed
   • Demonstrate how you trace and document all regression testing related to each iteration of each version
   • List of anomalies needs to be called out properly 
   • Maintain good traceability hygiene for PRD and SDD 
3. Scope of validation is key 
   • Define your clinical claims very precisely (e.g., clinical scenarios, integration of the subject device to the standard of care, etc.)
   • Define the scope of verification and validation based on the clinical claims 
4. Maintenance Procedure 
   • Maintenance procedure shall include maintenance plan, analysis of problems, and change request.
   • Change request shall include evidence of risk management review and analysis of impact of change to the entire QMS.
5. Configuration Practices 
   • Documentation on builds, releases, SOUP, etc. are all required. 
   • Configuration of the software system, to include identification of the configuration items and their versions.

RookQS has a well-rounded team of engineering professionals (e.g., software developers, software quality assurance engineers, quality engineers, etc.) who can help you navigate the SaMD MDR landscape beginning at any stage of your product development. We’ll be publishing a client case study regarding a SaMD MDR application in the near future. In the meanwhile, please also refer to a client case study regarding a SaMD 510K approval via this link.