Case study on how Charles River Laboratories Preclinical Services Edinburgh developed a CAPA (Corrective and Preventative Action) system In house
This paper will outline the experience Charles River Laboratories Preclinical Services Edinburgh Ltd had in developing our own Corrective and Preventative Management System in house. It will outline the challenges faced and the very real benefits obtained in developing a CAPA (Corrective and Preventative Action) system in house. Charles River Laboratories Preclinical Services Edinburgh Ltd, is a large very diverse Contract Research Organisation with 800 staff, and more than 15 scientific departments. The main activities on the site are performed to meet GLP (Good Laboratory Practice) regulations however we also work to GMP (Good Manufacturing Practice, GCP (Good Clinical Practice) and to GCPv (Good Clinical Practice Veterinary) regulations. In early 2000 we identified a need to replace our old GLP Master Schedule with a system based on current technology. GLP requires facilities claiming compliance to maintain a Master Schedule of studies. Our GLP Master Schedule had performed the functions of a Master Schedule adequately for a number of years however as it was based around outdated software it did not have all the computer systems controls, audit trails etc required. As we would be replacing the Master Schedule we decided it would be an opportunity to get a system that included CAPA functions as well as the Master Schedule functions. At that time we were using a paper based system to log CAPAs, consisting of typing up audits and inspections in Word templates, printing out the audits and inspections, signing and dating them and distributing them by paper. It was also decided to include key functions of the Quality Assurance (QA) department such as documenting study, process and facility inspections in the replacement system. It was therefore decided to include the full reporting of all types of inspections, plus the CAPA elements, in the replacement system. The first step of the project was to generate a Requirements Specification listing all these varied requirements in one approved document. (In summary the replacement system would need to function as a Master Schedule, as a CAPA system and to include other key QA processes as required). Using this Requirements Specification several possible suppliers were contacted to arrange demonstrations of their product. At this stage it became evident that none of the suppliers could meet our particular needs. There were many CAPA systems on the market but there were none suitable that also met our expectations of a Master Schedule. As we had IT Development expertise in house it was decided to develop the replacement system ourselves. Armed with the approved Requirements Specification, development of the system commenced, following classical Software Development Life Cycle Methodology. As a large project the development phase took over a year. There was a very thorough design and analysis decision making process, part of which involved the development of a Prototype which was used by QA personnel to trial the required functionality. After development was complete the system was passed to the End Users for formal Operation Qualification testing and release. The initial release did not include distribution of inspection reports. A competition was held to find a catchy relevant name and the winning entry was PaRIS which stands for Project and Reporting Information System. Shortly after the release of the first Version of the system, changes were planned to add functionality and improve the usability of the system, including electronic distribution of QA reports. For the second Version of the system the QA department spent a lot more time refining the requirements for the system and performing Report Management Reports process walk-throughs. A prototype of Version 1.1 was trialled by a sample of the main QA users and by Representatives from the Scientific User Areas. When Version 1.1 was rolled out it was found to be more streamlined and a much better fit to our routine QA processes. PaRIS System Overview The system is a web based application on an Oracle database, developed in VBnet and ASP.Net using PL/SQL and Crystal Reports. Module Study Function The system is a Master Schedule, listing all studies performed together with key study details. The system is set up so it can cover GLP, GMP,GCP and GCPv studies. The system is used to log and report study, process, facility and external supplier inspections. The system is used to log protocol reviews. The system also logs computer validation projects. Any resulting observations from inspections, either corrective or preventative, are logged on the system as individual actions. A great feature of the system is that it links to the internal e-mail system, so that personnel with actions are sent an e-mail from the system stating that they have an action and providing a link to the system and subsequently to the individual action. This function replaced a paper based circulation approach and speeds up the response time to actions. Over time this has significantly reduced the amount of long term CAPAs. The system is also used to log actions relating to GMP, Deviations, Change Controls and Out of Specification reports. Miscellaneous actions can also be logged using the same CAPA functions. All draft and final reports issued to sponsors are logged. The system allows production of a variety of Management Reports on outstanding actions, number of studies completed, number of inspections completed etc. The system is used by the GLP Archive staff to log the formal archive of GLP reports and data. Plans are in place to log audits on the system in the future further reducing the paperwork burden of QA activities.
Inspections
Actions
Archive Audit
What worked for PaRIS Several things worked well for PaRIS. In general the development of the system met the user requirements. The manipulation and tracking of studies and all associated Inspections, Audits, Observations and Reports on the system work well. We were successful in streamlining the QA Inspection – Action – Responses procedure. We were successful in the provision of a comprehensive management reporting facility. The Management Reports module works well using the information logged in the system in a flexible process. A robust relational database design to ease data storage and retrieval was achieved. We were successful in the integration of several technologies. We replaced ageing, hard-to-use and unsupported technology with supported flexible technology.
What Could be Improved in PaRIS ? Over time it became evident that various aspects of user interface, navigation, performance / speed could be improved. This was improved for Version 1.1 of the system but further improvements are still required long-term. The training on Version 1 of the system was too general; this was improved for Version 1.1 where detailed screen shots and User Guidance Notes were generated. Version 1 of the system was developed to a tight timeline and for this reason PaRIS was not marketed to the users as much as it needed to be. This was improved for Version 1.1 where End Users were much more involved in the changes to the system and were given more time to walk through the system functions in the prototype version and to suggest any required improvements. For this reason the user buy-in for Version 1.1 was much better. Advantages of Developing a System in House Throughout the course of the development of PaRIS we found some general advantages to developing a system in house. Communication was good as all required personnel were on site and readily available. The Developers already had a good business and regulatory understanding so did not have to spend additional time getting up to speed with the processes involved. As a result the terminology used on the system was familiar to the company, with not too much jargon. By developing the system in house we were allowed the flexibility to make the system match our company’s processes. We also retained the flexibility to modify the system at our discretion to adapt to changing business needs during its operational lifetime. We have also been able to easily adapt Management Reports as requirements have been identified. Commercial Off the Shelf (COTS) systems tend to be less flexible and slow to change in relation to an individual company’s specific needs so this was a big plus for us. We have IT support for the system on site. In-house personnel can communicate directly and in person and can perform fixes speedily. Developing our system in house had cost advantages as COTS systems can be very expensive and may have mandatory support clauses .The project provided a great opportunity to review our QA processes and to refine and improve them where required to make them more suitable for an automated system. Disadvantages of Developing a System In house Throughout the course of the development of PaRIS we found some general disadvantages to developing a system in house. The main disadvantage was being allocated End User time. In a busy organisation internal projects are competing for status against Sponsor-driven requirements. The development is not shared in a larger community as it would be for COTS systems so it is more difficult to identify and eliminate bugs. There may be a greater sense of defensiveness, “my baby” syndrome, where constructive criticism of the system is not best received in the first instance. Also the sense of responsibility for the Developers is greater. Developing in house can have hidden “opportunity” costs unless internal personnel time is carefully managed. There is a danger of diverging from the industry standard. What happens if industry expectations change? What if we are expected to classify findings for the FDA? We think we could modify the system in this instance but there may be other changes required. COTS systems will be ready to use so could be quick to set up and configure compared with developing a system from scratch. Conclusion / Recommendations In conclusion if we were to develop a similar system again we would get users more involved in the Requirements Specification and pilot the system more extensively to refine the processes in advance of actual use. Users get out what they put into the requirements and evaluation of the system. For the Master Schedule module which is basically just a database of all study information it is very good. The CAPA functions are also very good, but how to operate them was not as intuitive as we would have liked. Version 1.1 of the system greatly improved the usability of the system. This is probably in line with most experience of completely new computer systems. We found in Version 1 of the system that the more time spent on refining the requirements and process flows to match the daily tasks and of the users the better. Development is only a small part of the process albeit a critical one. The interface between IT and the users of a new system needs to be managed straight away from day 1 of the project. Then on an ongoing basis regular checks need to be made to ensure that software is achieving the requirements the users wanted in the manner they wanted. All in all the project was a real success in that we got our replacement Master Schedule with the additional CAPA and QA functions that we requested on time. Our IT personnel take great pride in this system and in their success in integrating several different technologies into a successful cohesive system.
Joanne Donald
Joanne has worked in the Quality Assurance field for 12 years. She is very experienced in all aspects of QA and has worked to GLP, GMP and GCP requirements. She joined Charles River Laboratories Pre Clinical Services Edinburgh Ltd as Electronic Systems Compliance Manager in August 2002. She is responsible for the regulatory compliance of any electronic systemin the company. She became a member of the BARQA Computing Committee in November 2003.