Medical: A Traceability Data Model
To read the first blog in this series, Comprehensive Medical Device Risk Management, please click here.
The first task of any product development process is generally to discover, define and link the items of interest for that product. This is best accomplished in a logic Flow Diagram, and is the basis for developing the Design V&V test plan, and risk Management framework. One example of such a diagram is the Polarion medical device template comprehensive traceability table (shown below).
A typical Report used to characterize the relationships is a nested relationship diagram.One example of such a diagram is shown below:
The flowchart is intended to represent the design, manufacturing, and risk management relationships typical in a medical device product development process. It also integrates concepts used in the development process such as Standards integration (FDA guidance, ISO, ASTM, etc.), images, and text justifications.
Other Artifacts
One of the most powerful leverage points in the use of a requirement management tool is the way ancillary artifacts are referenced throughout the design history file (DHF). One example is the medical device intended use statement. It is convenient to define the text once for approval, and then reference the tagged work item wherever it is used. This ensures consistency in the text, and the ability to establish every point where the standard text is used, which is critical to determine the full impact of a change, and assures the change is properly propagated to all relevant documents.
Conceptually, risk management is not difficult to describe and understand. We have hazardous situations that lead to harms. These hazardous situations should be documented and mitigated to control an outcome to make the use of a device predictable and safe. However, the implementation of such a system is complicated. This is due to a variety of factors including the number of variables needed to describe the relationships between the various system components, options for whether to make these concepts unique and reusable, many-to-many database relationships, and sometimes vague or confusing regulatory expectations. For this reason, the following is offered as exploration on how these various components of the system can be organized.
First, the data should be organized by how it will be reviewed. After release of a product to the field post market, surveillance will evaluate the product on the basis of the user harm, the user hazard, and the number or percentage of field occurrences. Our data fields should directly mirror the data returned for easy comparison and response to issues identified in the field. We should be able to see the occurrence of a harm in the field and directly compare it with the risk management process. This will allow us to immediately evaluate whether the factor used to determine how often the hazardous situation results in a harm is correct, or whether the probability of the hazardous situation occurring has been improperly assessed.
Second, the data fields should represent common terminology. The regulatory bodies have defined what is meant by a hazard, or hazardous situation. We should build the regulated terminology into our model to provide a system that helps auditors better understand our intent without additional explanation.
Third, the work items should be organized in such a way as to minimize the linking complexity. It is possible to provide so many degrees of freedom in the system that the logic becomes difficult to follow. This can make training of employees on the system, as well as explanation to regulatory authorities difficult.
The following is the flow diagram for definition of risk found in ISO 14971:2009 and required for compliance with both the United States and European medical device approval systems.
