7 Common oversights by medical device execs

Being an effective medical device project executive is no easy feat. Liaising between development teams and stakeholders, you must ensure that the project is not only completed on time and within budget but to the required quality standards, too. Consequently, even experienced executives can overlook some vital elements of quality software development.

In this article, we’ll discuss seven common oversights that medical device executives make and provide tips on how to avoid them. By following these tips, you can increase your team’s chances of success and deliver safe, reliable, and effective products.

Is there anything you’ve overlooked?

1. Absent solid test strategy
2. Compliance isn’t used to add value
3. Zero over-the-air updates
4. Not using automated testing
5. Using unvalidated tools
6. Poor psychological safety
7. Code quality isn’t invested in

1. Absent solid test strategy

Testing is an integral part of developing high-quality medical device software. It helps ensure your product has the necessary functionality, reliability, and safety. Failure to implement and follow a robust test strategy can jeopardise the success of your project and the safety and well-being of patients.

A test strategy outlines the approach and methods that will be used to ensure the quality and reliability of a software application. It helps to ensure that testing activities are carried out effectively, efficiently, and consistently. It also provides a reference point for stakeholders involved in the development and testing process.

Test early, test often.

It would help if you started thinking about testing from the outset of your project—before you’ve written a single line of code. This means asking critical questions like:

• How will we validate the software’s functionality, safety, and performance?
• What types of tests will be needed?
• What resources and expertise do we require to execute these tests effectively?

Don’t underestimate the time and resources required for testing.

It’s easy to downplay the importance of testing in the face of urgent deadlines. However, poor or rushed testing can lead to costly consequences, such as failing regulatory submissions, product recalls or patient harm.

Invest in dedicated testing resources.

Software developers can write their own tests in a pinch, but it’s not ideal. Thorough, effective testing requires dedicated software analysts and testers with specific skills and tools. As such, project managers should ensure that projects have sufficient resources for comprehensive testing throughout. This is essential for delivering safe and reliable medical device software.

Here are some additional tips for effective medical device software testing:

• Use a risk-based approach to testing. Focus your testing efforts on the most critical functionality and the areas with the highest risk of failure.
• Use a variety of testing methods. This includes unit tests, integration tests, system tests, acceptance tests, and usability testing.
• Use automated testing tools whenever possible. We will talk about this later in the blog.
• Document your test results thoroughly. This will help track your progress, provide evidence for regulatory submissions, and identify areas where further testing is needed.

By following these tips, you can help to ensure that your medical device software is thoroughly tested and meets the highest quality standards.

2. Compliance isn’t used to add value

Compliance standards such as IEC 62304 are essential for ensuring the safety and quality of medical device software. And, by extension, the success of your product; if your device doesn’t meet the appropriate criteria, it will not be allowed on the market.

However, meeting compliance isn’t just a bureaucratic box-ticking exercise. It’s an opportunity for improvement.

Quality matters

Compliance standards are about quality. They ensure that devices are built to a high standard, with proper consideration given to safety and risk management. You should want these things for your device and its users, regardless of whether market regulations demand them.

When you view compliance as an opportunity to enhance your project’s value, you can align software development efforts with customer needs, industry best practices, and continuous improvement.

So, you don’t just achieve compliance; you also get high-quality medical software that is more reliable, secure, and valuable—to stakeholders and end-users alike.

Invest in ways to make compliance part of your culture

Incorporating compliance into your everyday activities is key, such as using living documentation to evidence your compliance as well as being an easy overview of your compliance status for stakeholders. Take time for TDD (Test Driven Development) and TIR45 training to enable implementing compliance without being a burden on your software development teams.

3. Zero over-the-air (OTA) updates

The cost of fixing bugs increases massively throughout the development process. As a rule of thumb, a bug found during testing will cost 10 times more to fix than the same bug discovered by the software developer. It will cost 10 times more again to fix that same bug if it is found by a user.

Do you recall?

If a serious bug is found in your software after it has been released, there are several ways to apply an update:

• Recall the product
• Update via physical media such as USB
• Update “over-the-air”

Clearly, the first option is expensive, disruptive, and will cause significant damage to your reputation. And, while installing updates off a USB device is definitely an improvement, it’s still far from ideal.

The best choice is applying updates “over-the-air”.

Over-the-air updates are delivered remotely. The networked device intermittently checks for available firmware updates; when it finds one, it downloads and installs it. This means that bugs can be fixed in a timely, cost-effective manner, security is kept up to date, and new features can be added as needed.

Faster to market

Speaking of new features, over-the-air updates can also allow developers to get their products out on the market sooner.

Companies can release a minimum viable product (MVP) and apply future features with OTA updates rather than waiting for all the features to be ready.

When coupled with effective customer-experience management post-purchase, over-the-air updates offer good value for you and your customers.

4. Not using automated testing

Testing has come a long way in recent years. Gone are the days of QA teams manually working through lengthy checklists to ensure software behaves as expected.

Automated testing removes the need for much of the manual testing. Tools written by your engineers, as part of the software development process, can conduct:

• unit tests,
• end-to-end tests,
• integration tests, and
• performance tests.

This frees up your testers to focus on other testing activities less suited to automation—either because they cannot be automated or because the cost of creating the tools wouldn’t give a good return on investment.

5. Using unvalidated tools

There are a broad range of tools to help create, debug, manage, and support embedded software development.

