![\"SaMD\"](\"https:\/\/www.jamasoftware.com\/media\/2021\/08\/2021-08-17-samd-four-best-practices_1024x512.jpg\")
<\/p>\n<\/p>\n
This post on Software as a Medical Device (SaMD) development is written by Mercedes Massana, the Principal Consultant of MDM Engineering Consultants<\/a>.\u00a0<\/em><\/p>\n SaMD software is software intended to be used for one or more medical purposes that do not require embedding in a medical device. These purposes can range anywhere from helping to diagnose or treat disease, helping in the clinical management of a disease, or providing information to help with the clinical management of a disease. SaMD differs from other medical device software in that it will operate on different platforms and will interconnect with other devices, carrying with it an increased cybersecurity risk and a commensurate increase in the use of off-the-shelf software.<\/span>\u00a0<\/span><\/p>\n On the surface\u00a0it may appear that\u00a0the\u00a0development of SaMD software is no more difficult than\u00a0the\u00a0development of\u00a0Medical Device\u00a0embedded software,\u00a0but\u00a0appearances can be deceiving, and the development of SaMD products can be quite challenging.\u00a0In order to\u00a0deal with these challenges,\u00a0there are\u00a0four\u00a0key\u00a0best practices\u00a0that should be followed\u00a0for\u00a0SaMD\u00a0software development.\u00a0<\/span>\u00a0<\/span><\/p>\n These practices are:\u00a0<\/span>\u00a0<\/span><\/p>\n Although standards\u00a0development organizations and regulatory bodies have only started to scratch the surface in the creation of standards and guidance documents to help\u00a0SaMD\u00a0development organizations, there is a sufficiently\u00a0detailed body of work available to help development\u00a0organizations\u00a0succeed. The most relevant of these are the documents generated by the International Medical Device Regulators Forum (IMDRF)\u00a0related to SaMD\u00a0and IEC 82304 Safety and Security of Health Software Products. The IEC standard points to other well-known standards, such as IEC 62304 Software Development Lifecycle,\u00a0IEC 62336 Usability Engineering and\u00a0ISO 14971.\u00a0Additionally, several FDA guidance documents are available that apply to all medical device software and are useful for the development of SaMD, these include General Principles of Software Validation, Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices, Off-The-Shelf Software Use in Medical\u00a0Devices\u00a0and\u00a0the FDA pre and post market\u00a0cybersecurity guidance, as well as other\u00a0guidance\u00a0documents\u00a0<\/span><\/p>\n Within the development of SaMD, a clear understanding of the scope and intended use of the product is necessary, and to that end, it is necessary to have a method to gauge the risks associated with SaMD use. The IMDRF \u201cSoftware as a Medical Device\u201d Possible Framework for Risk Categorization and Corresponding Considerations, IEC 62304 , and FDA Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices all provide a method for risk based classification of SaMD. The rigor applied to the development of SaMD should be commensurate with the level of risk. IEC 62304 uses the Safety Classification to define the level of rigor of activities to be performed in the software lifecycle based on the level of risk. Ideally, the development process is sufficiently flexible to avoid the over-engineering or under-engineering of the SaMD in question. A development process that is adaptable requires organizational maturity and experience, in order to perform the right set of activities and understand the value provided by those activities.<\/span><\/p>\n SaMD is a medical product, a system in and of itself. Therefore, SaMD system requirements must be verified to have been implemented correctly, and\u00a0\u00a0SaMD user\u2019s needs must be validated to ensure that the product satisfies the user\u2019s need and that the right product was built for the customer. Validation typically includes human factors testing, clinical evaluation to determine the efficacy of the software for its intended use, and a demonstration that risk controls are effective. This requires more than just your standard set of software testing, which typically consists of code reviews, unit testing, static analysis, integration testing and requirements-based testing.\u00a0<\/span><\/p>\n Your SaMD software has successfully completed verification and validation, has been cleared by regulatory agencies, and is now ready to go live. Time to breathe a sigh of relief and congratulate the team for a job well done. Pop the champagne and throw a party, you have all earned it. Enjoy the festivities, but afterwards turn your attention promptly to monitoring the performance of the SaMD post launch. Rigorous and exhaustive as your testing was, you can never anticipate every possibility. Be ready to respond to identified software defects and emerging cyber threats and deploy patches or software fixes as issues are identified.\u00a0\u00a0The nature of cybersecurity risks is ever-changing, and no system, regardless of how well-designed, or rigorously-tested, is free of software defects. Additionally, customer input can provide opportunities for enhancements and improvement.\u00a0 However, be aware that proposed changes can impact the intended use of the device, the classification of the SaMD, and can ultimately result in additional regulatory submissions. It is paramount that prospective SaMD developers evaluate changes thoroughly and plan actions related to these changes to avoid surprises that can delay, or outright derail, SaMD implementation.<\/span>\u00a0<\/span><\/p>\n In summary,\u00a0SaMD\u00a0can provide great benefits\u00a0to the user;\u00a0however, to successfully launch\u00a0SaMD\u00a0that meets the user\u2019s needs,\u00a0several best practices should be utilized in their development. These best practices,\u00a0making use of standards and guidance documents, applying the appropriate level of rigor in the development of SaMD, understanding\u00a0the difference between Verification and Validation, managing\u00a0change appropriately, and implementing\u00a0a good post-market monitoring program.\u00a0 These best practices are\u00a0indispensable in\u00a0ensuring\u00a0a safe and effective SaMD product.<\/span>\u00a0<\/span>
\n\n
Best Practice #1\u2013\u00a0Making\u00a0Use of\u00a0Standards and\u00a0Guidance\u00a0Documents\u00a0<\/span><\/h3>\n
Best Practice #2 \u2013Applying\u00a0the\u00a0Right\u00a0Level of\u00a0Rigor\u00a0<\/span>\u00a0<\/span><\/h3>\n
\nRELATED: Regulatory Shift for Machine Learning in Software as a Medical Device (SaMD)<\/a><\/h4>\n
\nBest Practice #3 \u2013 Understanding the Differences Between Verification and Validation <\/span>\u00a0<\/span><\/h3>\n
Best Practice #4 \u2013 You Are Not Done When the Software is Released <\/span>\u00a0<\/span><\/h3>\n
\n<\/p>\n
\n<\/div>\n