Note: This is post #2 of a series which focuses on product development best practices for software-enabled medical device teams that want to ship faster.

In our first post, we compared two approaches to product development of software-enabled devices: 1) traditional, document-based, and 2) modern, platform-based.

In this post, Ultralight has continued our collaboration with Aaron Joseph–principal consultant with Sunstone Pilot and a seasoned expert in best practices for software-enabled devices–to explore how a modern, platform-based approach can streamline Design History File (DHF) documentation, enhance traceability, and improve flexibility in product development of software-enabled devices.

Docs or It Didn't Happen

Medical device product development involves many design and testing challenges. It also involves the challenge of documentation—writing and managing hundreds or thousands of pages of compliance documentation. The traditional approach to this Design History File (DHF) documentation challenge is to manage the product documentation simply as a set of documents, usually Microsoft Word or Excel files. These DHF documents must be maintained for the life of the medical device.

Unfortunately, this traditional “document-centric” approach has multiple drawbacks:

• Traceability is static—links must be maintained manually; there is no automatic updating with changes during development and post-launch.

  
  

• Difficult to manage changes, to know all the documents affected by a design change or to know what changed within a document.

  
  

• No defined workflow: Who can change what and when? What information must be linked and changed together.

  
  

• Difficult to search across documents.

  
  

• No way to efficiently manage product variants where there is a lot of overlap of risks, requirements, and tests.

In spite of these inherent drawbacks, nearly two-thirds of medical device companies still use this traditional, document-centric approach.

What do the other companies do?  In our previous post, we described how a product team was able to rapidly handle a last-minute product design change using “The Hub” (a set of software tools configured for rapid medical device development). In this post and subsequent posts we describe how The Hub works and how to leverage it to add speed and flexibility to medical device development while still ensuring rigorous compliance.

Smarter Data Structures

The diagram above illustrates this modern approach.

Here the contents of each document are represented as elements, such as individual design requirements, individual test cases, or individual risks. In this scheme, documents are actually derived from the structured data and can be exported from the database in whatever format is desired (and very rapidly).

This gives the product team much more control over the individual elements of each document and crucially, the relationships amongst those elements. It also provides more flexibility in comparing content, tracking changes, and tracking completion of documentation. And the software can do all this at a scale needed for very complex medical devices.

Note: These database applications are usually referred to as Requirements Management tools or Application Lifecycle Management (ALM) tools.

In this platform-based approach there are no documents or rather documents are no longer used to manage the product data. Instead, the platform manages the product data and automatically generates updated documents whenever they are needed. By managing product data as sets of elements, we immediately gain some significant advantages: 

• We can automatically track changes in detail, element-by-element long before the next document revision is signed off (and we can know exactly who made each change and when they did it).

  
  

• We can define dynamic links from one element to another; for example, from a software requirement to the software test that verifies that requirement or from a risk to a risk control.

  
  

• We can easily tell if a linked element has changed since the link was defined; for example a SW test engineer can see when a SW requirement has been changed and that the test that verifies that SW requirement needs to be revised.

  
  

• We can define multiple attributes per element to keep track of important aspects of the information. For example, attributes can be used to mark the software requirements that are intended for a future version of the product instead of the current version.

  
  

  
  

When one or more DHF elements are changed or added the platform will show exactly which documents are affected and need to be re-generated.

The Hub in Action (Ultralight)

What is it like to use this platform-based approach? We’ll go through some simple examples with the Ultralight software to show how The Hub functions.

First, in this screenshot the user is editing a single design requirement for a new ultrasound device.  Note that the software has a main field for the text of the requirement (Description) but it also supports other fields such as Component or Category to help manage large numbers of requirements by sorting and filtering. In this case the Ultralight software automatically screens the requirement for verifiability as it is created to flag poorly written requirements (before they end up in DHF documents).

After creating the new requirement, the user can then view the relationships of this new requirement (SSR-1) to a higher level requirement and to the User Need (UN-2) that drives it. Being able to easily view relationships (traceability) amongst elements that may end up in separate DHF documents is a key advantage of The Hub.

After writing and tracing the requirements in the software, the user then generates a PDF document with all of the requirements listed in it. That document, once approved, becomes part of the DHF.  The image below is an example of what this requirements document might look like. The software can be configured to generate documents in a wide variety of formats to match the style in use at each company.

Conclusion

This platform-based approach of The Hub provides a more rigorous and flexible way to manage product data during development than using documents. It allows everyone on the product team to see the same information immediately (a “single source of truth”) and to quickly identify inconsistencies and gaps in the product information. In our next blog post we will describe how The Hub supports efficient and flexible V&V testing.

Aaron Joseph, principal consultant with Sunstone Pilot, is a biomedical engineer based in Waltham, Mass. With over 20 years of experience across a broad range of medical devices from surgical robotics to medical imaging to IOT and SaMD products, he helps clients efficiently tackle risk management and design controls for new product development.

Ultralight Labs develops software to streamline product development and documentation for the most innovative medical device teams. Book an Ultralight demo here.