However, not all tools are built equal.

Many tools used in medical software development must be fully validated. This means they must be thoroughly tested and verified to ensure they meet their intended purpose and do not introduce new errors or security vulnerabilities into the software development process.

Not all tools need to be fully validated, however. It depends on the risk associated with the failure of that tool. If the risk is deemed acceptable, or there are other fail-safes, like reviews of outputs outside of the tool, you can do a less rigorous assessment.

What’s the problem with using unvalidated tools?

There are several risks associated with using unvalidated tools in software development. These include:

Reduced software quality: Unvalidated tools may contain errors or bugs, which can lead to defects in the software. These defects can jeopardise the safety and efficacy of the device and put patients at risk.

Increased security risks: Vulnerabilities in unvalidated tools may be exploited to gain access to software systems or data. This could allow attackers to tamper with the software or steal confidential patient information.

Compliance violations: Using unvalidated tools to develop medical device software goes against compliance standards like ISO 13485. This can lead to warnings, fines and other penalties for the organisation during product approval.

Damage to reputation: If software applications developed using unvalidated tools are released to customers and contain defects, the organisation’s reputation can be damaged.

Validated tools are designed and developed to meet the highest quality and safety standards. They are also regularly tested and updated to ensure they remain secure and compliant with all applicable regulations.

Here are some tips for choosing and using validated tools in the development of medical device software:

• Identify the tools that you need. Consider the software development process’s different stages and the specific tasks you need to accomplish with the tools.
• Research the available tools. A wide range of validated tools are available for medical device software development. Compare the features and functionality of different tools to find the best fit for your needs.
• Evaluate the tools that you are considering. Before you purchase a tool, ensure it is validated by a reputable organisation. Or ensure you have the resources to validate it yourself – this is especially important if you will be using the tool differently to the requirements it has been validated against. You should also request a demo or trial of the tool so that you can evaluate it firsthand.
• Implement the tools correctly. Once you have purchased a validated tool, ensure you implement it correctly according to the manufacturer’s instructions.
• Have a plan for keeping the tools up to date and revalidate them. Software development tools are regularly updated to address new security vulnerabilities and improve functionality.  If you make the decision to update your tool, ensure you have a revalidation plan for any changes introduced in the tool’s latest version.
• Ensure you can opt out of receiving automatic updates to allow you time to revalidate the new release before it is implemented. This also allows you time to risk assess the changes and decide if you want to accept the newest version. This is also valuable if you do not have the resources to revalidate the tool mid-project, or if the risk of any updates causing defects is too high.

By following these tips, you can help ensure that the medical device software you develop is safe, reliable, and compliant with all applicable regulations.

6. Poor psychological safety

Does your development team feel safe to speak up?

People feel unsafe to voice their opinions if their workplace has poor psychological safety. This could mean that bold new ideas go unspoken, potential problems are never raised, and your project is exposed to unnecessary risks.

For example:

• Someone makes a mistake that will put the project behind schedule. Will they flag it up or try to bury it?
• A junior developer thinks they have a better approach than what a senior is proposing. Will they present their idea or stay quiet?

Among other things, psychological safety empowers all members of an organisation to speak openly without judgement. The value of this should not be underestimated.

Stages of psychological safety

Psychological safety is not one thing that can be introduced all in one go, but several stages that organisations must work towards:

Inclusion safety: Individuals and teams feel included.

Learner safety: The work environment encourages learning, acceptance of failure, and the exchange of knowledge.

Contributor safety: People can bring their ideas to the table and are given the means and space to work without fear of micromanagement. Their ideas are actively listened to, and ideas trialled where possible.

Challenger safety: People can challenge the opinions of others and not be discouraged from doing so.

You can read more about psychological safety in our ebook, Why is psychological safety critical to managing software risk?

7. Code quality isn’t invested in

If your stakeholders are chiefly concerned with time-to-market and budget, it can be easy to overlook the importance of code quality. However, code quality is essential for the safety and reliability of medical device software. Neglecting it can lead to delays in product development, increased costs, and safety incidents. In the worst-case scenario, it can result in severe harm or death.

Two key aspects of code quality you need to be aware of are:

Readability: ensures code is easy to understand and maintain, which helps to reduce the risk of errors and enables new developers to fix and refactor code of previous developers with ease saving costly bring-up time.

Test coverage: measures how much code is checked by automated tests. High test coverage helps to identify and fix bugs early in the development process.

Device executives—particularly those in compliance sectors—must prioritise code quality. This means investing in resources and tools to improve code readability and test coverage. It also means tracking and reporting on these metrics regularly.

Here are some specific steps that device executives can take to improve code quality:

• Implement a coding style guide and ensure that all code is written in accordance with the guide.
• Promote pair/ensemble/mob programming.
• Conduct regular code reviews to identify and fix potential problems.
• Use static code analysis tools to automatically detect common errors and vulnerabilities.
• Write unit tests for all code and achieve high test coverage.
• Integrate code quality metrics into your continuous integration and continuous delivery (CI/CD) pipeline.

By investing in code quality, a company can reduce risk, improve product quality, and ensure the safety of their users.

Quality above all

Even the most experienced medical device executives must remain vigilant to ensure these oversights don’t creep in. We’ve prepared an oversights checklist to help you score your project against these risks and the likelihood of them occurring: 7 common oversights checklist