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...

1. Elements to Consider for Risk Assessment in SaMDs
By: Govind Yatnalkar
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
1 Peter Hartung(August 2018). Medical Device Software, Risk Management& IEC 62304. Retrieved on March1, 2021, from
https://www.regulatory-affairs.org/en/development-excellence/news-page/medical-device-software-risk-management-and-iec-
6 2304/.
2 Oriel (October 2018).Overview of Risk Managementfor Medical Device Software & SaMD. Retrieved on March1, 2021,from
https://www.orielstat.com/blog/risk-management-medical-device-software/.

2. I want to further discuss the commonactivities 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 canguide
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.