cGMPs For SaMDs

The rapid development of technology has changed how patients manage their health and interact with healthcare professionals. Software as a medical device (SaMD) has grown in market share and complexity. The traditional cGMP framework, best illustrated by ISO 13485, is not really suitable for the fast and iterative design and development, validation, and commercialization needed for SaMD deployment. Unlike traditional medical devices, SaMD can blur the lines between the design and development stages and the production aspect of commercialization. So, what are the activities necessary for medical device manufacturers to modify and improve upon their existing (or new) ISO 13485 practices to be compliant with the traditional cGMP framework and still meet a blazing product development life cycle? What are the pertinent sections in a quality manual that need to be altered?

Assuming that ISO 13485, the international management standard developed specifically for medical device manufacturers providing a harmonized model for creating and maintaining an effective quality management system (QMS) for the design and manufacture of traditional medical devices, is our baseline, let’s consider the following key considerations for SaMD design, development, and deployment.

Clause 6: Resource Management

The purpose of resource management is to provide the appropriate and necessary level of resources (people, tools, environment) to ensure the effectiveness of SaMD life cycle processes and activities that meet both regulatory and customer requirements.

People

Anyone assigned to participate in SaMD projects must have both the software knowledge and education, along with medical device training, to perform their duties. Ideally, SaMD personnel must have technical and software engineering capabilities and an understanding of the clinical aspects of the SaMD.

Environment/Tools

Medical device manufacturers would have to augment their existing infrastructure to provide SaMD development and testing capabilities and tools to manage software configurations throughout SaMD life cycle. Since the SaMD working environment is a virtualized space, the requirements for the working environment must be unambiguous when designing and developing products, and the reliability and dependence of the environment are also extremely important. Exceptional care has to be devoted when third-party cloud services are used to develop and commercialize SaMD; medical device manufacturers would have to qualify the cloud service irrespective of cloud resources provided, such as Software as a Service (SaaS), Platform as a Service (PaaS), or Infrastructure as a Service (IaaS).

Clause 7: Product Realization

One of the fundamental adjustments that needs to be made to accommodate SaMD is the inclusion of software risks (failures, errors, etc.) in an existing (or new) risk management process. The adjusted risk management process would have to include software updates, deployment, and the installation of SaMD by users, patients, and healthcare professionals, as well as corresponding updates and patches. See Table 1 for some suggestions.

Table 1: SaMD Risk Management.

Another SaMD adjustment is the evaluation of cybersecurity risks that could affect the confidentiality, integrity, and availability of the data processed by SaMDs. Since SaMDs are typically connected to the internet, networks, and databases and are generally used by a wide variety of users with different access rights, it is important for medical device manufacturers to consider medical device cybersecurity in both the design and deployment phases. When managing cybersecurity risks, the principles described in ISO 14971 should also be followed. There may be some device-specific cybersecurity risk involved but, generally, manufacturers should include the following in their risk management plan:

1. identify all possible cybersecurity hazards,
2. assess the associated risks,
3. implement mitigations or controls to reduce risks to acceptable level, and
4. monitor and evaluate effectiveness of mitigation measures.

It is strongly suggested that the following actions are incorporated into the SaMD risk management process:

• The use of tools such as threat modelling to identify vulnerabilities and develop mitigation after risk evaluation.
• The cybersecurity risk management process shall be conducted in parallel with safety risk management. The overall patient safety should be considered when introducing security measures prevent any unintentional patient harm.
• Establishment of an ongoing program for monitoring and surveillance of threats and vulnerabilities. If new cybersecurity vulnerabilities are discovered, SaMD manufacturers can conduct a vulnerability risk assessment to evaluate the potential for patient harm and compromise of SaMD performance. The vulnerability can be analyzed considering:
  • the exploitability of the vulnerability and
  • the severity of user/patient harm if the vulnerability were to be exploited.

Another key consideration within Clause 7 is design and development, and the bulk of the article will cover the necessary changes to commercialize SaMDs. One of the keys to the design process is to create life cycle processes and activities that best meet the needs of users and to develop SaMDs, validate them, and safely deploy and maintain them, clearly and succinctly through a logical structure. To ensure the quality of SaMD, safety and cybersecurity must be assessed at each stage of the SaMD life cycle. Some highlights to consider:

SaMD Design & Development

1. SaMD designs must have adequate controls in place to ensure robustness in the event of an unexpected upgrade or failure of the third-party platform.
2. SaMD design should include relevant considerations and appropriate measures when integrating or using legacy code or software, undocumented/unknown application programming interfaces (APIs), and wireless network infrastructure.
3. Development activities should take advantage of the unique characteristics of SaMDs that can understand the user's environment and use effective methods to prevent and manage failures.

SaMD Integration & Testing

It is imperative to establish and implement a SaMD integration strategy and associated testing to verify that the SaMD is working as intended, and such integration testing would have to be proportional to the risks associated with the SaMD itself. Both black- and white-box testing may be necessary to demonstrate such integration. Table 2 provides some examples of testing that would be beneficial to evaluate such integration. The interoperability of the components and the compatibility with other medical devices/interfaces on which the SaMD operates should be taken into account. It is advisable to include boundary conditions and exceptions (robustness, stress testing, data security, integrity, and continuous availability of SaMD).

Table 2: SaMD Testing.

Purchasing

SaMD manufacturers have been using open-source code or other commercial product code as part of their product development. To maintain the integrity and traceability throughout the entire SaMD life cycle, it is important to control configurable items such as source code, distribution, documentation, and software tools. As such, it is important to formally evaluate, document, and periodically audit suppliers (including open-source providers) because a defect in the open-source code can contribute to the overall risk of the SaMD and pose a threat to the SaMD. If the required information about open-source code is not known, which is usually the case, monitoring is necessary to assess the suitability, such as the purpose, safety, and effectiveness of the open-source code. At a minimum, SaMD manufacturers would have to:

1. continuously evaluate the validity of the deliverables,
2. assess whether the risk of missing relevant activities and deliverables can be reduced,
3. ensure that risk control measures are included in the software requirements, and
4. establish the rationale for use, if acceptable, for the continuous use of open-source based on output.

Conclusion

SaMDs are here to stay. They run on computers, smartphones, or in the cloud, are used in a variety of environments, and are connected to and used in other systems or databases. SaMD manufacturers have to adjust their existing cGMP practices to meet the devices’ unique and ever-changing characteristics. It is important to step away from the traditional way of thinking and consider developing SaMD that can operate with key elements beyond the manufacturer’s controls, such as operating systems, general-purpose hardware, and the internet. Any sudden interruption of the SaMD environment, like service interruption, upgrades, patches, or cybersecurity incidents, can bring about loss of information, delay, or errors, which may lead to incorrect or inaccurate diagnosis and treatment, adversely impacting the patient.

About The Author:

John Giantsidis is the president of CyberActa, Inc., a boutique consultancy empowering medical device, digital health, and pharmaceutical companies in their cybersecurity, privacy, data integrity, risk, regulatory compliance, and commercialization endeavors. He is the vice chair of the Florida Bar’s Committee on Technology and a Cyber Aux with the U.S. Marine Corps. He holds a Bachelor of Science degree from Clark University, a Juris Doctor from the University of New Hampshire, and a Master of Engineering in cybersecurity policy and compliance from The George Washington University. He can be reached at john.giantsidis@cyberacta.com.