This article is part of an ongoing series on successfully outsourcing medical device software development and software development for other healthcare technology products.

Outsourcing medical device software development has the potential to accelerate product development and expedite time to market, but remember that the process of developing software is different from developing hardware. 

The first part of this series discussed what you need to be aware of before embarking on a medical device development project and critical considerations for picking the right development partner. This second installment will look at managing requirements changes in the software development process.

To start development in a reasonable timeframe and avoid requirements changes (which can be hugely disruptive during the medical software development process), several valuable strategies must be considered.

“Software as a medical device” vs. software for medical devices

In this post, we’re providing guidance for the entirety of software development in the medical device development field, but there are several essential qualification and classification criteria to consider when developing medical devices. 

The FDA (Food and Drug Administration) writes:

“Software, which on its own is a medical device – Software as a Medical Device – is one of three types of software related to medical devices. The other two types of software related to medical devices include software that is integral to a medical device (Software in a medical device) and software used in the manufacture or maintenance of a medical device.”

In 2013, the IMDRF (International Medical Device Regulators Forum) specified the three definitions, distinguishing “software as a medical device” (SaMD) as “software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device.”

While software as a medical device falls under the purview of this article, it’s important to note that SaMD requires its own Quality Management System and clinical evaluation process, which is different from the regulatory guidelines required for medical device development, of which software development is a critical component.

With these differentiators out of the way, let’s discuss best practices for developing a medical device. 

Why are requirements changes so disruptive in medical device software development?

When projects fail, inaccurate requirements gathering is often the culprit.

Inaccurate requirements gathering often results in changing requirements throughout the project as new information is discovered. Late requirement changes adversely impact the project by adding project and product risk and increasing the required schedule and cost for project completion.

Software development in healthtech is a systematic process that carefully walks through the standard development lifecycle to capture and address all the requirements and risks at the beginning of the project so the result is a smooth implementation stage where feature interactions are understood. When a requirement changes, implementation details that have already been thought through are altered to fit the new requirement, leaving the possibility of unintended impacts on existing features.

The later this happens in the development schedule, the less time there is to test and fix any issues that may arise, increasing the risk of a schedule slip and the likelihood of problems that make it into customers’ hands. Because of the strict documentation, risk management, traceability, and testing requirements for medical software, late requirement changes also significantly increase the project cost due to the rework required to address the changes.

 As a project moves through the development phases, requirements are examined for risk, testing of the requirements is planned, and requirement implementation is documented. When a requirement is changed, all of the auxiliary work associated with that requirement is also examined and updated as needed. The later this happens in the development cycle, the more mature the documentation and planning are and the higher the cost of rework is.

As you either hand off requirements to your development partner or develop requirements with them, understand that there will be an impact if the requirements change. However, it is unlikely that there will be no requirement changes throughout your project. Sometimes, you can’t define functionality in enough detail at the beginning of a project without an excessively long requirements development phase. 

Therefore, the key is to manage requirement uncertainty to create the least possible disruption to your project and the least likelihood of experiencing submission pitfalls.

Three strategies to mitigate medical device software development disruptions

If changes are disruptive, how do you avoid requirement changes for functionality already implemented?

Whether developing firmware for embedded systems, software for life-sciences solutions, or other healthtech use cases, disruptions to the development process are incredibly challenging when your team members are not sitting in the cubicle next door. Three of the most effective strategies are prototyping, communication, and planning, and they are vital when enlisting staff augmentation services with a partner development team.

#1: Prototyping the user interface

Since medical device software development requirements come from two main places—the needed product features and how the user interacts with the software—minimizing expensive changes from one of those places through prototyped medical devices is a good investment in project success. 

When communicating to your partner how you want your product to work, sharing storyboards and using models in addition to traditional requirements documents is very effective in communicating the product vision. Then, ask your partner to provide an interactive prototyped medical device that illustrates how they interpret the product working.

