Software As A Medical Device: Development Tips

By Inga Shugalo, Itransition

The rise of the medical internet of things has propelled the appearance of software as a medical device, or SaMD. The tools are gaining prominence and, according to Business Insights, the market will exceed $86 billion in 2027. As for the specific types of software involved, Business Insights’ researchers name solutions for PCs and laptops, smartphones, tablets, and diverse wearable devices.

For developers all that looks familiar, and the market is promising. So, is it easy to succeed in that field? No, it’s not, as there are the specifics developers need to keep in mind. We’ll consider them below.

Defining Your Tool

This issue is two-faceted. First, medical device software is not about SaMD alone. There’s another group of software solutions for medical devices — software in a medical device, or SiMD. Though the two types of software are parts of medical devices, their key functions differ. SiMD solutions ensure the actual medical device operation; they can’t provide any medical service on their own.

SaMD solutions are fully-fledged medical devices in themselves. Such tools enable continuous monitoring, screening, diagnostics, and even condition management. As for the types of tools, those are remote patient monitoring devices, mHealth, blood sugar monitors, and more.

Whatever solution a team chooses for development, they should keep in mind that the tool may directly affect people’s health. Hence, the tool creation should be guided by FDA’s 21 CFR 820.30 or Design Control.

And here comes the other side of the issue. One of the Design Control requirements obliges SaMD developers to formulate the intended use of the product. This definition should be clear and linear to facilitate FDA certification.

Starting With Pre-Development

Having chosen the type of tool, developers tend to dive into medical device software development immediately. Nevertheless, specialists recommend kicking off with the so-called preparatory phase. During this relatively short time (2-4 weeks), the vendor’s BA specialists and development team gets to know the provider’s specifics and discuss the product vision with them. Well-versed in technical aspects, the vendor’s specialists help the provider gather testable requirements and formulate them precisely. As a result, the project team obtains a well-documented product vision. Besides, the vendor’s team helps the provider collect and revise the documents required by the relevant ISO standards.

Gaining FDA Approval

Valid product definition alone does not guarantee FDA certification. There are other important aspects to cover. Luckily, the regulation presents them in a fog-free manner. So apart from the intended use, the team needs to clearly explain how to:

• Meet the users’ needs in detail.
• Perform risk analysis and ensure product safety for users, based on ISO 14971.
• Validate the tool, i.e., run quality assurance (QA) and prove that the selected implementation scenario ensures that users’ needs will be met.

As FDA certification may take time, a team may be tempted to prepare the needed documents at the very project start. However, experts advise against the hurry. They recommend concentrating on ensuring FDA approval when the product is at the final stage of development. Otherwise, the rework loop may cause delays in the development and prolong the time to market.

Ensuring Validation

According to Statista, in mid-2019, software issues made the number one reason for medical device recall in the US. Hence, SaMD solutions need comprehensive QA and validation. The latter consists of checking if the specific requirements for the intended use have been fulfilled in their entirety. In this context, experts offer some noteworthy tips.

First, in medical device development (MDD), validation spans not only the product but also each tool enrolled in the development process. Luckily, only the tool features that are directly involved in the product development should be validated.

Another critical issue is traceability. This concept is the key to success in the field. The main point here is to make sure each feature or test case can be traced back to the corresponding product requirement and the changes introduced. Unfortunately, failing to ensure this seemingly simple traceability is quite commonplace. One of the reasons for this is that there may be many product versions involved.

This is a logical situation — as a rule, several teams are participating in a SaMD project, including developers, testers, business analysts, and others. Each team manages the project requirements independently and uses its own versioning system. However, as the project is developing, the versioning may grow more and more complex and finally turn chaotic.

Later, incorrect tracing in one team may provoke mistakes or confusion for other teams. Unfortunately, such mistakes may be pricey — experts state identifying and fixing such issues may cause the project cost to double or triple.

To avoid such situations, MDD professionals recommend marking requirements with tags or other unique identifiers right from the project start. Specific requirement management software may be of help here. This way teams can trace their tasks and relevant changes right to the project requirements and cross-link them with corresponding tasks of other teams. Besides, bottom-to-top requirement traceability allows for swifter FDA certification, and the project team can deliver the solution without delays.

As for SaMD quality assurance, there are some specificities as well. It’s better to start testing as early as possible. Apart from the traditional functional and security testing, SaMD testers should also perform independent unit, integration, and system testing, in addition to peer code review. Such measures help make sure the bottom-up traceability is in place.

Summing Up

SaMD development is not an easy task. As such solutions may affect health, their development is subject to the FDA’s Design Control, which puts some extra burden on developers’ shoulders. The key point to alleviate this complexity is to trace product requirements and changes. When they are observed throughout the project, the team is likely to ensure swift FDA certification and speed up time to market.

About The Author

Inga Shugalo is a Healthcare Industry Analyst at Itransition, a custom software development company headquartered in Denver, Colorado. She focuses on Healthcare IT, highlighting the industry challenges and technology solutions that tackle them. Inga’s articles explore diagnostic potential of healthcare IoT, opportunities of precision medicine, robotics, VR in healthcare, and more.