Users might get frustrated with software systems in the healthcare sector due to less compact UIs or functionality issues, such as taking a long time to load a web page. But what if the patient-sensitive data is exposed on a URL? What if an incorrect data visual analysis is displayed on the doctor’s screen and they prescribe medicines based on the flawed computed bar graphs? These are issues that are not easily visible to healthcare professionals or patients as they merely utilize the system to execute certain tasks. This is where the activity of risk assessment comes in.
Let me initially begin by giving the basic definition of Software as a Medical Device (SaMD). It is a software system that provides Digital healthcare services and is not reliant on any hardware components for executing its functionalities. A sophisticated development of a SaMD can be followed using the IEC 62304 harmonized standard which provides a defined framework for plans, procedures, and documentation relating to SaMD design and maintenance.1
Now let us dive into risk assessment. It is defined as the process of analyzing the system (design and implementation) to identify the hazards present in the system. For example, based on SaMD’s monitoring data, certain actions might be triggers. In such a case if the collected data is flawed, the application triggering might be delayed or triggered when not necessary. Such risks are extremely important to identify in high-risk- SaMDs such as software tools used in heartrate monitoring or for analyzing images of breast cancer. 1
One of the major components included in IEC 62304 is the risk assessment. Initially, it is important to identify your SaMD class. The class of the SaMD drives the further software design, development, testing, and documentation phases. The three major classes are Class A (No injury /damage), B (Has possibility for Nonserious injury), and Class C (Includes a possibility of death or serious injury). After identifying the SaMD class based on the associated risk, IEC 62304 provides certain activities that should be included based on identified classes. If the SaMD is identified as Class A/ B, activities such as detailed design are not required. For class C, this document is indeed required. 2
I want to further discuss the common activities manufacturers should carry out irrespective of the identified class. Initially, I would create a detailed development plan starting with software requirements and their in-depth analysis. At this stage, quality engineers play a vital role when it comes to risk assessment. They have broader visibility and knowledge when it comes to risk identification. Here, we go through every software requirement and identify if it affects patient safety. For example, there may be a software requirement that sends a signal to the master server if it detects any anomalies. A hazard identified here is the time the system takes to send signals. If it takes a large amount of time to even send the signal, this becomes a risk from a patient care and safety perspective. The final part comes from the unit-level implementation and verification. One of the best ways I think to conduct a risk assessment is assuming my code output is always in the ‘worst case’ scenario state. In such a case it helps to re-contemplate my design and make sure that are not software issues when I create the package to be deployed in the product.
To conclude, risk assessment is one of the most important processes when it comes to standard SaMD development. My recommendation to all software engineers is to not only always walk through the software design with a quality engineer but also to get the implemented software checked from a software validation perspective. Validation includes documenting the software requirements, architecture, conducting in-depth code testing with quality inspections, and most vitally, risk-assessment of the software tool. Surely, it can be tricky to implement and execute these processes without proper guidance and support. EMMA International can guide you step-by-step through these processes and make sure your SaMD follows all the required FDA regulatory guidelines. Do you have a SaMD that needs to be FDA-compliant? Contact us at 248-987-4497 or contact us at info@emmainternational.com for more information.
1Peter Hartung (August 2018). Medical Device Software, Risk Management & IEC 62304. Retrieved on March 1, 2021, from https://www.regulatory-affairs.org/en/development-excellence/news-page/medical-device-software-risk-management-and-iec-62304/.
2Oriel (October 2018). Overview of Risk Management for Medical Device Software & SaMD. Retrieved on March 1, 2021, from https://www.orielstat.com/blog/risk-management-medical-device-software/.
