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 documentation challenge is to manage the product documentation simply as a set of documents, usually Microsoft Word or Excel files. Figure 1 illustrates this approach. DHF stands for Design History File, a set of documents and other records that must be maintained for the life of the medical device.
Unfortunately, this traditional “document-centric” approach has multiple drawbacks:
- Traceability is static—traces must be maintained manually; there is no automatic updating with changes during development and post-launch
- There is no defined workflow: Who can change what and when? What information must be linked and changed together?
- Difficult to manage changes, to know all the documents affected by a design change or to know what changed within a document
- Difficult to search across documents
- No way to efficiently manage product variants where there is a lot of overlap of risks, requirements, and tests
Traceability across the DHF documentation is crucial to understanding how the content of the documents is interrelated and to maintaining consistency between documents. With the traditional approach traceability is static because it is managed manually as ID/code #’s which are cross-referenced in each document (or in a separate trace matrix document). This trace information is laborious to compile and difficult to maintain over the life of the product. Sometimes the trace information is not updated with changes to the product design or documentation and so it degrades over time (until discovered in an audit).
The traditional approach may appear adequate for simple medical devices but its drawbacks become increasingly burdensome as product complexity increases, especially for products with software. Software-intensive products are more likely to have rapid design changes, triggering revisions to multiple documents, and highlighting the shortcomings of the traditional approach. And whether these documents are printed hardcopies that are stored in a fire-proof file cabinet or whether they are e-documents stored in an electronic document control system, the approach is still document-centric with the corresponding problems.
In spite of these inherent drawbacks, nearly two-thirds of medical device companies still use this traditional, document-centric approach. The rest use a modern approach using a relational database. Figure 2 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. Each document then consists of a group of those elements. In this scheme documents are actually derived from the structured data and can be exported from the database in whatever format desired. This gives the company 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 can do all this at a scale needed for complex products. These database applications are usually referred to as Requirements Management tools or sometimes, for ones with broader functionality, as Application Lifecycle Management (ALM) tools.
How does this modern approach using a relational database address the drawbacks of the traditional approach for documentation?
First, traceability is managed through the database application as a series of relationships between database elements. A wide variety of reports and trace matrices can be generated from the database to support different aspects of design controls and project management. For example, you can generate a report that shows where all of the risk mitigations are implemented and tested or a report that identifies all the documents that need to be revised if a software feature is dropped late in development.
A good requirements management tool can be configured to define a workflow around each element in the database that aligns with controls in your quality system procedures. For example, the quality system can mandate that all design requirements for a product development project be promoted to a certain state by a particular milestone in product development. Customized workflows can also ensure that only certain people can make changes to certain types of elements, such as risks in a risk analysis document. Common word processing applications do not support this level of control.
When a change needs to be made to a medical device, whether during development or post-launch, it is crucial to identify all of the DHF documents affected by the change. This can be very challenging with the traditional document-centric approach but is straightforward with a database application that links together all the elements of the documents. The individual managing the change just needs to follow the links to compile a full impact assessment of the design change (and not depend on the memories of individuals who worked on the product months or years earlier). And the database stores a detailed history for every single element in every document of what changes were made and by whom.
Word processing applications allow the user to search within a single document but what if you need to search across dozens or hundreds of documents? Database applications support this kind of global search, which is increasingly valuable as the quantity and complexity of documentation increase. For example, if a project team needs to update the terminology used for a particular safety feature, they can quickly see everywhere that safety feature is mentioned across all the product documentation.
Product Variant Management
If a company develops multiple products that are based on the same design (product family) then a relational database provides a much more efficient way to manage the DHF documentation. Document elements in the database can be readily shared amongst two or more products while maintaining exact documentation for each product. For example, if a company is developing two versions of a new product (a fully featured and a bare bones model for two different market segments) then 95% of the product requirements may be identical between the two products. Within the database, these 95% of the requirements would be defined as belonging to both products and the remaining 5% as unique to one product. There’s no need to duplicate the shared requirements and manage them separately. Anyone making changes in the database to either shared or unique requirements will always be able to know which was which. The same efficiencies apply to risk analysis and test documentation.
The modern database approach to DHF documentation provides two other important advantages: better test management and a robust collaboration platform.
Additional advantage: test management
Good requirements management tools include test management functions as well, which support test execution and recording of test data. Since design verification and validation (V&V) testing at a medical device company is both labor-intensive and intensively scrutinized by regulators, any improvements in the process can yield big time savings for the company. This “paperless V&V” approach means the software tool guides test execution and the testers click and type results instead of writing them on a piece of paper. Reviewers no longer have to waste time trying to understand messy handwriting with words and numbers scribbled into tiny rectangles on a sheet of paper and tests don’t have to be repeated because some test steps were missed. It also allows for easy capture of screenshots and other test data during execution, which are automatically linked with the pass/fail results. Test management tools also make it easier to manage re-tests, especially important for complex, software intensive product development projects.
Additional advantage: collaboration platform
A relational database provides a robust collaboration platform because everyone on the project team is working from a single source of truth about the product. There is no scrambling or confusion to find the latest draft of the product requirements or some other document—the latest product information is in the database and is always visible to the entire project team. This is especially important for distributed teams, where members of the team may be split across multiple organizations and communication is more challenging. Anyone who has ever scrapped expensive components which were purchased based on a down-rev document or written code to an outdated software requirements specification can appreciate how important it is to always have direct access to the latest design information.
With all these advantages, why doesn’t every medical device company switch over immediately to the modern approach? We’ll discuss the challenges of implementing a requirements management database application in a future blog post. Or contact us to find out how your company can quickly make this transition.