What Labs Need to Know About Risk Management in Software

Every time we ride a bicycle, drive a car, or travel by plane, we’re faced with the risk of injury. While we can’t completely eliminate all the risks, we can reduce our chances of getting hurt — think bicycle helmets, seat belts, and oxygen masks. Similarly, clinical diagnostic labs have to accept a certain amount of risk (this is known as risk acceptance), but there are a number of ways these risks can be mitigated.

At Semaphore, we agree with the adage that “prevention is better than a cure”. We’ve found that proactively planning for risk mitigation creates significantly better options for dealing with the inevitable real-life events. A happy by-product we’ve experienced from this proactive strategy is that the cost of mitigation goes down, and dealing with the events is less stressful.

We recommend labs create a software-specific risk management strategy, like those used in other industries to identify financial, legal, technology, and other risks. A formal plan can help you prioritize risks so that you manage the most threatening ones ahead of those that will have less impact on your business.

It’s worth noting that the tolerance for risk in the regulated clinical space is much lower than it is in the unregulated research space. In clinical labs, the table stakes for quality are extremely high because patients’ lives are at risk. And as such, any software used by the lab is mission-critical and needs to be managed using a risk-based approach lest the burden of testing the software becomes prohibitive.

Risk management in software

Risk management in the context of software development involves containing and mitigating risks that could impact the quality of the software. Problems can arise when using new, unproven technologies, when user requirements change, or when there are architectural deficiencies in the software.

When implementing a piece of software in the clinical laboratory, we always take a risk-based approach, especially with software testing, to prevent these types of issues.

Risk-based testing

In software development, risk-based testing is the process used to determine how much testing is necessary for changes in the software system. It’s based on an assessment of the total risk associated with each change, which depends on the probability of risk. Essentially, it’s a way to optimize your software testing without compromising your software quality.

You might remember from our previous posts that making a change to the code can trigger breakages to seemingly unrelated components. This is why you need to test each change thoroughly and why software testing plays a key role in software quality.

Using risk-based testing, you can prioritize and execute the most appropriate tests. The idea is to perform a sufficient amount of testing to address the risk profile of the change being made to the software, based on the likelihood of it impacting another software module.

To apply a risk-based testing approach:

  1. Identify the areas of risk within the software. You can discover these by analyzing the software requirements and any other project documentation that’s available.
  2. Analyze these risks and determine the level of risk associated with each software module.
  3. Prioritize testing for those high-risk modules, and then decrease testing coverage for other modules according to decreasing probability of risk. High-priority modules (e.g., instrument interfaces) should receive more advanced testing and be tested earlier on in the software development life cycle than lower-risk modules (e.g., editing UI labels).
  4. Monitor risks and adjust testing as necessary throughout the process.

We consider risk-based testing to be critical in clinical labs. You should have thoughtful conversations with your stakeholders about how much effort is put into software testing and understand how much risk your organization is willing to tolerate.

Note that you don’t have to have all the answers when it comes to your lab software. Your software vendor can help you understand the risks and make an appropriate risk-based testing plan.

Other recommendations for mitigating risk within a clinical lab

In addition to the above, we recommend investing in your technology infrastructure. Your software and IT systems play a large role in the quality of your lab’s processes. Ensuring the software architecture is robust is a proactive way to mitigate the risks associated with building and deploying new software and updating your existing applications.

We also suggest confirming that your lab’s SOPs are easy to follow and your software systems are user-friendly so you can minimize the number of errors made during manual tasks.

Tackling risk management and adopting a risk-based approach to software testing can help you improve your market competitiveness, speed to market, and agility. But beyond that, peoples’ well-being is at stake. Better quality software can enable you to achieve medical breakthroughs that improve patient outcomes and save lives.

Check out our other posts in this series on quality and contact us with your questions.