Good Development Practices (GDPs) can be defined as the requirement to describe facilities and equipment; to document established procedures (including changes to those procedures and investigations of deviations); and to maintain method development data at the research and development stage. Part of the GDP helps any product development process to expose the affecting changes on the final product delivery. Such could be requirements, risks or customer complaints of interest for that product. As a Medical device vendor, you need to use the most common practice logic Flow Diagram based on V&V module. It includes requirements, test plan, and risk Management framework. In the diagram below ORCANOS | MEDICAL provides templates and regulatory guidance, with comprehensive traceability table (shown below).
A typical V&V traceability report characterizes the relationships between those items as a nested relationship diagram. The following example illustrates those relationships:
The report presents the flow of the IEC 62304 from the design phase to RISK and Validation. Such reports can be produced for different initiatives. Another initiative that is vital to your business, is the flow from your company business requirements down to implementation, and the validation of those requirements. Business goals are achieved by the R&D ability to implement them as they are described in the Market Requirement Document. Typically in a medical device product development process traceability relationships can be found across other aspects of the ISO 13485, such as management of customer complaints (Post Marketing Stage), their RISK assessment, and mitigation by design to those RISKs. More concepts used in the development process such as Standards integration (CE, FDA guidance, ISO, etc.) can be produced as documented evidence in your next audit.
The ORCANOS | MEDICAL system builds your entire Technical File or 510K submission files electronically, and maintains all necessary traceability between documents traceable artifacts which come from the requirements specified by your QMS system. This powerful tool is the way ancillary traceable artifacts are referenced throughout the product lifecycle.
One example is the medical device Essential Requirements statement. While it may be convenient to continue using regular Office tools such as Excel or Word, the complexities that come with the software is well known, especially when it becomes necessary for one document to reference another. Using process automation tools such as ORCANOS | MEDICAL, ensures consistency of traceability wherever it is used. The link between Essential Requirements and product Requirements are among evidence documents needed in your technical file or any other common submission. This ensures the ability to establish against any point where a standard requirement describe in simple text is used, what is the impact on items implementing those requirements in the product/process development. The ORCANOS | MEDICAL system will populate the relevant information for all documents or people.
If we talk some more about Risk Management, we may find that it is not difficult to describe and understand. Here is a simple description of the RISK management logic, We have hazardous situations that lead to harms. These hazardous situations should be documented, in order to mitigate and control an outcome to make the use of a device predictable and safe. However, the implementation of such a system is complicated by a variety of factors:
- Cross reference between many-to-many various system components
- Reusable data cross components
- Regulatory expectations
For this reason ORCANOS | MEDICAL software is offered as a means to organizing the various components of the system.
How To Organize Your Data
First, the data should be organized according to how it will be reviewed by internal/external auditors as well by the way it needs to be produced by the system out to official documents. After release of a product to the field which is referenced as post market, surveillance will evaluate the product on the basis of the user harm, the user hazard, and the number or percentage of field complaints occurrences. Our data fields should directly mirror the information returned for easy comparison (using traceability back to RISK), and respond to issues identified in the field. We should be able to track 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 RPN factor (ISO 14971) used to determine the frequency of hazardous situation results in a harm, is correct, or whether the probability of the hazardous situation occurring has been improperly assessed.
On that matter, ORCANOS | MEDICAL provides a post marketing surveillance system to collect customer experience and customer complaints, which can be linked to the RISK management artifacts on the same system. This is part of the combined solution ORCANOS | MEDICAL provides for all 3 sources of data: R&D QUALITY & REGULATION
Secondly, the data fields should represent common terminology. 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.
Thirdly, work items should be organized in such a way as to minimize linking complexity. It is possible to provide so many degrees of freedom in the system, that the flow of information becomes difficult to follow. This may result in some difficulty when training employees on the system, and explaining to regulatory authorities.
More about the flow diagram for definition of risk can be found in ISO 14971:2009 and required for compliance with both the United States and European medical device approval systems.