Medical Software Development
The first part of this blog revealed an interesting reality of software-enabled medical devices: iteration. In the medical device industry, companies offering SaMD/SiMD solutions are able to iterate at an unprecedented rate.
Traditionally, software development employs an Agile mindset to continually iterate and improve products; however, when it comes to medical devices, the FDA still strongly favours a Waterfall approach. Ideas on how to blend these two processes to achieve the safest, highest quality, and fastest iterative products will be covered in another article, but for now let’s take a look at the standards that should be followed when developing medical software and products, which may or may not change when it comes to the development of SiMD vs. SaMD.
ISO 14971.
Another standard that is similar between the two types of medical software is risk management. the format of the risk assessment in the SiMD and SaMD risk documents is similar; be sure to include the risk of cyber-attacks and data breaches.
IEC 62304
This is the de facto software development standard. Whether the software is part of an imaging machine, a wearable device, a stand-alone application, or a robot, there needs to be a defined software development process that includes everything from how the software is developed, controlled, configured, and tested, to how risk is managed in the software, to how the software is released, maintained, and monitored in the field.
IEC 62366
Usability and human factors are critical to demonstrate that medical products have been developed with the patient and/or user in mind. In SaMD products, there is an opportunity to utilise wireframes and prototyping tools to conduct formative or summative studies and to iterate quickly when required. In contrast, in SiMD, more traditional industrial design prototyping methods are required because the user interface (UI) often controls some of the other hardware. For any critical content of a device that includes a user interface, I strongly recommend incorporating usability and human factors testing into the software development process, as even changing the colour of a button can have unforeseen impacts.
Cybersecurity
Cybersecurity has been in the spotlight recently due to the FDA’s “right to refuse” policy. In the absence of clear consensus standards, the standards recommended in the FDA Cybersecurity Guidance serve as current guidance on what is acceptable in a 510(k) application.Both SiMDs and SaMDs are subject to cybersecurity testing. Please be prepared with relevant documentation such as threat models, vulnerability assessments, and SBOMs.Unless the SiMD product is considered a “connected device,” the attack surface of the device is likely to be very small (ports on the physical device or the potential for tampering). On the other hand, unless the SaMD product is standalone (not cloud-based), a thorough cybersecurity analysis and subsequent testing is absolutely required to prove it is a secure product.
Privacy.
Both product types must comply with the privacy laws of the regions in which they are sold, and it is highly recommended that these requirements be incorporated at the outset of development, rather than retroactively, such as the Health Insurance Portability and Accountability Act (HIPAA), the Personal Information Protection and Electronic Documents Act (PIPEDA), and the General Data Protection Regulation (GDPR). For SiMD, it is recommended that Protected Health Information (PHI)/PII not be stored directly on the device.
Conclusion.
The convergence of the software and medical device space marks a significant shift in the way healthcare is delivered. Traditional medical device manufacturers and tech giants alike are realising the immense potential of software-driven health and medical solutions. With the advent of SaMD, it is clear that the lines between traditional medical devices and software solutions are becoming increasingly blurred.
This changing landscape is not without its challenges. Ensuring patient safety, meeting regulatory requirements and maintaining robust cybersecurity measures remain paramount concerns. While software has the potential for rapid development and iteration, it also requires a careful approach to ensure that patient interests are not compromised.
The development of SaMD and SiMD is indicative of a wider trend in healthcare – a shift towards more personalised, convenient and data-driven healthcare. It’s a testament to the strides we’ve made in integrating technology with health, and a reminder of our responsibility to ensure that innovations safely benefit patients.
In conclusion, the importance of understanding nuance and complexity cannot be overstated as we delve into the world of SaMD and SiMD. As the lines between software and medical devices become increasingly blurred, our top priority should always be to provide safe, effective and innovative solutions to improve patient outcomes.