Author: Andreas Gerber, ANGIOMED GmbH & Co. MEDIZINTECHNIK KG
Section Leader Pilotserie / PE, 76227 Karlsruhe

"We always keep an eye on the quality of our products because tomorrow we may be our own customer."

As a leading company in the development and manufacture of minimally invasive medical devices, we need to ensure that weak spots are systematically detected and eliminated, deadlines are met and the level of quality is maintained during the planning phase for new products. For complex medical devices, constant product innovations and increasingly shorter development times result in the demand for increasingly higher levels of quality. The ISO 14971 standard, "Application of Risk Management to Medical Devices", demands this as well. In order to reach and maintain this high level of quality, a risk management system adapted to the needs of the company must be engaged in the initial development phases. This is the only way to fulfill the requirements placed by the approving authorities while simultaneously ensuring the product will be released on schedule.

What do the standards demand?
The ISO 14971 standard and the revised ISO 13485 standard "Medical Devices - Quality Management Systems" interact with each other. While the ISO 14971 standard demands that quality management is integrated into the risk review and control process, the ISO 13485 standard states that without a proven risk management system, CE certification will not be awarded to the product, and the basic requirement for placing a medical device on the market is therefore not met.

As of April 2004, the previous directive for risk analysis, EN 1441, was replaced by the significantly more comprehensive DIN EN ISO 14971, a standard valid worldwide that encompasses the entire risk management process and not just risk analysis according to EN 1441.

Every manufacturer of medical devices and in-vitro diagnostics is required to introduce the processes described in DIN EN ISO 14971 in its company and apply them to their risk management. In order to meet these requirements, many companies have already based their risk management on the market leader, Qware Riskmanager.

Requirements placed on a system
To effectively meet the risk management requirements, we considered an implementation using a computer-based program. The flood of incoming information, paper documentation collected over years and local, file-based solutions couldn't be handled efficiently anymore. We intend to migrate to a central database. However, it was feared that the data, once it had disappeared in the database, could only be found again at great expense. The technology is too complicated and the costs for maintenance too high. A system specification was therefore created that placed the following requirements on such a system:

• Process flow charter to create process flows. The flows are to be displayed graphically to obtain an overview of the entire process flow and to see how the process steps interact in order to optimize them.
• FMEA module to prevent errors in the design and development phases of new and existing products and/or processes.
• Control plan module to create inspection plans (control plans) as required by QS 9000 and Advanced Product Quality Planning for the purpose of quality assurance.
• Action management system to create and manage the resulting activities with reminder, escalation, and newsletter functions as well as evaluation capabilities in order to guarantee the fast flow of information and make an estimate of the required resources.
• Database system to avoid duplicate entries and data conflicts. The information obtained is to flow back into the existing project/product and therefore must be fast and easy to find.

Implementation => New structure in the Design FMEA
After completing a selection process, we decided to use the software module from the Plato AG. Each module is a link in the chain to fulfilling the required standards. By installing the new software modules, we quickly realized that the checklists we used previously were not effective. Expensive revisions with the resulting project delays were minimized through the use of the SCIO Matrix Analyse module. For customer-oriented product development, the QFD (Quality Function Deployment) method was used to analyze the customer requirements and implement these requirements in the product. In just one single step, functions and system structures were designed and specified. The result was a complete description of the system that delivered secure and understandable information about the overall system. The system can be analyzed down to the lowest level of detail, from the product specification to the component process level. It is possible to assign priorities to important functions and features using the assessment in the correlation field. "Critical paths" in the relationships between functions were detected in this manner. The number of large team meetings was reduced due to the systematic procedure. Before the first team meeting, the project leader and the head of the team meeting work out the matrix analysis. With the PPC (Product Performance Characteristic), the product characteristics and customer requests are documented in the X axis. The first level of the Y axis then represents the product to be replaced, the new design suggestions and the products from the competition.

Risk analysis kick-off meeting
Once the data is entered in the matrix analysis, the interactions are linked and suitable designs are chosen for the A-sample during the first team session with the corresponding departments. Using the matrix, the structured procedure can show the advantages and disadvantages of:

• the various designs
• the product to be replaced
• the weak spots
• unnecessary properties
• products from competitors

in a clear manner. The documents required include, for example, any samples, diagrams, PPC's, and specifications. Once a design has been chosen, the part list is recorded in the next level below in the Y axis and the relationships to the properties of the product are defined. This results in an overview of the requirements placed on individual components, assemblies and parts. Furthermore, the specifications of the requirements are documented in the X axis. Due to the structural design matrix, it is possible to go down to the level of the raw material structure and the manufacturing method.

From the matrix to the design FMEA
The data from the matrix analysis is automatically copied to the FMEA. Only the potential failures need to be entered after that. The main advantage of this method is that the members of the team are only needed for a short time for the FMEA, and no in-depth experience as a moderator is required. Potential effects are generated from the higher-level system, and causes are generated from the lower-level system in accordance with the VDA FF - F - FU (effect of failure - failure - cause of failure) method. Using this method, the time needed in the development phase to produce the risk analysis was reduced by 38%, and the number of design errors was reduce by 100%.

