Choose The Right Development Process For Medical Products

Posted on May 13, 2020 by Steve Bedford

Several years ago, DornerWorks expanded into a building that once housed a reality company. Prior to the remodel, I was wandering through the old offices and came across a beautiful 4 feet by 6 feet map of the greater Grand Rapids area hanging on a wall of one of the hallways, a work of art left behind for some reason unfathomable to me. I promptly rolled it up (with permission), saving it from the impending demolition.

An old map of Kent County, Michigan.

I love to look at the thing, to plot out new bike paths, to look for odd street names. One of my favorite features is the M-6 freeway along the bottom edge, plotted in red because it was planned but not yet built. I am sure later editions show M6 in black like the rest of the roads, but this map is a snapshot of a specific time; it isn’t updatable, aside from issuing a new edition. While I love the map for its nostalgia, it is not the most practical roadmap.

What does any of this have to do with medical software development processes?

Product development could be compared to exploration, to setting out on a journey from a specific location to a desired destination. Say we want to build a thing that does these three important tasks and that is affordable for the end user. Or say I want to ride my bike from our office building and end up at Riverside Park. I know I need to head north, and a bit west. I know some streets are safer for a bike than others. If I come across an unexpected closure, I could check my big 1996 print edition of the greater Grand Rapids area, but it would become quite unwieldy on the side of the road, aside from the fact it is nearly 25 years out of date.

On the bike ride, it would be much more useful to have a GPS enabled map app on a smartphone that is able to update traffic and road conditions during the ride. In the same way when creating a new product, having a software development process that is adaptable, flexible, and updatable is much preferred.

How do we balance safety critical software with efficient development practices?

It is possible to assume that a more rigid development process like the Waterfall method would be the safest approach when trying to write safety critical software for a medical device. Requirements are defined up front and in detail. The design is set before starting to implement, it is just a matter of executing the plan, then integrating and testing components.

This works well enough for projects without much complexity, where there is little to no need for discovery, or for updating requirements along the way. This does not lend itself well to innovative product ideas that have never been tried before, when new discoveries require detours, or when new features lead to a different destination entirely. When roadblocks pop up on certain features, the entire program can grind to a halt.

Diagram 1: Waterfall Method of Development

Waterfall tends to push high risk and difficult to execute elements to the end of the project. Integration and system testing take place very late in the game. Compounding complexity and scope changes are difficult to handle, leading to unreliable up-front schedules and estimates, which themselves are a supposed benefit of the method.

Diagram 2: Agile Method of Development

At DornerWorks, we help our clients thrive with a more agile approach.

Test early and test often

Unit testing is a cost-effective way to test software early in the development process. Translating requirements into practical code is made more efficient by implementing and testing the conditions of the requirements into practical tests. Tests are written to check boundaries and limits of system interactions, and even allow the developer to test specific conditions that would be impractical to cause repeatably in hardware.

Unit testing was especially useful when writing an event logging system for College Park’s Espire Elbow. We needed to record system configuration data and error conditions to on-board flash memory to be recalled later. To ensure proper error handling, we needed a reliable way to cause the error conditions. Rather than poking and prodding at the hardware to attempt to cause these errors, they were programmed into unit tests, giving our client confidence that all their bases were covered. Part of that confidence comes from:

Continuous Integration

With as many moving parts as there are in a myo-signal controlled, wireless enabled, battery power prosthetic elbow, it is easy to imagine how the complexity could compound too quickly to make testing practical. That is why we don’t wait until the end of the project to work out all the kinks of integration, and we don’t let early features sit idle and grow outdated from later developments.

Continuous integration includes automated unit and regression testing throughout the development process, as well as automated tests run on a dedicated hardware setup, so that with every new software build we can be confident that our implementations continue to work. This frees us to look ahead instead of behind, to anticipate potential issues further along the road, and guide our clients towards new solutions.

Define up front but refine as we go

On a multi-year project like College Park’s Espire Elbow, it would have been nearly impossible and cost prohibitive to have every detail nailed down before beginning to implement features. Starting with the things we knew for sure, we worked with College Park to tailor a solution that fit their needs. One of the largest unexpected discoveries was that the prosthetists in charge of fitting patients with the prosthetic device would greatly benefit from having a mobile app to configure and update the elbow wirelessly. Wireless connectivity to a mobile app was not on the original development roadmap, but the DornerWorks team was able to help guide College Park to a streamlined solution for their end users.

Choosing an experienced guide makes all the difference

At the start of a project, it is important to have the right kind of map, one that is both accurate and adaptable. There are fixed road signs along the way in the form of standards like IEC62304 and IEC60601. It is often helpful to have an experienced guide to read the signposts along with the terrain to be able to navigate the landscape of new product design. Contact us today and schedule a meeting with our experienced team of guides. We will collaborate with you on medical product design that grows your business and betters the lives of your customers.

Steve Bedford
by Steve Bedford
Embedded Engineer
Steve Bedford is an embedded engineer at DornerWorks.