A Map for Commercializing Software-Driven Medical Devices

You have a breakthrough concept and even an early version that works or sort of works. Now you have to turn it into a reliable medical device that will meet FDA’s scrutiny and do well in the market.

Even early-stage life science projects initially intended only for use in research often migrate toward commercial products that must adhere to regulatory requirements. Typically, the scientists on the project don’t have the software skills or experience required for productization. Software specialists will start with good planning. Getting the software completed for a commercial product can be a bumpy journey, but this basic map can help smooth the ride.

While you begin with a proof of concept, you shouldn’t aim to reuse much of that software or expect the final product to look very similar. That original system shows your idea can work but probably has unexpected errors or crashes, produces some invalid results, and requires a lot of hand-holding to use. The proof of concept is good for demonstrating what the device can do but is not a sturdy foundation to build on.

Solid Planning is a Critical Success Factor

Identify Inefficiencies by Mapping Workflows

After your initial planning, move on to planning the various workflows. You will need to map each workflow out and then revise a few times for improved efficiency and ease of use.

Physical Workflow. In life science products intended to process samples, focus on reducing the time required to process those samples and increasing the success rate. Determine how you will track samples. Perhaps you will want to use barcodes to automate data entry. Find instances of idle time for one sample that you can take advantage of by doing other work on the next or previous sample. Figure out if you can use batches and racks, and determine their appropriate sizes. Investigate newer technologies, such as smart consumables from Sony DADC BioSciences.

For medical devices intended for patient treatment, document the patient workflow for the device use from beginning to end. Determine what information the system needs at each step and how that data will be delivered.

Data Workflow. Record when a sample or patient record goes in and a report comes out, and detail what happens to the data in between. Document how the information is input at each step, where it is stored, and who needs to see it and when and where. Look for easier ways for input as well as output, such as exchanging data with an LIMS or HIS, or a report on a Web interface instead of a printout.

User Workflow(s). Consider the various tasks the software must perform and the types of operators for each. Design user interfaces (UIs) to accomplish the tasks at a high, rough level with slides in PowerPoint or another lightweight application. For a complex or critical workflow, consider developing a functional UI prototype using Sketch or a similar software tool, so you get it right. Just don’t expect to reuse the code in the product.

The goal is to prototype quickly without concern for robustness of code. You will make lots of changes, so investment in elegant code is wasted at this stage. ?Throughout the planning stage, formally record and update the requirements. This is critical not only because you’ll need them for your 510K or PMA submission, but also because they direct your development effort.

Requirements set the scope, let you know when you’re done, and help you prevent feature creep. A good requirement statement is clear and unambiguous, atomic, and verifiable. A requirement should not be stylistic, express an opinion, or be open to interpretation. For example, “The system shall process a sample plate in under 10 seconds” is a good requirement because it sets clear boundaries and is measurably testable. ?

Time Savers ?

Limit the requirements to what you want to verify, and do not include how you want the feature to work; that will be addressed in specifications. If your requirements include “the how,” the verification process will be burdensome. ?

Prioritize the requirements. It’s rare that a first release product addresses all the imaginable features, so identify the importance of these features up front. When facing schedule or budget issues, the priorities will help you decide what to defer or cut. ?Some developers might shortchange the planning process to show quick progress, and there is even a misperception that development without planning is the agile approach to software development. With agile, there is still planning; it’s just not all done at the beginning of the project. Instead, the detailed planning is done “just in time”, meaning not until you begin to work on those features.

There are some aspects of agile that must be done differently to develop a regulated product. For example, agile directs a project with user stories like, “As a clinician, I want to be able to observe results from a particular date.” That’s not enough for a regulated product, so break the stories into multiple requirements that a software developer and quality assurance (QA) engineer can implement and test: Store the results in a database, encrypt the data, show results for a specified date range, and archive and dearchive the results. (For related information, see Using Agile to Achieve Rapid Failure.)

Keep Everyone Headed to the Same Destination

At this point, everyone is anxious to start coding, but there’s still more planning to be done, and it’s the kind not everyone enjoys: functional and design specifications.

Documenting specifications upfront and maintaining them throughout the process provides guidelines for software developers and quality assurance engineers; they ensure everyone is headed to the same destination.

Functional specifications are written primarily from a user’s perspective. They describe the actions on and between the screens, plus any hardware that is affected by or that affects the screens. Developers then write the software to match the functional specification, and the QA engineer tests against it (although not for formal verification and validation, which is distinguished later). Screenshots can be included in the specification.

When following an agile approach, the specification would not be completed upfront but continuously updated to reflect features about to be coded.

Design specifications ensure the coding structure is well thought out. These specifications are consumed by the software engineers as guidance for implementation but can also be helpful for product maintenance. Included in the document are the system architecture, state machines, protocols, database schemas, algorithms, and the aspects of standard toolkits that will be used.

You will also need to determine what tools to use. Three critical tools needed are source control, bug tracking, and project management. These tools can come in many different forms, from single-purpose to fully integrated application life cycle management suites. Open-source tools can be perfectly suitable, too. Be sure to plan the time to set them up and configure the tools for your needs.

For a regulated product, be sure to validate the tools. Working with integrated multirole tools requires a bigger time and monetary investment. One way to manage the burden is to break up the adoption into components. For example, set up and validate Microsoft’s Team Foundation Server for only the bug tracking and source control; you can do the same for continuous build integration and automated testing later.

Finally, during the planning phase, identify what you will need for testing, verification, and validation, and when you will need it.

A good process includes testing throughout and may include unit tests and load and performance tests. In some cases, the tests can be automated to run when code changes and new modules are checked in. SQA engineers will augment automated tests with solid manual testing at milestone points to uncover remaining bugs.

Formal, written verification protocols are needed to demonstrate that each requirement is met. During the planning stage, you determine the protocols needed and create a traceability matrix to document where each requirement is verified. Writing the actual steps and expected results happens later, during the coding phase, but is based on the requirements and functional specification.

Validation testing will confirm the product performs as expected for the intended application. This form of testing often involves domain experts and the full system at its intended environment. Again, the tests required are identified during planning but not created until coding is underway.?With the planning done and by using professional, experienced software developers, QA engineers, and a project manager, the implementation will proceed much more smoothly. You’ll still face some problems along the way, like unexpected technical hurdles and staff changes. But you can review your prioritized requirements, triage the least important, avoid feature creep, and defer bug fixing where appropriate. ?

Planning Again ?

When you are ready to ship, it’s time to begin planning for the next version. Start by doing the following:

Finally, you’re ready to begin the development process all over again. For the next version of your software, you’ll also consider your triaged bugs and features from the earlier release, new developments and technologies in the market, and user feedback and requests based on the first version.

By applying thoughtful and organized upfront planning for the software, you are much more likely to end up with a commercial success.

Andrew Dallas is president and CTO at Full Spectrum Software. For nearly 20 years, Full Spectrum Software has developed software and provided quality assurance services for the medical device and life science industries. The firm is ISO 13485 certified and follows the IEC 62304 standard for software development.