Assessing errors with the focus on the customer
Before starting a design or, later on, the process FMEA, the moderator gives a short introduction of each method to the members of the team, and they are also shown how to handle the assessment tables by the moderator. All functions are generally inspected on a line-by-line basis. The effects of a failure are examined individually to determine their severity for the external customer (patient, doctor, assistant) and for the internal customer (Production). While the VDA only specifies the severity for the end customer, this method also assesses the severity of the failure for the Production department in order to uncover any potential for optimization within the internal customer-supplier relationship. To minimize the time spent on discussing the assessments, the O, S and D assessments are evaluated using the standard specified earlier. Reasons for the deviations can be entered in the comments. To obtain an even better feel for the assessments, the VDA recommendations were converted to specific daily production figures.

From the flow chart to the control plan via the P-FMEA
The moderator creates an initial process flow chart with the process engineer. The process specifications are entered in the next step. The structure is an important factor when creating PFC's as the structure determines the AAW structure obtained later. From the process flow chart, the functions and specifications for the process FMEA are generated automatically for the first team meeting. Diagrams, samples and specifications are absolutely necessary to perform the FMEA in the team meeting. The moderator only has to guide the team to the failures, causes and effects by asking specific questions. The Control Plan module effortlessly creates the inspection/control plans as required by QS 9000 and Advanced Product Quality Planning. Using the SCIO database, it is possible to automatically generate control plans that are almost completely filled in from the existing FMEA. A small team then just has to add data regarding the control resources and scope of spot checks and random samplings. The reaction plan specifies the procedure to follow when an error occurs. The result is one PFC, FMEA and CP for each AAW. Due to the database structure, the data only has to be entered once in the database to enter the data in the various documents. When data is changed, all documents are automatically updated. Due to the modular design, an individual set of these documents can be assembled for new products.

Defining actions in the FMEA
Once the risk priority numbers (RPN = O x S x D) have been specified for each individual failure in the FMEA, the recommended actions are initially assigned the highest RPN. The recommended action must be taken for an RPN > 100 or a severity > 9. To quickly obtain an overview of the risks spread across hundreds of pages, a Pareto or RPN analysis can be performed simply by pressing a button. The risk matrix according to DIN 14971 is very effective. The risk matrix is used to define the level of risk. The term "risk" is to be analyzed in terms of a combination of two components.
1. The probability that damage will occur.
2. The severity of the damage with any possible effects (severity).
The diagram provides a good overview of the assessment before and after taking corrective action and is part of the risk management report.

Specifying actions in Ergon
In the modules named above, a number of other actions arise in addition to the FMEA actions (approx. 1000 actions) such as:

• Project-based actions (3 projects with 500 actions each)
• Process engineering (approx. 100 actions and rising)
• Employee-based actions (approx. 20 actions per employee)
• Department-based actions (approx. 25 actions)
• Audit-based actions (approx. 15 actions)
• CAPA (approx. 35 actions)

They are all integrated and coordinated in an ERGON action management system, and risks are displayed by the system and monitored by a deadline monitor. ERGON is a stand-alone software tool and a method used to initiate, implement and control the actions named above. ERGON has optimized the continuous improvement process for companies and contributes to an increase in productivity. The initiation of action based on goals (e.g. to minimize the error rate) and on results (e.g. from audits or complaints) is documented and communicated using ERGON. Actions are uniquely assigned to one person designated as responsible for this action, and this person can introduce additional actions due to the hierarchical design. This principle of cascading responsibilities defines the responsibilities for monitoring and performing the actions. The procedure is aided by a clear and configurable access concept. Resource management, deadline monitoring (reminders, escalations, monitoring entities) and assessment are the most important cornerstones of action controlling in ERGON. The use of a central database with ERGON provides the user with transparency and allows the user to utilize synergies. The open configuration capabilities of ERGON make it easier to present all personal task of a user, even when from other applications, in the form of an action gateway. Therefore the user always has an overview of all tasks to be performed. The tracing capability, which conforms to the standards, the archiving capability and their scalability permit its use in a wide variety of fields . In particular, the FDA requirements (21 CFR Part 11) are implemented in ERGON.

Medical technology has the leading role
The risk management process has become more complex with the introduction of the ISO 14971 and ISO 13485 standards in comparison to the process based on the DIN 1441 standard. The entire life cycle of a product now needs to be covered in terms of the risk analysis, risk assessment and risk control; from the product idea to the design input and from the manufacturing process to disposal. It is important in this regard that due to the auditing of information in later product phases, it may be necessary to reassess the risks, which in turn could lead to a modified product design. With this demand in mind and the simultaneous introduction of the Plato systems described, a significant improvement process has been detected, and at the same time the employees are learning the concepts involved. The amount of preparatory work and number of revisions has steadily decreased. The procedure developed, whose main goal was to disconnect teamwork from daily work, was able to constantly optimize the expensive teamwork. The participants from the various departments and levels all had access to the same up-to-date information through the intensive application of the method in a compressed time frame. In some cases, synergies were also utilized. A total of 1762 risk priority numbers were assigned to one product. After prioritization, 352 corrective actions were planned and performed. The average time spent on an FMEA was 20 days, and through consistent separation of the work done alone from work done in the team, this time was reduced to 14 days. During the evaluation of the FMEA it was discovered that ¼ of the assumed errors and failures were caused by machines and equipment. Almost half of these were due to error on the part of employees. This allowed us to achieve an enormous potential for improvement by reorganizing work steps and installing equipment at low investment costs. The systematic use of methods and the software modules improved the transparency and overall understanding in all departments. This permitted more effective communication, and a higher level of acceptance was attained in all departments. The procedure developed serves as a guide for other applications.