From CSV to CSA
The Center for Devices and Radiological Health (CDRH), FDA’s Center for Medical Devices, plans to issue a new guidance document called “Computer Software Assurance for Manufacturing, Operations and Quality Systems Software” (Computer Software Assurance for Manufacturing, Operations and Quality Systems Software).
The CDRH is the lead agency for this guidance, but the Center for Drug Evaluation and Research (CDER), the center for human pharmaceuticals, and the Center for Biologics Evaluation and Research (CBER), the Center for Biologics Evaluation and Research (CBER), also works in cooperation with CDRH.
The ISPE’s GAMP working team also participated in the development of the new guidance.
In other words, it will be able to handle not only medical devices but also pharmaceuticals.
Review of Part 11
In the pharmaceutical and medical device industries, 21 CFR Part 11 “Electronic Records; Electronic Signature” (“Part 11”), enacted in 1997, has mandated the implementation of CSV ( The implementation of CSV (Computerized System Validation) has been mandatory in the pharmaceutical and medical device industries.
This has caused many pharmaceutical and medical device companies to delay IT (automation) or hesitate to update their IT systems (computer systems).
This is because CSV requires a lot of documentation to be carried out, which has been a major burden for companies in terms of labor, cost, and time.
In other industries, such as food and chemicals, IT and automation have lowered costs and improved quality. In pharmaceutical and medical device companies, however, regulatory requirements have slowed such innovation.
The new guidance will also be the FDA’s common guidance for new computer systems that will replace Part 11.
Problems with GPSV
In January 2002, the FDA issued a guidance called “General Principles of Software Validation; Final Guidance for Industry and FDA Staff” (General Principles of Software Validation; Final Guidance for Industry and FDA Staff), which provides principles for the validation of software used in the design, development, and manufacture of medical devices. Validation; Final Guidance for Industry and FDA Staff” (General Principles of Software Validation) in January 2002, which outlines principles for the validation of software used in the design, development, and manufacture of medical devices.
This guidance provides software validation-related guidance to industry and FDA staff involved with medical devices.
First published in 1987, it was revised in 2002 with the publication of the QSR and Part 11 in 1997.
However, while the guidance describes medical device software (Product Software) in detail, it contains little on CSV for software that supports the quality of medical devices (Non-Product Software).
From Validation to Assurance
To begin with, documentation in CSV has been prepared for the purpose of presenting to audits and inspections by authorities, rather than for quality assurance of computer systems.
In addition, the compliance costs spent by the companies were passed on to the drug prices and other costs, resulting in a patient burden.
The new guidance is expected to eliminate the “complexities” of CSV.
What is important in IT and automation is to ensure patient safety, data integrity, and product quality. It is by no means something that can be successfully explained during an inspection by the authorities.
Therefore, systems that affect them indirectly rather than directly (e.g., education management systems) do not need to unnecessarily increase the number or volume of documents.
For example, it is not always necessary to create test scripts. The important thing is to keep an eye on the test results.
However, the principle remains that the absence of documentation or records means that it is deemed not to have been implemented.
The traceability matrix between documents also remains important.
scope (of a document)
The scope of the new guidance covers software used in the manufacture of pharmaceuticals and medical devices, measurement and analysis, and the performance of quality systems.
Software used for quality system fulfillment specifically corresponds to ERP, LIMS (laboratory database), LMS (educational management system), EDMS (document management system), event management system (complaint and CAPA management system), etc.
The new guidance includes the concept of critical thinking in addition to the risk-based approach that the FDA published in 2003.
This concept called critical thinking is at the heart of CSA.
Critical thinking, called “critical thinking” in Japanese, is a way of thinking that eliminates assumptions and preconceived notions, and tackles problems by questioning assumptions.
In pharmaceutical and medical device companies, compliance is often a goal or objective. Many managers and employees engage in activities to avoid violating regulatory requirements and avoid being cited by regulators. However. Isn’t the goal essentially to ensure patient safety by assuring product quality?
Quality assurance of computer systems must also be implemented with those objectives and goals in mind.
It may not make sense to exhaustively test every feature and simply keep a record.
Readers will be tested to see how much they can break down stereotypes and question assumptions.
The new guidance will take a risk-based approach.
As shown in the figure above, analyze the degree to which the computer system (each function of the computer system) poses a risk to the patient/product or to the quality system.
The result is a risk determination such as High, Medium, or Low.
This will determine the quality assurance approach.
One of three test methods will be determined: “Ad-Hoc,” “Unscripted,” or “Scripted.
Classify software into three categories.
Out of the Box (OOTB) corresponds to Category 3 in GAMP.
Configured is Category 4 and Custom is Category 5.
Calculate the risk level by multiplying the risk to the patient by the software category.
The risk level determines the activities for quality assurance.
５：Requirements are validated by robust scripted tests.
４：Requirements are validated by limited scripted testing.
３：Requirements are validated by non-scripted tests.
２：Requirements are validated by ad hoc testing.
１：Rely on vendor audits and basic quality assurance.
Transition from CSV to CSA
There will be many difficulties in getting them to move from CSV to CSA.
We need to dispel preconceived notions and eliminate the fear of being pointed out by the authorities.
And all employees must learn exactly what quality assurance is.
Improving quality will result in fewer complaints and less time spent on CAPAs and investigations. It will also reduce the number of people in the quality control and quality assurance departments.
Above all, it reduces the number of accidents in the market and makes medical devices safer for patients and users.
IEC-62304 compliant] Sample of regulations and procedure manuals goes on sale.
In this country, IEC 62304 (Medical Device Software – Software Lifecycle Processes) became a substantive regulatory requirement as of November 2017.
IEC 62304 was published in May 2006 and JIS-ized (JIS T 2304) in Japan in 2012.
The U.S. FDA also recognized it as a Recognized Consensus Standard in July 2008.
IEC 62304 specifies processes for the development and maintenance of “medical device software”.
Outside of Japan, evidence of software development based on IEC 62304 is required for medical device applications in Europe, North America, China, and other countries.
In other words, without developing “medical device software” in accordance with IEC 62304, medical devices (including stand-alone programs) equipped with software cannot be sold in Japan or abroad. However, IEC 62304 is very difficult to understand. What exactly should we do?
In general, process standards such as IEC 62304 are interpreted differently by different companies, and the content of the procedures can vary greatly.
・Even after reading IEC 62304, I don’t know what I need to address or how to do it.
・After reading IEC 62304, I don’t understand the scope of how far I should go.
・The details of IEC 62304 are still unclear in the construction of the document.
Many questions are raised, such as
By introducing this “Model for IEC 62304 Compliant Regulations and Procedures,” you can efficiently and effectively create a QMS that complies with IEC 62304.