Medical Device Link.

Final Thoughts

The regulatory climate for IVDs continues to evolve, with more countries establishing submission and inspection requirements. Although the promise of a single submission format and acceptance of reciprocal inspections still seem a long way off, there is one constant across regulatory groups: emphasis on a risk-based approach to compliance inspections and submission reviews. (Note that risk, in this context, refers to safety risk.)

There have been numerous guidance documents issued by FDA on this theme, from a risk-based approach to quality system inspections (QSIT 1999) to a risk-based approach to Part 11 compliance (August 2003 guidance). This emphasis on risk-based methods is also apparent in recent ISO/IEC standards, such as ISO 14971:2007 (Medical devices—Application of risk management to medical devices) and IEC 62304:2006 (Medical device software—Software life cycle processes), which uses risk classifications to define software process activities. Industry standards such as ISPE’s GAMP 5 have also taken up this emphasis.

The transition to an increased focus on risk-based compliance methods is pragmatic. With the increasing number and complexity of products that are regulated, it is apparent that traditional comprehensive assessment methods are no longer adequate. Instead, it is essential to focus on increased scrutiny of products that have a higher potential risk of patient injury as well as those products’ safety-related features.

What Does This Mean to Industry?

As the complexity of devices increases, so does the corresponding volume of documentation. Regulatory bodies lack the time and interest required to read voluminous submissions. The challenge becomes creating documentation for new products that supports successful regulatory submissions, ensures compliant inspections results, and does not make the design and development process overly burdensome.

In fact, risk-based practices that have long been recognized as the hallmarks of both quality management and good business practices are now encouraged for regulatory compliance. This philosophy is at the essence of the Pareto principle (i.e., focus on the most prevalent issues first) and Joseph Juran’s emphasis on the “vital few” versus the “trivial many.”

A risk-based approach allows separate documents and documentation detail dependent on whether a process is identified as safety-risk related. Submissions and inspections are part of being in a regulated business; however, with a risk-based approach, companies can control where this added overhead is essential and where it need not be applied.

Examples of how processes can be tailored to a risk-based approach include:

• Writing detailed design specifications and requirements for detailed design traceability, unit testing, and integration testing for validation of safety-related components only.

• Specifying device-detailed-design and component-level reviews for safety-related items only.

• Requiring design validation protocols for safety-related requirements to challenge multiple failure conditions, but allowing simple functional testing for other requirements.

• Using hazard analysis of critical control points to focus process validation boundary testing and determine acceptance criteria instead of challenging more numerous process parameters.

• Recording and retaining Device History Record data for test results that have an impact on product safety or essential performance, but not results of all test activities.

• Specifying electronic-records audit trails for Part 11 compliance only for transactions that impact product quality and safety and record integrity.

Condoning a risk-based strategy does not imply that non-safety-related functions are not important. It suggests simply that a less-detailed process may satisfy product-quality needs. For many companies, lesser documentation translates to following similar processes but not requiring formal auditable specifications.

A risk-based approach to design and process validation makes sense because the cost of failure of safety-related requirements is much higher than the cost of failure of other requirements. It is appropriate to require more process rigor for safety-related requirements to gain increased confidence in reliability. Although trying to apply increased rigor to all process steps is attractive, it is not practical if one wants to stay competitive.