High Process Risk vs. Medical Device Risk in Computer Software Assurance
After defining a software function’s intended use, the next step in the Computer Software Assurance (CSA) process is determining the level of risk associated with that function. While this sounds straightforward, it is one of the most commonly misunderstood aspects of the FDA’s guidance.
Many manufacturers naturally evaluate software based on the immediate impact of a failure. If production stops, data is lost, or a report fails to generate, the software is often assumed to be ‘high risk.’ However, the FDA’s methodology for risk determination looks beyond the immediate impact of a failure on the product or business, such as what may be captured through a risk priority number (RPN). Instead, manufacturers are expected to consider whether that failure could result in a quality problem that foreseeably compromises the safety or effectiveness of the medical device.
The key distinction is that the potential for a software failure to result in a quality problem that foreseeably compromises safety is what drives the determination. The failure does not need to be likely, highly severe, or difficult to detect; what matters is whether that outcome can occur.
Process Risk and Medical Device Risk Are Not the Same
Once intended use has been established, understanding the difference between process risk and medical device risk—and how they relate—is critical to determining the appropriate assurance activities.
Process risk considers the potential impact a software failure may have on manufacturing or the quality management system. Medical device risk considers whether that failure could affect the safety or effectiveness of the finished medical device.
While these concepts are related, they are not interchangeable. A software failure that creates operational inconvenience or requires additional work does not automatically represent a high process risk. Likewise, a minor software failure may have downstream effects that compromise product quality and patient safety. Understanding that relationship helps manufacturers correctly determine software risk and, in turn, apply the appropriate level of assurance.
Looking Beyond the Immediate Failure
Instead of asking, ‘What happens if this software function fails?’, CSA encourages manufacturers to ask, ‘If this function fails, could that failure create a quality problem that foreseeably compromises safety?’
For example, software responsible for recording final inspection results would likely receive significant attention because inaccurate results could directly affect product release decisions.
Now consider a different function that transfers those inspection results into a trending database. At first glance, that function may appear less critical because it is not directly involved in product acceptance. However, if inspection data is never transferred or transferred incorrectly, quality trends may go unnoticed over time. If those trends are not identified, declining product quality or process variation may continue unnoticed until product no longer meets acceptable quality limits, potentially allowing nonconforming product to reach the field. Under the right circumstances, that downstream effect could compromise product quality and patient safety.
High Process Risk Is About Consequences, Not Complexity
Complexity does not determine risk. Neither does the cost of the software, the number of users, or the size of the application. Instead, risk is determined by understanding what could happen if the software function fails to perform as intended.
Two functions within the same application may have completely different risk profiles because their intended uses are different. This is why risk evaluation of software at the feature and function level is so important.
Applying Critical Thinking
The FDA intentionally avoids prescribing a rigid formula for determining software risk. Instead, manufacturers are encouraged to apply critical thinking throughout the assessment process.
Questions to consider include:
• What is this software function intended to accomplish?
• What happens if it fails?
• Could that failure create a quality problem?
• If a quality problem occurs, could it foreseeably compromise the safety or effectiveness of the medical device?
• Are there existing process controls that would detect or prevent the issue before it affects product quality?
When critical thinking is applied and clearly documented, it can make the CSA process more flexible, efficient, and effective. A well-documented rationale makes risk-based decisions easier to defend and provides a clear record that can be revisited as software changes or additional evaluation is needed.
Why This Matters
When manufacturers correctly distinguish between process risk and medical device risk, assurance activities become more focused and meaningful. High-risk software functions receive the level of assurance necessary to support product quality and patient safety, while lower-risk functions can receive assurance activities appropriate for their intended use. Ultimately, CSA is not about performing less work; it is about performing the right work.
Key Takeaway
Determining software risk requires more than identifying what happens when software fails. It requires understanding how that failure could affect the manufacturing process, product quality, and ultimately the safety and effectiveness of the medical device.
Manufacturers that evaluate software through this broader lens are better equipped to make sound, risk-based decisions that align with the intent of the FDA’s Computer Software Assurance guidance.
Coming Next: Why More Validation Isn’t Always Better: Finding the Right Level of Software Assurance.
