An important question for companies looking to launch new software as a medical device (SaMD) is: what are the most common mistakes, and how can they be avoided? Having this knowledge can help healthcare software vendors avoid the pitfalls and speed up the time to market for new products.

1. Ill-defined software requirements

As with any medical device, software destined for the healthcare sector should have a clearly defined purpose. It’s also essential to define the hardware needed to run it. Considering the number of devices and operating systems (OS) on the market, that’s an enormous task – especially when certain Android device manufacturers insert their own layer of functionality, adding to the burden of testing compatibility for software vendors.

That’s why it’s so important to define requirements beforehand to ensure that customers can easily decipher whether it will work on their chosen OS and device. We recommend taking a risk-based approach to defining software requirements. With a major release, every function should be properly tested, whereas with a minor release only the changed or new functionality and some key functionalities need testing (regression testing).

2. Inadequate testing

It’s important to rigorously test any new software product. That’s especially true of new SaMD, which has a direct impact on patient care and outcomes.

Inadequate verification and validation testing allow correctable issues to pass unnoticed into the market release – resulting in a faulty or poorly functioning product. At best, this is a potential PR disaster, at worst there could be a negative impact on patient safety. For example, imagine if important patient data was lost or compromised in some way.

That’s why it’s essential to define a proper verification and validation plan. Testing protocols should cover all software requirements. Any testing protocol should also provide step-by-step guidance on how to obtain the necessary evidence to verify and validate the software requirements, and which results are expected to be obtained by following the protocol.

3. Insufficient risk management

No one likes to think of the consequences of something going wrong with healthcare software. But when there’s insufficient risk management at the design and development phase, it can lead to significant problems later down the line. For that reason, software requirements should cover every aspect of the design including security, functionality, user interface (UI), labelling, installation, and configuration – in line with the MDR requirements.

Each requirement needs a robust testing system, providing verification and validation to confirm that they’re met. Failure to define all the necessary requirements, can result in a lack of evidence in the technical documentation. Our advice? Follow the standard ISO14971 which outlines the risk management process for medical devices – including ‘software as a medical device’. For further guidance on risk management, you can also refer to ISO/TR 24971, and AAMI TIR32:2004 (R2016).

4. Poor usability testing

In the rush to get healthcare software to market, some companies omit to properly conduct user experience (UX) testing. This is a mistake. Usability should be properly executed and planned in order to test the software against the defined user population. As such, it’s important to assemble a representative testing group with diverse backgrounds within the defined population, getting them to perform tests that reflect real-world use. Two things are important here: defining the intended use and ensuring a proper sample size.

This kind of testing is the key to getting powerful feedback on how to improve the software and UX. It’s also a mandatory component in the MDR. Feedback on UX determines whether a company needs to make instructions for use or whether they need to make changes to make it more usable. Skip this step, and companies can expect complaints from users.

5. Incomplete change documentation

Whenever there’s a change to healthcare software, it needs to be documented. The changes also require verification and validation. Depending on the scope of the update, this process can take time – from a day to much longer, depending on the complexity of the software and scope of the update.

Certain changes also need to be sent to the Notified Body for approval. In this respect, healthcare software is different to other types of software – there is an additional regulatory burden that must be handled properly to ensure compliance and product safety. This can slow down updates and put a further regulatory burden on healthcare software providers.

6. Missing instructions for use

The MDR stipulates that there must be instructions for use – unless the product is Class I or IIa and easy to use. Exemption from having to provide instructions needs to be clearly documented, and based on the results of the aforementioned usability testing.

However, when companies are required to produce instructions, this can end up becoming a burdensome task. Depending on the type of software, this could run to pages and pages of documentation. For high-risk devices, instructions are mandatory to ensure the software can be used as intended – especially when improper use of the product can result in patient harm or even death.

7. Feature creep

When any software – including products designed for the healthcare sector –  is without a clearly defined use, it can easily become overloaded with unnecessary features. This sort of feature creep can drain development hours, acting as a distraction from core development and the compiling of accompanying documentation.

For that reason, it’s important that the software meets the needs of the user population. We recommend always keeping development goals in line with business objectives and the intended use of a software product.

8. Failure to demonstrate clinical benefit

With products such as SaMD, defining the clinical benefit can sometimes be a challenge. That’s because depending on what it does, there may not always be quantitative data to support a clinical benefit. Put simply, it’s not always easy to demonstrate the clinical benefit of SaMD.

In this situation, completing the clinical evaluation report requires alternative approaches. We recommend looking at literature on similar software and including as much scientific data as possible. As well as that, include results from user testing – such as user interviews – and define post-market clinical follow-up (PMCF) plans, which illustrate plans for proving the clinical benefit in the near future now that people can use it in a real-life context.

9. Lack of regulatory processes

As we’ve already covered, under the MDR, healthcare software must conform with regulatory processes for change management. On top of that, there must be clear processes for complaint handling. It’s a good idea to get processes for Corrective and Preventive Actions (CAPAs), and post-market surveillance (PMS) in place before release.

Not only are these mandatory components for the MDR, but your team also needs to be trained for these procedures so that data can be gathered and complaints can be quickly resolved to maintain positive customer relationships. The post-market surveillance is important for iteratively improving the software, remaining state-of-the-art, adding useful functionality, and mitigating further risks.

Peercode Regulatory Consultancy provides high-quality services, auditing, and training for medical device companies. Talk to a specialist today.