5 Pharmaceutical Software Quality Assurance System BOJANA KOTESKA and ANASTAS MISHEV, University SS. Cyril and Methodius, Faculty of Computer Science and Engineering, Skopje LJUPCO PEJOV, University SS. Cyril and Methodius, Faculty of Natural Science and Mathematics, Skopje The risk-based nature of the pharmaceutical computer software puts it in a critical software category which imposes a must quality assurance and careful testing. This paper presents the architecture and data model of a quality assurance system for computer software solutions in pharmaceutical industry. Its main goal is to provide an online cloud solution with increased storage capacity and full time authorized access for quality checking of the developed software functionalities. The system corresponds to the requirements of the existing standards and protocols for pharmaceutical software quality. This system aims to ease the process of pharmaceutical software quality assurance process and automate the document generation required for quality document evidence. Categories and Subject Descriptors: D.2.4 [Software Engineering]: Software/Program Verification —Validation; D.2.11 [Software Architectures] Domain-specific Architecture General Terms: System Architecture Additional Key Words and Phrases: Quality assurance system, pharmacy, verication. 1. INTRODUCTION Life science companies are obligated to follow strict procedures when developing computer software. For example, computer software designed for food or drug manufacturing process must fulfill strict quality requirements during the software development life cycle. In order to prove that the developed software meets the quality criteria, companies must deliver documented evidence which confirms that computer software is developed according to the defined requirement specification. The document evidence is a part of the validation process, which also includes software testing. According to the Guideline on General Principles of Process Validation defined by Center for Drugs and Biologics and Center for Devices and Radiological Health Food and Drug Administration [Food et al. 1985], process validation is defined as "Establishing documented evidence which provides a high degree of assurance that a specific process will consistently produce a product meeting its predetermined specifications and quality characteristics". The Food and Drug Administration (FDA) agency applies this to all processes that fall under its regulation, including computer systems [FDA 2011]. In the present paper, we propose a quality assurance system for computer software solutions in the pharmaceutical industry. We describe both the system architecture and data model in details and the benefits from the implementation of such a system. The idea of putting this system in a cloud is to provide centralized solution with continuously moni- toring of the software development progress and its quality. Additionally, the cloud provides increased storage capacity and full time authorized access for quality checking of the developed software functionalities. Our system corresponds to the existing guidelines, protocols, GxP (generalization of quality guidelines in pharmaceutical and food industries) Author’s address: Bojana Koteska, FCSE, Rugjer Boshkovikj 16, P.O. Box 393 1000, Skopje; email: bojana.koteska@finki.ukim.mk; Ljupco Pejov, FNSM, P.O. Box 1001, 1000 Skopje; email: ljupcop@iunona.pmf.ukim.edu.mk; Anastas Mishev, FCSE, Rugjer Boshkovikj 16, P.O. Box 393 1000, Skopje;email: anastas.mishev@finki.ukim.mk. Copyright c by the paper’s authors. Copying permitted only for private and academic purposes. In: Z. Budimac, Z. Horváth, T. Kozsik (eds.): Proceedings of the SQAMIA 2016: 5th Workshop of Software Quality, Analysis, Monitoring, Improvement, and Applications, Budapest, Hungary, 29.-31.08.2016. Also published online by CEUR Workshop Proceedings (CEUR-WS.org, ISSN 1613-0073) 5:42 • B. Koteska, Lj. Pejov and A. Mishev rules and good manufacturing practice (GMP) methods specified for drug software system design and quality. The goal of the system is to provide a structured data environment and to automate the process of documents generation re- quired for quality document evidence. It is mainly based, but not limited on the quality requirements specified in Good Automated Manufacturing Practice (GAMP) 5 risk based-approach to Compliant GxP Computerized Systems [GAMP 5]. The main idea is to ensure that pharmaceutical software is developed according to already accepted standards for developing software in pharmaceutical industry, in this case, GAMP 5. The paper is organized as follows: in the next Section we give an overview of the existing computer software quality validation methods in the pharmaceutical industry. In Section 3, we describe the system architecture in details. Section 4 provides the data model of our system. The benefits and drawbacks of the systems are provided in Section 5 and conclusive remarks are given in the last Section. 2. RELATED WORK GAMP 5 [GAMP 5] is a cost effective framework of good practice which ensures that computerized systems are ready to be used and compliant with applicable regulations. Its aim is to ensure patient safety, product quality, and data integrity. This Guide can be used by regulated companies, suppliers, and regulators for software, hardware, equipment, system integration services, and IT support services. In addition to GAMP 5, there are several more validation guiding specifications that are commonly used in validating automation systems in pharmaceutical industry. The "Guidance for Industry: General Principles of Software Validation" [US Food and Drug Administration and others 2002] describes the general validation principles that FDA proposes for the validation of software used to design, develop, or manufacture medical devices. This guideline covers the integration of software life cycle management and the risk management activities. The "CFR(Code of Federal Regulations) Title 21 - part 11" [US Food and Drug Administration and others 2012] provides rules for the food and drug administration. It emphasizes the validation of systems in order to ensure accuracy, reliability, consistent intended performance, and the ability to discern invalid or altered electronic records. The "CFR(Code of Federal Regulations) Title 21 - part 820" [Food and Drug Administration and others 1996] sets the current good manufacturing practice (CGMP). The requirements in this part are oriented to the the design, manufacture, packaging, labeling, storage, installation, and servicing of all finished devices intended for human use. These requirements ensure that finished devices will be safe and effective. The "PDA Technical Report 18, (TR 18) Validation of Computer-Related Systems" [PDA Committee on Validation of Computer-Related Systems 1995] elaborates the steps to be taken in selecting, installing, and validating computer systems used in pharmaceutical GMP (Good Manufacturing Practice) functions. It provides information about practical documentation that can be used to validate the proper performance of the computer systems. According to the "1012-2004 - IEEE Standard for Software Verification and Validation" [148 2005] the term soft- ware also includes firmware, microcode, and documentation. This standard specifies the software verification and validation life cycle process requirements. It includes software-based systems, computer software, hardware, and in- terfaces and it can be applied for software being developed, reused or maintained. In [Wingate 2016], the authors provide practical advices and guidance on how to achieve quality when developing pharmaceutical software. Various processes utilized to automate QA (quality assurance) within CRM systems within the pharmaceutical and biotech industry and to define current QA requirements are presented in [Simmons et al. 2014]. Compared to the researches that have been made so far, no system for automatic quality assurance based on GAMP 5 has been proposed yet in the pharmaceutical industry. The system we propose should provide cloud based solution for pharmaceutical software management and automatic document generation based on GAMP 5. 3. SYSTEM ARCHITECTURE Fig. 1 shows the architecture of our pharmaceutical software quality assurance system. Pharmacists from different pharmaceutical laboratories access the quality assurance system solution hosted in the Cloud by using a web browser. Pharmaceutical Software Quality Assurance System Architecture • 5:43 Each user in the pharmaceutical laboratory has login credentials which allow him to log in to the system and to manage data for the computer software being tested. A user from the pharmaceutical laboratory 1 has permissions only to manage data for software solutions developed in his laboratory. Also, a pharmacist with provided credentials has a possibility to access the cloud solution outside the laboratory by using any electronic device that is connected to Internet and supports web browsing. The primary method for the authentication will be weblogin. Users are authorized to access only the data for the projects they participate in. Fig. 1. Pharmaceutical Software Quality Assurance System After the successful login, the user has a possibility to chose a software project from the list of the project being developed in his laboratory. According to example forms proposed by GAMP 5 [GAMP 5], the system must provide generation of the following documents: —Risk assessment form; —Source code review form; —Forms to assist with testing; —Forms to assist with the process of managing a change; —Forms to assist with document management; —Format for a traceability matrix; —Forms to support validation reporting; —Forms to support backup and restore; —Forms to support performance monitoring. 5:44 • B. Koteska, Lj. Pejov and A. Mishev The main idea of our quality assurance system is the automatic generation of the required document forms. The system should provide a preview of the missing documents by checking the inserted data for a selected software solution. The manual document filling is replaced by importing the data from the database. User is only responsible for inserting the data for the software solution by using the web interface. For example, if a user inserted the names of the software functions once, they will be used for the generation of all documents that contains records for the software functions names. When a change for an inserted function is required or a new test should be added, the user only selects the function from the lists of provided functions and change the required data. There is also an option for autofill of certain fields provided in the web interface such as: today’s date, user name, project name, function auto increase number, test status, etc. The details about the required data for successful generation of all quality documents (listed above) is given in the data model, described in the next Section. The benefits of using cloud solution for our quality assurance system is described in the Section 5. 4. SYSTEM DATA MODEL The data model of our pharmaceutical software quality assurance system is shown in Fig. 2. Each user has an oppor- tunity to access multiple projects that is authorized for. Projects must have at least one user. A project is composed of many functions which are divided into subfunctions. The entity "Document" is intended for storing the each generated document specified in GAMP 5, as listed in Section 3. The risk assessment form can be generated by using the "RiskAssesment" entity where each row represents one row from the risk assessment document. Each row of the "RiskAssessment" entity is aimed for a specific system subfunction. A given subfucntion can have multiple risk assessment row records. The entity "SourceCodeReview" is designed for the creation of the Source Code Review Report document. Simi- larly, each row from this entity represents a row in the Source Code Review Report and it is dedicated to a specific system subfucntion. Test Results Sheet is created for a system subfunction by using the entity "Test" and for each test a new document is generated. A Test Incident Sheet must be connected to the specific test. There might be more test incidents for a given test. Change Request is a document for proposing project changes. Each change request can have multiple change notes as shown in our data model. The "ChangeRequest" and "ChangeNote" entities are used for this purpose. The system backup is documented in the Data Backup document. In our data model this entity is named "DataBackup". A new document is created for each performed system backup. Data Restoration Form is aimed to be generated from data stored in one row in the "DataRestoration" entity table. Monitoring Plan Form is consisted of records for different Monitored Parameters. These data are stored in the "MonitoredParameter" entity table. Each row of this table represents a data row in the document. The Test Progress Sheet, Change Request Index, all forms to assist with document management (Document Circu- lation Register, Document History, Master Document Index, Review Report, Review Summary), Traceability Matrix Form, forms to support validation reporting are summary documents and they are generated with querying the data model by joining the required entity tables. 5. PROS AND CONS OF THE SYSTEM IMPLEMENTATION The proposed quality assurance system has both advantages and disadvantages. It can be beneficial in terms of: —Centralized solution accessible from everywhere; —Automatic generation of quality assurance documents; —Records for functions and subfunctions are used in multiple document creation; —Summary reports are generated from the existing data, no need to insert additional data; Pharmaceutical Software Quality Assurance System Architecture • 5:45 User SoftwareProject MonitoredParameter DataBackup M PK userID PK projectID PK mpID PK dbID N name projectTitle warningLimit type institution projectNumber frequencyObservation DataRestoration interval 1 country shortDescription monitoringTool behaviorIfFailure PK drID 1 notificationMechanism remarks username files resultsLocation backupMedia password M 1 M reason retentionPeriod storage Document 1 1 M backupTool PK documentID 1 Function 1 call type 1 PK functionID ChangeRequest subject functionTitle date PK crID 1 RiskAssesment 1 M change M approvedBy PK riskAssesmentID 1 1 1 reason M 1 1 relevance(GxP/Business) decision SourceCodeReview 1 riskScenario PK scrID Test probabilityOccurrence observation PK testID TestIncident 1 M 1 severity recommended title PK incidentID ChangeNote CorrectiveAction 1 riskClass attribute description PK cnID M date name detectability changes details M runNumber Required priority M result action M details status M status 1 Subfunction 1 PK subfunctionID 1 N subfunctionTitle 1 Fig. 2. Pharmaceutical Software Quality Assurance System Data Model 5:46 • B. Koteska, Lj. Pejov and A. Mishev —Name unification of system components (functions, subfunctions); —Easy accessible interface; —Allowing parallel data insertion; —Reduced number of errors in documents; —Cloud provides elasticity, scalability and multi-tenancy; —Only pay for the options you want in the Cloud; —Cloud provides easy backup of the data at regular intervals, minimizing the data loss; —No need of an investment in hardware and infrastructure. As a main possible disadvantage is the Internet connection factor. We cannot rely on an Internet connection to access the data if Internet goes down on user side or on the cloud provider’s side. Also, the users do not have physical control over the servers. 6. CONCLUSION In this paper we propose an architecture and data model for pharmaceutical software quality assurance system hosted on the Cloud. We made a brief review of the existing guidelines and standards for developing quality software in pharmaceutical industry. The proposed architecture shows the easy system accessibility from any electronic device connected to Internet. We also provide data model showing the organization and structure of the data used in the system. There are many advantages for developing such a system and we describe each of them. In the future, we plan to implement and use this system in practice and to found any inconsistencies that can be improved in the next system versions. Acknowledgement This work is supported by the project Advanced Scientific Computing Infrastructure and Implementations, financed by the Faculty of computer science and engineering, UKIM. REFERENCES 2005. IEEE Standard for Software Verification and Validation. IEEE Std 1012-2004 (Revision of IEEE Std 1012-1998) (June 2005), 1–110. DOI:http://dx.doi.org/10.1109/IEEESTD.2005.96278 US FDA. 2011. Guidance for Industry–Process Validation: General Principles and Practices. US Department of Health and Human Services, Rockville, MD, USA 1 (2011), 1–22. Food, Drug Administration, and others. 1985. Guideline on general principles of process validation. Scrip Bookshop. Food and Drug Administration and others. 1996. Code of Federal Regulations Title 21 Part 820 Quality System Regulation. Federal Register 61, 195 (1996). R GAMP. 5. Good Automated Manufacturing Practice (GAMP R) Guide for a Risk-Based Approach to Compliant GxP Computerized Systems, 5th edn (2008), International Society for Pharmaceutical Engineering (ISPE), Tampa, FL. Technical Report. ISBN 1-931879-61-3, www. ispe. org. PDA Committee on Validation of Computer-Related Systems. 1995. PDA Technical Report No.18, Validation of Computer-Related Systems. J. of Pharmaceutical Science and Technology 1 (1995). K Simmons, C Marsh, S Wiejowski, and L Ashworth. 2014. Assessment of Implementation Requirements for an Automated Quality Assurance Program for a Medical Information Customer Response Management System. J Health Med Informat 5, 149 (2014), 2. US Food and Drug Administration and others. 2002. Guidance for Industry, General Principles of Software Validation. Center for Devices and Radiological Health (2002). US Food and Drug Administration and others. 2012. Code of federal regulations title 21: part 11âĂŤelectronic records; electronic signatures. (2012). Guy Wingate. 2016. Pharmaceutical Computer Systems Validation: Quality Assurance, Risk Management and Regulatory Compliance. CRC Press.