Typically, an iterative effort on this prototype will allow you and your partner to ensure the design intent is clearly understood and the requirements are accurately documented. Whether during the R&D (Research and Development) phase or sometime later, it’s an essential step.

This prototype is not expected to be a complicated, functional system but rather a quick, lightweight representation of user interaction. The requirement for the prototype is only that it represents the actual interaction in a way that all parties will understand. Also, when considering this prototype user interface, it is essential to remember that the user interface is much more than a screen. It includes buttons, sounds, lights, and vibration—any aspect of the product that communicates information to the user. 

This effort should occur early in the project so any hidden requirements can be found and documented before development starts in earnest. An early prototype will also enable the validation of user assumptions with subject matter experts or actual users early in the design cycle, further mitigating the risks of late requirement changes.

#2: Communication of critical decision points

As explained in the first part of this series, successful software development projects cannot be treated with a “set it and forget it” mentality. 

When managing medical device development partners, it is vital to understand when critical decisions are being made by your partners and the impact of those decisions. After requirements definition, a software development effort typically starts by determining the system-level architecture that defines the project’s structure and then builds on top of that architecture to achieve the different levels of functionality needed. 

It is crucial to understand which requirements drove the implementation direction, why they drove the direction, and which requirements now will be expensive to change. Knowing this information enables the management of expectations within your organization. It heads off future expensive changes by addressing incorrect or incomplete requirements before the development team has gone too far in implementation.

Critical requirements can be communicated in various ways depending on how the development partner is being managed. An effective method could be to hold a review at each software development increment to discuss the requirements that drove the current design and “lock” them moving forward. 

Another method may be to have the development partner color code the requirements document to show which requirements have already been implemented, which are in the implementation process, and which have yet to be implemented to communicate where they are in the development effort. 

Whichever method is selected, the development partner must regularly communicate which requirements will be difficult to change moving forward and why those requirements are driving implementation.

We write more about the importance of cross disciplinary collaboration and communication in the following article: Medical Device Engineering and Cross-Disciplinary Collaboration. Consider exploring it for more insights on this topic!

#3: Planning for changes to happen

As much as communication and prototyping can help eliminate expensive changes to the requirements, it would be naïve to assume that you can get through a software project without some changes to the requirements. 

Fortunately, most changes have signs that they could occur before they impact the project. These changes could be market changes like adding new communication protocol expectations, technological need changes like needing a faster sensor sample rate to ensure success in performance evaluation, or even a user need change like adding an entirely new product mode.

Since there will be some visibility that these changes may occur, it is essential to communicate the possibility of these changes immediately to your medical software development partner. If the development partner knows which requirements may change, they can help determine the potential development impact and the appropriate timing for risk management and mitigation. 

For example, if you become aware that the communication requirements might change to add another communication protocol to a device, the development partner could propose a different software architecture to allow easy expansion to meet the possible new requirement with an up-front cost that would be much lower than if the team was blindsided by the feature later. 

Keeping your development partner informed of possible requirements changes allows for upfront planning rather than late firefighting, which increases the chance of project success. 

Common techniques for planning for requirements changes include:

• Overdesign (as in the example above)
• Delayed implementation
• Breadboarding high-risk systems

Both delayed implementation and breadboarding deliberately dedicate time to work out outside dependencies and uncertainties before final implementation in the software. 

A general idea of what must be implemented is often enough for development to move forward while still working out the details. In all of these cases, collaborative communication with your development partner will ensure the design is as flexible as possible in areas with a high risk for change.

Communication, planning, and prototyping: three keys to reducing disruption in medical device software development

Employing the strategies discussed in this post on your software project will help you and your development partner ensure project success. These focus areas will enable you to circumvent the common challenges inherent in late software requirements changes, such as increased cost, schedule, and risk. 

The next part of the series will provide guidance on ensuring that your organization maintains productive cross-functional collaboration and that your project ends satisfactorily for both you and your development partner.