{"docstore/data": {"5728cbd7-2018-4b09-9076-7b6146bdc50d": {"__data__": {"id_": "5728cbd7-2018-4b09-9076-7b6146bdc50d", "embedding": null, "metadata": {"page_label": "1", "file_name": "[3] EU GMP guide annexes Supplementary requirements Annex 11 Computerised systems.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[3] EU GMP guide annexes Supplementary requirements Annex 11 Computerised systems.pdf", "file_type": "application/pdf", "file_size": 178746, "creation_date": "2024-04-07", "last_modified_date": "2024-03-28", "document_title": "Requirements and Considerations for Computerised Systems in GMP Compliance: A Comprehensive Guide", "questions_this_excerpt_can_answer": "1. What specific guidance does Annex 11 of the EU GMP guide provide regarding the implementation of controls for electronic document templates, particularly for spreadsheets, to ensure accuracy and reliability?\n \n2. How does Annex 11 of the EU GMP guide address the validation requirements for spreadsheets, especially those containing custom code or algorithms, within the context of GMP compliance for computerised systems?\n\n3. According to the EU GMP guide's Annex 11, what considerations are recommended for ensuring data security in databases throughout their lifecycle, including during validation and potential data migration phases?", "excerpt_keywords": "EU GMP guide, Annex 11, Computerised systems, Validation requirements, Data security, Risk management"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[3] EU GMP guide annexes Supplementary requirements Annex 11 Computerised systems.pdf\n## eu gmp guide annexes: supplementary requirements: annex 11: computerised systems\n\n1. appropriate controls for electronic documents such as templates should be implemented. are there any specific requirements for templates of spreadsheets? h+v february 2011\n\ntemplates of spreadsheets help to avoid erroneous calculations from data remaining from previous calculations. they should be suitably checked for accuracy and reliability (annex 11 p7.1). they should be stored in a manner which ensures appropriate version control (chapter 4 p4.1).\n\n2. what type of accuracy checks (annex 11 p 6) are expected for the use of spreadsheets? h+v february 2011\n\ndata integrity should be ensured by suitably implemented and risk-assessed controls. the calculations and the files should be secured in such a way that formulations are not accidentally overwritten. accidental input of an inappropriate data type should be prevented or result in an error message (e.g. text in a numeric field or a decimal format into an integer field). so-called boundary checks are encouraged.\n\n3. are there any specific considerations for the validation of spreadsheets? h+v february 2011\n\nvalidation according to paragraph 4 of annex 11 is required at least for spreadsheets that contain custom code (e.g. visual basic for applications). formulas or other types of algorithm should be verified for correctness.\n\n4. what measures are required to ensure data security of databases? h+v february 2011\n\ndata security includes integrity, reliability and availability of data. during validation of a database-based or inclusive system, consideration should be given to:\n\n- implementing procedures and mechanisms to ensure data security and keeping the meaning and logical arrangement of data;\n- load-testing, taking into account future growth of the database and tools to monitor the saturation of the database;\n- precautions for necessary migration of data (annex 11 p17) at the end of the life-cycle of the system.\n\n5. at which phases of the system life-cycle is risk management recommended? h+v february 2011\n\nrisk management should be applied throughout the whole life-cycle. a first risk assessment should be performed to determine the gmp criticality of the system, i.e. does the system have an impact on patient safety, product quality or data integrity? user-requirement specifications are usually developed with consideration of potential risks and form the basis for the first formal risk assessment. complex systems should be evaluated in further more detailed risk assessments to determine critical functions. this will help ensure that validation activities cover all critical functions. risk management includes the implementation of appropriate controls and their verification.", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "8d810076-8b93-4240-803c-b4451848f4ff": {"__data__": {"id_": "8d810076-8b93-4240-803c-b4451848f4ff", "embedding": null, "metadata": {"page_label": "2", "file_name": "[3] EU GMP guide annexes Supplementary requirements Annex 11 Computerised systems.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[3] EU GMP guide annexes Supplementary requirements Annex 11 Computerised systems.pdf", "file_type": "application/pdf", "file_size": 178746, "creation_date": "2024-04-07", "last_modified_date": "2024-03-28", "document_title": "Validation and Compliance Requirements for Computerised Systems and Small Devices: A Comprehensive Guide", "questions_this_excerpt_can_answer": "1. What specific steps should be taken to validate small devices used in pharmaceutical manufacturing according to the EU GMP guide annexes, particularly in terms of vendor assessment and verification testing?\n \n2. How does the EU GMP guide annexes outline the process for conducting a retrospective validation of legacy computerised systems, including the necessity of defining user requirements and performing a gap analysis?\n\n3. According to the EU GMP guide annexes, what criteria determine the frequency of revalidation for computerised systems in the pharmaceutical industry, and what factors should be considered during periodic evaluations to ensure these systems remain in a validated state?", "prev_section_summary": "The section discusses the specific guidance provided in Annex 11 of the EU GMP guide regarding the implementation of controls for electronic document templates, particularly for spreadsheets, to ensure accuracy and reliability. It covers the requirements for accuracy checks, validation of spreadsheets containing custom code or algorithms, and considerations for data security in databases throughout their lifecycle. The key topics include appropriate controls for electronic documents, accuracy checks for spreadsheets, validation requirements, data security measures for databases, and the importance of risk management throughout the system life-cycle. Key entities mentioned include templates of spreadsheets, data integrity, validation procedures, data security mechanisms, risk management, and critical functions in complex systems.", "excerpt_keywords": "EU GMP guide, Annex 11, Computerised systems, Validation, Small devices"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[3] EU GMP guide annexes Supplementary requirements Annex 11 Computerised systems.pdf\n## 6. are user requirements needed as part of the retrospective validation of legacy systems? h+v february 2011\n\nthe way to check whether a computerised system is fit for its intended purpose is to define user requirements and perform a gap analysis to determine the validation effort for retrospective validation. these user requirements should be verified.\n\n## 7. when do i have to revalidate computerised systems? h+v february 2011\n\ncomputerised systems should be reviewed periodically to confirm that they remain in a validated state. periodic evaluation should include, where applicable, the current range of functionality, deviation records, change records, upgrade history, performance, reliability and security. the time period for revaluation and revalidation should be based on the criticality of the system.\n\n## 8. what are the requirements for storage time of electronic data and documents? h+v february 2011\n\nthe requirements for storage of electronically data and documents do not differ from paper documents. it should be ensured that electronic signatures applied to electronic records are valid for the entire storage period for documents.\n\n## 9. what are the relevant validation efforts for small devices? h+v february 2011\n\nsmall devices are usually off-the-shelf pieces of equipment that is widely used. in these cases, the development life-cycle is mainly controlled by the vendor. the pharmaceutical customer should therefore reasonably assess the vendors capability of developing software according to common standards of quality. a vendor assessment needs to be performed and the application needs to be verified against the requirements for the intended use. from the perspective of the regulated industry, the implementation of such a device is driven by an implementation life-cycle. at minimum the following items need to be addressed:\n\n- requirement definition for the intended use including process limitations. this should also include a statement indicating whether data are stored or transferred to another system. as per the definition of a small device, data are not stored permanently but temporarily and are not to be modified by a user. therefore, limited user access handling is acceptable. it needs to be ensured that parameter data influencing the devices behaviour may not be altered without suitable permission;\n- risk assessment, taking into consideration the intended use and the risk to patients for associated with the process supported by the small device;\n- vendor assessment;\n- list of available documentation from the vendor, especially those describing the methodology used and the calculation algorithm, if applicable. a vendor certificate or equivalent detailing the testing performed by the vendor may also be included;\n- calibration certificate, if applicable;\n- validation plan according to the risk-assessment results;\n- verification testing proving that the device fulfills the requirements for the intended use. it may be equivalent to a pq-phase.\n\nsmall manufacturing devices are sometimes only equipped with microprocessors and firmware and are not capable of high-level administration functions. moreover, data is often transient in nature in these devices. due to the latter there is no risk of", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "31f4d830-13e3-4b6e-a3bc-73fb75c40bd9": {"__data__": {"id_": "31f4d830-13e3-4b6e-a3bc-73fb75c40bd9", "embedding": null, "metadata": {"page_label": "3", "file_name": "[3] EU GMP guide annexes Supplementary requirements Annex 11 Computerised systems.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[3] EU GMP guide annexes Supplementary requirements Annex 11 Computerised systems.pdf", "file_type": "application/pdf", "file_size": 178746, "creation_date": "2024-04-07", "last_modified_date": "2024-03-28", "document_title": "Enhancing Data Security: Alternative Controls for Monitoring Data Modifications", "questions_this_excerpt_can_answer": "1. What measures can be taken if a computerized system is unable to automatically generate printouts that indicate changes made to data since its original entry, according to the EU GMP guide annexes?\n \n2. How does the EU GMP guide annexes address the issue of computerized systems that lack the capability to provide automated audit trails for data modifications, specifically in the context of supporting batch release documentation?\n\n3. In the scenario where a computerized system does not support the functionality of generating audit trail reports automatically, what alternative procedure is deemed acceptable by the EU GMP guide annexes to ensure data integrity and compliance during batch release?", "prev_section_summary": "This section discusses the validation and compliance requirements for computerised systems and small devices in pharmaceutical manufacturing according to the EU GMP guide annexes. Key topics include the need for user requirements in retrospective validation of legacy systems, the criteria for revalidation of computerised systems, storage requirements for electronic data and documents, and validation efforts for small devices. Entities mentioned include user requirements, gap analysis, periodic evaluation, electronic signatures, vendor assessment, risk assessment, calibration certificate, validation plan, and verification testing.", "excerpt_keywords": "EU GMP guide, Annex 11, Computerised systems, Data security, Audit trails"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[3] EU GMP guide annexes Supplementary requirements Annex 11 Computerised systems.pdf\ninadvertently modifying data. an audit trail is therefore not necessary and user access may be limited to those functions of parameter control.\n\n10. what alternative controls are accepted in case a system is not capable to generate printouts indicating if any of the data has been changed since the original entry? h+v february 2011\n\nas long as this functionality is not supported by the supplier, it may be acceptable to describe in a procedure the fact that a print-out of the related audit trail report must be generated and linked manually to the record supporting batch release.", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "98effcc6-a140-4126-935e-2a5f1150ce2c": {"__data__": {"id_": "98effcc6-a140-4126-935e-2a5f1150ce2c", "embedding": null, "metadata": {"page_label": "4", "file_name": "[3] EU GMP guide annexes Supplementary requirements Annex 11 Computerised systems.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[3] EU GMP guide annexes Supplementary requirements Annex 11 Computerised systems.pdf", "file_type": "application/pdf", "file_size": 178746, "creation_date": "2024-04-07", "last_modified_date": "2024-03-28", "document_title": "Ensuring Data Integrity in Pharmaceutical Manufacturing: Strategies for Regulatory Compliance", "questions_this_excerpt_can_answer": "1. How does the EU GMP Chapter 1 relate to the principles of data integrity in pharmaceutical manufacturing, and what role does it assign to senior management in ensuring data integrity?\n \n2. What specific strategies are recommended for assessing and mitigating data integrity risks within pharmaceutical manufacturing environments, according to the principles outlined in the PIC/S scheme and related regulatory guidance?\n\n3. How does the complexity and consistency of business processes impact the risk of data integrity failures in pharmaceutical manufacturing, and what considerations should be made when integrating manual interfaces with IT systems to minimize these risks?", "prev_section_summary": "The section discusses alternative controls for monitoring data modifications in computerized systems as outlined in the EU GMP guide annexes. Key topics include the lack of automated audit trails for data modifications, the need for manual generation of audit trail reports, and the importance of ensuring data integrity and compliance during batch release. The section also addresses the acceptable procedures for systems that do not support automated audit trail generation. Key entities mentioned include the supplier, users, and batch release documentation.", "excerpt_keywords": "EU GMP, data integrity, pharmaceutical manufacturing, regulatory compliance, risk assessment"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[3] EU GMP guide annexes Supplementary requirements Annex 11 Computerised systems.pdf\n## data integrity\n\ndata integrity enables good decision-making by pharmaceutical manufacturers and regulatory authorities. it is a fundamental requirement of the pharmaceutical quality system described in eu gmp chapter 1, applying equally to manual (paper) and electronic systems.\n\npromotion of a quality culture together with implementation of organizational and technical measures which ensure data integrity is the responsibility of senior management. it requires participation and commitment by staff at all levels within the company, by the companys suppliers and by its distributors.\n\nsenior management should ensure that data integrity risk is assessed, mitigated and communicated in accordance with the principles of quality risk management. the effort and resource assigned to data integrity measures should be commensurate with the risk to product quality, and balanced with other quality assurance resource demands. where long term measures are identified in order to achieve the desired state of control, interim measures should be implemented to mitigate risk, and should be monitored for effectiveness.\n\nthe following questions and answers describe foundational principles which facilitate successful implementation of existing guidance published by regulatory authorities participating in the pic/s scheme. it should be read in conjunction with national guidance, medicines legislation and the gmp standards published in eudralex volume 4.\n\nthe importance of data integrity to quality assurance and public health protection should be included in personnel training programs.\n\n- who - annex 5: guidance on good data and record management practices\n\n### 1. how can data risk be assessed?\n\ndata risk assessment should consider the vulnerability of data to involuntary or deliberate amendment, deletion or recreation. control measures which prevent unauthorized activity and increase visibility / detectability can be used as risk mitigating actions.\n\nexamples of factors which can increase risk of data integrity failure include complex, inconsistent processes with open-ended and subjective outcomes. simple tasks which are consistent, well-defined and objective lead to reduced risk.\n\nrisk assessment should include a business process focus (e.g. production, qc) and not just consider it system functionality or complexity. factors to consider include:\n\n- process complexity\n- process consistency, degree of automation / human interface\n- subjectivity of outcome / result\n- is the process open-ended or well defined\n\nthis ensures that manual interfaces with it systems are considered in the risk assessment process. computerized system validation in isolation may not result in low data integrity risk, in particular when the user is able to influence the reporting of data from the validated system.", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "23a87aaa-93fe-40e5-bd66-600e6a24d8cb": {"__data__": {"id_": "23a87aaa-93fe-40e5-bd66-600e6a24d8cb", "embedding": null, "metadata": {"page_label": "5", "file_name": "[3] EU GMP guide annexes Supplementary requirements Annex 11 Computerised systems.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[3] EU GMP guide annexes Supplementary requirements Annex 11 Computerised systems.pdf", "file_type": "application/pdf", "file_size": 178746, "creation_date": "2024-04-07", "last_modified_date": "2024-03-28", "document_title": "Data Management Best Practices: Assessing Data Criticality, Managing Data Lifecycle, and Ensuring Data Integrity Measures", "questions_this_excerpt_can_answer": "1. How does the assessment of data criticality influence decision-making processes within the context of EU GMP guide annexes, specifically in relation to batch release decisions and the prioritization of data types such as compliance with critical quality attributes versus warehouse cleaning records?\n\n2. In the framework of EU GMP guide annexes, what specific elements and boundaries are involved in the data lifecycle of a product or process, including the transition across IT systems, quality system applications, and various organizational and external interfaces, particularly in the pharmaceutical industry?\n\n3. Why is the management of the data lifecycle considered crucial for maintaining data integrity within the pharmaceutical sector, according to the EU GMP guide annexes, and what specific stages and considerations are highlighted to ensure effective data integrity measures throughout the lifecycle of data?", "prev_section_summary": "The section discusses the importance of data integrity in pharmaceutical manufacturing, outlining the responsibilities of senior management in ensuring data integrity and the need for organizational and technical measures. It emphasizes the role of quality risk management in assessing and mitigating data integrity risks, and highlights the impact of business process complexity on data integrity failures. The section also addresses the need for training programs on data integrity and provides guidance on assessing data risk, including factors such as process complexity, consistency, and human interface. It stresses the importance of considering manual interfaces with IT systems in the risk assessment process to minimize data integrity risks.", "excerpt_keywords": "EU GMP guide, Annex 11, Computerised systems, Data criticality, Data lifecycle, Data integrity"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[3] EU GMP guide annexes Supplementary requirements Annex 11 Computerised systems.pdf\n## 2. how can data criticality be assessed?\n\nthe decision which data influences may differ in importance, and the impact of the data to a decision may also vary. points to consider regarding data criticality include:\n\n- what decision does the data influence? for example: when making a batch release decision, data which determines compliance with critical quality attributes is of greater importance than warehouse cleaning records.\n- what is the impact of the data to product quality or safety? for example: for an oral tablet, active substance assay data is of greater impact to product quality and safety than tablet dimensions data.\n\n## 3. what does data lifecycle refer to?\n\ndata lifecycle refers to how data is generated, processed, reported, checked, used for decision-making, stored and finally discarded at the end of the retention period. data relating to a product or process may cross various boundaries within the lifecycle, for example:\n\n- it systems\n- quality system applications\n- production\n- analytical\n- stock management systems\n- data storage (back-up and archival)\n- organisational\n- internal (e.g. between production, qc and qa)\n- external (e.g. between contract givers and acceptors)\n- cloud-based applications and storage\n\n## 4. why is data lifecycle management important to ensure effective data integrity measures?\n\ndata integrity can be affected at any stage in the lifecycle. it is therefore important to understand the lifecycle elements for each type of data or record, and ensure controls which are proportionate to data criticality and risk at all stages.\n\n## 5. what should be considered when reviewing the data lifecycle?\n\nthe data lifecycle refers to the:\n\n- generation and recording of data\n- processing into usable information\n- checking the completeness and accuracy of reported data and processed information\n- data (or results) are used to make a decision\n- retaining and retrieval of data which protects it from loss or unauthorized amendment\n- retiring or disposal of data in a controlled manner at the end of its life", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "6505eda7-0f1d-47b2-a143-31e31e6775a7": {"__data__": {"id_": "6505eda7-0f1d-47b2-a143-31e31e6775a7", "embedding": null, "metadata": {"page_label": "6", "file_name": "[3] EU GMP guide annexes Supplementary requirements Annex 11 Computerised systems.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[3] EU GMP guide annexes Supplementary requirements Annex 11 Computerised systems.pdf", "file_type": "application/pdf", "file_size": 178746, "creation_date": "2024-04-07", "last_modified_date": "2024-03-28", "document_title": "Data Lifecycle Review and Risk Assessment in Computerised Systems: A Comprehensive Analysis", "questions_this_excerpt_can_answer": "1. How does EU GMP Annex 11 paragraph 4.3 contribute to the data lifecycle review process in computerised systems, and what role do business process owners and IT personnel play in this review?\n \n2. What specific risks and control measures should be considered regarding the creation, storage, and transfer of original data and metadata in computerised systems to ensure compliance with ALCOA principles and safeguard against data integrity failures?\n\n3. How does the guidance address the handling of data stored in temporary memory by computerised analytical and manufacturing equipment, including the risks associated with limited audit trail provision during this period, and what strategies are recommended to mitigate these risks?", "prev_section_summary": "This section discusses the assessment of data criticality, the concept of data lifecycle, the importance of data lifecycle management for ensuring data integrity measures, and considerations for reviewing the data lifecycle. Key topics include assessing data criticality for decision-making processes, understanding the data lifecycle from generation to disposal, and implementing controls proportionate to data criticality and risk. Entities mentioned include IT systems, quality system applications, production, analytical processes, stock management systems, data storage, organizational boundaries, and external interfaces in the pharmaceutical industry.", "excerpt_keywords": "EU GMP, Annex 11, Computerised systems, Data lifecycle, Data integrity"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[3] EU GMP guide annexes Supplementary requirements Annex 11 Computerised systems.pdf\ndata lifecycle reviews are applicable to both paper and electronic records, although control measures may be applied differently. in the case of computerised systems, the data lifecycle review should be performed by business process owners (e.g. production, qc) in collaboration with it personnel who understand the system architecture. the description of computerised systems required by eu gmp annex 11 paragraph 4.3 can assist this review. the application of critical thinking skills is important to not only identify gaps in data governance, but to also challenge the effectiveness of the procedural and systematic controls in place.\n\nsegregation of duties between data lifecycle stages provides safeguards against data integrity failure by reducing the opportunity for an individual to alter, misrepresent or falsify data without detection. data risk should be considered at each stage of the data lifecycle review.\n\ndata lifecycle: what risks should be considered when assessing the generating and recording of data?\n\nthe following aspects should be considered when determining risk and control measures:\n\nhow and where is original data created (i.e. paper or electronic)\nwhat metadata is associated wip pe data, to ensure a complete, accurate and traceable record, taking into account alcoa principles. does pe record permit pe reconstruction of pe activity\nwhere is pe data and metadata located\ndoes pe system require pat data is saved to permanent memory at pe time of recording, or is it held in a temporary buffer\n\nin the case of some computerised analytical and manufacturing equipment, data may be stored as a temporary local file prior to transfer to a permanent storage location (e.g. server). during the period of temporary storage, there is often limited audit trail provision amending, deleting or recreating data. this is a data integrity risk. removing the use of temporary memory (or reducing the time period that data is stored in temporary memory) reduces the risk of undetected data manipulation.\n\nis it possible to recreate, amend or delete original data and metadata; controls over paper records are discussed elsewhere in this guidance. computerised system controls may be more complex, including setting of user privileges and system configuration to limit or prevent access to amend data. it is important to review all data access opportunities, including it helpdesk staff, who may make changes at the request of the data user. these changes should be procedurally controlled, visible and approved within the quality system.\n\nhow data is transferred to other locations or systems for processing or storage; data should be protected from possibility of intentional or unintentional loss or amendment during transfer to other systems (e.g. for processing, review or storage). paper records should be protected from amendment, or substitution. electronic interfaces should be validated to demonstrate security and no corruption of data, particularly where systems require an interface to present data in a different structure or file format.", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "a1470842-4cbd-45fb-9e71-6004b63c1ff0": {"__data__": {"id_": "a1470842-4cbd-45fb-9e71-6004b63c1ff0", "embedding": null, "metadata": {"page_label": "7", "file_name": "[3] EU GMP guide annexes Supplementary requirements Annex 11 Computerised systems.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[3] EU GMP guide annexes Supplementary requirements Annex 11 Computerised systems.pdf", "file_type": "application/pdf", "file_size": 178746, "creation_date": "2024-04-07", "last_modified_date": "2024-03-28", "document_title": "\"Risk Management Strategies for Data Processing and Reporting\"", "questions_this_excerpt_can_answer": "1. What specific measures should be taken to ensure the integrity and version control of data processing methods in electronic data processing systems, according to the EU GMP guide annexes?\n \n2. How does the EU GMP guide annexes recommend handling situations where data has been processed multiple times to ensure each iteration is verifiable and maintains data integrity?\n\n3. According to the EU GMP guide annexes, what are the recommended practices for preserving the format of original data and ensuring it is accessible for a risk-based review by data reviewers?", "prev_section_summary": "The section discusses the importance of data lifecycle reviews in computerised systems, involving collaboration between business process owners and IT personnel. It highlights the risks and control measures related to the creation, storage, and transfer of data and metadata to ensure compliance with ALCOA principles and prevent data integrity failures. The handling of data stored in temporary memory by computerised equipment is also addressed, emphasizing the need for strategies to mitigate associated risks. Segregation of duties, data risk assessment, and controls over data access and transfer are key topics covered in the section.", "excerpt_keywords": "EU GMP guide, Annex 11, Computerised systems, Data integrity, Risk management"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[3] EU GMP guide annexes Supplementary requirements Annex 11 Computerised systems.pdf\ndata lifecycle: what risks should be considered when assessing the processing data into usable information?\n\nthe following aspects should be considered when determining risk and control measures:\nhow is data processed;\ndata processing mepods should be approved, identifiable and version controlled. in pe case of electronic data processing, mepods should be locked where appropriate to prevent unauporized amendment.\nhow is data processing recorded;\nthe processing mepod should be recorded. in situations where raw data has been processed more pan once, each iteration (including mepod and result) should be available to pe data checker for verification.\ndoes pe person processing pe data have pe ability to influence what data is reported, or how it is presented;\neven validated systems which do not permit pe user to make any changes to data may be at risk if pe user can choose what data is printed, reported or transferred for processing. this includes performing pe activity multiple times as separate events and reporting a desired outcome from one of pese repeats. data presentation (e.g. changing scale of graphical reports to enhance or reduce presentation of analytical peaks) can also influence decision making, and perefore impact data integrity.\n\ndata lifecycle: what risks should be considered when checking the completeness and accuracy of reported data and processed information?\n\nthe following aspects should be considered when determining risk and control measures:\nis original data (including pe original data format) available for checking;\nthe format of pe original data (electronic or paper) should be preserved, and available to pe data reviewer in a manner which permits interaction wip pe data (e.g. search, query). this approach facilitates a risk-based review of pe record, and can also reduce administrative burden for instance utilizing validated audit trail exception reports instead of an onerous line-by-line review.\nare pere any periods of time when data is not audit trailed;\nthis may present opportunity for data amendment which is not subsequently visible to pe data reviewer. additional control measures should be implemented to reduce risk of undisclosed data manipulation.\ndoes pe data reviewer have visibility and access to all data generated;", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "93bc0650-55fc-4fe0-bc1c-0156df9181d9": {"__data__": {"id_": "93bc0650-55fc-4fe0-bc1c-0156df9181d9", "embedding": null, "metadata": {"page_label": "8", "file_name": "[3] EU GMP guide annexes Supplementary requirements Annex 11 Computerised systems.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[3] EU GMP guide annexes Supplementary requirements Annex 11 Computerised systems.pdf", "file_type": "application/pdf", "file_size": 178746, "creation_date": "2024-04-07", "last_modified_date": "2024-03-28", "document_title": "\"Ensuring Data Integrity and Security Throughout the Data Lifecycle: Best Practices and Strategies\"", "questions_this_excerpt_can_answer": "1. How does Annex 11 of the EU GMP guide address the issue of data integrity and security throughout the data lifecycle, specifically in relation to the visibility and handling of failed, aborted, or discrepant data activities?\n\n2. What specific risks and control measures does Annex 11 recommend considering during the data lifecycle to ensure the integrity of data when making pass/fail decisions, particularly in relation to the timing of these decisions and the visibility of changes in the audit trail?\n\n3. According to Annex 11, what are the recommended practices for the storage, backup, and protection against loss or unauthorized amendment of data within the pharmaceutical quality system to ensure data integrity and security throughout its lifecycle?", "prev_section_summary": "The section discusses risk management strategies for data processing and reporting in electronic data processing systems according to the EU GMP guide annexes. Key topics include ensuring integrity and version control of data processing methods, handling situations where data has been processed multiple times, preserving the format of original data for review, and ensuring data accuracy and completeness. Entities mentioned include data processing methods, data checkers, data reviewers, and control measures to mitigate risks related to data manipulation and integrity.", "excerpt_keywords": "EU GMP guide, Annex 11, data integrity, security, data lifecycle"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[3] EU GMP guide annexes Supplementary requirements Annex 11 Computerised systems.pdf\nthis should include any data from failed or aborted activities, discrepant or unusual data which has been excluded from processing or the final decision-making process. visibility of all data provides protection against selective data reporting or testing into compliance.\n\n- does the data reviewer have visibility and access to all processing of data; this ensures that the final result obtained from raw data is based on good science, and that any data exclusion or changes to processing method is based on good science. visibility of all processing information provides protection against undisclosed processing into compliance.\n\n9. data lifecycle: what risks should be considered when data (or results) are used to make a decision?\n\nthe following aspects should be considered when determining risk and control measures:\n\n- when is the pass / fail decision taken; if data acceptability decisions are taken before a record (raw data or processed result) is saved to permanent memory, there may be opportunity for the user to manipulate data to provide a satisfactory result, without this change being visible in audit trail. this would not be visible to the data reviewer. this is a particular consideration where computerised systems alert the user to an out of specification entry before the data entry process is complete (i.e. the user saves the data entry), or saves the record in temporary memory.\n\n10. data lifecycle: what risks should be considered when retaining and retrieving data to protect it from loss or unauthorised amendment?\n\nthe following aspects should be considered when determining risk and control measures:\n\n- how / where is data stored; storage of data (paper or electronic) should be at secure locations, with access limited to authorised persons. the storage location must provide adequate protection from damage due to water, fire, etc.\n- what are the measures protecting against loss or unauthorised amendment; data security measures should be at least equivalent to those applied during the earlier data lifecycle stages. retrospective data amendment (e.g. via it helpdesk or data base amendments) should be controlled by the pharmaceutical quality system, with appropriate segregation of duties and approval processes.\n- is data backed up in a manner permitting reconstruction of the activity; back-up arrangements should be validated to demonstrate the ability to restore data following it system failure. in situations where metadata (including relevant operating system event logs) are stored in different file locations from raw data, the back-up process should be carefully designed to ensure that all data required to reconstruct a record is included.", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "de675a68-a1ae-4ede-8fc4-433c43bc3949": {"__data__": {"id_": "de675a68-a1ae-4ede-8fc4-433c43bc3949", "embedding": null, "metadata": {"page_label": "9", "file_name": "[3] EU GMP guide annexes Supplementary requirements Annex 11 Computerised systems.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[3] EU GMP guide annexes Supplementary requirements Annex 11 Computerised systems.pdf", "file_type": "application/pdf", "file_size": 178746, "creation_date": "2024-04-07", "last_modified_date": "2024-03-28", "document_title": "Data Lifecycle Management and Risk Considerations in GMP Compliance: A Comprehensive Guide", "questions_this_excerpt_can_answer": "1. What specific guidelines does the EU GMP Annex 11 suggest for managing the ownership and retrieval of data, especially in scenarios involving outsourced activities or data storage?\n\n2. According to the document, what factors should be considered when determining the risk and control measures for the retirement or disposal of data at the end of its lifecycle within a GMP-compliant environment?\n\n3. How does the document propose integrating a quality-risk management approach, specifically ICH Q9, into the management of data integrity throughout its lifecycle, and what role does senior management play in this process according to EU GMP guidelines?", "prev_section_summary": "The section discusses the importance of data integrity and security throughout the data lifecycle, specifically focusing on Annex 11 of the EU GMP guide. Key topics include the visibility and handling of failed, aborted, or discrepant data activities, risks and control measures for making pass/fail decisions, and practices for storage, backup, and protection against loss or unauthorized amendment of data. Entities mentioned include data reviewers, processing information, data acceptability decisions, storage locations, data security measures, and back-up arrangements.", "excerpt_keywords": "EU GMP, Annex 11, Data Lifecycle Management, Risk Considerations, GMP Compliance"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[3] EU GMP guide annexes Supplementary requirements Annex 11 Computerised systems.pdf\nsimilarly, true copies of paper records may be duplicated on paper, microfilm, or electronically, and stored in a separate location.\n\nwhat are ownership / retrieval arrangements, particularly considering outsourced activities or data storage;\n\na technical agreement should be in place which addresses the requirements of part i chapter 7 and part ii section 16 of the gmp guide.\n\n11. data lifecycle: what risks should be considered when retiring or disposal of data in a controlled manner at the end of its life?\n\nthe following aspects should be considered when determining risk and control measures:\n\n- the data retention period\nthis will be influenced by regulatory requirements and data criticality. when considering data for a single product, there may be different data retention needs for pivotal trial data and manufacturing process / analytical validation data compared to routine commercial batch data.\n- how data disposal is authorised\nany disposal of data should be approved within the quality system and be performed in accordance with a procedure to ensure compliance with the required data retention period.\n\n12. is it required by the eu gmp to implement a specific procedure for data integrity?\n\nthere is no requirement for a specific procedure, however it may be beneficial to provide a summary document which outlines the organisations total approach to data governance.\n\na compliant pharmaceutical quality system generates and assesses a significant amount of data. while all data has an overall influence on gmp compliance, different data will have different levels of impact to product quality.\n\na quality-risk management (ich q9) approach to data integrity can be achieved by considering data risk and data criticality at each stage in the data lifecycle. the effort applied to control measures should be commensurate with this data risk and criticality assessment.\n\nthe approach to risk identification, mitigation, review and communication should be iterative, and integrated into the pharmaceutical quality system. this should provide senior management supervision and permit a balance between data integrity and general gmp priorities in line with the principles of ich q9 & q10.", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "687ab5b3-dae8-4f13-925b-53e6cedc4206": {"__data__": {"id_": "687ab5b3-dae8-4f13-925b-53e6cedc4206", "embedding": null, "metadata": {"page_label": "10", "file_name": "[3] EU GMP guide annexes Supplementary requirements Annex 11 Computerised systems.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[3] EU GMP guide annexes Supplementary requirements Annex 11 Computerised systems.pdf", "file_type": "application/pdf", "file_size": 178746, "creation_date": "2024-04-07", "last_modified_date": "2024-03-28", "document_title": "Design and Control of Paper Documentation System for GMP Data Integrity: A Comprehensive Guide", "questions_this_excerpt_can_answer": "1. How does the EU GMP Annex 11 specifically correlate the ALCOA principles with the requirements for both medicinal products and active substances used as starting materials, providing chapter and paragraph references for each principle?\n\n2. What specific chapters and paragraphs in the EU GMP guidelines (Part I and Part II) address the requirement for data to be attributable, legible, contemporaneous, original, and accurate within the context of pharmaceutical manufacturing and documentation?\n\n3. What are the recommended practices for designing and controlling paper documentation systems to prevent unauthorized recreation of GMP data, including the management of template forms, according to the EU GMP guide annexes and supplementary requirements detailed in Annex 11?", "prev_section_summary": "The section discusses the management of data ownership and retrieval, especially in outsourced activities or data storage, as per EU GMP Annex 11 guidelines. It also covers the risks and control measures to consider when retiring or disposing of data at the end of its lifecycle within a GMP-compliant environment. The document proposes integrating a quality-risk management approach, specifically ICH Q9, into data integrity management throughout its lifecycle, with a focus on data risk and criticality assessment. Senior management's role in supervising and balancing data integrity with general GMP priorities is highlighted.", "excerpt_keywords": "EU GMP, Annex 11, Data Integrity, Paper Documentation System, ALCOA Principles"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[3] EU GMP guide annexes Supplementary requirements Annex 11 Computerised systems.pdf\n## 13. how are the data integrity expectations (alcoa) for the pharmaceutical industry prescribed in the existing eu gmp relating to active substances and dosage forms published in eudralex volume 4?\n\nthe main regulatory expectation for data integrity is to comply with the requirement of alcoa principles. the table below provides for each alcoa principle the link to eu gmp references (part i, part ii and annex 11):\n\n|alcoa principle|basic requirements for medicinal products (part i): chapter 4 (1) / chapter 6 (2)|basic requirements for active substances used as starting materials (part ii): chapter 5 (3) / chapter 6 (4)|\n|---|---|---|\n|attributable (data can be assigned to the individual performing the task)|[4.20, c & f], [4.21, c & i], [4.29, e]|[6.14], [6.18], [6.52]|\n|legible (data can be read by eye or electronically and retained in a permanent format)|[4.1], [4.2], [4.7], [4.8], [4.9], [4.10]|[5.43] [6.11], [6.14], [6.15], [6.16]|\n|contemporaneous (data is created at the time the activity is performed)|[4.8]|[6.14]|\n|original (data is in the same format as it was initially generated, or as a verified copy, which retains content and meaning)|[4.9], [4.27], [paragraph \"record\"]|[6.14], [6.15], [6.16]|\n|accurate (data is true / reflective of the activity or measurement performed)|[4.1], [6.17]|[5.40], [5.45], [6.6]|\n\n1chapter 4 (part i): documentation\n\n2chapter 6 (part i): quality control\n\n3chapter 5 (part ii): process equipment (computerized system)\n\n4chapter 6 (part ii): documentation and records\n\n## 14. how should the company design and control their paper documentation system to prevent the unauthorised re-creation of gmp data?\n\nthe template (blank) forms used for manual recordings may be created in an electronic system (word, excel, etc.). the corresponding master documents should be approved and controlled electronically or in paper versions. the following expectations should be considered for the template (blank) form:\n\n- have a unique reference number (including version number) and include reference to corresponding sop number\n- should be stored in a manner which ensures appropriate version control\n- if signed electronically, should use a secure e-signature\n\nthe distribution of template records (e.g. blank forms) should be controlled. the following expectations should be considered where appropriate, based on data risk and criticality:", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "92857046-d0f4-4b99-b507-f7c29b708f3a": {"__data__": {"id_": "92857046-d0f4-4b99-b507-f7c29b708f3a", "embedding": null, "metadata": {"page_label": "11", "file_name": "[3] EU GMP guide annexes Supplementary requirements Annex 11 Computerised systems.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[3] EU GMP guide annexes Supplementary requirements Annex 11 Computerised systems.pdf", "file_type": "application/pdf", "file_size": 178746, "creation_date": "2024-04-07", "last_modified_date": "2024-03-28", "document_title": "\"Ensuring Data Integrity and Traceability in Electronic Systems: Best Practices and Strategies\"", "questions_this_excerpt_can_answer": "1. What specific measures are recommended to ensure the traceability and integrity of paper-based records, such as blank forms, in a GMP environment according to the EU GMP guide annexes?\n \n2. How does the document suggest computerized systems should be designed to preserve original electronic data and maintain data integrity, as outlined in the EU GMP guide annexes?\n\n3. What is the significance of reviewing electronic data in the context of GMP-related decisions, and what potential risks does solely relying on printouts for review pose according to the insights provided in the EU GMP guide annexes?", "prev_section_summary": "This section discusses the correlation of ALCOA principles with EU GMP requirements for medicinal products and active substances, providing specific chapter and paragraph references. It also addresses the design and control of paper documentation systems to prevent unauthorized recreation of GMP data, including the management of template forms. The section emphasizes the importance of data integrity expectations in the pharmaceutical industry and outlines recommended practices for ensuring compliance with regulatory requirements.", "excerpt_keywords": "EU GMP guide, Data Integrity, Traceability, Electronic Systems, Compliance"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[3] EU GMP guide annexes Supplementary requirements Annex 11 Computerised systems.pdf\nenable traceability for issuance of the blank form by using a bound logbook with numbered pages or other appropriate system. for loose leaf template forms, the distribution date, a sequential issuing number, the number of the copies distributed, the department name where the blank forms are distributed, etc.\n\nshould be known\n\ndistributed copies should be designed to avoid photocopying either by using a secure stamp, or by the use of paper color code not available in the working areas or another appropriate system.\n\nwhat controls should be in place to ensure original electronic data is preserved?\n\ncomputerized systems should be designed in a way that ensures compliance with the principles of data integrity. the system design should make provisions such that original data cannot be deleted and for the retention of audit trails reflecting changes made to original data.\n\nwhy is it important to review electronic data?\n\nin the case of data generated from an electronic system, electronic data is the original record which must be reviewed and evaluated prior to making batch release decisions and other decisions relating to gmp related activities (e.g. approval of stability results, analytical method validation etc.). in the event that the review is based solely on printouts there is potential for records to be excluded from the review process which may contain un-investigated out of specification data or other data anomalies. the review of the raw electronic data should mitigate risk and enable detection of data deletion, amendment, duplication, reusing and fabrication which are common data integrity failures.\n\nexample of an inspection citing:\n\nraw data for hplc/gc runs which had been invalidated was stored separately to the qc raw data packages and had not been included in the review process.\n\nin the above situation, the procedure for review of chromatographic data packages did not require a review of the electronic raw data or a review of relevant audit trails associated with the analyses. this lead to the exclusion of records from the review process and to lack of visibility of changes made during the processing and reporting of the data. the company was unable to provide any explanation for the data which had been invalidated.\n\nis a risk-based review of electronic data acceptable?\n\nyes. the principles of quality risk management may be applied during the review of electronic data and review by exception is permitted, when scientifically justified. exception reporting is used commonly as a tool to focus the review of electronic data such as (but not limited to) electronic batch records. exception reporting rapidly highlights to the reviewer one of the most critical elements of batch review, i.e. the exceptions. the level of review of the full electronic batch record can vary based on the exceptions as well as the level of confidence and experience with a particular process. appropriate testing and validation must be completed for the automated system and the", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "47efd296-7683-40a4-b25a-0289c44a5574": {"__data__": {"id_": "47efd296-7683-40a4-b25a-0289c44a5574", "embedding": null, "metadata": {"page_label": "12", "file_name": "[3] EU GMP guide annexes Supplementary requirements Annex 11 Computerised systems.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[3] EU GMP guide annexes Supplementary requirements Annex 11 Computerised systems.pdf", "file_type": "application/pdf", "file_size": 178746, "creation_date": "2024-04-07", "last_modified_date": "2024-03-28", "document_title": "Ensuring Data Integrity and Compliance in Outsourced GMP Activities: A Comprehensive Guide", "questions_this_excerpt_can_answer": "1. What specific steps should a company take to ensure ongoing compliance with its data governance policy/procedures during self-inspections, especially in relation to the data lifecycle elements discussed earlier in the document?\n\n2. How should a company approach the verification of data integrity and governance systems when outsourcing GMP activities to another company, and what are the key components of a formal assessment for a contract acceptor's competency and compliance in this regard?\n\n3. What strategies should a recipient (contract giver) employ to build and maintain confidence in the validity of documents such as Certificates of Analysis (CoA) provided by a supplier (contract acceptor), especially considering the significance of reviewing summary data for outsourced activities?", "prev_section_summary": "The section discusses measures recommended to ensure traceability and integrity of paper-based records in a GMP environment, as well as how computerized systems should be designed to preserve original electronic data and maintain data integrity. It emphasizes the importance of reviewing electronic data for GMP-related decisions and highlights the risks of solely relying on printouts for review. The section also mentions the significance of quality risk management in the review of electronic data and the use of exception reporting to focus on critical elements of batch review. Key topics include traceability of blank forms, design of computerized systems for data integrity, review of electronic data, and risk-based review practices. Key entities mentioned include bound logbooks, sequential issuing numbers, secure stamps, audit trails, electronic data, batch release decisions, quality risk management, exception reporting, and validation of automated systems.", "excerpt_keywords": "Data Integrity, Compliance, Outsourced GMP Activities, Contract Acceptors, Certificate of Analysis"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[3] EU GMP guide annexes Supplementary requirements Annex 11 Computerised systems.pdf\noutput batch exception report to ensure its functionality meets the business and regulatory requirements as per gmp.\n\n18. what are the expectations for the self-inspection program related to data integrity? ongoing compliance with the companys data governance policy/procedures should be reviewed during self-inspection, to ensure that they remain effective. this may also include elements of the data lifecycle discussed in q3-q9.\n\n19. what are my companys responsibilities relating to data integrity for gmp activities contracted out to another company? data integrity requirements should be incorporated into the companys contractor/vendor qualification/assurance program and associated procedures. in addition to having their own data governance systems, companies outsourcing activities should verify the adequacy of comparable systems at the contract acceptor. the contract acceptor should apply equivalent levels of control to those applied by the contract giver. formal assessment of the contract acceptors competency and compliance in this regard should be conducted in the first instance prior to the approval of a contractor, and thereafter verified on a periodic basis at an appropriate frequency based on risk.\n\n20. how can a recipient (contract giver) build confidence in the validity of documents such as certificate of analysis (coa) provided by a supplier (contract acceptor)? the recipient should have knowledge of the systems and procedures implemented at the supplier for the generation of the coa. arrangements should be in place to ensure that significant changes to systems are notified and the effectiveness of these arrangements should be subjected to periodic review. data related to activities which are outsourced are routinely provided as summary data in a report format (e.g. coa). these summary documents are reviewed on a routine basis by the contract acceptor and therefore the review of data integrity at the contract acceptor site on a regular periodic basis (e.g. during on-site audit) takes on even greater significance, in order to build and maintain confidence in the summary data provided.\n\n21. what are the expectations in relation to contract calibration service providers who conduct calibrations on-site and/or off-site? are audits of these companies premises required? using the principles of qrm to assess data criticality and risk, the company should include assessment of data governance systems implemented by the service provider when making decisions on service contracts. this may be achieved by on-site audit or desk-based assessment of information submitted by the service provider.", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "de10bc30-2086-42c2-8663-02927d06037a": {"__data__": {"id_": "de10bc30-2086-42c2-8663-02927d06037a", "embedding": null, "metadata": {"page_label": "13", "file_name": "[3] EU GMP guide annexes Supplementary requirements Annex 11 Computerised systems.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[3] EU GMP guide annexes Supplementary requirements Annex 11 Computerised systems.pdf", "file_type": "application/pdf", "file_size": 178746, "creation_date": "2024-04-07", "last_modified_date": "2024-03-28", "document_title": "Ensuring Data Integrity in the Supply Chain for Medicinal Products: Responsibilities and Actions", "questions_this_excerpt_can_answer": "1. What specific steps should a company take if an approved contractor receives a warning letter or statement of non-compliance concerning data integrity from a regulatory authority, according to the EU GMP guide annexes?\n \n2. How does the EU GMP guide annexes suggest a company should manage the risk to its products if an approved contractor is found non-compliant in terms of data integrity?\n\n3. According to the EU GMP guide annexes, who holds the final responsibility for ensuring data integrity and compliance throughout the supply chain for medicinal products, and how should responsibilities be documented between parties?", "prev_section_summary": "The section discusses the importance of ensuring data integrity and compliance in outsourced GMP activities. Key topics include self-inspection programs for data integrity, responsibilities for data integrity in contracted activities, building confidence in documents provided by suppliers, and expectations for contract calibration service providers. Entities mentioned include the company, contract acceptor, contract giver, and service providers. The section emphasizes the need for ongoing compliance with data governance policies, verification of data integrity systems, formal assessments of contract acceptors, and regular reviews of outsourced data to maintain confidence in summary documents.", "excerpt_keywords": "EU GMP guide, Data integrity, Supply chain, Medicinal products, Responsibilities"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[3] EU GMP guide annexes Supplementary requirements Annex 11 Computerised systems.pdf\n## 22. what is expected of my company in the event that one of my approved contractors is issued with a warning letter/statement of non-compliance concerning data integrity, from a regulatory authority?\n\nwhat is expected of my company in the event that one of my approved contractors (e.g. active substance manufacturer, finished product manufacturer, quality control laboratory etc.) is issued with a warning letter/statement of non-compliance concerning data integrity, from a regulatory authority?\n\nit is considered that the company should evaluate the risk to its products manufactured/released using the principles of quality risk management. risk assessments should be made available to inspectors, on request. depending on the outcome of the risk assessment, appropriate action should be taken which may entail delisting the contractor from the approved contractor list. in the event that abnormal disruption in supply may result from a contractor compliance situation, relevant regulatory authorities should be consulted in this regard.\n\n## 23. where does my companys responsibility begin and end in relation to data integrity aspects of the supply chain for medicinal products?\n\nall actors in the supply chain play an important part in overall data integrity and assurance of product quality. data governance systems should be implemented from the manufacture of starting materials right through to the delivery of medicinal products to persons authorized or entitled to supply medicinal products to the public. relative responsibilities and boundaries should be documented in the contracts between the relevant parties. final responsibility of ensuring compliance throughout the supply chain rests with batch certifying qp.", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "c47cec4a-8287-44ea-9ff8-b420d6a06e5a": {"__data__": {"id_": "c47cec4a-8287-44ea-9ff8-b420d6a06e5a", "embedding": null, "metadata": {"page_label": "1", "file_name": "[22] EMA Annex 15 Qualification and Validation.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[22] EMA Annex 15 Qualification and Validation.pdf", "file_type": "application/pdf", "file_size": 96427, "creation_date": "2024-04-07", "last_modified_date": "2024-03-29", "document_title": "Guidelines for Qualification and Validation of Medicinal Products", "questions_this_excerpt_can_answer": "1. What specific legislative directives provide the legal basis for the publication of the detailed guidelines on qualification and validation of medicinal products as outlined in the EMA Annex 15 document?\n\n2. How does the revised Annex 15 document address changes in the manufacturing and regulatory environment for medicinal products since its initial publication in 2001?\n\n3. What are the specific international guidelines and quality working party (QWP) guidance documents that the revision of Annex 15 takes into account to reflect the current manufacturing technology and regulatory standards?", "excerpt_keywords": "EMA, Annex 15, Qualification, Validation, Medicinal Products"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[22] EMA Annex 15 Qualification and Validation.pdf\n## european commission\n\nref. ares(2015)1380025 - 30/03/2015\n\ndirectorate-general for health and food safety\n\nmedicinal products - quality, safety and efficacy\n\nbrussels, 30 march 2015\n\neudralex\n\nvolume 4\n\neu guidelines for good manufacturing practice for medicinal products for human and veterinary use\n\nannex 15: qualification and validation\n\nlegal basis for publishing the detailed guidelines: article 47 of directive 2001/83/ec on the community code relating to medicinal products for human use and article 51 of directive 2001/82/ec on the community code relating to veterinary medicinal products.\n\nthis document provides guidance for the interpretation of the principles and guidelines of good manufacturing practice (gmp) for medicinal products as laid down in directive 2003/94/ec for medicinal products for human use and directive 91/412/eec for veterinary use.\n\nstatus of the document: revision\n\nreasons for changes: since annex 15 was published in 2001 the manufacturing and regulatory environment has changed significantly and an update is required to this annex to reflect this changed environment. this revision to annex 15 takes into account changes to other sections of the eudralex, volume 4, part i, relationship to part ii, annex 11, ich q8, q9, q10 and q11, qwp guidance on process validation, and changes in manufacturing technology.\n\ndeadline for coming into operation: 1 october 2015\n\ncommission europeenne/europese commissie, 1049 bruxelles/brussel, belgique/belgie - tel. +32 22991111", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "d6b0c4e5-6839-4563-a426-22e014cb89c6": {"__data__": {"id_": "d6b0c4e5-6839-4563-a426-22e014cb89c6", "embedding": null, "metadata": {"page_label": "2", "file_name": "[22] EMA Annex 15 Qualification and Validation.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[22] EMA Annex 15 Qualification and Validation.pdf", "file_type": "application/pdf", "file_size": 96427, "creation_date": "2024-04-07", "last_modified_date": "2024-03-29", "document_title": "Principles and Planning for Qualification and Validation in Medicinal Product Manufacturing: A Comprehensive Guide", "questions_this_excerpt_can_answer": "1. What specific guidance documents and concepts should be considered in addition to EudraLex, Volume 4, Part II, when implementing qualification and validation processes for the manufacture of medicinal products according to the EMA Annex 15?\n \n2. How does EMA Annex 15 address the use of data obtained from sources outside of the manufacturer's own programs for qualification and/or validation studies, and what conditions must be met for this approach to be considered justified?\n\n3. What are the key elements that must be defined and documented in a Validation Master Plan (VMP) or equivalent document as per the guidelines provided in EMA Annex 15 for organising and planning qualification and validation activities?", "prev_section_summary": "The section discusses the guidelines for qualification and validation of medicinal products outlined in the EMA Annex 15 document. Key topics include the legal basis for publishing the guidelines, changes in the manufacturing and regulatory environment since the initial publication in 2001, and the international guidelines and QWP guidance documents considered in the revision of Annex 15. Entities mentioned include the European Commission, directives 2001/83/ec and 2001/82/ec, Eudralex, and various international guidelines and quality working party documents.", "excerpt_keywords": "qualification, validation, medicinal products, EMA Annex 15, validation master plan"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[22] EMA Annex 15 Qualification and Validation.pdf\n## principle\n\nthis annex describes the principles of qualification and validation which are applicable to the facilities, equipment, utilities and processes used for the manufacture of medicinal products and may also be used as supplementary optional guidance for active substances without introduction of additional requirements to eudralex, volume 4, part ii. it is a gmp requirement that manufacturers control the critical aspects of their particular operations through qualification and validation over the life cycle of the product and process. any planned changes to the facilities, equipment, utilities and processes, which may affect the quality of the product, should be formally documented and the impact on the validated status or control strategy assessed. computerised systems used for the manufacture of medicinal products should also be validated according to the requirements of annex 11. the relevant concepts and guidance presented in ich q8, q9, q10 and q11 should also be taken into account.\n\n## general\n\na quality risk management approach should be applied throughout the lifecycle of a medicinal product. as part of a quality risk management system, decisions on the scope and extent of qualification and validation should be based on a justified and documented risk assessment of the facilities, equipment, utilities and processes. retrospective validation is no longer considered an acceptable approach. data supporting qualification and/or validation studies which were obtained from sources outside of the manufacturers own programs may be used provided that this approach has been justified and that there is adequate assurance that controls were in place throughout the acquisition of such data.\n\n## organising and planning for qualification and validation\n\n|1.1.|all qualification and validation activities should be planned and take the life cycle of facilities, equipment, utilities, process and product into consideration.|\n|---|---|\n|1.2.|qualification and validation activities should only be performed by suitably trained personnel who follow approved procedures.|\n|1.3.|qualification/validation personnel should report as defined in the pharmaceutical quality system although this may not necessarily be to a quality management or a quality assurance function. however, there should be appropriate quality oversight over the whole validation life cycle.|\n|1.4.|the key elements of the site qualification and validation programme should be clearly defined and documented in a validation master plan (vmp) or equivalent document.|\n|1.5.|the vmp or equivalent document should define the qualification/validation system and include or reference information on at least the following: i. qualification and validation policy; ii. the organisational structure including roles and responsibilities for qualification and validation activities;|", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "e0ce4149-ca7a-4d02-bdd5-178c88d4960f": {"__data__": {"id_": "e0ce4149-ca7a-4d02-bdd5-178c88d4960f", "embedding": null, "metadata": {"page_label": "3", "file_name": "[22] EMA Annex 15 Qualification and Validation.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[22] EMA Annex 15 Qualification and Validation.pdf", "file_type": "application/pdf", "file_size": 96427, "creation_date": "2024-04-07", "last_modified_date": "2024-03-29", "document_title": "Qualification and Validation Documentation and Processes in Pharmaceutical Manufacturing: A Comprehensive Guide", "questions_this_excerpt_can_answer": "1. How does the document suggest handling significant changes to the approved validation protocol during its execution, and what is required for such changes to be accepted?\n \n2. What approach does the document recommend for managing qualification and validation activities in relation to quality risk management, and how should changes in knowledge or understanding affect this process?\n\n3. In the context of large and complex pharmaceutical manufacturing projects, what does the document specify about the planning of validation activities and the potential need for separate validation plans?", "prev_section_summary": "The section discusses the principles and planning for qualification and validation in medicinal product manufacturing according to EMA Annex 15. Key topics include the application of qualification and validation to facilities, equipment, utilities, and processes, the use of quality risk management, the importance of planning and organizing qualification and validation activities, and the requirements for a Validation Master Plan (VMP) or equivalent document. Entities such as suitably trained personnel, quality oversight, and key elements of the qualification and validation program are also highlighted.", "excerpt_keywords": "Qualification, Validation, Pharmaceutical Manufacturing, Quality Risk Management, Documentation"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[22] EMA Annex 15 Qualification and Validation.pdf\n### summary of the facilities, equipment, systems, processes on site and the qualification and validation status;\n\n### change control and deviation management for qualification and validation;\n\n### guidance on developing acceptance criteria;\n\n### references to existing documents;\n\n### the qualification and validation strategy, including requalification, where applicable.\n\n1.6. for large and complex projects, planning takes on added importance and separate validation plans may enhance clarity\n\n1.7. a quality risk management approach should be used for qualification and validation activities. in light of increased knowledge and understanding from any changes during the project phase or during commercial production, the risk assessments should be repeated, as required. the way in which risk assessments are used to support qualification and validation activities should be clearly documented.\n\n1.8. appropriate checks should be incorporated into qualification and validation work to ensure the integrity of all data obtained.\n\n## documentation, including vmp\n\n2.1. good documentation practices are important to support knowledge management throughout the product lifecycle.\n\n2.2. all documents generated during qualification and validation should be approved and authorised by appropriate personnel as defined in the pharmaceutical quality system.\n\n2.3. the inter-relationship between documents in complex validation projects should be clearly defined.\n\n2.4. validation protocols should be prepared which defines the critical systems, attributes and parameters and the associated acceptance criteria.\n\n2.5. qualification documents may be combined together, where appropriate, e.g. installation qualification (iq) and operational qualification (oq).\n\n2.6. where validation protocols and other documentation are supplied by a third party providing validation services, appropriate personnel at the manufacturing site should confirm suitability and compliance with internal procedures before approval. vendor protocols may be supplemented by additional documentation/test protocols before use.\n\n2.7. any significant changes to the approved protocol during execution, e.g. acceptance criteria, operating parameters etc., should be documented as a deviation and be scientifically justified.", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "6eb0c7fe-c66c-4c46-a60c-340fa563b0b8": {"__data__": {"id_": "6eb0c7fe-c66c-4c46-a60c-340fa563b0b8", "embedding": null, "metadata": {"page_label": "4", "file_name": "[22] EMA Annex 15 Qualification and Validation.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[22] EMA Annex 15 Qualification and Validation.pdf", "file_type": "application/pdf", "file_size": 96427, "creation_date": "2024-04-07", "last_modified_date": "2024-03-29", "document_title": "Qualification and Validation Process for Equipment, Facilities, Utilities, and Systems in Pharmaceutical Manufacturing.", "questions_this_excerpt_can_answer": "1. What steps should be taken if results fail to meet the pre-defined acceptance criteria during the qualification and validation process in pharmaceutical manufacturing, according to the EMA Annex 15?\n \n2. How does the EMA Annex 15 document suggest handling changes to acceptance criteria after the initial validation results have been reviewed in the context of pharmaceutical equipment, facilities, utilities, and systems qualification?\n\n3. What are the specific stages and activities involved in the qualification process for equipment, facilities, utilities, and systems in pharmaceutical manufacturing as outlined in the EMA Annex 15, and how does it recommend incorporating user requirements and design compliance with GMP standards?", "prev_section_summary": "The section discusses the importance of documentation, change control, and deviation management in qualification and validation processes in pharmaceutical manufacturing. It emphasizes the need for a quality risk management approach, clear validation plans for large projects, and the repetition of risk assessments as knowledge and understanding evolve. The section also highlights the significance of incorporating appropriate checks to ensure data integrity, the approval and authorization of all documents by relevant personnel, and the preparation of validation protocols defining critical systems and acceptance criteria. Additionally, it mentions the combination of qualification documents where appropriate and the need for scientific justification for any significant changes to approved protocols during execution.", "excerpt_keywords": "Qualification, Validation, Equipment, Facilities, Utilities, Systems"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[22] EMA Annex 15 Qualification and Validation.pdf\n## 2.8 results\n\nresults which fail to meet the pre-defined acceptance criteria should be recorded as a deviation and be fully investigated according to local procedures. any implications for the validation should be discussed in the report.\n\n## 2.9 review and conclusions\n\nthe review and conclusions of the validation should be reported and the results obtained summarized against the acceptance criteria. any subsequent changes to acceptance criteria should be scientifically justified and a final recommendation made as to the outcome of the validation.\n\n## 2.10 formal release\n\na formal release for the next stage in the qualification and validation process should be authorized by the relevant responsible personnel either as part of the validation report approval or as a separate summary document. conditional approval to proceed to the next qualification stage can be given where certain acceptance criteria or deviations have not been fully addressed and there is a documented assessment that there is no significant impact on the next activity.\n\n## 3. qualification stages for equipment, facilities, utilities, and systems\n\n### 3.1 qualification activities\n\nqualification activities should consider all stages from initial development of the user requirements specification through to the end of use of the equipment, facility, utility, or system. the main stages and some suggested criteria which could be included in each stage are indicated below:\n\n### user requirements specification (urs)\n\nthe specification for equipment, facilities, utilities, or systems should be defined in a urs and/or a functional specification. the essential elements of quality need to be built in at this stage and any gmp risks mitigated to an acceptable level. the urs should be a point of reference throughout the validation life cycle.\n\n### design qualification (dq)\n\nthe next element in the qualification of equipment, facilities, utilities, or systems is dq where the compliance of the design with gmp should be demonstrated and documented. the requirements of the user requirements specification should be verified during the design qualification.\n\n### factory acceptance testing (fat) / site acceptance testing (sat)\n\nequipment, especially if incorporating novel or complex technology, may be evaluated at the vendor prior to delivery. prior to installation, equipment should be confirmed to comply with the urs/functional specification at the vendor site, if applicable. where appropriate and justified, documentation review and some tests could be performed at the fat or other stages without the need to repeat on-site at iq/oq if it can be shown that the functionality is not affected by the transport and installation. fat may be supplemented by the execution of a sat following the receipt of equipment at the manufacturing site.", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "7eac6349-581a-477e-994a-78dd34402a46": {"__data__": {"id_": "7eac6349-581a-477e-994a-78dd34402a46", "embedding": null, "metadata": {"page_label": "5", "file_name": "[22] EMA Annex 15 Qualification and Validation.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[22] EMA Annex 15 Qualification and Validation.pdf", "file_type": "application/pdf", "file_size": 96427, "creation_date": "2024-04-07", "last_modified_date": "2024-03-29", "document_title": "Equipment Installation, Operation, and Performance Qualification Process", "questions_this_excerpt_can_answer": "1. What specific elements are included in the Installation Qualification (IQ) process for equipment, facilities, utilities, or systems according to the EMA Annex 15 guidelines?\n\n2. How does the Operational Qualification (OQ) process differ in its execution and objectives from the Installation Qualification (IQ), and what specific tests or verifications does it entail as per the EMA Annex 15?\n\n3. What criteria and tests are outlined for the Performance Qualification (PQ) phase in the context of equipment and system validation, and how does it integrate with or differ from the IQ and OQ phases according to the document?", "prev_section_summary": "The section discusses the qualification and validation process for equipment, facilities, utilities, and systems in pharmaceutical manufacturing according to the EMA Annex 15. Key topics include handling results that fail to meet acceptance criteria, reviewing and justifying changes to acceptance criteria, and the stages of qualification activities such as user requirements specification, design qualification, and factory acceptance testing. The section emphasizes the importance of documenting deviations, justifying changes, and obtaining formal release for the next qualification stage.", "excerpt_keywords": "Equipment, Qualification, Validation, EMA Annex 15, Pharmaceutical Manufacturing"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[22] EMA Annex 15 Qualification and Validation.pdf\n## installation qualification (iq)\n\n3.8. iq should be performed on equipment, facilities, utilities, or systems.\n\n3.9. iq should include, but is not limited to the following:\n\n- i. verification of the correct installation of components, instrumentation, equipment, pipe work and services against the engineering drawings and specifications;\n- ii. verification of the correct installation against pre-defined criteria;\n- iii. collection and collation of supplier operating and working instructions and maintenance requirements;\n- iv. calibration of instrumentation;\n- v. verification of the materials of construction.\n\n## operational qualification (oq)\n\n3.10. oq normally follows iq but depending on the complexity of the equipment, it may be performed as a combined installation/operation qualification (ioq).\n\n3.11. oq should include but is not limited to the following:\n\n- i. tests that have been developed from the knowledge of processes, systems and equipment to ensure the system is operating as designed;\n- ii. tests to confirm upper and lower operating limits, and /or \"worst case\" conditions.\n\n3.12. the completion of a successful oq should allow the finalisation of standard operating and cleaning procedures, operator training and preventative maintenance requirements.\n\n## performance qualification (pq)\n\n3.13. pq should normally follow the successful completion of iq and oq. however, it may in some cases be appropriate to perform it in conjunction with oq or process validation.\n\n3.14. pq should include, but is not limited to the following:\n\n- i. tests, using production materials, qualified substitutes or simulated product proven to have equivalent behaviour under normal operating conditions with worst case batch sizes. the frequency of sampling used to confirm process control should be justified;\n- ii. tests should cover the operating range of the intended process, unless documented evidence from the development phases confirming the operational ranges is available.", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "bc4563ca-f838-435f-8c3e-3e1612d9e557": {"__data__": {"id_": "bc4563ca-f838-435f-8c3e-3e1612d9e557", "embedding": null, "metadata": {"page_label": "6", "file_name": "[22] EMA Annex 15 Qualification and Validation.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[22] EMA Annex 15 Qualification and Validation.pdf", "file_type": "application/pdf", "file_size": 96427, "creation_date": "2024-04-07", "last_modified_date": "2024-03-29", "document_title": "Process Validation and Re-Qualification in Pharmaceutical Manufacturing: A Comprehensive Guide", "questions_this_excerpt_can_answer": "1. What criteria must be met for the re-qualification of equipment, facilities, utilities, and systems in pharmaceutical manufacturing according to the EMA Annex 15?\n \n2. How does the EMA Annex 15 guide the process validation for new pharmaceutical products, including the approach towards manufacturing processes developed using a traditional versus a continuous verification approach?\n\n3. What specific considerations are outlined in the EMA Annex 15 for process validation when transferring pharmaceutical products from one manufacturing site to another, or within the same site, particularly in terms of batch validation and the use of a bracketing approach?", "prev_section_summary": "The section discusses the Equipment Installation, Operation, and Performance Qualification Process according to the EMA Annex 15 guidelines. It covers the Installation Qualification (IQ) process, which involves verifying correct installation, calibration of instrumentation, and material verification. The Operational Qualification (OQ) process includes tests to ensure the system operates as designed and confirms operating limits. The Performance Qualification (PQ) phase involves tests with production materials to confirm process control and operating ranges. The section outlines the specific elements and tests involved in each phase of qualification.", "excerpt_keywords": "Process Validation, Re-Qualification, Pharmaceutical Manufacturing, EMA Annex 15, Continuous Verification"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[22] EMA Annex 15 Qualification and Validation.pdf\n#### re-qualification\n\n4.1. equipment, facilities, utilities and systems should be evaluated at an appropriate frequency to confirm that they remain in a state of control.\n\n4.2. where re-qualification is necessary and performed at a specific time period, the period should be justified and the criteria for evaluation defined. furthermore, the possibility of small changes over time should be assessed.\n\n#### process validation\n\ngeneral\n\n5.1. the requirements and principles outlined in this section are applicable to the manufacture of all pharmaceutical dosage forms. they cover the initial validation of new processes, subsequent validation of modified processes, site transfers and ongoing process verification. it is implicit in this annex that a robust product development process is in place to enable successful process validation.\n\n5.2. section 5 should be used in conjunction with the current ema guideline on process validation.\n\n5.2.1. the guideline on process validation is intended to provide guidance on the information and data to be provided in the regulatory submission only. however gmp requirements for process validation continue throughout the lifecycle of the process.\n\n5.2.2. this approach should be applied to link product and process development. it will ensure validation of the commercial manufacturing process and maintenance of the process in a state of control during routine commercial production.\n\n5.3. manufacturing processes may be developed using a traditional approach or a continuous verification approach. however, irrespective of the approach used, processes must be shown to be robust and ensure consistent product quality before any product is released to the market. manufacturing processes using the traditional approach should undergo a prospective validation programme, wherever possible, prior to certification of the product. retrospective validation is no longer an acceptable approach.\n\n5.4. process validation of new products should cover all intended marketed strengths and sites of manufacture. bracketing could be justified for new products based on extensive process knowledge from the development stage in conjunction with an appropriate ongoing verification programme.\n\n5.5. for process validation of products which are transferred from one site to another or within the same site, the number of validation batches could be reduced by the use of a bracketing approach. however, existing product knowledge, including the content of the previous validation, should be available. different strengths, batch sizes and pack sizes/container types may also use a bracketing approach, if justified.\n\n5.6. for the site transfer of legacy products, the manufacturing process and controls must comply with the marketing authorisation and meet current standards for", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "46d21eb0-0c17-4ce1-a631-a8ba6450b7b8": {"__data__": {"id_": "46d21eb0-0c17-4ce1-a631-a8ba6450b7b8", "embedding": null, "metadata": {"page_label": "7", "file_name": "[22] EMA Annex 15 Qualification and Validation.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[22] EMA Annex 15 Qualification and Validation.pdf", "file_type": "application/pdf", "file_size": 96427, "creation_date": "2024-04-07", "last_modified_date": "2024-03-29", "document_title": "Process Validation and Batch Manufacturing Requirements Guide", "questions_this_excerpt_can_answer": "1. What criteria must be met for batches manufactured during process validation in terms of size compared to commercial scale batches, and under what conditions can deviations from this standard be justified according to the EMA Annex 15?\n \n2. How does the EMA Annex 15 guide address the qualification of suppliers for critical starting and packaging materials prior to the manufacture of validation batches, and what exceptions are allowed based on quality risk management principles?\n\n3. Under what exceptional circumstances does the EMA Annex 15 allow for concurrent validation before routine production starts, and what documentation and approvals are required to proceed with this approach?", "prev_section_summary": "This section discusses the re-qualification of equipment, facilities, utilities, and systems in pharmaceutical manufacturing, emphasizing the need for periodic evaluation to ensure they remain in a state of control. It also covers process validation for new pharmaceutical products, including the importance of a robust product development process, the use of traditional versus continuous verification approaches, and considerations for transferring products between manufacturing sites. The section highlights the need for validation of all intended marketed strengths and sites of manufacture, the use of bracketing approaches to reduce validation batches, and the importance of maintaining process control during routine commercial production.", "excerpt_keywords": "Process Validation, Batch Manufacturing, Qualification, Validation, EMA Annex 15"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[22] EMA Annex 15 Qualification and Validation.pdf\n## marketing authorisation for that product type. if necessary, variations to the marketing authorisation should be submitted.\n\n5.7. process validation should establish whether all quality attributes and process parameters, which are considered important for ensuring the validated state and acceptable product quality, can be consistently met by the process. the basis by which process parameters and quality attributes were identified as being critical or non-critical should be clearly documented, taking into account the results of any risk assessment activities.\n\n5.8. normally batches manufactured for process validation should be the same size as the intended commercial scale batches and the use of any other batch sizes should be justified or specified in other sections of eudralex, volume 4.\n\n5.9. equipment, facilities, utilities and systems used for process validation should be qualified. test methods should be validated for their intended use.\n\n5.10. for all products irrespective of the approach used, process knowledge from development studies or other sources should be accessible to the manufacturing site, unless otherwise justified, and be the basis for validation activities.\n\n5.11. for process validation batches, production, development, or other site transfer personnel may be involved. batches should only be manufactured by trained personnel in accordance with gmp using approved documentation. it is expected that production personnel are involved in the manufacture of validation batches to facilitate product understanding.\n\n5.12. the suppliers of critical starting and packaging materials should be qualified prior to the manufacture of validation batches; otherwise a justification based on the application of quality risk management principles should be documented.\n\n5.13. it is especially important that the underlying process knowledge for the design space justification (if used) and for development of any mathematical models (if used) to confirm a process control strategy should be available.\n\n5.14. where validation batches are released to the market, this should be pre-defined. the conditions under which they are produced should fully comply with gmp, with the validation acceptance criteria, with any continuous process verification criteria (if used) and with the marketing authorisation or clinical trial authorisation.\n\n5.15. for the process validation of investigational medicinal products (imp), please refer to annex 13.\n\nconcurrent validation\n\n5.16. in exceptional circumstances, where there is a strong benefit-risk ratio for the patient, it may be acceptable not to complete a validation programme before routine production starts and concurrent validation could be used. however, the decision to carry out concurrent validation must be justified, documented in the vmp for visibility and approved by authorised personnel.", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "a4397009-231c-4e32-b5cc-7854efee7941": {"__data__": {"id_": "a4397009-231c-4e32-b5cc-7854efee7941", "embedding": null, "metadata": {"page_label": "8", "file_name": "[22] EMA Annex 15 Qualification and Validation.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[22] EMA Annex 15 Qualification and Validation.pdf", "file_type": "application/pdf", "file_size": 96427, "creation_date": "2024-04-07", "last_modified_date": "2024-03-29", "document_title": "Process Validation in Pharmaceutical Manufacturing: A Comprehensive Guide", "questions_this_excerpt_can_answer": "1. What specific criteria must be met for a batch of product to be certified under a concurrent validation approach in pharmaceutical manufacturing, according to the EMA Annex 15 guidelines?\n \n2. How does the EMA Annex 15 guideline justify the number of batches required for traditional process validation in pharmaceutical manufacturing, and what factors can influence the deviation from the minimum suggested number of batches?\n\n3. What are the essential components that must be included in a process validation protocol as per the EMA Annex 15 guidelines, and how is the calibration status of equipment addressed in this context?", "prev_section_summary": "The key topics of this section include process validation requirements, batch manufacturing guidelines, qualification of suppliers for critical materials, concurrent validation, process parameters, quality attributes, equipment qualification, test method validation, process knowledge, production personnel involvement, validation batch release criteria, and concurrent validation justification and approval process. Key entities mentioned include critical starting and packaging material suppliers, trained personnel, validation batches, process knowledge sources, and authorised personnel for approval.", "excerpt_keywords": "Process Validation, Pharmaceutical Manufacturing, EMA Annex 15, Validation Protocol, Equipment Qualification"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[22] EMA Annex 15 Qualification and Validation.pdf\n## 5.17\n\nwhere a concurrent validation approach has been adopted, there should be sufficient data to support a conclusion that any given batch of product is uniform and meets the defined acceptance criteria. the results and conclusion should be formally documented and available to the qualified person prior to certification of the batch.\n\n## traditional process validation\n\n5.18. in the traditional approach, a number of batches of the finished product are manufactured under routine conditions to confirm reproducibility.\n\n5.19. the number of batches manufactured and the number of samples taken should be based on quality risk management principles, allow the normal range of variation and trends to be established and provide sufficient data for evaluation. each manufacturer must determine and justify the number of batches necessary to demonstrate a high level of assurance that the process is capable of consistently delivering quality product.\n\n5.20. without prejudice to 5.19, it is generally considered acceptable that a minimum of three consecutive batches manufactured under routine conditions could constitute a validation of the process. an alternative number of batches may be justified taking into account whether standard methods of manufacture are used and whether similar products or processes are already used at the site. an initial validation exercise with three batches may need to be supplemented with further data obtained from subsequent batches as part of an on-going process verification exercise.\n\n5.21. a process validation protocol should be prepared which defines the critical process parameters (cpp), critical quality attributes (cqa) and the associated acceptance criteria which should be based on development data or documented process knowledge.\n\n5.22. process validation protocols should include, but are not limited to the following:\n\ni. a short description of pe process and a reference to pe respective master batch record;\nii. functions and responsibilities;\niii. summary of pe cqas to be investigated;\niv. summary of cpps and peir associated limits;\nv. summary of oper (non-critical) attributes and parameters which will be investigated or monitored during pe validation activity, and pe reasons for peir inclusion;\nvi. list of pe equipment/facilities to be used (including measuring/monitoring/recording equipment) togeper wip pe calibration status;\nvii. list of analytical mepods and mepod validation, as appropriate.", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "562f23dc-2d1b-43f2-af43-9a490f5619c7": {"__data__": {"id_": "562f23dc-2d1b-43f2-af43-9a490f5619c7", "embedding": null, "metadata": {"page_label": "9", "file_name": "[22] EMA Annex 15 Qualification and Validation.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[22] EMA Annex 15 Qualification and Validation.pdf", "file_type": "application/pdf", "file_size": 96427, "creation_date": "2024-04-07", "last_modified_date": "2024-03-29", "document_title": "Process Validation Approaches and Ongoing Process Verification: A Comprehensive Guide", "questions_this_excerpt_can_answer": "1. What specific criteria does the EMA Annex 15 document outline for employing continuous process verification in pharmaceutical manufacturing, particularly for products developed with a quality by design approach?\n\n2. How does the EMA Annex 15 document propose a hybrid approach to process validation, and under what circumstances can this approach be utilized according to the guidelines?\n\n3. According to the EMA Annex 15 document, what are the recommended practices for ongoing process verification during the lifecycle of a pharmaceutical product, and how should the extent and frequency of this verification be determined?", "prev_section_summary": "The section discusses the requirements for batch certification under concurrent validation and traditional process validation in pharmaceutical manufacturing according to the EMA Annex 15 guidelines. Key topics include the criteria for batch certification, the justification for the number of batches in traditional validation, the components of a process validation protocol, and the calibration status of equipment. Entities mentioned include critical process parameters, critical quality attributes, acceptance criteria, equipment/facilities, analytical methods, and validation protocols.", "excerpt_keywords": "EMA Annex 15, Qualification, Validation, Process Validation, Ongoing Process Verification"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[22] EMA Annex 15 Qualification and Validation.pdf\n## proposed in-process controls with acceptance criteria and the reason(s) why each in-process control is selected;\n\n## additional testing to be carried out with acceptance criteria;\n\n## sampling plan and the rationale behind it;\n\n## methods for recording and evaluating results;\n\n## process for release and certification of batches (if applicable).\n\n## continuous process verification\n\n5.23. for products developed by a quality by design approach, where it has been scientifically established during development that the established control strategy provides a high degree of assurance of product quality, then continuous process verification can be used as an alternative to traditional process validation.\n\n5.24. the method by which the process will be verified should be defined. there should be a science based control strategy for the required attributes for incoming materials, critical quality attributes and critical process parameters to confirm product realisation. this should also include regular evaluation of the control strategy. process analytical technology and multivariate statistical process control may be used as tools. each manufacturer must determine and justify the number of batches necessary to demonstrate a high level of assurance that the process is capable of consistently delivering quality product.\n\n5.25. the general principles laid down in 5.1 - 5.14 above still apply.\n\n## hybrid approach\n\n5.26. a hybrid of the traditional approach and continuous process verification could be used where there is a substantial amount of product and process knowledge and understanding which has been gained from manufacturing experience and historical batch data.\n\n5.27. this approach may also be used for any validation activities after changes or during ongoing process verification even though the product was initially validated using a traditional approach.\n\n## ongoing process verification during lifecycle\n\n5.28. paragraphs 5.28-5.32 are applicable to all three approaches to process validation mentioned above, i.e. traditional, continuous and hybrid.\n\n5.29. manufacturers should monitor product quality to ensure that a state of control is maintained throughout the product lifecycle with the relevant process trends evaluated.\n\n5.30. the extent and frequency of ongoing process verification should be reviewed periodically. at any point throughout the product lifecycle, it may be appropriate to modify the requirements taking into account the current level of process understanding and process performance.", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "dad1a77a-856b-426c-b5e8-e220357d2c1f": {"__data__": {"id_": "dad1a77a-856b-426c-b5e8-e220357d2c1f", "embedding": null, "metadata": {"page_label": "10", "file_name": "[22] EMA Annex 15 Qualification and Validation.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[22] EMA Annex 15 Qualification and Validation.pdf", "file_type": "application/pdf", "file_size": 96427, "creation_date": "2024-04-07", "last_modified_date": "2024-03-29", "document_title": "Quality Assurance in Pharmaceutical Manufacturing Processes: A Comprehensive Guide", "questions_this_excerpt_can_answer": "1. What specific statistical tools are recommended for supporting conclusions regarding the variability and capability of a given process during ongoing process verification in pharmaceutical manufacturing, as outlined in the EMA Annex 15 Qualification and Validation guidelines?\n\n2. How does the EMA Annex 15 Qualification and Validation document suggest handling the verification of transportation for medicinal products, especially considering the challenges posed by variable factors and the need for continuous monitoring of critical environmental conditions?\n\n3. What are the specific qualification requirements for equipment used in primary packaging of pharmaceutical products according to the EMA Annex 15 Qualification and Validation guidelines, particularly in relation to managing variation in equipment processing parameters?", "prev_section_summary": "The section discusses the use of continuous process verification as an alternative to traditional process validation for products developed with a quality by design approach. It outlines the criteria for employing continuous process verification, the method for verifying the process, and the number of batches necessary to demonstrate process capability. Additionally, it introduces a hybrid approach that combines traditional validation with continuous process verification based on product and process knowledge. The section also covers recommended practices for ongoing process verification during the lifecycle of a pharmaceutical product, emphasizing the need to monitor product quality, evaluate process trends, and periodically review the extent and frequency of verification.", "excerpt_keywords": "ongoing process verification, transportation verification, validation of packaging, qualification of utilities, pharmaceutical manufacturing"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[22] EMA Annex 15 Qualification and Validation.pdf\n## 5. ongoing process verification\n\nongoing process verification should be conducted under an approved protocol or equivalent documents and a corresponding report should be prepared to document the results obtained. statistical tools should be used, where appropriate, to support any conclusions with regard to the variability and capability of a given process and ensure a state of control.\n\nongoing process verification should be used throughout the product lifecycle to support the validated status of the product as documented in the product quality review. incremental changes over time should also be considered and the need for any additional actions, e.g. enhanced sampling, should be assessed.\n\n## 6. verification of transportation\n\nfinished medicinal products, investigational medicinal products, bulk product and samples should be transported from manufacturing sites in accordance with the conditions defined in the marketing authorisation, the approved label, product specification file or as justified by the manufacturer.\n\nit is recognized that verification of transportation may be challenging due to the variable factors involved; however, transportation routes should be clearly defined. seasonal and other variations should also be considered during verification of transport.\n\na risk assessment should be performed to consider the impact of variables in the transportation process other than those conditions which are continuously controlled or monitored, e.g. delays during transportation, failure of monitoring devices, topping up liquid nitrogen, product susceptibility and any other relevant factors.\n\ndue to the variable conditions expected during transportation, continuous monitoring and recording of any critical environmental conditions to which the product may be subjected should be performed, unless otherwise justified.\n\n## 7. validation of packaging\n\nvariation in equipment processing parameters especially during primary packaging may have a significant impact on the integrity and correct functioning of the pack, e.g. blister strips, sachets and sterile components, therefore primary and secondary packaging equipment for finished and bulk products should be qualified.\n\nqualification of the equipment used for primary packing should be carried out at the minimum and maximum operating ranges defined for the critical process parameters such as temperature, machine speed and sealing pressure or for any other factors.\n\n## 8. qualification of utilities\n\nthe quality of steam, water, air, other gases etc. should be confirmed following installation using the qualification steps described in section 3 above.\n\nthe period and extent of qualification should reflect any seasonal variations, if applicable, and the intended use of the utility.", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "b1e3808e-20a3-45b5-9584-bf1fd562b5de": {"__data__": {"id_": "b1e3808e-20a3-45b5-9584-bf1fd562b5de", "embedding": null, "metadata": {"page_label": "11", "file_name": "[22] EMA Annex 15 Qualification and Validation.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[22] EMA Annex 15 Qualification and Validation.pdf", "file_type": "application/pdf", "file_size": 96427, "creation_date": "2024-04-07", "last_modified_date": "2024-03-29", "document_title": "Quality Control and Validation in Pharmaceutical Manufacturing: Ensuring Compliance and Product Quality", "questions_this_excerpt_can_answer": "1. What specific criteria must analytical test methods meet in the context of qualification, validation, or cleaning exercises within pharmaceutical manufacturing, as outlined in the EMA Annex 15?\n \n2. How does the document address the validation of microbial testing methods for products and surfaces in clean rooms, particularly in relation to the influence of the product or sanitizing agents on the recovery of microorganisms?\n\n3. What considerations and criteria are outlined for conducting cleaning validation of product contact equipment in pharmaceutical manufacturing, including the approach to selecting equipment for validation and establishing limits for the carryover of product residues?", "prev_section_summary": "This section discusses ongoing process verification, verification of transportation for medicinal products, validation of packaging equipment, and qualification of utilities in pharmaceutical manufacturing processes according to the EMA Annex 15 Qualification and Validation guidelines. Key topics include the use of statistical tools for process variability, monitoring of critical environmental conditions during transportation, qualification requirements for packaging equipment, and confirmation of utility quality. Key entities mentioned include finished medicinal products, investigational medicinal products, bulk product, samples, primary and secondary packaging equipment, critical process parameters, and utilities such as steam, water, and air.", "excerpt_keywords": "risk assessment, validation, test methods, cleaning validation, pharmaceutical manufacturing"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[22] EMA Annex 15 Qualification and Validation.pdf\n### 8.3. risk assessment\n\na risk assessment should be carried out where there may be direct contact with the product, e.g. heating, ventilation and air-conditioning (hvac) systems, or indirect contact such as through heat exchangers to mitigate any risks of failure.\n\n### 9. validation of test methods\n\n9.1. all analytical test methods used in qualification, validation or cleaning exercises should be validated with an appropriate detection and quantification limit, where necessary, as defined in chapter 6 of the eudralex, volume 4, part i.\n\n9.2. where microbial testing of product is carried out, the method should be validated to confirm that the product does not influence the recovery of microorganisms.\n\n9.3. where microbial testing of surfaces in clean rooms is carried out, validation should be performed on the test method to confirm that sanitising agents do not influence the recovery of microorganisms.\n\n### 10. cleaning validation\n\n10.1. cleaning validation should be performed in order to confirm the effectiveness of any cleaning procedure for all product contact equipment. simulating agents may be used with appropriate scientific justification. where similar types of equipment are grouped together, a justification of the specific equipment selected for cleaning validation is expected.\n\n10.2. a visual check for cleanliness is an important part of the acceptance criteria for cleaning validation. it is not generally acceptable for this criterion alone to be used. repeated cleaning and retesting until acceptable residue results are obtained is not considered an acceptable approach.\n\n10.3. it is recognised that a cleaning validation programme may take some time to complete and validation with verification after each batch may be required for some products, e.g. investigational medicinal products. there should be sufficient data from the verification to support a conclusion that the equipment is clean and available for further use.\n\n10.4. validation should consider the level of automation in the cleaning process. where an automatic process is used, the specified normal operating range of the utilities and equipment should be validated.\n\n10.5. for all cleaning processes an assessment should be performed to determine the variable factors which influence cleaning effectiveness and performance, e.g. operators, the level of detail in procedures such as rinsing times etc. if variable factors have been identified, the worst case situations should be used as the basis for cleaning validation studies.\n\n10.6. limits for the carryover of product residues should be based on a toxicological evaluation. the justification for the selected limits should be documented in a risk assessment which includes all the supporting references. limits should be established for the removal of any cleaning agents used. acceptance criteria\n\n1 see ema guideline on setting health based exposure limits for use in risk identification in the manufacture of different medicinal products in shared facilities", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "75d1b5c5-9583-4f1f-8064-b0027c5e9992": {"__data__": {"id_": "75d1b5c5-9583-4f1f-8064-b0027c5e9992", "embedding": null, "metadata": {"page_label": "12", "file_name": "[22] EMA Annex 15 Qualification and Validation.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[22] EMA Annex 15 Qualification and Validation.pdf", "file_type": "application/pdf", "file_size": 96427, "creation_date": "2024-04-07", "last_modified_date": "2024-03-29", "document_title": "Cleaning Validation and Change Control in Pharmaceutical Manufacturing: Considerations and Best Practices", "questions_this_excerpt_can_answer": "1. What considerations should be taken into account when assessing the potential cumulative effect of equipment in the process equipment train for cleaning validation in pharmaceutical manufacturing?\n\n2. How should a pharmaceutical manufacturing facility approach the validation of cleaning processes for equipment that cannot be effectively cleaned using standard procedures, according to EudraLex, Volume 4, Part I?\n\n3. What criteria should be used to determine the worst-case product for cleaning validation in pharmaceutical manufacturing, and how should the impact of new products on the site be assessed?", "prev_section_summary": "This section discusses the importance of risk assessment in pharmaceutical manufacturing, validation of test methods, and cleaning validation. Key topics include the need for risk assessment in areas with direct or indirect contact with the product, validation of analytical test methods with appropriate limits, validation of microbial testing methods for products and surfaces in clean rooms, and criteria for conducting cleaning validation of product contact equipment. Entities mentioned include HVAC systems, detection and quantification limits, microbial testing, sanitizing agents, cleaning procedures, visual checks for cleanliness, automation in the cleaning process, variable factors influencing cleaning effectiveness, and limits for the carryover of product residues.", "excerpt_keywords": "Cleaning validation, Pharmaceutical manufacturing, Risk assessment, Equipment cleaning, Change control"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[22] EMA Annex 15 Qualification and Validation.pdf\n## 10. considerations for cleaning validation\n\n10.1. it is important to consider the potential cumulative effect of multiple items of equipment in the process equipment train.\n\n10.6.1. therapeutic macromolecules and peptides may degrade and denature when exposed to ph extremes and/or heat, potentially becoming pharmacologically inactive. in such cases, a toxicological evaluation may not be applicable.\n\n10.6.2. if specific product residues cannot be tested, other representative parameters such as total organic carbon (toc) and conductivity may be selected.\n\n10.7. the risk of microbial and endotoxin contamination should be taken into account when developing cleaning validation protocols.\n\n10.8. the time between manufacture and cleaning, as well as between cleaning and use, should be considered to define dirty and clean hold times for the cleaning process.\n\n10.9. for campaign manufacture, the ease of cleaning at the end of the campaign should be considered. the maximum length of a campaign (in time and/or number of batches) should determine cleaning validation exercises.\n\n10.10. when using a worst-case product approach for cleaning validation, a scientific rationale should be provided for selecting the worst-case product. the impact of new products on the site should also be assessed, with criteria for determining the worst case including solubility, cleanability, toxicity, and potency.\n\n10.11. cleaning validation protocols should specify or reference the locations to be sampled, provide rationale for their selection, and define acceptance criteria.\n\n10.12. sampling methods, such as swabbing, rinsing, or others, should be based on the production equipment. the sampling materials and method should not affect the result, and recovery should be possible from all product contact materials.\n\n10.13. the cleaning procedure should be performed a sufficient number of times based on risk assessment to meet acceptance criteria and validate the cleaning method.\n\n10.14. in cases where a cleaning process is ineffective or inappropriate for certain equipment, dedicated equipment or other measures should be used as outlined in chapters 3 and 5 of eudralex, volume 4, part i.\n\n10.15. for manual cleaning of equipment, the effectiveness of the manual process should be confirmed at a justified frequency.\n\n## 11. change control\n\n12", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "27313fe2-2826-4aa8-af51-14d9d4290ea9": {"__data__": {"id_": "27313fe2-2826-4aa8-af51-14d9d4290ea9", "embedding": null, "metadata": {"page_label": "13", "file_name": "[22] EMA Annex 15 Qualification and Validation.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[22] EMA Annex 15 Qualification and Validation.pdf", "file_type": "application/pdf", "file_size": 96427, "creation_date": "2024-04-07", "last_modified_date": "2024-03-29", "document_title": "Control of Change in Pharmaceutical Quality Management: Strategies and Best Practices", "questions_this_excerpt_can_answer": "1. What specific procedures should be in place within a pharmaceutical quality system to manage changes affecting product quality or reproducibility, according to the EMA Annex 15 Qualification and Validation guidelines?\n\n2. How should changes to the design space be managed and assessed in relation to the registered design space within the marketing authorization, as outlined in the EMA Annex 15 Qualification and Validation document?\n\n3. What steps are recommended by the EMA Annex 15 Qualification and Validation guidelines for evaluating the effectiveness of a change after its implementation within the pharmaceutical quality management system?", "prev_section_summary": "This section discusses considerations for cleaning validation in pharmaceutical manufacturing, including the potential cumulative effect of equipment, risks of degradation of therapeutic macromolecules, selection of representative parameters for testing, risk of microbial contamination, hold times for cleaning processes, considerations for campaign manufacture, worst-case product selection criteria, sampling methods and acceptance criteria, validation of cleaning methods, and measures for ineffective cleaning processes. It also touches on change control in pharmaceutical manufacturing. Key entities include equipment, product residues, microbial contamination, cleaning validation protocols, sampling methods, cleaning procedures, and change control processes.", "excerpt_keywords": "pharmaceutical quality system, design space, quality risk management, authorization, supporting data"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[22] EMA Annex 15 Qualification and Validation.pdf\n## 11. control of change\n\nthe control of change is an important part of knowledge management and should be handled within the pharmaceutical quality system.\n\n## 11.1 written procedures\n\nwritten procedures should be in place to describe the actions to be taken if a planned change is proposed to a starting material, product component, process, equipment, premises, product range, method of production or testing, batch size, design space or any other change during the lifecycle that may affect product quality or reproducibility.\n\n## 11.2 impact on design space\n\nwhere design space is used, the impact on changes to the design space should be considered against the registered design space within the marketing authorisation and the need for any regulatory actions assessed.\n\n## 11.3 quality risk management\n\nquality risk management should be used to evaluate planned changes to determine the potential impact on product quality, pharmaceutical quality systems, documentation, validation, regulatory status, calibration, maintenance and on any other system to avoid unintended consequences and to plan for any necessary process validation, verification or requalification efforts.\n\n## 11.4 authorization and approval\n\nchanges should be authorised and approved by the responsible persons or relevant functional personnel in accordance with the pharmaceutical quality system.\n\n## 11.5 supporting data review\n\nsupporting data, e.g. copies of documents, should be reviewed to confirm that the impact of the change has been demonstrated prior to final approval.\n\n## 11.6 evaluation of change\n\nfollowing implementation, and, where appropriate, an evaluation of the effectiveness of change should be carried out to confirm that the change has been successful.", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "67e32622-7021-4188-bb39-981e2005d0f6": {"__data__": {"id_": "67e32622-7021-4188-bb39-981e2005d0f6", "embedding": null, "metadata": {"page_label": "14", "file_name": "[22] EMA Annex 15 Qualification and Validation.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[22] EMA Annex 15 Qualification and Validation.pdf", "file_type": "application/pdf", "file_size": 96427, "creation_date": "2024-04-07", "last_modified_date": "2024-03-29", "document_title": "Qualification and Validation Terminology Guide", "questions_this_excerpt_can_answer": "1. How does the EMA Annex 15 document define the term \"bracketing approach\" in the context of process validation, and what are the specific conditions under which it can be applied?\n \n2. What distinguishes \"cleaning validation\" from \"cleaning verification\" according to the definitions provided in the EMA Annex 15 Qualification and Validation guide?\n\n3. Can you explain the concept of \"design space\" as outlined in the EMA Annex 15 document, including how it relates to changes within the manufacturing process?", "prev_section_summary": "The section discusses the importance of control of change within a pharmaceutical quality system, emphasizing the need for written procedures, consideration of the impact on design space, use of quality risk management, authorization and approval of changes, review of supporting data, and evaluation of change effectiveness. Key entities include planned changes affecting product quality or reproducibility, design space, quality risk management, responsible persons or relevant functional personnel, supporting data, and evaluation of change.", "excerpt_keywords": "EMA Annex 15, Qualification, Validation, Bracketing approach, Cleaning validation, Design space"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[22] EMA Annex 15 Qualification and Validation.pdf\n## glossary\n\ndefinitions of terms relating to qualification and validation which are not given in other sections of the current eudralex, volume 4, are given below.\n\n|bracketing approach.|a science and risk based validation approach such that only batches on the extremes of certain predetermined and justified design factors, e.g. strength, batch size and/or pack size, are tested during process validation. the design assumes that validation of any intermediate levels is represented by validation of the extremes. where a range of strengths is to be validated, bracketing could be applicable if the strengths are identical or very closely related in composition, e.g. for a tablet range made with different compression weights of a similar basic granulation or a capsule range made by filling different plug fill weights of the same basic composition into different size capsule shells. bracketing can be applied to different container sizes or different fills in the same container closure system.|\n|---|---|\n|change control.|a formal system by which qualified representatives of appropriate disciplines review proposed or actual changes that might affect the validated status of facilities, systems, equipment or processes. the intent is to determine the need for action to ensure and document that the system is maintained in a validated state.|\n|cleaning validation.|cleaning validation is documented evidence that an approved cleaning procedure will reproducibly remove the previous product or cleaning agents used in the equipment below the scientifically set maximum allowable carryover level.|\n|cleaning verification.|the gathering of evidence through chemical analysis after each batch/campaign to show that the residues of the previous product or cleaning agents have been reduced below the scientifically set maximum allowable carryover level.|\n|concurrent validation.|validation carried out in exceptional circumstances, justified on the basis of significant patient benefit, where the validation protocol is executed concurrently with commercialization of the validation batches.|\n|continuous process verification.|an alternative approach to process validation in which manufacturing process performance is continuously monitored and evaluated. (ich q8)|\n|control strategy.|a planned set of controls derived from current product and process understanding that ensures process performance and product quality. the controls can include parameters and attributes related to drug substance and drug product materials and components, facility and equipment operating conditions, in-process controls, finished product specifications and the associated methods and frequency of monitoring and control. (ich q10)|\n|critical process parameter (cpp).|a process parameter whose variability has an impact on a critical quality attribute and therefore should be monitored or controlled to ensure the process produces the desired quality. (ich q8)|\n|critical quality attribute (cqa).|a physical, chemical, biological or microbiological property or characteristic that should be within an approved limit, range or distribution to ensure the desired product quality. (ich q8)|\n|design qualification (dq).|the documented verification that the proposed design of the facilities, systems and equipment is suitable for the intended purpose.|\n|design space.|the multidimensional combination and interaction of input variables, e.g. material attributes, and process parameters that have been demonstrated to provide assurance of quality. working within the design space is not considered as a change.|", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "b858c026-7a99-4411-b8be-85d3fc4c1e1c": {"__data__": {"id_": "b858c026-7a99-4411-b8be-85d3fc4c1e1c", "embedding": null, "metadata": {"page_label": "15", "file_name": "[22] EMA Annex 15 Qualification and Validation.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[22] EMA Annex 15 Qualification and Validation.pdf", "file_type": "application/pdf", "file_size": 96427, "creation_date": "2024-04-07", "last_modified_date": "2024-03-29", "document_title": "Quality Assurance and Validation Processes in Pharmaceutical Manufacturing: A Comprehensive Guide", "questions_this_excerpt_can_answer": "1. What is the definition of \"design space\" in the context of pharmaceutical manufacturing and how does it relate to regulatory post-approval processes according to the EMA Annex 15?\n \n2. How does the EMA Annex 15 differentiate between Installation Qualification (IQ), Operational Qualification (OQ), and Performance Qualification (PQ) in the validation process of pharmaceutical manufacturing equipment and systems?\n\n3. According to the EMA Annex 15, what constitutes \"ongoing process verification\" in the pharmaceutical industry, and how does it ensure that the manufacturing process remains in a state of control during commercial production?", "prev_section_summary": "The section provides definitions of key terms related to qualification and validation in the pharmaceutical industry, as outlined in the EMA Annex 15 document. It covers concepts such as bracketing approach, change control, cleaning validation, cleaning verification, concurrent validation, continuous process verification, control strategy, critical process parameter, critical quality attribute, design qualification, and design space. These definitions help clarify the terminology and processes involved in ensuring the quality and validation of pharmaceutical manufacturing processes.", "excerpt_keywords": "pharmaceutical manufacturing, validation, EMA Annex 15, quality assurance, process verification"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[22] EMA Annex 15 Qualification and Validation.pdf\n## movement out of the design space is considered to be a change and would normally initiate a regulatory post-approval change process. design space is proposed by the applicant and is subject to regulatory assessment and approval. (ich q8)\n\ninstallation qualification (iq). the documented verification that the facilities, systems, and equipment, as installed or modified, comply with the approved design and the manufacturers recommendations.\n\nknowledge management. a systematic approach to acquire, analyze, store, and disseminate information. (ich q10)\n\nlifecycle. all phases in the life of a product, equipment, or facility from initial development or use through to discontinuation of use.\n\nongoing process verification (also known as continued process verification). documented evidence that the process remains in a state of control during commercial manufacture.\n\noperational qualification (oq). the documented verification that the facilities, systems, and equipment, as installed or modified, perform as intended throughout the anticipated operating ranges.\n\nperformance qualification (pq). the documented verification that systems and equipment can perform effectively and reproducibly based on the approved process method and product specification.\n\nprocess validation. the documented evidence that the process, operated within established parameters, can perform effectively and reproducibly to produce a medicinal product meeting its predetermined specifications and quality attributes.\n\nproduct realization. achievement of a product with the quality attributes to meet the needs of patients, healthcare professionals, regulatory authorities, and internal customer requirements. (ich q10)\n\nprospective validation. validation carried out before routine production of products intended for sale.\n\nquality by design. a systematic approach that begins with predefined objectives and emphasizes product and process understanding and process control, based on sound science and quality risk management.\n\nquality risk management. a systematic process for the assessment, control, communication, and review of risks to quality across the lifecycle. (ich q9)\n\nsimulated agents. a material that closely approximates the physical and, where practical, the chemical characteristics, e.g. viscosity, particle size, ph, etc., of the product under validation.\n\nstate of control. a condition in which the set of controls consistently provides assurance of acceptable process performance and product quality.\n\ntraditional approach. a product development approach where set points and operating ranges for process parameters are defined to ensure reproducibility.\n\nworst case. a condition or set of conditions encompassing upper and lower processing limits and circumstances, within standard operating procedures, which pose the greatest chance of product or process failure when compared to ideal conditions. such conditions do not necessarily induce product or process failure.", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "ebc26979-d7c2-4b0e-8463-22c806396e9d": {"__data__": {"id_": "ebc26979-d7c2-4b0e-8463-22c806396e9d", "embedding": null, "metadata": {"page_label": "16", "file_name": "[22] EMA Annex 15 Qualification and Validation.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[22] EMA Annex 15 Qualification and Validation.pdf", "file_type": "application/pdf", "file_size": 96427, "creation_date": "2024-04-07", "last_modified_date": "2024-03-29", "document_title": "User Requirements Specification (URS) Framework: A Comprehensive Guide for Developing User Requirements Specifications", "questions_this_excerpt_can_answer": "1. What is the definition of User Requirements Specification (URS) as outlined in the EMA Annex 15 Qualification and Validation document?\n \n2. According to the document titled \"User Requirements Specification (URS) Framework: A Comprehensive Guide for Developing User Requirements Specifications,\" what are the key components necessary for creating a feasible design that meets the intended purpose of a system?\n\n3. How does the EMA Annex 15 document describe the relationship between owner, user, and engineering requirements in the development of a User Requirements Specification (URS)?", "prev_section_summary": "The section discusses key concepts related to qualification and validation processes in pharmaceutical manufacturing according to the EMA Annex 15. It covers topics such as design space, installation qualification (IQ), operational qualification (OQ), performance qualification (PQ), ongoing process verification, process validation, quality by design, quality risk management, and more. The entities mentioned include lifecycle, knowledge management, product realization, quality attributes, quality risk management, and state of control. These concepts are essential for ensuring the quality and consistency of pharmaceutical manufacturing processes.", "excerpt_keywords": "User Requirements Specification, URS, EMA Annex 15, Qualification, Validation"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[22] EMA Annex 15 Qualification and Validation.pdf\n# user requirements specification (urs)\n\nthe set of owner, user and engineering requirements necessary and sufficient to create a feasible design meeting the intended purpose of the system.\n\n16", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "9c56d074-d765-4c0a-8c20-6432648a8f4d": {"__data__": {"id_": "9c56d074-d765-4c0a-8c20-6432648a8f4d", "embedding": null, "metadata": {"page_label": "1", "file_name": "[23] EMA Annex 11 Computerised Systems.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[23] EMA Annex 11 Computerised Systems.pdf", "file_type": "application/pdf", "file_size": 22461, "creation_date": "2024-04-07", "last_modified_date": "2024-03-29", "document_title": "Guidelines for Computerised Systems in Good Manufacturing Practice for Medicinal Products in the European Union: Ensuring Compliance and Quality Assurance", "questions_this_excerpt_can_answer": "1. What is the legal basis for publishing the detailed guidelines found in Annex 11 of the \"Guidelines for Computerised Systems in Good Manufacturing Practice for Medicinal Products in the European Union\"?\n \n2. What prompted the revision of Annex 11 in the \"Guidelines for Computerised Systems in Good Manufacturing Practice for Medicinal Products in the European Union\"?\n\n3. By what date did the revised Annex 11 of the \"Guidelines for Computerised Systems in Good Manufacturing Practice for Medicinal Products in the European Union\" come into operation?", "excerpt_keywords": "European Commission, Good Manufacturing Practice, Medicinal Products, Computerised Systems, Directive 2001/83/EC"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[23] EMA Annex 11 Computerised Systems.pdf\n## european commission\n\n## health and consumers directorate-general\n\n## public health and risk assessment\n\n## pharmaceuticals brussels\n\neudralex sanco/c8/am/sl/ares(2010)1064599\n\n## the rules governing medicinal products in the european union\n\n## volume 4\n\n## good manufacturing practice\n\n## medicinal products for human and veterinary use\n\n## annex 11: computerised systems\n\nlegal basis for publishing the detailed guidelines: article 47 of directive 2001/83/ec on\nthe community code relating to medicinal products for human use and article 51 of directive\n2001/82/ec on the community code relating to veterinary medicinal products. this document\nprovides guidance for the interpretation of the principles and guidelines of good\nmanufacturing practice (gmp) for medicinal products as laid down in directive 2003/94/ec\nfor medicinal products for human use and directive 91/412/eec for veterinary use.\n\nstatus of the document: revision 1\n\nreasons for changes: the annex has been revised in response to the increased use of\ncomputerised systems and the increased complexity of these systems. consequential\namendments are also proposed for chapter 4 of the gmp guide.\n\ndeadline for coming into operation: 30 june 2011", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "2611e357-48e7-44d7-9173-43b81777aa5e": {"__data__": {"id_": "2611e357-48e7-44d7-9173-43b81777aa5e", "embedding": null, "metadata": {"page_label": "2", "file_name": "[23] EMA Annex 11 Computerised Systems.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[23] EMA Annex 11 Computerised Systems.pdf", "file_type": "application/pdf", "file_size": 22461, "creation_date": "2024-04-07", "last_modified_date": "2024-03-29", "document_title": "Guidelines for Computerised System Validation and Risk Management in GMP Regulated Activities", "questions_this_excerpt_can_answer": "1. What principles guide the application of risk management throughout the lifecycle of computerised systems in GMP regulated activities according to the EMA Annex 11 guidelines?\n \n2. How does the EMA Annex 11 address the involvement and responsibilities of third parties, such as suppliers and service providers, in the context of computerised systems used in GMP regulated activities?\n\n3. What criteria and considerations are outlined in the EMA Annex 11 for the validation process of computerised systems within GMP regulated environments, particularly in relation to the project phase documentation and reports?", "prev_section_summary": "The section discusses the guidelines for computerised systems in Good Manufacturing Practice for Medicinal Products in the European Union, specifically focusing on Annex 11. The legal basis for publishing these guidelines is provided, citing directives related to medicinal products for human and veterinary use. The document is in revision 1 due to the increased use and complexity of computerised systems, with consequential amendments proposed for the GMP guide. The deadline for the revised Annex 11 to come into operation is 30 June 2011. Key entities mentioned include the European Commission, the Health and Consumers Directorate-General, and the Pharmaceuticals Brussels division.", "excerpt_keywords": "EMA Annex 11, Computerised Systems, Risk Management, GMP Regulated Activities, Validation"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[23] EMA Annex 11 Computerised Systems.pdf\n## commission europeenne, b-1049 bruxelles / europese commissie, b-1049 brussel - belgium\n\nprinciple telephone: (32-2) 299 11 11\n\nthis annex applies to all forms of computerised systems used as part of a gmp regulated activities. a computerised system is a set of software and hardware components which together fulfill certain functionalities. the application should be validated; it infrastructure should be qualified. where a computerised system replaces a manual operation, there should be no resultant decrease in product quality, process control or quality assurance. there should be no increase in the overall risk of the process.\n\n### general\n\n1. risk management\nrisk management should be applied throughout the lifecycle of the computerised system taking into account patient safety, data integrity and product quality. as part of a risk management system, decisions on the extent of validation and data integrity controls should be based on a justified and documented risk assessment of the computerised system.\n2. personnel\nthere should be close cooperation between all relevant personnel such as process owner, system owner, qualified persons and it. all personnel should have appropriate qualifications, level of access and defined responsibilities to carry out their assigned duties.\n3. suppliers and service providers\n1. when third parties (e.g. suppliers, service providers) are used e.g. to provide, install, configure, integrate, validate, maintain (e.g. via remote access), modify or retain a computerised system or related service or for data processing, formal agreements must exist between the manufacturer and any third parties, and these agreements should include clear statements of the responsibilities of the third party. it-departments should be considered analogous.\n2. the competence and reliability of a supplier are key factors when selecting a product or service provider. the need for an audit should be based on a risk assessment.\n3. documentation supplied with commercial off-the-shelf products should be reviewed by regulated users to check that user requirements are fulfilled.\n4. quality system and audit information relating to suppliers or developers of software and implemented systems should be made available to inspectors on request.\n\n### project phase\n\n1. validation\nthe validation documentation and reports should cover the relevant steps of the life cycle. manufacturers should be able to justify their standards, protocols, acceptance criteria, procedures and records based on their risk assessment.", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "88f29c14-e4ef-4b65-ae5f-b057fe58317d": {"__data__": {"id_": "88f29c14-e4ef-4b65-ae5f-b057fe58317d", "embedding": null, "metadata": {"page_label": "3", "file_name": "[23] EMA Annex 11 Computerised Systems.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[23] EMA Annex 11 Computerised Systems.pdf", "file_type": "application/pdf", "file_size": 22461, "creation_date": "2024-04-07", "last_modified_date": "2024-03-29", "document_title": "Best Practices for Computerized System Validation and Data Management", "questions_this_excerpt_can_answer": "1. What specific elements should validation documentation for computerized systems in a GMP environment include, particularly regarding change control and deviations observed during the validation process?\n\n2. How does the document recommend ensuring the integrity and accuracy of data when transferring it to another format or system, especially in the context of validation checks to prevent alteration in value and/or meaning?\n\n3. What are the recommended practices for securing stored data in computerized systems, including measures for data security, back-ups, and ensuring data accessibility, readability, and accuracy throughout the retention period?", "prev_section_summary": "The section discusses the principles of risk management in computerised systems used in GMP regulated activities according to EMA Annex 11 guidelines. It emphasizes the importance of validation, qualification of IT infrastructure, and ensuring no decrease in product quality or increase in process risk when transitioning from manual to computerised systems. The section also addresses the involvement and responsibilities of third parties, such as suppliers and service providers, in the context of computerised systems. It highlights the need for formal agreements, supplier competence, and documentation review. Additionally, the section outlines criteria for the validation process during the project phase, emphasizing the importance of justification based on risk assessment and the availability of quality system and audit information for inspectors.", "excerpt_keywords": "Computerized Systems, Validation Documentation, Data Integrity, Data Management, GMP Environment"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[23] EMA Annex 11 Computerised Systems.pdf\n#### validation documentation\n\nvalidation documentation should include change control records (if applicable) and reports on any deviations observed during the validation process.\n\n#### listing of relevant systems\n\nan up to date listing of all relevant systems and their gmp functionality (inventory) should be available. for critical systems, an up to date system description detailing the physical and logical arrangements, data flows and interfaces with other systems or processes, any hardware and software pre-requisites, and security measures should be available.\n\n#### user requirements specifications\n\nuser requirements specifications should describe the required functions of the computerized system and be based on documented risk assessment and gmp impact. user requirements should be traceable throughout the life-cycle.\n\n#### quality management system\n\nthe regulated user should take all reasonable steps to ensure that the system has been developed in accordance with an appropriate quality management system. the supplier should be assessed appropriately.\n\n#### validation of bespoke systems\n\nfor the validation of bespoke or customized computerized systems, there should be a process in place that ensures the formal assessment and reporting of quality and performance measures for all the life-cycle stages of the system.\n\n#### test methods and scenarios\n\nevidence of appropriate test methods and test scenarios should be demonstrated. particularly, system (process) parameter limits, data limits, and error handling should be considered. automated testing tools and test environments should have documented assessments for their adequacy.\n\n#### data validation\n\nif data are transferred to another data format or system, validation should include checks that data are not altered in value and/or meaning during this migration process.\n\n### operational phase\n\n#### data exchange\n\ncomputerized systems exchanging data electronically with other systems should include appropriate built-in checks for the correct and secure entry and processing of data to minimize risks.\n\n#### accuracy checks\n\nfor critical data entered manually, there should be an additional check on the accuracy of the data. this check may be done by a second operator or by validated electronic means. the criticality and potential consequences of erroneous or incorrectly entered data to a system should be covered by risk management.\n\n#### data storage\n\n7.1 data security: data should be secured by both physical and electronic means against damage. stored data should be checked for accessibility, readability, and accuracy. access to data should be ensured throughout the retention period.\n\n7.2 data back-ups: regular back-ups of all relevant data should be done. integrity and accuracy of back-up data and the ability to restore the data should be checked during validation and monitored periodically.", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "51df4e6d-658e-4a38-8217-01937b7c0499": {"__data__": {"id_": "51df4e6d-658e-4a38-8217-01937b7c0499", "embedding": null, "metadata": {"page_label": "4", "file_name": "[23] EMA Annex 11 Computerised Systems.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[23] EMA Annex 11 Computerised Systems.pdf", "file_type": "application/pdf", "file_size": 22461, "creation_date": "2024-04-07", "last_modified_date": "2024-03-29", "document_title": "\"Ensuring Compliance and Security in Computerised Systems\"", "questions_this_excerpt_can_answer": "1. What considerations should be made when implementing an audit trail for GMP-relevant changes in computerised systems according to the EMA Annex 11 guidelines?\n\n2. How does the EMA Annex 11 document suggest handling the security of computerised systems to ensure only authorised access, and what methods are recommended for preventing unauthorised entry?\n\n3. What are the specific expectations outlined in the EMA Annex 11 document regarding the use and characteristics of electronic signatures in the context of compliance and security within computerised systems?", "prev_section_summary": "The section discusses the importance of validation documentation for computerized systems in a GMP environment, including elements such as change control records and reports on deviations. It emphasizes the need for an up-to-date listing of relevant systems, user requirements specifications based on risk assessment, and the validation of bespoke systems. The section also covers test methods and scenarios, data validation during data transfer, data exchange with other systems, accuracy checks for manually entered data, and data storage practices including data security, back-ups, and ensuring data accessibility, readability, and accuracy throughout the retention period.", "excerpt_keywords": "EMA Annex 11, Computerised Systems, Compliance, Security, Audit Trail"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[23] EMA Annex 11 Computerised Systems.pdf\n## 8. printouts\n\n8.1 it should be possible to obtain clear printed copies of electronically stored data.\n\n8.2 for records supporting batch release it should be possible to generate printouts indicating if any of the data has been changed since the original entry.\n\n## 9. audit trails\n\nconsideration should be given, based on a risk assessment, to building into the system the creation of a record of all gmp-relevant changes and deletions (a system generated \"audit trail\"). for change or deletion of gmp-relevant data the reason should be documented. audit trails need to be available and convertible to a generally intelligible form and regularly reviewed.\n\n## 10. change and configuration management\n\nany changes to a computerised system including system configurations should only be made in a controlled manner in accordance with a defined procedure.\n\n## 11. periodic evaluation\n\ncomputerised systems should be periodically evaluated to confirm that they remain in a valid state and are compliant with gmp. such evaluations should include, where appropriate, the current range of functionality, deviation records, incidents, problems, upgrade history, performance, reliability, security and validation status reports.\n\n## 12. security\n\n12.1 physical and/or logical controls should be in place to restrict access to computerised system to authorised persons. suitable methods of preventing unauthorised entry to the system may include the use of keys, pass cards, personal codes with passwords, biometrics, restricted access to computer equipment and data storage areas.\n\n12.2 the extent of security controls depends on the criticality of the computerised system.\n\n12.3 creation, change, and cancellation of access authorisations should be recorded.\n\n12.4 management systems for data and for documents should be designed to record the identity of operators entering, changing, confirming or deleting data including date and time.\n\n## 13. incident management\n\nall incidents, not only system failures and data errors, should be reported and assessed. the root cause of a critical incident should be identified and should form the basis of corrective and preventive actions.\n\n## 14. electronic signature\n\nelectronic records may be signed electronically. electronic signatures are expected to:\n\na. have the same impact as hand-written signatures within the boundaries of the company,\n\nb. be permanently linked to their respective record,\n\nc. include the time and date that they were applied.", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "5fe796f0-3943-42e1-8ae6-24986e98f68c": {"__data__": {"id_": "5fe796f0-3943-42e1-8ae6-24986e98f68c", "embedding": null, "metadata": {"page_label": "5", "file_name": "[23] EMA Annex 11 Computerised Systems.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[23] EMA Annex 11 Computerised Systems.pdf", "file_type": "application/pdf", "file_size": 22461, "creation_date": "2024-04-07", "last_modified_date": "2024-03-29", "document_title": "Computerised System Management and Compliance Guidelines", "questions_this_excerpt_can_answer": "1. What specific measures should be taken to ensure the integrity and accessibility of archived data when significant changes are made to a computerised system, according to the EMA Annex 11 guidelines?\n\n2. How does the EMA Annex 11 define the responsibilities of a \"system owner\" in the context of computerised system management and compliance within pharmaceutical manufacturing?\n\n3. What are the EMA Annex 11 guidelines' requirements for the certification and release of pharmaceutical batches using a computerised system, particularly regarding the use of electronic signatures?", "prev_section_summary": "The section covers important topics related to compliance and security in computerised systems, including printouts, audit trails, change and configuration management, periodic evaluation, security controls, incident management, and electronic signatures. Key entities mentioned include the need for clear printed copies of electronically stored data, the importance of audit trails for tracking GMP-relevant changes, the controlled management of system changes, the periodic evaluation of system validity and compliance, security controls to restrict access to authorised personnel, incident reporting and assessment, and the requirements for electronic signatures to have the same impact as handwritten signatures.", "excerpt_keywords": "Computerised system, Compliance guidelines, Pharmaceutical manufacturing, Electronic signatures, Data integrity"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[23] EMA Annex 11 Computerised Systems.pdf\n## batch release\n\nwhen a computerised system is used for recording certification and batch release, the system should allow only qualified persons to certify the release of the batches and it should clearly identify and record the person releasing or certifying the batches. this should be performed using an electronic signature.\n\n## business continuity\n\nfor the availability of computerised systems supporting critical processes, provisions should be made to ensure continuity of support for those processes in the event of a system breakdown (e.g. a manual or alternative system). the time required to bring the alternative arrangements into use should be based on risk and appropriate for a particular system and the business process it supports. these arrangements should be adequately documented and tested.\n\n## archiving\n\ndata may be archived. this data should be checked for accessibility, readability and integrity. if relevant changes are to be made to the system (e.g. computer equipment or programs), then the ability to retrieve the data should be ensured and tested.\n\n## glossary\n\n|application:|software installed on a defined platform/hardware providing specific functionality|\n|---|---|\n|bespoke/customized computerised system:|a computerised system individually designed to suit a specific business process|\n|commercial of the shelf software:|software commercially available, whose fitness for use is demonstrated by a broad spectrum of users.|\n|it infrastructure:|the hardware and software such as networking software and operation systems, which makes it possible for the application to function.|\n|life cycle:|all phases in the life of the system from initial requirements until retirement including design, specification, programming, testing, installation, operation, and maintenance.|\n|process owner:|the person responsible for the business process.|\n|system owner:|the person responsible for the availability, and maintenance of a computerised system and for the security of the data residing on that system.|\n|third party:|parties not directly managed by the holder of the manufacturing and/or import authorisation.|", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "e5b1f2e6-4915-44a5-911e-08c035b9aec0": {"__data__": {"id_": "e5b1f2e6-4915-44a5-911e-08c035b9aec0", "embedding": null, "metadata": {"page_label": "1", "file_name": "[27] PA-PH-OMCL (08) 88 R5 Annex 2 Validation of Complex Computerised Systems.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[27] PA-PH-OMCL (08) 88 R5 Annex 2 Validation of Complex Computerised Systems.pdf", "file_type": "application/pdf", "file_size": 296295, "creation_date": "2024-04-07", "last_modified_date": "2024-04-05", "document_title": "Validation of Computerised Systems in the General European OMCL Network (GEON) by the European Directorate for Quality of Medicines & Healthcare", "questions_this_excerpt_can_answer": "1. What is the legislative basis for the \"Validation of Computerised Systems in the General European OMCL Network (GEON)\" guideline as outlined by the European Directorate for Quality of Medicines & Healthcare?\n\n2. Can you detail the evolution or changes in the titles or references of the document related to the validation of computerised systems within the GEON from its first adoption to the latest revision in 2018?\n\n3. Who is the custodian responsible for the elaboration of the document titled \"Validation of Computerised Systems\" and its annexes, specifically focusing on the validation of complex computerised systems within the context of the OMCL network and the EDQM of the Council of Europe?", "excerpt_keywords": "Keywords: European Directorate, OMCL Network, Validation, Complex Computerised Systems, EDQM"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[27] PA-PH-OMCL (08) 88 R5 Annex 2 Validation of Complex Computerised Systems.pdf\n## european directorate for the quality of medicines & healthcare\n\n## general european omcl network (geon)\n\n## quality management document\n\npa/ph/omcl (08) 88 r5\n\n|full document title|validation of computerised systems|\n|---|---|\n|and reference|annex 2 - validation of complex computerised systems|\n|document type|guideline|\n|legislative basis|-|\n|date of first adoption|may 2009|\n|date of original entry into force|july 2009|\n|date of entry into force of revised document|august 2018|\n|previous titles/other references / last valid version|validation of computerised systems|\n| |annex 2: validation of databases (db), laboratory information management systems (lims) and electronic laboratory notebooks (eln)|\n| |pa/ph/omcl (08) 88 r|\n|custodian|the present document was elaborated by the omcl network / edqm of the council of europe|\n|concerned network|geon|", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "d09a0fcf-8040-4491-ae81-e18556e69cdd": {"__data__": {"id_": "d09a0fcf-8040-4491-ae81-e18556e69cdd", "embedding": null, "metadata": {"page_label": "2", "file_name": "[27] PA-PH-OMCL (08) 88 R5 Annex 2 Validation of Complex Computerised Systems.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[27] PA-PH-OMCL (08) 88 R5 Annex 2 Validation of Complex Computerised Systems.pdf", "file_type": "application/pdf", "file_size": 296295, "creation_date": "2024-04-07", "last_modified_date": "2024-04-05", "document_title": "Validation of Complex Computerised Systems: User Requirements Specifications (URS) Document", "questions_this_excerpt_can_answer": "1. What specific criteria are recommended for inclusion in the User Requirements Specification (URS) for the validation of complex computerised systems according to the OMCL network guideline's annex 2?\n \n2. How does the OMCL network guideline's annex 2 differentiate between mandatory requirements, recommendations, and non-binding possibilities in the context of validating complex computerised systems?\n\n3. What procedures are outlined in the OMCL network guideline's annex 2 for updating the User Requirements Specification (URS) document to ensure traceability and version control of changes in the validation process of complex computerised systems?", "prev_section_summary": "The section discusses the validation of computerised systems within the General European OMCL Network (GEON) by the European Directorate for Quality of Medicines & Healthcare. Key topics include the legislative basis for the guideline, the evolution of the document titles and references from its first adoption in 2009 to the latest revision in 2018, and the custodian responsible for the document's elaboration. Entities mentioned include the European Directorate for the Quality of Medicines & Healthcare, GEON, and the OMCL network/EDQM of the Council of Europe.", "excerpt_keywords": "Validation, Complex Computerised Systems, User Requirements Specification, OMCL Network Guideline, Traceability"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[27] PA-PH-OMCL (08) 88 R5 Annex 2 Validation of Complex Computerised Systems.pdf\n## annex 2 of the omcl network guideline \"validation of computerised systems\"\n\n## validation of complex computerised systems\n\nnote: mandatory requirements in this guideline and its annexes are defined using the terms \"shall\" or \"must\". the use of \"should\" indicates a recommendation. for these parts of the text other appropriately justified approaches are acceptable. the term \"can\" indicates a possibility or an example with non-binding character.\n\n### 1. introduction\n\nthis is the 2nd annex of the core document \"validation of computerised systems\", and it should be used in combination with the latter when planning, performing and documenting the validation steps of complex computerised systems. excel spreadsheet validation is described in the 1st annex of the core document and not subjected here.\n\n### 2. user requirements specifications (urs)\n\nthe selection and purchase of new software and the associated computer and laboratory equipment should follow a conscious decision-making process based on the requirements for the intended use of the computerised system. a user requirements specification (urs) should describe the functional and technical requirements of the computerised system, as defined by the omcl, in terms of both software and hardware. it should also cover the aspects of information security and data integrity.\n\nsome of the items that can be included are:\n\na) description of pe software used (e.g. excel, access, oracle), including version;\nb) requirements on hardware components and operating system;\nc) description of functions;\nd) description of pe attributes of data;\ne) terminology (e.g. important especially for pe consistent description of input masks/fields);\nf) database design, including masks and fields as well as a map of pe data relationships;\ng) specifications of macros, formulas and control commands;\nh) specifications of pe data inputs (e.g. format, decimal places, units);\ni) specification of pe mandatory fields for data;\nj) specifications of pe protection of masks, working sheets or pe whole application;\nk) planning of pe data migration, if applicable;\nl) specifications for traceability of data entry and changes (audit trail) of interfaces to oper system components, if applicable.\n\nthe urs shall be released by a responsible person. changes to the requirements are possible but the changes should be traceable and the urs document should be version controlled or an equivalent system established in order to ensure traceability. new or changed requirements should be communicated to all persons involved.", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "165767df-333e-48dc-9240-3ca266c1219d": {"__data__": {"id_": "165767df-333e-48dc-9240-3ca266c1219d", "embedding": null, "metadata": {"page_label": "3", "file_name": "[27] PA-PH-OMCL (08) 88 R5 Annex 2 Validation of Complex Computerised Systems.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[27] PA-PH-OMCL (08) 88 R5 Annex 2 Validation of Complex Computerised Systems.pdf", "file_type": "application/pdf", "file_size": 296295, "creation_date": "2024-04-07", "last_modified_date": "2024-04-05", "document_title": "Software Qualification and Testing in IT Environment: A Comprehensive Guide", "questions_this_excerpt_can_answer": "1. What specific steps and documentation are recommended for ensuring the correct installation of a complex computerised system within an IT environment, as outlined in the \"Software Qualification and Testing in IT Environment: A Comprehensive Guide\"?\n\n2. How does the guide suggest verifying the proper functioning of software during the Operational Qualification (OQ) phase, especially in scenarios where known raw data sets are not available for comparison?\n\n3. What risk-based approach does the document recommend for repeating the Operational Qualification (OQ) process in the context of software and hardware updates or major changes within the IT environment of a complex computerised system?", "prev_section_summary": "The section discusses the validation of complex computerised systems according to the OMCL network guideline's annex 2. It outlines the criteria recommended for inclusion in the User Requirements Specification (URS), differentiates between mandatory requirements, recommendations, and non-binding possibilities, and provides procedures for updating the URS document to ensure traceability and version control. Key topics include the introduction to the annex, user requirements specifications, and the importance of describing functional and technical requirements, information security, and data integrity in the URS. Key entities mentioned are the responsible person releasing the URS, the need for traceability of changes, and communication of new or changed requirements to all involved parties.", "excerpt_keywords": "Software Qualification, Testing, IT Environment, Operational Qualification, Risk-based Approach"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[27] PA-PH-OMCL (08) 88 R5 Annex 2 Validation of Complex Computerised Systems.pdf\n### installation qualification (iq)\n\nthe correct installation of the system in the it environment with defined hardware and operating software shall be documented and tested. detailed installation procedures should be available and carried out by well-trained personnel only.\n\nchecklists with predefined installation steps and acceptance criteria can ensure the correct installation of the system and the traceable qualification of the installation.\n\nin most cases, the computerised system is connected to a computer network with interfaces to other software (other applications) and hardware (computer equipment or laboratory equipment). it must be ensured that the system is correctly integrated and that all components are operative.\n\nthe iq typically includes:\n\n- a) a check of the required system resources both of the server and client, when applicable (e.g. supported operating system, database engine, performance of the processor, free space on the hard disk, memory, access rights for installations);\n- b) documentation of the components of the system (as a minimum, a description of the components and version of the relevant components with date of implementation);\n- c) list of users or user groups with access to the application, including type of access;\n- d) integration test and/or communication test for the interfaces to other systems/equipment.\n\noften the installation is supported by the supplier and the internal it unit.\n\n### operational qualification (oq)\n\nthe proper functioning of the software shall be checked by testing the key functions, e.g. calibration and quantification (internal standards, external standards), peak identification, and calculation of system suitability parameters.\n\nideally, a raw data set can be used for which the results are known. these raw data sets are often provided by the supplier of the software, are processed by the software and the results are then compared to the expected values.\n\nif no such data sets are available, example raw data sets can be acquired by running typical samples.\n\nthe results of the processed raw data sets should be verified by recalculating the key parameters (e.g. calibration curves from peak areas of standards) using standard (e.g., spreadsheet) software.\n\nraw data from the testing of functions affecting the measurement result and its associated measurement uncertainty (input and output data, screenshots) shall be documented within the qualification report.\n\noperational qualification should be repeated in a risk-based approach after installation of new software modules, new software versions, new service packs, patch updates, or after major changes in the software structure of the computer (e.g. new anti-virus software). a similar approach should be taken for every change in hardware platform or system upgrades.", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "1debcfb7-f11f-4a67-bb33-fcf93d0cbafc": {"__data__": {"id_": "1debcfb7-f11f-4a67-bb33-fcf93d0cbafc", "embedding": null, "metadata": {"page_label": "4", "file_name": "[27] PA-PH-OMCL (08) 88 R5 Annex 2 Validation of Complex Computerised Systems.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[27] PA-PH-OMCL (08) 88 R5 Annex 2 Validation of Complex Computerised Systems.pdf", "file_type": "application/pdf", "file_size": 296295, "creation_date": "2024-04-07", "last_modified_date": "2024-04-05", "document_title": "Computerised System Performance Qualification, Release for Use, and Archiving Documentation", "questions_this_excerpt_can_answer": "1. What specific types of tests are recommended during the Performance Qualification (PQ) phase to ensure a computerised system meets its intended purpose according to the document \"Computerised System Performance Qualification, Release for Use, and Archiving Documentation\"?\n\n2. How should deviations from expected results during the Performance Qualification (PQ) of a computerised system be handled, as outlined in the document titled \"Computerised System Performance Qualification, Release for Use, and Archiving Documentation\"?\n\n3. What are the requirements for archiving documentation related to the specification and qualification of complex computerised systems, as specified in the document \"Computerised System Performance Qualification, Release for Use, and Archiving Documentation\"?", "prev_section_summary": "This section discusses the Installation Qualification (IQ) and Operational Qualification (OQ) processes for complex computerised systems within an IT environment. Key topics include the importance of documenting and testing the correct installation of the system, integration with other software and hardware components, and verification of system resources. The OQ phase involves testing key functions of the software, using known raw data sets for comparison when available, and documenting testing results. The section also emphasizes the need for a risk-based approach to repeating OQ after software or hardware updates, ensuring the proper functioning of the system in changing IT environments.", "excerpt_keywords": "Computerised System, Performance Qualification, Release for Use, Archiving, Validation, Documentation"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[27] PA-PH-OMCL (08) 88 R5 Annex 2 Validation of Complex Computerised Systems.pdf\n##### performance qualification (pq)\n\nthe aim of the performance qualification is to demonstrate that a computerised system is suitable for its intended purpose in the users own environment as defined in the urs. the user requirements shall be tested in the pq phase to cover the overall business use of the system in the daily routine.\n\nthe pq typically includes:\n\n- tests of functions (e.g. with a data set to ensure each feature of the application is tested);\n- negative or limit test (e.g. input of values outside the specified range);\n- test of alarm displays, if applicable (e.g. display of an oos result);\n- unauthorised input of data and access to the application;\n- tests of aberrant data (e.g. input of data in the wrong data format);\n- backup system and restore test;\n- verification of data migration, if applicable;\n- conformity with requirements of data protection, if applicable;\n- black box test as acceptance testing of the whole system.\n\neach test scenario should be traceable to the urs being tested and should describe the expected results, the acceptance criteria and the observed results. each deviation from the expected results and acceptance criteria must be discussed in the test report. a deviation can either lead to a change in the system and the test being run again or be accepted and documented with an update of the corresponding urs. raw data from the testing (input and output data, screenshots) shall be documented within the qualification report.\n\n##### release for use\n\na summary of all the test findings shall be presented in a validation report, including any deviation and the corrective actions taken. when all deviations are resolved or accepted, a formal release of the system is issued.\n\n##### archiving\n\nall documentation related to specification and qualification of complex computerised systems must be retained as long as the application is in use, plus a defined retention period covering all applicable archiving obligations. this obligation can be covered by a contract with the software provider.", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "3b51ceb5-d60b-4a17-8e08-8def1e3ae81f": {"__data__": {"id_": "3b51ceb5-d60b-4a17-8e08-8def1e3ae81f", "embedding": null, "metadata": {"page_label": "1", "file_name": "[29] PA-PH-OMCL (08) 87 R6 Annex 1 Validation of Excel Spreadsheets.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[29] PA-PH-OMCL (08) 87 R6 Annex 1 Validation of Excel Spreadsheets.pdf", "file_type": "application/pdf", "file_size": 955603, "creation_date": "2024-04-07", "last_modified_date": "2024-04-05", "document_title": "Validation of Computerised Systems in the European Directorate for the Quality of Medicines & Healthcare and General European OMCL Network (GEON): A Comprehensive Guide", "questions_this_excerpt_can_answer": "1. What is the legislative basis for the guideline titled \"Validation of Computerised Systems\" specifically related to the validation of Excel spreadsheets as outlined in the document from the European Directorate for the Quality of Medicines & Healthcare and the General European OMCL Network (GEON)?\n\n2. How has the title or reference of the guideline concerning the validation of computerised systems, particularly Excel spreadsheets, evolved over time according to the document provided by the European Directorate for the Quality of Medicines & Healthcare and the General European OMCL Network (GEON)?\n\n3. Who is the custodian responsible for the elaboration of the document titled \"Validation of Computerised Systems\" with a focus on Annex 1 - Validation of Excel Spreadsheets, and under which organisation's umbrella does this custodian operate as indicated in the provided context?", "excerpt_keywords": "Validation, Computerised Systems, Excel Spreadsheets, European Directorate, Quality Management"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[29] PA-PH-OMCL (08) 87 R6 Annex 1 Validation of Excel Spreadsheets.pdf\n## european directorate for the quality of medicines & healthcare\n\n## general european omcl network (geon)\n\n## quality management document\n\npa/ph/omcl (08) 87 r6\n\n|full document title|validation of computerised systems|\n|---|---|\n|and reference|annex 1 - validation of excel spreadsheets|\n|document type|guideline|\n|legislative basis|-|\n|date of first adoption|may 2009|\n|date of original entry into force|july 2009|\n|date of entry into force of revised document|august 2018|\n|previous titles/other references / last valid version|validation of computerised systems annex 1: validation of computerised calculation systems: example of validation of in-house software pa/ph/omcl (08) 87 2r|\n|custodian|the present document was elaborated by the omcl network / organisation edqm of the council of europe|\n|concerned network|geon|", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "46fed1e5-288b-4e72-aee4-3a3ea5db184f": {"__data__": {"id_": "46fed1e5-288b-4e72-aee4-3a3ea5db184f", "embedding": null, "metadata": {"page_label": "2", "file_name": "[29] PA-PH-OMCL (08) 87 R6 Annex 1 Validation of Excel Spreadsheets.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[29] PA-PH-OMCL (08) 87 R6 Annex 1 Validation of Excel Spreadsheets.pdf", "file_type": "application/pdf", "file_size": 955603, "creation_date": "2024-04-07", "last_modified_date": "2024-04-05", "document_title": "Best Practices for Validating and Securing Excel Spreadsheets", "questions_this_excerpt_can_answer": "1. What specific steps should be taken to ensure the security and integrity of validated Excel spreadsheets used for processing laboratory data, according to the OMCL network guideline annex on validation of computerised systems?\n\n2. How does the OMCL network guideline differentiate between mandatory requirements, recommendations, and possibilities or examples in the context of validating Excel spreadsheets?\n\n3. What are the documented procedures for the installation and maintenance of validated Excel spreadsheets to prevent unauthorized modifications, as outlined in the OMCL network guideline annex on validation of computerised systems?", "prev_section_summary": "The section discusses the validation of computerised systems, specifically focusing on Excel spreadsheets, as outlined in a document from the European Directorate for the Quality of Medicines & Healthcare and the General European OMCL Network (GEON). It provides information on the legislative basis, evolution of the guideline title, and the custodian responsible for the document. Key entities mentioned include the European Directorate for the Quality of Medicines & Healthcare, General European OMCL Network (GEON), and the custodian organization EDQM of the Council of Europe.", "excerpt_keywords": "Validation, Excel Spreadsheets, Security, Laboratory Data, OMCL Network"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[29] PA-PH-OMCL (08) 87 R6 Annex 1 Validation of Excel Spreadsheets.pdf\n## annex 1 of the omcl network guideline\n\"validation of computerised systems\"\nvalidation of excel spreadsheets\n\nnote: mandatory requirements in this guideline and its annexes are defined using the terms\n\"shall\" or \"must\". the use of \"should\" indicates a recommendation. for these parts of the text\nother appropriately justified approaches are acceptable. the term \"can\" indicates a possibility or\nan example with non-binding character.\n\n### 1. introduction\n\nthis is the 1st annex of the core document \"validation of computerised systems\", and it should be\nused in combination with the latter when planning, performing and documenting the validation\nprocess of excel(r) spreadsheets used for the processing of laboratory data.\nthis annex presents an example of excel spreadsheet validation, which should be used in\ncombination with the general requirements and recommendations given in the core document.\n\n### 2. installation and security\n\nto guarantee that only the latest validated version of the spreadsheet is being used and to maintain\nthe validated state of the spreadsheet, all validated excel spreadsheets should be stored with read-only access rights for the end users (e.g., on a protected network share). only responsible persons\nshould have write access to the network share.\nend users should have no right to modify a validated spreadsheet, add a non-validated spreadsheet\nto the share, or save data on the share. end users should only have the right to fill in the (permitted)\ncells and to print the data or save a copy to a data repository if needed.\ninstallation shall be documented, e.g. in the validation file, in a system log book or on a qa form.\nthe name of the spreadsheet, unique identification, localization, and the person responsible for the\nspreadsheet shall be documented. the records shall also include verification, regular verification\nand other issues such as updates or any problem encountered. verification is completed after\ninstallation and recorded.\n\n### 3. good practices\n\nwhen setting up a new spreadsheet, following the good practices below will reduce the risk of\naccidental modifications of the template and erroneous data input:\n- all calculating cells shall be locked (format cells > protection > locked) in order to protect\ncells containing calculations against unintended modification, except those used for data\ninput.", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "50965ba4-9a99-49da-acd2-c245a4b9bd44": {"__data__": {"id_": "50965ba4-9a99-49da-acd2-c245a4b9bd44", "embedding": null, "metadata": {"page_label": "3", "file_name": "[29] PA-PH-OMCL (08) 87 R6 Annex 1 Validation of Excel Spreadsheets.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[29] PA-PH-OMCL (08) 87 R6 Annex 1 Validation of Excel Spreadsheets.pdf", "file_type": "application/pdf", "file_size": 955603, "creation_date": "2024-04-07", "last_modified_date": "2024-04-05", "document_title": "Excel Data Input and Validation Settings Guide", "questions_this_excerpt_can_answer": "1. How can Excel spreadsheets be configured to ensure data input cells are easily identifiable and protected from the introduction of aberrant values, according to the guidelines provided in the \"Excel Data Input and Validation Settings Guide\" from the document \"[29] PA-PH-OMCL (08) 87 R6 Annex 1 Validation of Excel Spreadsheets.pdf\"?\n\n2. What specific steps are recommended in the \"Excel Data Input and Validation Settings Guide\" for applying data validation rules to prevent incorrect data entry, and how can these settings be communicated to the end user through input and error alert messages?\n\n3. In the context of validating Excel spreadsheets for pharmaceutical development, as outlined in the document \"[29] PA-PH-OMCL (08) 87 R6 Annex 1 Validation of Excel Spreadsheets.pdf\", what are the detailed procedures for locking cells and hiding formulas to secure the worksheet, and how does this process contribute to the overall data integrity and compliance with regulatory standards?", "prev_section_summary": "This section discusses the validation of Excel spreadsheets according to the OMCL network guideline on the validation of computerised systems. It covers topics such as mandatory requirements, recommendations, and examples for ensuring the security and integrity of validated Excel spreadsheets used for processing laboratory data. The section emphasizes the importance of installation and security measures, such as storing validated spreadsheets with read-only access rights, documenting installation procedures, and implementing good practices to prevent accidental modifications and errors in data input. Overall, the section provides guidance on how to validate and secure Excel spreadsheets effectively in a laboratory setting.", "excerpt_keywords": "Excel, validation, data input, data integrity, pharmaceutical development"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[29] PA-PH-OMCL (08) 87 R6 Annex 1 Validation of Excel Spreadsheets.pdf\n|content|page number|\n|---|---|\n|format cell:| |\n|number| |\n|alignment| |\n|font| |\n|border| |\n|locked| |\n|hidden| |\n|locking cells hiding formulas has no effect until you protect the worksheet (review tab changes group protect sheet button)| |\n|cells used for data input can be identified by a specific colour.| |\n|data validation rules (data tab > data validation) can be applied to data input cells to prevent the introduction of aberrant values. input messages and error alert messages can be used to inform the end user of the expected data type and acceptable range.| |\n|data validation| |\n|settings| |\n|input message| |\n|error alert| |\n|validation criteria| |\n|allow:| |\n|decimal| |\n|ignore blank| |\n|data:| |\n|between| |\n|minimum:| |\n|maximum:| |\n|apply these changes to all other cells with the same settings| |\n|clear all| |\n|cancel| |", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "99a8a15d-d23a-4b30-9615-5f714615d2fa": {"__data__": {"id_": "99a8a15d-d23a-4b30-9615-5f714615d2fa", "embedding": null, "metadata": {"page_label": "4", "file_name": "[29] PA-PH-OMCL (08) 87 R6 Annex 1 Validation of Excel Spreadsheets.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[29] PA-PH-OMCL (08) 87 R6 Annex 1 Validation of Excel Spreadsheets.pdf", "file_type": "application/pdf", "file_size": 955603, "creation_date": "2024-04-07", "last_modified_date": "2024-04-05", "document_title": "Data Validation and Documentation Best Practices in MS Excel", "questions_this_excerpt_can_answer": "1. How does the document recommend handling data validation errors related to numeric values outside a specified range in Excel spreadsheets, specifically when the value is not between 0 and 10?\n \n2. What specific Excel features does the document suggest for highlighting out-of-specification results in cells that present calculation outputs, and what are the recommended formatting options for these cells?\n\n3. According to the document, what information should be recorded or displayed to ensure proper documentation and traceability of data entries in Excel spreadsheets used for pharmaceutical development?", "prev_section_summary": "The section discusses how Excel spreadsheets can be configured to ensure data input cells are easily identifiable and protected from aberrant values. It outlines specific steps recommended in the \"Excel Data Input and Validation Settings Guide\" for applying data validation rules to prevent incorrect data entry, and how these settings can be communicated to the end user through input and error alert messages. The section also covers detailed procedures for locking cells and hiding formulas to secure the worksheet, contributing to overall data integrity and compliance with regulatory standards. Key topics include formatting cells, applying data validation rules, input and error alert messages, validation criteria, and protecting the worksheet. Key entities mentioned are data input cells, data validation rules, input messages, error alert messages, and locking cells.", "excerpt_keywords": "Excel, data validation, documentation, pharmaceutical development, data integrity"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[29] PA-PH-OMCL (08) 87 R6 Annex 1 Validation of Excel Spreadsheets.pdf\n## data validation\n\n|settings|input message|error alert|\n|---|---|---|\n|show error alert after invalid data entered|when user enters invalid data, show this error alert:| |\n|style:| | |\n|warning|out of range| |\n| |error message:| |\n|cannot enter numeric value|between and 10| |\n|clear all| |cancel|\n\n- cells used for presenting the results of the calculations (output) can be identified by a specific colour. when the results are tested against acceptance criteria it is recommended using conditional formatting (home tab > conditional formatting) to highlight out-of-specifications results.\n\ngreater than\nformat cells pat are greater than:\nwip light red fill wip dark red text\ncancel\n\n- the name of the operator responsible for data entry, and the date and time of data entry should be recorded in dedicated input cells or the spreadsheet is printed, signed and dated after calculation.\n\n- file path, spreadsheet filename and ms excel(r) version number can be displayed within the print area of the spreadsheet. the excel functions =cell(\"filename\") and =info(\"release\") can be used to display the path, filename, active sheet and the version number of ms excel(r) in use.", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "25808d54-1dd0-4a91-9e63-1cfa45511a98": {"__data__": {"id_": "25808d54-1dd0-4a91-9e63-1cfa45511a98", "embedding": null, "metadata": {"page_label": "5", "file_name": "[29] PA-PH-OMCL (08) 87 R6 Annex 1 Validation of Excel Spreadsheets.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[29] PA-PH-OMCL (08) 87 R6 Annex 1 Validation of Excel Spreadsheets.pdf", "file_type": "application/pdf", "file_size": 955603, "creation_date": "2024-04-07", "last_modified_date": "2024-04-05", "document_title": "\"Securing Vaccine Titration Spreadsheet: Password Protection and Workbook Security Measures\"", "questions_this_excerpt_can_answer": "1. What specific steps are recommended for protecting cells containing calculations in an Excel spreadsheet used for vaccine titration calculations, according to the document \"[29] PA-PH-OMCL (08) 87 R6 Annex 1 Validation of Excel Spreadsheets.pdf\"?\n\n2. How does the document suggest handling the password for both sheet protection and workbook structure protection in Excel spreadsheets used for pharmaceutical calculations, and what is the recommended practice for documenting this password?\n\n3. Can you describe the example provided in the document for calculating vaccine titration, including the type of data required and how the calibration curve and its formula are utilized in the process?", "prev_section_summary": "The section discusses data validation best practices in MS Excel, including handling errors related to numeric values outside a specified range, highlighting out-of-specification results using conditional formatting, and ensuring proper documentation and traceability of data entries. Key topics include setting error alerts for invalid data, identifying output cells with specific colors, recording operator information and entry timestamps, and displaying file path and Excel version information within the spreadsheet.", "excerpt_keywords": "Excel, Spreadsheet, Validation, Vaccine, Titration"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[29] PA-PH-OMCL (08) 87 R6 Annex 1 Validation of Excel Spreadsheets.pdf\n## cell \"filename\"\n\n|path:|u:lprofessionalldesktop [excel template xlsxlsheetl|\n|---|---|\n|version:|=info(\"release\")|\n|excel version:|140|\n\npassword protection is recommended for all cells containing calculations (review tab > protect sheet), with only the default options checked. the same password can be used for all sheets and can be documented in the validation file. the sheet protection password should not be communicated to the end users.\n\nafter protecting each sheet, the workbook structure should also be password protected (review tab > protect workbook). the same password can be used as the one for sheet protection.\n\nan example of a spreadsheet used to calculate a vaccine titration is shown on the image below. from results obtained for a reference product (height measured at 4 concentrations), a calibration curve and its formula are provided. both of them are needed to calculate the concentrations corresponding to the height measured for the tested vaccine.", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "c960cdeb-4e3b-4383-b10e-18db73a1be89": {"__data__": {"id_": "c960cdeb-4e3b-4383-b10e-18db73a1be89", "embedding": null, "metadata": {"page_label": "6", "file_name": "[29] PA-PH-OMCL (08) 87 R6 Annex 1 Validation of Excel Spreadsheets.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[29] PA-PH-OMCL (08) 87 R6 Annex 1 Validation of Excel Spreadsheets.pdf", "file_type": "application/pdf", "file_size": 955603, "creation_date": "2024-04-07", "last_modified_date": "2024-04-05", "document_title": "Validation of ## Operator Software Version 1.0 Spreadsheet for Vaccine Dosage Calculation and Concentration Analysis", "questions_this_excerpt_can_answer": "1. What specific mathematical formula is used in the \"Validation of ## Operator Software Version 1.0 Spreadsheet for Vaccine Dosage Calculation and Concentration Analysis\" to calculate dosage and concentration, and how is it represented in the document?\n\n2. In the validation process of Excel spreadsheets for vaccine dosage calculation and concentration analysis as outlined in the document, what are the specific requirements and steps for documenting the spreadsheet, including handling of VBA macros and matrix formulas?\n\n3. How does the document specify the handling of data input and cell modification within the Excel spreadsheet used for vaccine dosage calculation and concentration analysis, particularly in relation to grey cells and the calibration range?", "prev_section_summary": "The section discusses the importance of password protection for cells containing calculations in Excel spreadsheets used for vaccine titration. It recommends using the same password for sheet protection and workbook structure protection, documenting the password in the validation file, and not sharing the sheet protection password with end users. An example of a spreadsheet for calculating vaccine titration is provided, including the calibration curve and formula needed for the calculations.", "excerpt_keywords": "Validation, Excel Spreadsheets, Vaccine Dosage, Concentration Analysis, VBA Macros"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[29] PA-PH-OMCL (08) 87 R6 Annex 1 Validation of Excel Spreadsheets.pdf\n## operator software name version 1.0 form:\n\n|date|y=0.335x +6.5|\n|---|---|\n|dosage|y=0.335x + 6.5rz = 0.947|\n|29.00|dosage|0.947|\n| |28.00|\n|conc (hgm)|hmm)|\n|65.00|28.00|\n|55.00| |\n|45.00|20.50|\n|35.00|18.50|\n|65.00|28.uu|\n|55.00|24.50|\n|45.00|21.00|\n|35.00|18.50|\n|r2= 0.95|0.97|\n|valid|calculated|calculated concentration|\n|batch number|height mm|concentration (pgml)|(ug/dose)|cv %|\n|8.00|3433|1716|\n|1750| |1642|\n|1900|13|18.66|\n|mean|18.17|34.83|17.41|6.55|valid|\n|25.00| |27.81|\n|2700| |3060|\n|2700|61.49|30.60|\n|mean|26.33|59.20|29.60|5.82|malid|\n|technician| |scientist|\n|software| |\n\nin the image, grey cells are filled with numerical data from experimentation and are the only ones that can be changed by the operator. all other cells are locked. no more than one cell from the calibration range can be empty; all cells for vaccines must be filled to guarantee proper use.\n\n## validation stages\n\n### 4.1. documentation of the spreadsheet\n\nthere should be a general description of the spreadsheet explaining its purpose, general layout, input types and data validation rules if required (some spreadsheet might be self-explaining). this description can be documented in the spreadsheet itself (e.g. in a dedicated sheet), in a sop or in the validation file.\n\nnext to the general description, a full print-out of the spreadsheet where all formulas are shown (formulas tab > show formulas) should be kept in the validation file.\n\nwhen vba macros are used, the vba code should also be printed and kept in the validation file.\n\nif matrix-formulas (array-formulas) are used, this must be indicated. an individual printout of each matrix formula is necessary.\n\n1visual basic for applications", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "8d7962ee-44dd-4167-b6f3-4ef2bf0e8916": {"__data__": {"id_": "8d7962ee-44dd-4167-b6f3-4ef2bf0e8916", "embedding": null, "metadata": {"page_label": "7", "file_name": "[29] PA-PH-OMCL (08) 87 R6 Annex 1 Validation of Excel Spreadsheets.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[29] PA-PH-OMCL (08) 87 R6 Annex 1 Validation of Excel Spreadsheets.pdf", "file_type": "application/pdf", "file_size": 955603, "creation_date": "2024-04-07", "last_modified_date": "2024-04-05", "document_title": "Validation and Documentation Requirements for Spreadsheet Calculations", "questions_this_excerpt_can_answer": "1. What specific documentation requirements are outlined for validating new versions of Excel spreadsheets used in pharmaceutical calculations, according to the document titled \"Validation and Documentation Requirements for Spreadsheet Calculations\"?\n\n2. How does the document \"Validation and Documentation Requirements for Spreadsheet Calculations\" suggest verifying the accuracy of calculations performed by self-developed Excel spreadsheets in a pharmaceutical setting?\n\n3. What example formulas and validation data entries are provided in the document \"Validation and Documentation Requirements for Spreadsheet Calculations\" to illustrate how spreadsheet calculations should be documented for validation purposes?", "prev_section_summary": "This section discusses the validation of an Excel spreadsheet used for vaccine dosage calculation and concentration analysis. It includes details on the mathematical formula used for calculations, handling of data input and cell modification, requirements for documenting the spreadsheet, and the validation stages. The section emphasizes the importance of documenting the spreadsheet, including descriptions of its purpose, layout, and validation rules, as well as the need to keep printouts of formulas, VBA macros, and matrix formulas. Grey cells in the spreadsheet contain experimental data and can be modified by the operator, while other cells are locked. Proper filling of cells is necessary for accurate vaccine dosage calculations.", "excerpt_keywords": "Validation, Documentation, Excel Spreadsheets, Pharmaceutical, Calculations"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[29] PA-PH-OMCL (08) 87 R6 Annex 1 Validation of Excel Spreadsheets.pdf\nc40 {frequency(b5;b14,d38,d40)}\n\n=frequency(b5:b14,d38:d40)\n\n=frequency(b5:b14,d38,d40)\n\n=frequency(b5:b14,d38,d40)\n\nall print-outs shall clearly identify the spreadsheet name or identification and version number. when a new version of the spreadsheet is being validated, a summary of the changes since the previous version should be given. the version of microsoft excel used for the creation and validation of the spreadsheet should be traceable (either by the documentation of the spreadsheet or by the change log of the it department), and any known incompatibilities with older or newer versions should be documented. the documentation of the spreadsheet can be considered as the urs. in order to properly document the spreadsheet, formulas shall be printed and entered into the validation document (see example below).\n\n|operator|software name & version 1.0|date|conc (ug/ml)|h (mm)|\n|---|---|---|---|---|\n|=if(b19<0.85,\"not valid\",\"valid\")|batch number|height|calculated concentration (ug/ml)|(b2+b25+b26)|\n|mean =(b28+b29+b30)|i829-ordonneedrg| | | |\n|technician|software name version|30004/2009| | |\n\n4.2. validation of the calculations of the spreadsheet\n\nall calculations are to be verified with a system completely independent from the self-developed spreadsheet. one validation method is to compare the results obtained by the spreadsheet with results obtained by commercial software or with a calculator, using the same dataset as input. another validation method is to compare the results obtained by the spreadsheet with published reference data (e.g. physicochemical data of substances).", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "06a6db1e-e6a0-481c-9373-dc660640b869": {"__data__": {"id_": "06a6db1e-e6a0-481c-9373-dc660640b869", "embedding": null, "metadata": {"page_label": "8", "file_name": "[29] PA-PH-OMCL (08) 87 R6 Annex 1 Validation of Excel Spreadsheets.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[29] PA-PH-OMCL (08) 87 R6 Annex 1 Validation of Excel Spreadsheets.pdf", "file_type": "application/pdf", "file_size": 955603, "creation_date": "2024-04-07", "last_modified_date": "2024-04-05", "document_title": "Validation of Excel Calculations using Commercial Software and Published Data: A Comprehensive Analysis", "questions_this_excerpt_can_answer": "1. How does the document address the issue of Excel version compatibility in the context of spreadsheet validation, and what specific actions are recommended for ensuring validation across different versions of Excel?\n \n2. What methodology does the document suggest for validating Excel calculations, particularly in terms of comparing Excel results with those from commercial software or published data, and how is the coefficient of correlation and calibration curve coefficients utilized in this process?\n\n3. Based on the regression analysis example provided in the document, how is the statistical significance of the relationship between the dependent and independent variables determined, and what specific statistical measures are used to assess the fit and predictive accuracy of the model?", "prev_section_summary": "The section discusses the validation and documentation requirements for Excel spreadsheets used in pharmaceutical calculations. Key topics include documenting spreadsheet changes, identifying spreadsheet versions, tracing Excel version used, documenting incompatibilities, and printing and entering formulas for validation. The section also emphasizes the need to verify calculations with independent systems and methods such as comparing results with commercial software, calculators, or published reference data. Key entities mentioned include spreadsheet name, version number, Microsoft Excel version, formulas, operators, software names, batch numbers, technicians, and validation methods.", "excerpt_keywords": "Excel, Validation, Commercial Software, Regression Analysis, Statistical Significance"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[29] PA-PH-OMCL (08) 87 R6 Annex 1 Validation of Excel Spreadsheets.pdf\n#### if the spreadsheet will be used on computers running different versions of excel it is required to perform the validation of the functionality using each of those different versions as some newer excel functions are not retro-compatible with older versions of excel.\n\n#### validation of the calculations by using commercial software or published data\n\na dataset as close to real values as possible must be chosen. excel calculations are compared to the results given by commercial software or by published data, which are considered as validated (see example in the image below). the commercial software provides the coefficient of correlation, r2 and the coefficients of the calibration curve.\n\n|regression analysis|linear model: b%|\n|---|---|\n|dependent variable:|coic standard|\n|independent variable:|estimate error|\n|parameter|significant error|\n|intercept|6389|\n|slope|335|\n|analysis|variance|\n|source|square mean square f-ratio value|\n|model|112.225 112.225 107.31 0ooo|\n|residual|.75 04583|\n|total (corr|116.|\n|correlation coefficient|0.973163|\n|r-squared|7046 percent|\n|standard error|02266|\n\nthe table shows the fitting linear model describing the relationship between coic. the equation of the fitted model is 4 = 6.5 335 coic. since the p-value in the anova table is less than 0.05, there is statistically significant relationship between coic and the confidence level.\n\nthe r-squared statistic indicates that the model fitted explains 94.70468% of the variability. the correlation coefficient of 0.973163 indicates a relatively strong relationship between the variables. the standard error of the estimate shows the standard deviation of the residuals 0.2266. this value can be used to construct prediction limits for new observations by selecting the forecast option from the excel data tab.\n\nif no discrepancy occurs, the validation of this part of the calculation is considered as fulfilled. if a discrepancy is observed, a check and revision of the formulas must be performed (and the whole validation re-performed).", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "728ae6a3-5f6d-4dba-be2d-9d4e12ec3ca1": {"__data__": {"id_": "728ae6a3-5f6d-4dba-be2d-9d4e12ec3ca1", "embedding": null, "metadata": {"page_label": "9", "file_name": "[29] PA-PH-OMCL (08) 87 R6 Annex 1 Validation of Excel Spreadsheets.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[29] PA-PH-OMCL (08) 87 R6 Annex 1 Validation of Excel Spreadsheets.pdf", "file_type": "application/pdf", "file_size": 955603, "creation_date": "2024-04-07", "last_modified_date": "2024-04-05", "document_title": "Validation and Comparison of Calculations Using a Calculator and Spreadsheet", "questions_this_excerpt_can_answer": "1. What specific method is recommended for validating calculations derived from Excel spreadsheets in a pharmaceutical context, as outlined in the document \"Validation of Excel Spreadsheets\"?\n \n2. How does the document \"Validation of Excel Spreadsheets\" suggest handling discrepancies between manual calculations and spreadsheet results in the context of pharmaceutical validation processes?\n\n3. What are the specific steps and documentation recommended for using a PC calculator as part of the validation process for Excel spreadsheet calculations in pharmaceutical environments, according to the \"Validation of Excel Spreadsheets\" document?", "prev_section_summary": "The section discusses the validation of Excel calculations, particularly in the context of compatibility across different versions of Excel. It emphasizes the importance of comparing Excel results with those from commercial software or published data to ensure accuracy. The methodology involves selecting a dataset close to real values, analyzing regression models, and utilizing statistical measures such as coefficient of correlation, r-squared, and standard error. The section provides an example of regression analysis and highlights the significance of the relationship between variables. It also mentions the need for revising formulas in case of discrepancies during validation.", "excerpt_keywords": "Validation, Excel Spreadsheets, Pharmaceutical, Calculations, Comparison"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[29] PA-PH-OMCL (08) 87 R6 Annex 1 Validation of Excel Spreadsheets.pdf\n## 4.2.2. validation of the calculations with a calculator (manual calculation)\n\nusing the printed formulas from the spreadsheet, all concentrations are calculated using a calculator (see next image) and compared with the results given by the spreadsheet.\n\n|operator|xx|software name version 1.0|form|\n|---|---|---|---|\n|date|03/06/2003|40.00|dosage|\n|h(mm)|38.00| | |\n|conc (pg/ml)|36.00| | |\n|65.00|210|34.00|hhe (omma&l)|\n|55.00|210|32.00|fno|\n|45.00|20.5|130.00|setewaxe|\n|35.00|als|28.08| |\n|65.00|1&.0|24.00| |\n|55.00|24 $|22.00| |\n|45.00|1lo|20.00| |\n|35.00|4s|30.00|45.00 50.00 55.00 60.00 65.00 70.00|\n| | | |concentration pg/ml|\n\nr? = calculated concentration h-6,$ + 0,335 * lnc\n\n|batch number|height mm|concentration (hg/ml)|(ug/dose)|cv %|\n|---|---|---|---|---|\n|a8|333| | | |\n|4s|324|alz| | |\n|mean|4s|mean : 34.| |6.ss val:4|\n|2 $|55.22|23| | |\n|27| |30.06| | |\n|14|3aj572|30.62|582|vakd|\n|mean|40.33|mean = 1160| | |\n\ntechnician: 03/06/2009\n\nscientist: software name version 1.0\n\nas an alternative, the pc calculator can be used and documented in screen shots, as in the image below.\n\nacnual staxdard umcke [ ima ml eee\n\n|70967660545348|747102|61.616|\n|---|---|---|\n|89.827|740|57161|\n\nif no discrepancy occurs, the validation of this part of the calculation is considered fulfilled. if a discrepancy is observed, both the revision of the formulas and the manual calculations should be repeated (and the whole validation re-performed).", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "60231c92-ab4e-45a9-8298-8653957a1c17": {"__data__": {"id_": "60231c92-ab4e-45a9-8298-8653957a1c17", "embedding": null, "metadata": {"page_label": "10", "file_name": "[29] PA-PH-OMCL (08) 87 R6 Annex 1 Validation of Excel Spreadsheets.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[29] PA-PH-OMCL (08) 87 R6 Annex 1 Validation of Excel Spreadsheets.pdf", "file_type": "application/pdf", "file_size": 955603, "creation_date": "2024-04-07", "last_modified_date": "2024-04-05", "document_title": "\"Ensuring Accuracy and Security in Spreadsheet Operations: Validation and Regular Verification of Protections and Calculations\"", "questions_this_excerpt_can_answer": "1. What specific steps are outlined for validating the protections of Excel spreadsheets used in pharmaceutical operations, according to the document titled \"Ensuring Accuracy and Security in Spreadsheet Operations: Validation and Regular Verification of Protections and Calculations\"?\n\n2. How does the document recommend handling the validation of Excel spreadsheet calculations in scenarios involving out-of-specification (OOS) results, missing data, or nonsensical data within the pharmaceutical industry?\n\n3. What procedure does the document suggest for the regular verification of Excel spreadsheets to maintain their validated state after any changes in software or hardware configurations within pharmaceutical operations?", "prev_section_summary": "This section discusses the validation of calculations derived from Excel spreadsheets in a pharmaceutical context. It outlines the method of validating calculations with a calculator by comparing manually calculated concentrations with spreadsheet results. The document suggests documenting the manual calculations using a PC calculator and screen shots. Discrepancies between manual calculations and spreadsheet results should be addressed by revising formulas and repeating the validation process. Key entities mentioned include operators, software version, dates, concentrations, batch numbers, technicians, and scientists.", "excerpt_keywords": "Excel spreadsheets, validation, pharmaceutical operations, calculations, data integrity"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[29] PA-PH-OMCL (08) 87 R6 Annex 1 Validation of Excel Spreadsheets.pdf\nmoreover, calculations in paragraph 4.2.1 and 4.2.2 should be re-performed with other datasets including exceptional situations, for example: oos results, missing data, or nonsense data. calculations should also be validated under these conditions, as applicable (data not shown).\n\n4.2.3. validation of the protections\n\nthe following points shall be verified and documented:\n\n- access rights to the spreadsheet (e.g. on the network share) are correct: the file cannot be modified or deleted by users.\n- the different sheets within the spreadsheet are properly protected: only input cells can be edited, all other cells are locked.\n- a password (if applicable) is needed to remove sheet protection and workbook protection.\n\nat this stage, the spreadsheet is considered as validated and its status is issued and filed.\n\n5. regular verification of the spreadsheet\n\nregularly, in a risk-based approach an omcl should define an appropriate frequency of regular verification of an existing spreadsheet. after every change performed in the soft- or hardware configuration, the spreadsheet should be verified to ensure that its validated state is maintained. a known dataset is used and the results are compared to the standard one. in order to help the operator, verification instructions containing the information required should be available. each verification is registered, with the following information: date of operation, intervention (i.e. verification), comments, and operators signature. results from the verification should be kept in the validation file or system documentation.", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "50bd9d5d-d7a4-402f-a9df-5ae4ef8d6e85": {"__data__": {"id_": "50bd9d5d-d7a4-402f-a9df-5ae4ef8d6e85", "embedding": null, "metadata": {"page_label": "1", "file_name": "[30] PA-PH-OMCL (08) 69 R7 Validation of Computerised Systems.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[30] PA-PH-OMCL (08) 69 R7 Validation of Computerised Systems.pdf", "file_type": "application/pdf", "file_size": 431019, "creation_date": "2024-04-07", "last_modified_date": "2024-04-05", "document_title": "Validation of Computerised Systems in the European Directorate for the Quality of Medicines & Healthcare: A Comprehensive Guide", "questions_this_excerpt_can_answer": "1. What is the legislative basis for the \"Validation of Computerised Systems\" guideline as provided by the European Directorate for the Quality of Medicines & Healthcare, and how does it relate to the General European OMCL Network (GEON)?\n\n2. Can you detail the history and revisions of the \"Validation of Computerised Systems\" guideline, including its original adoption, entry into force, and the entry into force of its revised document, as outlined by the European Directorate for the Quality of Medicines & Healthcare?\n\n3. Who is the custodian responsible for the elaboration of the \"Validation of Computerised Systems - Core Document,\" and what is the role of the Organisation EDQM of the Council of Europe in the context of this guideline?", "excerpt_keywords": "European Directorate, Quality of Medicines, Healthcare, Validation, Computerised Systems"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[30] PA-PH-OMCL (08) 69 R7 Validation of Computerised Systems.pdf\n## european directorate for the quality of medicines & healthcare\n\n## general european omcl network (geon)\n\nquality management document\npa/ph/omcl (08) 69 r7\n\n### validation of computerised systems\n\n### core document\n\n|full document title|validation of computerised systems - core document|\n|---|---|\n|and reference|pa/ph/omcl (08) 69 r7|\n|document type|guideline|\n|legislative basis|-|\n|date of first adoption|may 2009|\n|date of original entry into force|july 2009|\n|date of entry into force of revised document|august 2018|\n|previous titles/other references / last valid version|pa/ph/omcl (08) 69 3r|\n|custodian|the present document was elaborated by the omcl network / organisation edqm of the council of europe|\n|concerned network|geon|", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "9bb0e330-3592-443c-80b9-dfebdb103684": {"__data__": {"id_": "9bb0e330-3592-443c-80b9-dfebdb103684", "embedding": null, "metadata": {"page_label": "2", "file_name": "[30] PA-PH-OMCL (08) 69 R7 Validation of Computerised Systems.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[30] PA-PH-OMCL (08) 69 R7 Validation of Computerised Systems.pdf", "file_type": "application/pdf", "file_size": 431019, "creation_date": "2024-04-07", "last_modified_date": "2024-04-05", "document_title": "Guidelines for Validation of Computerised Systems in Official Medicines Control Laboratories: Ensuring Compliance and Data Integrity", "questions_this_excerpt_can_answer": "1. What specific terminology does the guideline use to differentiate between mandatory requirements, recommendations, and non-binding examples in the validation of computerised systems within Official Medicines Control Laboratories (OMCLs)?\n\n2. How does the guideline propose to handle the validation of computerised systems of varying complexity within OMCLs, and what categorization does it introduce for these systems?\n\n3. According to the document, on what basis should the extent of validation activities for computerised systems in OMCLs be defined, and how does this relate to the dependency of test results' correctness and traceability on these systems?", "prev_section_summary": "The section discusses the \"Validation of Computerised Systems\" guideline provided by the European Directorate for the Quality of Medicines & Healthcare, specifically focusing on the legislative basis, history, and revisions of the document. Key entities mentioned include the General European OMCL Network (GEON), the Organisation EDQM of the Council of Europe as the custodian responsible for the guideline, and the dates of adoption and entry into force of the original and revised documents. The section provides a comprehensive overview of the core document and its importance in ensuring the quality management of computerised systems in the pharmaceutical industry.", "excerpt_keywords": "Validation, Computerised Systems, Official Medicines Control Laboratories, Data Integrity, ISO/IEC 17025"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[30] PA-PH-OMCL (08) 69 R7 Validation of Computerised Systems.pdf\n# validation of computerised systems\n\n## core document\n\nnote: mandatory requirements in this guideline and its annexes are defined using the terms\n<> or <>. the use of <> indicates a recommendation. for these parts of the text\nother appropriately justified approaches are acceptable. the term <> indicates a possibility or\nan example with non-binding character.\n\n## 1. scope\n\nthis guideline defines basic principles for the validation of computerised systems used within\nofficial medicines control laboratories (omcls) and having an impact on the quality of results,\ndocument control, and data storage [1]. the purpose of this validation is to guarantee confidence in\nthe laboratory data captured, processed, reported, or stored by computerised systems. a validated\nsystem ensures accurate results and reduces any risks to data integrity.\n\nthis document applies to all types of computerised systems used in omcls. however, depending\non their complexity, the extent of testing and documentation will differ. computerised systems can\nbe categorized into three types: exempted, simple, and complex (see table i in section 3). this\ndocument describes a scalable validation approach for simple and complex computerised systems.\n\n## 2. introduction\n\nthis guideline outlines general validation principles for computerised systems of omcls in\naccordance with iso/iec 17025. it defines general minimum requirements for the validation of\ndifferent types of computerised systems and additionally gives recommendations for the practical\nimplementation and practical examples specific for omcls.\n\nthe extent of validation activities should be defined based on risk assessment, considering the\ndependency of the correctness and traceability of test results of the omcl on the computerised\nsystems.\n\ndue to the great variety of computerised systems available, it is not possible to state in a single\ndocument all the specific validation elements that are applicable.\n\nthis guideline is intended for use by omcls working under quality management systems based\non the iso/iec 17025 standard, which use computerised systems for a part or the totality of the\nprocesses related to the quality control of medicines.\n\nin order to simplify the guideline, the present core document contains a general introduction and\ngeneral requirements for different types of computerised systems. this core document is\nsupplemented with system-related annexes containing additional requirements and/or practical\nexamples of validation documentation, which are to be used in combination with the general\nrequirements given here.\n\nthis document should be considered as a guide to omcls for planning, performing, and\ndocumenting the validation of their computerised systems. it is left to the professional judgment\nand background experience of each omcl to decide on the most relevant procedures to be\nundertaken in order to give evidence that their computerised systems are working properly and are\nappropriate for their intended use.", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "6d877aa0-717f-4328-b7e6-e30a55988d25": {"__data__": {"id_": "6d877aa0-717f-4328-b7e6-e30a55988d25", "embedding": null, "metadata": {"page_label": "3", "file_name": "[30] PA-PH-OMCL (08) 69 R7 Validation of Computerised Systems.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[30] PA-PH-OMCL (08) 69 R7 Validation of Computerised Systems.pdf", "file_type": "application/pdf", "file_size": 431019, "creation_date": "2024-04-07", "last_modified_date": "2024-04-05", "document_title": "Comprehensive Guide to Computerized System Validation and Qualification Processes", "questions_this_excerpt_can_answer": "1. What distinguishes a \"commercial (off-the-shelf, configurable) computerised system\" from an \"in-house developed (custom-made or bespoke) computerised system\" according to the guidelines provided in the \"Comprehensive Guide to Computerized System Validation and Qualification Processes\"?\n\n2. How does the document define the process and criteria for \"black-box validation\" in the context of computerized system validation, and how does it differ from traditional validation methods?\n\n3. What are the specific roles and definitions of Design Qualification (DQ), Installation Qualification (IQ), Operational Qualification (OQ), and Performance Qualification (PQ) or User Acceptance Testing (UAT) in the validation process of computerized systems as outlined in the \"Comprehensive Guide to Computerized System Validation and Qualification Processes\"?", "prev_section_summary": "This section discusses the guidelines for the validation of computerised systems in Official Medicines Control Laboratories (OMCLs). Key topics include the scope of the validation, categorization of computerised systems into exempted, simple, and complex types, the importance of validation for ensuring accurate results and data integrity, general validation principles in accordance with ISO/IEC 17025, the need for risk assessment in determining the extent of validation activities, and the use of this guideline by OMCLs under quality management systems. Entities mentioned include computerised systems, OMCLs, ISO/IEC 17025 standard, validation documentation, and the professional judgment of OMCLs in planning and performing validation activities.", "excerpt_keywords": "Computerized System Validation, Qualification Processes, OMCLs, ISO/IEC 17025, Black Box Validation"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[30] PA-PH-OMCL (08) 69 R7 Validation of Computerised Systems.pdf\n### definitions\n\nfollowing definitions should be used in order speak the same language in omcls documents. some of these terms are also used in environments subjected to good manufacturing practice requirements (gmp). it is stressed that gmp requirements do not apply to omcls, though for practical reasons the commonly used terms are also used in this document.\n\n|computer system|a system containing one or more computers and associated software.|\n|---|---|\n|computerised system|a broad range of systems including, but not limited to, automated laboratory equipment, laboratory information management, and document management systems. the computerised system consists of the hardware, software, and network components, together with the controlled functions and associated documentation.|\n|commercial (off-the-shelf, configurable) computerised system|software defined by a market-driven need, commercially available, and whose fitness for use has been demonstrated by a broad spectrum of commercial users; also known as cots.|\n|in-house developed (custom-made or bespoke) computerised system|a system produced for a customer, specifically to order, to meet a defined set of user requirements set out in a user requirement specification.|\n|user requirement specifications (urs)|describes what the system should do. the user requirements contain scientific, business, legal, regulatory, safety, performance and quality aspects of the future system. the user requirements serve as the basis for the performance qualification (pq).|\n|black box|a black box in this guideline is a system whose inner working is unknown.|\n|computerized system validation plan|the validation plan shall be an approved document, which describes the validation activities and responsibilities. the validation plan specifies the computerized system subjected to validation and compiles the validation activities to be performed and the validation targets/criteria to be fulfilled. the validation plan shall be prepared and approved prior to conducting the test.|\n|dq (design qualification)|documented verification that the proposed design of facilities, systems, and equipment is suitable for the intended purpose.|\n|iq (installation qualification)|documented verification that a system is installed according to written and pre-approved specifications.|\n|oq (operational qualification)|documented verification that a system operates according to written and pre-approved specifications throughout specified operating ranges at the customer.|\n|pq (performance qualification) or user acceptance testing (uat)|documented verification that a system is capable of performing the activities of the processes it is required to perform, according to written and pre-approved specifications, within the scope of the business process and operating environment.|\n|black-box validation|validation based on the fact that, for a given computerised system, its source code or design is unknown to the user. validation is performed from the computerised system or computer system users point of view.|\n|black-box test|periodic check of a computer, computerised system or computerised system based on the black-box validation approach. black box testing examines the functionality of a system without peering its inner structure or workings.|", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "b52182b5-44f0-4c07-af38-0c23882a34f1": {"__data__": {"id_": "b52182b5-44f0-4c07-af38-0c23882a34f1", "embedding": null, "metadata": {"page_label": "4", "file_name": "[30] PA-PH-OMCL (08) 69 R7 Validation of Computerised Systems.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[30] PA-PH-OMCL (08) 69 R7 Validation of Computerised Systems.pdf", "file_type": "application/pdf", "file_size": 431019, "creation_date": "2024-04-07", "last_modified_date": "2024-04-05", "document_title": "\"Comprehensive Guidelines for Inventory Management and Validation of Computerised Systems\"", "questions_this_excerpt_can_answer": "1. What specific actions are recommended for computerised systems that lack a calibration function according to the \"Comprehensive Guidelines for Inventory Management and Validation of Computerised Systems\"?\n\n2. How does the document classify and recommend handling software with a \"small part of software\" in terms of validation, calibration, and function control tests?\n\n3. What are the minimum requirements for the inventory of computerised systems as outlined in the \"Comprehensive Guidelines for Inventory Management and Validation of Computerised Systems\"?", "prev_section_summary": "The section provides definitions related to computerized systems and validation processes. Key topics include distinguishing between commercial and in-house developed computerized systems, user requirement specifications, black-box validation, and the roles of Design Qualification (DQ), Installation Qualification (IQ), Operational Qualification (OQ), and Performance Qualification (PQ) or User Acceptance Testing (UAT) in the validation process. The section emphasizes the importance of using consistent terminology in documents and outlines the criteria for validating computerized systems.", "excerpt_keywords": "Inventory Management, Validation, Computerised Systems, Calibration, Software Classification"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[30] PA-PH-OMCL (08) 69 R7 Validation of Computerised Systems.pdf\n|definition|examples|action|\n|---|---|---|\n|no calibration function|calculator, microscope, photo or video camera, standard office pc, microwave, etc.|none|\n|exempted|operating system (e.g. windows, linux, unix), network software, security software (virus check, firewall), office application software (word, excel), database software (e.g. oracle, sql, access), etc.| |\n|small part of software|ph meter, oxidisers, incubator, titration processor, colorimeter, thermo hygrograph/hygrometer, balance, particle sizer, uv/vis spectrometer, liquid scintillation counter, tlc analyser, aas, micro plate counter, image analyser, polarimeter, combistats, etc.|simplified validation - calibration - function control test|\n|restricted customisation|lims (laboratory information management system), erp (enterprise resource planning), edms (electronic document management system), eln (electronic laboratory notebooks), user-developed excel spreadsheet, user-developed access application, automated sample processing systems, liquid chromatograph (lc, hplc), gas chromatograph (gc) including auto sampler and detection systems (uv, vis, ir, ms, nmr, radioactivity or fluorescence monitor, etc.), biological analyser, ecg, etc.|validation|\n|extended amount of functionality|operating systems, office applications, databases and framework packages such as windows, excel, oracle, sas do not have to be validated by the omcl. however, user applications written within or by means of these packages, such as sas procedures, oracle applications, and excel spreadsheets (including complex calculations and macros) shall be validated.| |\n\ngeneral requirements for computerised systems\n\na) inventory\n\nan inventory or equivalent listing of all computerised systems shall be available. the following minimum information shall be included in the computerised systems inventory:\n\n- identification & version\n- purpose\n- validation status\n- physical or storage (drive and files path) location of the computerised system and related documentation\n- responsible or contact person\n\nfor equipment software, this information can be recorded in the equipment logbook. in the case of local installation (workstation), each individual copy of the software installed on several computers needs its own unique identification (e.g. license).", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "c9933559-d98d-4ad3-bedd-5b230a64b55c": {"__data__": {"id_": "c9933559-d98d-4ad3-bedd-5b230a64b55c", "embedding": null, "metadata": {"page_label": "5", "file_name": "[30] PA-PH-OMCL (08) 69 R7 Validation of Computerised Systems.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[30] PA-PH-OMCL (08) 69 R7 Validation of Computerised Systems.pdf", "file_type": "application/pdf", "file_size": 431019, "creation_date": "2024-04-07", "last_modified_date": "2024-04-05", "document_title": "Computerised System Validation and Validation Plan: A Comprehensive Guide", "questions_this_excerpt_can_answer": "1. What are the key components and activities included in a validation plan for computerised systems within the pharmaceutical industry, as outlined in the \"Computerised System Validation and Validation Plan: A Comprehensive Guide\"?\n\n2. How does the document suggest incorporating supplier validation activities and documents into the OMCLs validation file, and under what conditions can the validation effort in OMCLs be reduced to the performance qualification (PQ) phase?\n\n3. What specific methods are recommended for conducting black-box validation of computerised systems to ensure they meet user needs and intended uses, according to the guidelines provided in the document?", "prev_section_summary": "The section discusses the classification and handling of computerised systems based on their functionality and software components. It outlines specific actions recommended for systems without a calibration function, software with a small part of software, and those with extended functionality. The document emphasizes the importance of maintaining an inventory of computerised systems, including identification, purpose, validation status, location, and responsible contact person. It also mentions the requirements for recording software information in equipment logbooks and unique identification for individual software copies.", "excerpt_keywords": "Computerised system validation, Validation plan, Supplier validation, Performance qualification, Black-box validation"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[30] PA-PH-OMCL (08) 69 R7 Validation of Computerised Systems.pdf\n## b) validation\n\nprior to routine use, the computerised system shall be validated. the purpose of validation is to confirm that the computerised system specifications conform to the user needs and intended uses by examination and provision of objective evidence and that the particular requirements can be consistently fulfilled. the extent of validation will depend on the complexity and intended use of the computerised system being validated. the validation effort can be scaled and adapted to the type of system justified by documented risk assessment. the categories mentioned in this guideline (see table i in section 3) can be used in omcls for risk assessment.\n\nurs, validation plans, test and release can also be performed on a rolling basis, if an iterative process (agile software development) is used. use of the supplier activities validation documents and results of tests performed by the supplier of the software can be incorporated into the omcls validation file and does not need to be repeated again by the omcl. the supplier must be subject to supplier evaluation (e.g. by a questionnaire or an audit). validation documents shall verify the computerized system performance, confirming that the system is performing correctly and to standard specifications. using a suppliers validation documents, validation in the omcls can be reduced to the performance qualification (pq) phase and ongoing controls indicating the system is working properly.\n\nvalidation plan\n\nto ensure the correct implementation of a validation, a plan is needed. the validation plan describes all activities such as review of the urs, review of the development plan (design), test strategy, verification of the data migration (if applicable), review of the validation documents and the acceptance testing of the whole system. the plan includes the date, the responsible person and the acceptance criteria for each review or test, or at least a reference to these tests. the validation plan is to be authorised by a responsible person before starting the validation. the test cases and descriptions can be described later, if an iterative process is used.\n\nblack-box validation is an approach to establish by adequate testing that the computerised system meets user needs and intended use, and can involve:\n\n- checking correctness of calculations and formulas and/or analytical results for dedicated and/or samples, references and calibrators;\n- manual calculation of computerised system calculation data (see annex 1); and/or\n- using a second, independent computerised system tool to review correctness of calculations and/or analytical results;", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "687dabcd-fba8-4dd8-aa2d-b6cc3dd94a67": {"__data__": {"id_": "687dabcd-fba8-4dd8-aa2d-b6cc3dd94a67", "embedding": null, "metadata": {"page_label": "6", "file_name": "[30] PA-PH-OMCL (08) 69 R7 Validation of Computerised Systems.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[30] PA-PH-OMCL (08) 69 R7 Validation of Computerised Systems.pdf", "file_type": "application/pdf", "file_size": 431019, "creation_date": "2024-04-07", "last_modified_date": "2024-04-05", "document_title": "Validation of Computerised Systems in the OMCL Environment: A Comprehensive Guide", "questions_this_excerpt_can_answer": "1. What specific steps are recommended for validating simple computerised systems in the OMCL environment, particularly for systems with no or limited customization?\n \n2. How does the document suggest OMCLs should validate the functionality and accuracy of the CombiStats application, including the verification process after downloading from the EDQM website?\n\n3. What is the outlined process for validating complex computerised systems according to the document, including the initial steps and the documentation required to confirm the system's suitability for its intended use?", "prev_section_summary": "The section discusses the validation of computerised systems in the pharmaceutical industry, emphasizing the importance of confirming that system specifications align with user needs and intended uses. It mentions the scalability of validation efforts based on system complexity and intended use, as well as the incorporation of supplier validation activities and documents into the validation process. The section also highlights the need for a validation plan outlining activities such as review of user requirements, test strategies, and acceptance testing. Additionally, it introduces the concept of black-box validation to ensure that computerised systems meet user needs through various testing methods.", "excerpt_keywords": "Validation, Computerised Systems, OMCL Environment, CombiStats, Documentation"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[30] PA-PH-OMCL (08) 69 R7 Validation of Computerised Systems.pdf\nand/or\n\n(4) documentation of simulations of invalid or oos data input and flagging/mistake signals. for the validation of a computerised system that does not belong to the omcl (e.g. a computerised system from the agency/authority), a simplified validation (e.g.: a function control test) can be performed by the omcl, taking into consideration the specific functionalities for the omcl, to check compliance with the iso 17025 requirements and the omcl guidelines. if there is an interface between computerised systems, for example, exchange of information between an analytical system and lims, validation of the interface should be considered.\n\ni. validation of simple systems validation of simple computerised systems, e.g. systems with no or limited customisation, will usually rely on instrument calibration and/or a system function test, depending on the type of system. for analytical instruments where the raw data cannot be modified by the user (e.g. stand-alone balance, ph meter) instrument calibration is considered as sufficient to demonstrate the system is fit for purpose. for off-the-shelf applications, commercial or supplied by a public agency/authority, a function test shall be performed by the user in order to demonstrate that the application performs properly in the omcl environment. an example of this approach is given below for combistats. the appropriateness and correctness of the calculations performed by combistats is pre-checked and demonstrated by the provider (mainly by the comparison with data published in the book by d.j. finney [7], a standard reference for statistics in bioassays) so that the computerised system can be considered as fit for purpose (i.e., it fulfils the user requirements). however, an omcl shall verify that combistats works properly in its hardware configuration, once downloaded from the edqm website. this can be done by comparing the output of the same example reported both in the user manual (in .pdf format, that will be the \"reference\") and in the \"example\" directory (in .epa format) automatically downloaded in each user pc hard disk. the conclusion regarding the validation status based on this comparison shall be documented. combistats templates and data sheets shall be protected from accidental mistakes and editing. four different levels of protection are available (each one with or without the use of a password). the user manual can be used by the omcl for further details, and to choose the strategy, depending on the internal policy and decision.\n\nii. validation of complex systems validation of complex computerised systems begins with the definition of the user requirements specification (urs), which will serve as a basis for the validation requirements. a validation plan is needed, based on risk assessment, describing the different validation activities planned for the system, and the responsibilities of the different persons involved in the validation process. then test protocols for iq, oq and pq shall be prepared taking into consideration the user requirements and the acceptance criteria. test protocols or checklists provided by the supplier can be used for iq and oq, when available. the process is finalised after the issuing of the various test reports and a final validation report with the statement that the computerised system is suitable for the intended use. if", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "5807dfb5-9407-472b-8015-50cd7141b07d": {"__data__": {"id_": "5807dfb5-9407-472b-8015-50cd7141b07d", "embedding": null, "metadata": {"page_label": "7", "file_name": "[30] PA-PH-OMCL (08) 69 R7 Validation of Computerised Systems.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[30] PA-PH-OMCL (08) 69 R7 Validation of Computerised Systems.pdf", "file_type": "application/pdf", "file_size": 431019, "creation_date": "2024-04-07", "last_modified_date": "2024-04-05", "document_title": "Ensuring Adequate Functioning and Security of Computerised Systems in Analytical Procedures: A Comprehensive Guide", "questions_this_excerpt_can_answer": "1. What specific examples are provided in the document for the validation of complex computerised systems in analytical procedures?\n \n2. How does the document recommend handling automatic system updates to minimize disruption and ensure the continued validated status of computerised systems in analytical settings?\n\n3. What strategies does the document suggest for ensuring the security of computerised systems against unauthorized access and data alteration in analytical environments?", "prev_section_summary": "The section discusses the validation of computerised systems in the OMCL environment, including recommendations for validating simple and complex systems. Key topics include steps for validating simple systems, such as instrument calibration and function tests, as well as the validation process for complex systems, starting with user requirements specification and risk assessment. The document also outlines the validation of the CombiStats application and the importance of verifying interfaces between computerised systems. Key entities mentioned include instrument calibration, function tests, user requirements specification, risk assessment, test protocols, and validation reports.", "excerpt_keywords": "Validation, Computerised Systems, Analytical Procedures, Security, Risk Assessment"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[30] PA-PH-OMCL (08) 69 R7 Validation of Computerised Systems.pdf\ndeviations are identified during validation, they must be addressed and the impact on the adequate functioning of the system shall be evaluated.\n\nin the case of a computerised system for analytical procedures such as an assay, the software is an integrated part of the test procedure. the respective sop should include or make reference to the sample, the reference standard, reagent preparations, use of apparatus and its computerised system as a unit, generation of calibration curve by means of a computerised system tool, use of calculation formulas, etc.\n\nexamples of validation of complex systems are given for excel spreadsheets (see annex 1) and lims/eln/erp/cds (see annex 2).\n\nc) logging of issues\n\na record of the issues identified by the users and the actions taken should be kept.\n\nd) change control\n\nin the event of changes in the computerised system, including version updates, these should ideally be done first in a test environment after which the validation status needs to be re-established. if a revalidation is needed, it should be conducted not just for validation of the individual change, but also to determine the extent and impact of that change on the entire computerised system.\n\nthe extent of the revalidation will depend on assessment of the change(s), which shall be documented. one possible approach could be the use of logbooks as it is done for equipment, and/or using a documented change control procedure.\n\nautomatic system updates should ideally be controlled by it or a system administrator and installed at pre-defined dates to minimise both disruption and unexpected behaviour of the system. it can be necessary to check the operation of the computerised system following any system updates.\n\ne) periodic review\n\nthe omcl should endorse a policy to check the computerised system periodically, to avoid any error and guarantee the maintained validated status of the system. the frequency of the reviews should be defined on a risk-based approach.\n\ncomputerised systems shall be covered by the internal audit strategy.\n\nf) security and environmental conditions\n\ncomputerised systems must be protected against any intrusion that could change the data and affect the final results.\n\nserver rooms should have restricted access and have the conditions necessary to ensure the correct functioning of equipment (control of temperature, firefighting measures, uninterruptible power supply - ups, etc.).\n\nsystems should be accessed only by authorised personnel, using personalised accounts and password or equivalent identification method. the use of shared and generic accounts should be avoided to ensure that actions documented in computerised systems can be attributed to a unique individual. where personal accounts are not available or feasible, combinations of paper and electronic records should be used to trace actions to the personnel responsible.", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "a0725ad4-dbbe-46cb-b348-eb24e82dc5b4": {"__data__": {"id_": "a0725ad4-dbbe-46cb-b348-eb24e82dc5b4", "embedding": null, "metadata": {"page_label": "8", "file_name": "[30] PA-PH-OMCL (08) 69 R7 Validation of Computerised Systems.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[30] PA-PH-OMCL (08) 69 R7 Validation of Computerised Systems.pdf", "file_type": "application/pdf", "file_size": 431019, "creation_date": "2024-04-07", "last_modified_date": "2024-04-05", "document_title": "Comprehensive Guide to Computerised System Security and Data Integrity Management", "questions_this_excerpt_can_answer": "1. What specific measures are recommended for managing administrative rights within a computerised system to ensure system security and data integrity, according to the document titled \"Comprehensive Guide to Computerised System Security and Data Integrity Management\"?\n\n2. How does the document \"Comprehensive Guide to Computerised System Security and Data Integrity Management\" suggest handling the installation and maintenance of hardware components in computerised systems to meet technical and functional requirements?\n\n3. What protocols does the \"Comprehensive Guide to Computerised System Security and Data Integrity Management\" outline for ensuring traceability and integrity of data through audit trails, electronic signatures, and backup processes in computerised systems?", "prev_section_summary": "The section discusses the validation of computerised systems in analytical procedures, emphasizing the importance of addressing deviations and evaluating their impact on system functioning. It provides examples of validation for complex systems like Excel spreadsheets and LIMS/ELN/ERP/CDS. The document recommends logging issues, implementing change control procedures for system updates, conducting periodic reviews, and ensuring security measures to protect against unauthorized access and data alteration. It highlights the need for restricted access to server rooms, personalized accounts for system access, and the use of audit strategies to maintain the validated status of computerised systems.", "excerpt_keywords": "Computerised systems, System security, Data integrity, Audit trails, Electronic signatures"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[30] PA-PH-OMCL (08) 69 R7 Validation of Computerised Systems.pdf\nonly the responsible person(s) or designated it personnel should have administrative rights to implement any computerised system updates and/or installations, change critical system settings (e.g. audit trail, time/date) and manage permissions for other users. all routine tasks, such as for analysis, should be based on a user account and password which does not have administrative rights.\n\nadministrative rights should be documented and only be granted to personnel with system maintenance roles (e.g. it) that are fully independent of the personnel responsible for the content of the records (e.g. laboratory analysts, laboratory management). where these independent security role assignments are not feasible, other control strategies should be used to reduce data integrity risks.\n\ncomputers should be locked after use and the users should not be allowed to change date and time settings.\n\nthe hardware used must fulfil the technical requirements so that the work to be completed can be carried out. such requirements include e.g. minimum system requirements indicated by the manufacturer of the equipment. these requirements should be predefined in accordance with the intended use.\n\nthe hardware components must be installed by skilled personnel (e.g. staff from the information technology (it) unit, a technician from the manufacturer of the equipment, or other trained personnel), and must be checked for their functionality and compared with the requirements. computerised systems that are part of test equipment must be labelled unambiguously and records must be kept on relevant hardware configuration, installation and changes. these records can be entered in the logbook/equipment record of the test equipment.\n\naudit trail\n\nthe computerised system should keep a record of any critical actions that occur, for example who has accessed it and when, any deletion or change of data, etc. if a computerised system does not automatically record an audit trail, an alternative record shall be kept by the omcl. users shall not be allowed to amend or switch off the audit trails or alternative means of providing traceability of user actions. the need for the implementation of appropriate audit trail functionality should be considered for all new computerised systems. where an existing computerised system lacks computer-generated audit trails, personnel shall use alternative means such as procedurally controlled use of logbooks, change control, record version control or other combinations of paper and electronic records to meet the requirement for traceability to document the what, who, when and why of an action.\n\nelectronic signatures\n\nif electronic signatures are used, a statement about the equivalence of the electronic signature to the handwritten signature or similar legal statement must be available.\n\nbackup\n\ntraceability must be ensured from raw data to test results. if all or part of the traceability of parameters relevant for the quality of the results is available only in electronic form, a backup process must be implemented to allow for recovery of the system following any failure which", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "ecbe8ea0-be22-453a-8f48-981ecd5f46ef": {"__data__": {"id_": "ecbe8ea0-be22-453a-8f48-981ecd5f46ef", "embedding": null, "metadata": {"page_label": "9", "file_name": "[30] PA-PH-OMCL (08) 69 R7 Validation of Computerised Systems.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[30] PA-PH-OMCL (08) 69 R7 Validation of Computerised Systems.pdf", "file_type": "application/pdf", "file_size": 431019, "creation_date": "2024-04-07", "last_modified_date": "2024-04-05", "document_title": "Computerised System Documentation and Validation: A Comprehensive Guide", "questions_this_excerpt_can_answer": "1. What types of documentation are required for all computerised systems regardless of their complexity, as outlined in the \"Computerised System Documentation and Validation: A Comprehensive Guide\"?\n\n2. How does the documentation requirement differ between simple and complex computerised systems according to the guide provided in the document \"[30] PA-PH-OMCL (08) 69 R7 Validation of Computerised Systems.pdf\"?\n\n3. What specific documentation is only mandated for complex computerised systems, indicating a higher level of scrutiny and validation, as per the comprehensive guide on computerised system documentation and validation?", "prev_section_summary": "The section discusses the management of administrative rights within computerized systems to ensure system security and data integrity. It emphasizes the importance of granting administrative rights only to designated personnel, locking computers after use, and ensuring hardware components meet technical requirements. The document also outlines protocols for maintaining audit trails, electronic signatures, and backup processes to ensure traceability and integrity of data. Key entities mentioned include responsible personnel, IT personnel, laboratory analysts, hardware components, audit trails, electronic signatures, and backup processes.", "excerpt_keywords": "Computerised systems, Documentation, Validation, Complex systems, Audit trails"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[30] PA-PH-OMCL (08) 69 R7 Validation of Computerised Systems.pdf\n## documentation\n\n|information/documentation that shall be available|exempted|simple|complex|\n|---|---|---|---|\n|inventory list, name, version and unique identification of the computerised system|x|x|x|\n|original files (cd-rom...) or storage location to install the computerised system, and computerised system to manage the computer environment| |x|x|\n|date at which the computerised system was put into operation| |x|x|\n|responsible person in charge of the computerised system| |x|x|\n|manufacturers name, licence number and serial number or other unique identification, where applicable| |x|x|\n|conditions under which the computerised system runs, where applicable (hardware, operating system, ...)| |x|x|\n|manufacturers validation certificate, if available| |x|x|\n|manufacturers instructions, if available, or reference to their location| |x|x|\n|documentation on validation of configurations/modifications performed by the user that can impact the results| | |x|\n|name of the person who developed and validated the computerised system, and the date of validation| | |x|\n|source code (if available)| | |(x)|\n|operating instruction (sop)|x|x|x|\n|documentation on computerised system periodic review and results of audits| | |x|\n|documentation on computerised system validation| | |x|", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "3595b473-9b95-48f4-9ad3-4980b6194eb5": {"__data__": {"id_": "3595b473-9b95-48f4-9ad3-4980b6194eb5", "embedding": null, "metadata": {"page_label": "10", "file_name": "[30] PA-PH-OMCL (08) 69 R7 Validation of Computerised Systems.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[30] PA-PH-OMCL (08) 69 R7 Validation of Computerised Systems.pdf", "file_type": "application/pdf", "file_size": 431019, "creation_date": "2024-04-07", "last_modified_date": "2024-04-05", "document_title": "Regulatory Guidelines and Best Practices for Computerized Systems Validation in GxP Environments: A Comprehensive Guide", "questions_this_excerpt_can_answer": "1. What specific international standards and guidelines are referenced in the document for the validation of computerized systems in GxP environments?\n2. As of the document's last update, what are the two specific annexes included that detail the validation processes for different types of computerized systems within pharmaceutical environments?\n3. What historical statistical method publication is cited in the document as a reference for the validation of computerized systems, including the edition and publication year?", "prev_section_summary": "The section discusses the documentation requirements for computerised systems, distinguishing between simple and complex systems. Key topics include the types of documentation needed for all systems, such as inventory lists and system operation dates, as well as additional documentation mandated for complex systems, such as validation certificates and source code. Entities mentioned include responsible persons, manufacturers, and developers of the computerised systems. The section emphasizes the importance of thorough documentation for validation and compliance purposes.", "excerpt_keywords": "Regulatory guidelines, Computerized systems validation, GxP environments, International standards, Annexes"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[30] PA-PH-OMCL (08) 69 R7 Validation of Computerised Systems.pdf\nreferences and further reading\n[1] en iso/iec 17025.\n[2] good practices for computerized systems in regulated \"gxp\" environments. pharmaceutical inspection convention/pharmaceutical inspections co-operation scheme (pic/s).\n[3] eu guidelines to good manufacturing practice (gmp). annex 11. computerized systems.\n[4] oecd series on principles of good laboratory practices and compliance monitoring. number 17. the application of pe principles of glp to computerized systems. environment monograph no. 13 (2016).\n[5] u.s. food and drug agency (fda) general principles of computerized system validation; fda glossary of computerized system and computerized system development terminology.\n[6] agit - validation of computerised systems, v 2.0 (2007).\n[7] d. j. finney - \"statistical mepod in biological assay\", 3rd edition, griffin, london (1978).\n[8] who trs 996 annex 5 - guidance on good data and record management practices (2016).\n\nlist of annexes\nthe latest version applies:\n- annex 1: validation of excel spreadsheets - pa/ph/omcl (08) 87;\n- annex 2: validation of complex computerised systems - pa/ph/omcl (08) 88.", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "6ad84e08-8922-416e-a6fb-3692f4f190df": {"__data__": {"id_": "6ad84e08-8922-416e-a6fb-3692f4f190df", "embedding": null, "metadata": {"page_label": "1", "file_name": "[17] FDA Guidance for Industry Part 11, Electronic Records; Electronic Signatures.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[17] FDA Guidance for Industry Part 11, Electronic Records; Electronic Signatures.pdf", "file_type": "application/pdf", "file_size": 44957, "creation_date": "2024-04-07", "last_modified_date": "2024-03-28", "document_title": "FDA Guidance on Electronic Records and Signatures in Pharmaceutical Current Good Manufacturing Practices (CGMPs)", "questions_this_excerpt_can_answer": "1. What specific FDA centers are involved in the guidance for Part 11 regarding electronic records and electronic signatures within the pharmaceutical industry?\n \n2. As of August 2003, what document outlines the FDA's guidance on electronic records and electronic signatures for entities regulated under pharmaceutical current good manufacturing practices (CGMPs)?\n\n3. What is the scope and application of the FDA's Part 11 guidance on electronic records and electronic signatures, and which regulatory offices within the FDA are responsible for its enforcement and guidance as of the document's last update?", "excerpt_keywords": "FDA, guidance, electronic records, electronic signatures, pharmaceutical industry"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[17] FDA Guidance for Industry Part 11, Electronic Records; Electronic Signatures.pdf\n## guidance for industry\n\npart 11, electronic records; electronic signatures -- scope and application\n\nu.s. department of health and human services\n\nfood and drug administration\n\ncenter for drug evaluation and research (cder)\n\ncenter for biologics evaluation and research (cber)\n\ncenter for devices and radiological health (cdrh)\n\ncenter for food safety and applied nutrition (cfsan)\n\ncenter for veterinary medicine (cvm)\n\noffice of regulatory affairs (ora)\n\naugust 2003\n\npharmaceutical cgmps", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "573fc8b8-dcf3-445a-bf2f-a2cfaf91606c": {"__data__": {"id_": "573fc8b8-dcf3-445a-bf2f-a2cfaf91606c", "embedding": null, "metadata": {"page_label": "2", "file_name": "[17] FDA Guidance for Industry Part 11, Electronic Records; Electronic Signatures.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[17] FDA Guidance for Industry Part 11, Electronic Records; Electronic Signatures.pdf", "file_type": "application/pdf", "file_size": 44957, "creation_date": "2024-04-07", "last_modified_date": "2024-03-28", "document_title": "FDA Guidance for Industry on Electronic Records and Signatures in Various Centers and Divisions: Ensuring Compliance and Security", "questions_this_excerpt_can_answer": "1. What specific FDA guidance document addresses the scope and application of electronic records and electronic signatures within various centers and divisions, including contact information for inquiries?\n \n2. As of August 2003, which FDA centers and offices provide guidance and assistance related to electronic records and electronic signatures, including specific URLs and phone numbers for direct contact?\n\n3. How can manufacturers and international staff obtain assistance or guidance on electronic records and electronic signatures from the FDA, including specific divisions and contact information provided in the document?", "prev_section_summary": "The section provides guidance from the FDA on electronic records and electronic signatures in the pharmaceutical industry, specifically focusing on Part 11. The key topics covered include the scope and application of the guidance, as well as the regulatory offices within the FDA responsible for enforcement and guidance. The entities involved in the guidance for Part 11 include the Center for Drug Evaluation and Research (CDER), Center for Biologics Evaluation and Research (CBER), Center for Devices and Radiological Health (CDRH), Center for Food Safety and Applied Nutrition (CFSAN), Center for Veterinary Medicine (CVM), and the Office of Regulatory Affairs (ORA). The document was last updated in August 2003.", "excerpt_keywords": "FDA, guidance, electronic records, electronic signatures, compliance"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[17] FDA Guidance for Industry Part 11, Electronic Records; Electronic Signatures.pdf\n## guidance for industry\n\npart 11, electronic records; electronic signatures -- scope and application\n\ndivision of drug information, hfd-240\n\ncenter for drug evaluation and research (cder)\n\n(tel) 301-827-4573\n\nhttp://www.fda.gov/cder/guidance/index.htm\n\nor\n\noffice of communication, training and manufacturers assistance, hfm-40\n\ncenter for biologics evaluation and research (cber)\n\nhttp://www.fda.gov/cber/guidelines.htm\n\nphone: the voice information system at 800-835-4709 or 301-827-1800\n\nor\n\ncommunications staff (hfv-12),\n\ncenter for veterinary medicine (cvm)\n\n(tel) 301-594-1755\n\nhttp://www.fda.gov/cvm/guidance/guidance.html\n\nor\n\ndivision of small manufacturers assistance (hfz-220)\n\nhttp://www.fda.gov/cdrh/ggpmain.html\n\nmanufacturers assistance phone number: 800.638.2041 or 301.443.6597\n\ninterntl staff phone: 301.827.3993\n\nor\n\ncenter for food safety and applied nutrition (cfsan)\n\nhttp://www.cfsan.fda.gov/~dms/guidance.html.\n\nu.s. department of health and human services\n\nfood and drug administration\n\ncenter for drug evaluation and research (cder)\n\ncenter for biologics evaluation and research (cber)\n\ncenter for devices and radiological health (cdrh)\n\ncenter for food safety and applied nutrition (cfsan)\n\ncenter for veterinary medicine (cvm)\n\noffice of regulatory affairs (ora)\n\naugust 2003\n\npharmaceutical cgmps", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "336d948d-c386-40ae-bb68-d42bc4e3b648": {"__data__": {"id_": "336d948d-c386-40ae-bb68-d42bc4e3b648", "embedding": null, "metadata": {"page_label": "3", "file_name": "[17] FDA Guidance for Industry Part 11, Electronic Records; Electronic Signatures.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[17] FDA Guidance for Industry Part 11, Electronic Records; Electronic Signatures.pdf", "file_type": "application/pdf", "file_size": 44957, "creation_date": "2024-04-07", "last_modified_date": "2024-03-28", "document_title": "\"Guide to Part 11 Requirements and Compliance in [Industry/Company Name]\"", "questions_this_excerpt_can_answer": "1. What is the detailed approach adopted by [Industry/Company Name] to ensure compliance with the FDA's Part 11 requirements on electronic records and electronic signatures, specifically regarding the scope of Part 11 and the definition of Part 11 records?\n\n2. How does [Industry/Company Name] address specific Part 11 requirements such as validation, audit trails, legacy systems, copies of records, and record retention to meet FDA guidelines?\n\n3. Can you outline the overall strategy and specific actions taken by [Industry/Company Name] to interpret and implement the FDA's Part 11 requirements, including any narrow interpretations of scope that were considered?", "prev_section_summary": "The section provides guidance from the FDA for industry on the scope and application of electronic records and electronic signatures. It includes contact information for various FDA centers and divisions that offer assistance and guidance related to electronic records and signatures. The key entities mentioned in the section include the Center for Drug Evaluation and Research (CDER), Center for Biologics Evaluation and Research (CBER), Center for Veterinary Medicine (CVM), Center for Food Safety and Applied Nutrition (CFSAN), and the Office of Regulatory Affairs (ORA). The section emphasizes the importance of compliance and security in electronic recordkeeping within the pharmaceutical industry.", "excerpt_keywords": "FDA, Part 11, electronic records, electronic signatures, compliance"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[17] FDA Guidance for Industry Part 11, Electronic Records; Electronic Signatures.pdf\n|content|page number|\n|---|---|\n|i. introduction|1|\n|ii. background|2|\n|iii. discussion|3|\n|a. overall approach to part 11 requirements|3|\n|b. details of approach - scope of part 11|4|\n|1. narrow interpretation of scope|4|\n|2. definition of part 11 records|5|\n|c. approach to specific part 11 requirements|6|\n|1. validation|6|\n|2. audit trail|6|\n|3. legacy systems|7|\n|4. copies of records|7|\n|5. record retention|8|\n|iv. references|9|", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "1b47f575-c973-43f1-b00b-fec15a4bde70": {"__data__": {"id_": "1b47f575-c973-43f1-b00b-fec15a4bde70", "embedding": null, "metadata": {"page_label": "4", "file_name": "[17] FDA Guidance for Industry Part 11, Electronic Records; Electronic Signatures.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[17] FDA Guidance for Industry Part 11, Electronic Records; Electronic Signatures.pdf", "file_type": "application/pdf", "file_size": 44957, "creation_date": "2024-04-07", "last_modified_date": "2024-03-28", "document_title": "FDA Guidance on Part 11 of Title 21 of the Code of Federal Regulations: Electronic Records; Electronic Signatures", "questions_this_excerpt_can_answer": "1. What is the FDA's stance on alternative approaches to maintaining electronic records and electronic signatures as per the guidance provided in Part 11 of Title 21 of the Code of Federal Regulations?\n \n2. How does the FDA's guidance for Part 11 of Title 21 define the scope of electronic records and signatures that are subject to regulatory requirements, and what are some examples of the types of regulations that might necessitate the maintenance or submission of electronic records?\n\n3. According to the FDA's guidance document on Part 11, what are the steps or recommendations for entities wishing to discuss alternative approaches to the electronic records and electronic signatures requirements with the FDA, including how to identify and contact the appropriate FDA staff?", "prev_section_summary": "The key topics covered in this section include the overall approach to Part 11 requirements, details of the approach such as the scope of Part 11 and the definition of Part 11 records, and the approach to specific Part 11 requirements like validation, audit trails, legacy systems, copies of records, and record retention. The section also mentions the interpretation and implementation of FDA's Part 11 requirements by [Industry/Company Name].", "excerpt_keywords": "FDA, guidance, electronic records, electronic signatures, regulations"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[17] FDA Guidance for Industry Part 11, Electronic Records; Electronic Signatures.pdf\n## contains nonbinding recommendations\n\nguidance for industry\n1\n\nthis guidance represents the food and drug administrations (fdas) current thinking on this topic. it does not create or confer any rights for or on any person and does not operate to bind fda or the public. you can use an alternative approach if the approach satisfies the requirements of the applicable statutes and regulations. if you want to discuss an alternative approach, contact the fda staff responsible for implementing this guidance. if you cannot identify the appropriate fda staff, call the appropriate number listed on the title page of this guidance.\n\n### i. introduction\n\nthis guidance is intended to describe the food and drug administrations (fdas) current thinking regarding the scope and application of part 11 of title 21 of the code of federal regulations; electronic records; electronic signatures (21 cfr part 11).\n\nthis document provides guidance to persons who, in fulfillment of a requirement in a statute or another part of fdas regulations to maintain records or submit information to fda, have chosen to maintain the records or submit designated information electronically and, as a result, have become subject to part 11. part 11 applies to records in electronic form that are created, modified, maintained, archived, retrieved, or transmitted under any records requirements set forth in agency regulations. part 11 also applies to electronic records submitted to the agency under the federal food, drug, and cosmetic act (the act) and the public health service act (the phs act), even if such records are not specifically identified in agency regulations (SS 11.1). the underlying requirements set forth in the act, phs act, and fda regulations (other than part 11) are referred to in this guidance document as predicate rules.\n\n1this guidance has been prepared by the office of compliance in the center for drug evaluation and research (cder) in consultation with the other agency centers and the office of regulatory affairs at the food and drug administration.\n\n262 fr 13430\n\n3these requirements include, for example, certain provisions of the current good manufacturing practice regulations (21 cfr part 211), the quality system regulation (21 cfr part 820), and the good laboratory practice for nonclinical laboratory studies regulations (21 cfr part 58).", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "2f3cdfa7-b8ff-42d3-90f6-2b85e46bde0a": {"__data__": {"id_": "2f3cdfa7-b8ff-42d3-90f6-2b85e46bde0a", "embedding": null, "metadata": {"page_label": "5", "file_name": "[17] FDA Guidance for Industry Part 11, Electronic Records; Electronic Signatures.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[17] FDA Guidance for Industry Part 11, Electronic Records; Electronic Signatures.pdf", "file_type": "application/pdf", "file_size": 44957, "creation_date": "2024-04-07", "last_modified_date": "2024-03-28", "document_title": "FDA's Exercise of Enforcement Discretion for Part 11 Requirements: Guidance for Industry and FDA Staff", "questions_this_excerpt_can_answer": "1. What specific Part 11 requirements has the FDA decided not to enforce while re-examining the regulation as part of its current good manufacturing practice (CGMP) initiative for human and animal drugs and biologics?\n \n2. How does the FDA intend to handle enforcement of Part 11 requirements for systems that were operational before the effective date of Part 11, August 20, 1997, according to the guidance document?\n\n3. Can you detail the FDA's approach to engaging with industry and other stakeholders regarding the interpretation and implementation of Part 11 regulations after they became effective in August 1997?", "prev_section_summary": "This section provides an excerpt from the FDA Guidance for Industry on Part 11 of Title 21 of the Code of Federal Regulations regarding electronic records and electronic signatures. The key topics covered include the FDA's current thinking on alternative approaches to maintaining electronic records and signatures, the scope and application of Part 11, and the steps for entities to discuss alternative approaches with the FDA. The entities involved in this guidance include the Food and Drug Administration (FDA), persons subject to Part 11 requirements, and FDA staff responsible for implementing the guidance. The section also mentions predicate rules and regulations such as current good manufacturing practices, quality system regulations, and good laboratory practices that may necessitate the maintenance or submission of electronic records.", "excerpt_keywords": "FDA, Part 11, Electronic Records, Electronic Signatures, Enforcement Discretion"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[17] FDA Guidance for Industry Part 11, Electronic Records; Electronic Signatures.pdf\n## contains nonbinding recommendations\n\nas an outgrowth of its current good manufacturing practice (cgmp) initiative for human and animal drugs and biologics, fda is re-examining part 11 as it applies to all fda regulated products. we anticipate initiating rulemaking to change part 11 as a result of that re-examination. this guidance explains that we will narrowly interpret the scope of part 11. while the re-examination of part 11 is under way, we intend to exercise enforcement discretion with respect to certain part 11 requirements. that is, we do not intend to take enforcement action to enforce compliance with the validation, audit trail, record retention, and record copying requirements of part 11 as explained in this guidance. however, records must still be maintained or submitted in accordance with the underlying predicate rules, and the agency can take regulatory action for noncompliance with such predicate rules.\n\nin addition, we intend to exercise enforcement discretion and do not intend to take (or recommend) action to enforce any part 11 requirements with regard to systems that were operational before august 20, 1997, the effective date of part 11 (commonly known as legacy systems) under the circumstances described in section iii.c.3 of this guidance.\n\nnote that part 11 remains in effect and that this exercise of enforcement discretion applies only as identified in this guidance.\n\nfdas guidance documents, including this guidance, do not establish legally enforceable responsibilities. instead, guidances describe the agencys current thinking on a topic and should be viewed only as recommendations, unless specific regulatory or statutory requirements are cited. the use of the word should in agency guidances means that something is suggested or recommended, but not required.\n\n## background\n\nin march of 1997, fda issued final part 11 regulations that provide criteria for acceptance by fda, under certain circumstances, of electronic records, electronic signatures, and handwritten signatures executed to electronic records as equivalent to paper records and handwritten signatures executed on paper. these regulations, which apply to all fda program areas, were intended to permit the widest possible use of electronic technology, compatible with fdas responsibility to protect the public health.\n\nafter part 11 became effective in august 1997, significant discussions ensued among industry, contractors, and the agency concerning the interpretation and implementation of the regulations. fda has (1) spoken about part 11 at many conferences and met numerous times with an industry coalition and other interested parties in an effort to hear more about potential part 11 issues; (2) published a compliance policy guide, cpg 7153.17: enforcement policy: 21 cfr part 11; electronic records; electronic signatures; and (3) published numerous draft guidance documents including the following:\n\nsee pharmaceutical cgmps for the 21st century: a risk-based approach; a science and risk-based approach to product quality regulation incorporating an integrated quality systems approach at www.fda.gov/oc/guidance/gmp.html.", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "41674149-3ff3-4381-adb5-303af6f10dcc": {"__data__": {"id_": "41674149-3ff3-4381-adb5-303af6f10dcc", "embedding": null, "metadata": {"page_label": "6", "file_name": "[17] FDA Guidance for Industry Part 11, Electronic Records; Electronic Signatures.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[17] FDA Guidance for Industry Part 11, Electronic Records; Electronic Signatures.pdf", "file_type": "application/pdf", "file_size": 44957, "creation_date": "2024-04-07", "last_modified_date": "2024-03-28", "document_title": "FDA's Approach to Part 11 Requirements and Enforcement Discretion Guidance", "questions_this_excerpt_can_answer": "1. What were the main concerns raised by stakeholders regarding the interpretations of Part 11 requirements that led the FDA to reconsider its approach to electronic records and electronic signatures?\n \n2. Can you detail the specific Part 11 draft guidance documents and initiatives that the FDA withdrew in early 2003, as part of its re-examination of the regulation and its alignment with the CGMP initiative?\n\n3. How does the FDA's current stance on the use of time stamps in systems that span different time zones differ from the requirement to record the signer's local time, and what documentation does the FDA expect to be provided in relation to time zone references?", "prev_section_summary": "This section discusses the FDA's exercise of enforcement discretion for Part 11 requirements, specifically in relation to electronic records and electronic signatures for FDA-regulated products. Key topics include the re-examination of Part 11 as part of the current good manufacturing practice (CGMP) initiative, the agency's intention to narrowly interpret the scope of Part 11, and the exercise of enforcement discretion for certain requirements such as validation, audit trail, record retention, and record copying. The section also addresses the handling of Part 11 requirements for systems operational before August 20, 1997 (legacy systems), and emphasizes that Part 11 remains in effect despite the enforcement discretion outlined in the guidance. Key entities mentioned include the FDA, industry stakeholders, contractors, and the public health sector.", "excerpt_keywords": "FDA, Part 11, Electronic Records, Electronic Signatures, Enforcement Discretion"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[17] FDA Guidance for Industry Part 11, Electronic Records; Electronic Signatures.pdf\n## contains nonbinding recommendations\n\n21 cfr part 11; electronic records; electronic signatures, validation\n21 cfr part 11; electronic records; electronic signatures, glossary of terms\n21 cfr part 11; electronic records; electronic signatures, time stamps\n21 cfr part 11; electronic records; electronic signatures, maintenance of electronic records\n21 cfr part 11; electronic records; electronic signatures, electronic copies of electronic records\n\nthroughout all of these communications, concerns have been raised that some interpretations of the part 11 requirements would (1) unnecessarily restrict the use of electronic technology in a manner that is inconsistent with fdas stated intent in issuing the rule, (2) significantly increase the costs of compliance to an extent that was not contemplated at the time the rule was drafted, and (3) discourage innovation and technological advances without providing a significant public health benefit. these concerns have been raised particularly in the areas of part 11 requirements for validation, audit trails, record retention, record copying, and legacy systems.\n\nas a result of these concerns, we decided to review the part 11 documents and related issues, particularly in light of the agencys cgmp initiative. in the federal register of february 4, 2003 (68 fr 5645), we announced the withdrawal of the draft guidance for industry, 21 cfr part 11; electronic records; electronic signatures, electronic copies of electronic records. we had decided we wanted to minimize industry time spent reviewing and commenting on the draft guidance when that draft guidance may no longer represent our approach under the cgmp initiative. then, in the federal register of february 25, 2003 (68 fr 8775), we announced the withdrawal of the part 11 draft guidance documents on validation, glossary of terms, time stamps, maintenance of electronic records, and cpg 7153.17. we received valuable public comments on these draft guidances, and we plan to use that information to help with future decision-making with respect to part 11. we do not intend to re-issue these draft guidance documents or the cpg.\n\nwe are now re-examining part 11, and we anticipate initiating rulemaking to revise provisions of that regulation. to avoid unnecessary resource expenditures to comply with part 11 requirements, we are issuing this guidance to describe how we intend to exercise enforcement discretion with regard to certain part 11 requirements during the re-examination of part 11. as mentioned previously, part 11 remains in effect during this re-examination period.\n\n### discussion\n\n#### overall approach to part 11 requirements\n\nalthough we withdrew the draft guidance on time stamps, our current thinking has not changed in that when using time stamps for systems that span different time zones, we do not expect you to record the signers local time. when using time stamps, they should be implemented with a clear understanding of the time zone reference used. in such instances, system documentation should explain time zone references as well as zone acronyms or other naming conventions.", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "da8c2fec-8b55-43e0-9374-fc3a1323b2d8": {"__data__": {"id_": "da8c2fec-8b55-43e0-9374-fc3a1323b2d8", "embedding": null, "metadata": {"page_label": "7", "file_name": "[17] FDA Guidance for Industry Part 11, Electronic Records; Electronic Signatures.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[17] FDA Guidance for Industry Part 11, Electronic Records; Electronic Signatures.pdf", "file_type": "application/pdf", "file_size": 44957, "creation_date": "2024-04-07", "last_modified_date": "2024-03-28", "document_title": "FDA Enforcement Discretion and Compliance with Part 11 Requirements: A Comprehensive Guide", "questions_this_excerpt_can_answer": "1. What specific enforcement discretion does the FDA intend to exercise regarding Part 11 requirements for electronic records and signatures, particularly for legacy systems and certain other aspects?\n \n2. How does the FDA's current guidance interpret the scope of Part 11, especially in terms of which records are considered subject to these regulations, and what does this mean for the industry's understanding of Part 11's breadth?\n\n3. What are the specific Part 11 provisions and controls that the FDA explicitly intends to continue enforcing, despite the narrower interpretation and enforcement discretion outlined in the guidance?", "prev_section_summary": "The section discusses the FDA's approach to Part 11 requirements and enforcement discretion guidance. Key topics include concerns raised by stakeholders regarding interpretations of Part 11 requirements, withdrawal of draft guidance documents in 2003, the use of time stamps in systems spanning different time zones, and the agency's re-examination of Part 11 with plans for rulemaking. Entities mentioned include the FDA, industry stakeholders, and the CGMP initiative.", "excerpt_keywords": "FDA, Part 11, Electronic Records, Electronic Signatures, Enforcement Discretion"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[17] FDA Guidance for Industry Part 11, Electronic Records; Electronic Signatures.pdf\n## contains nonbinding recommendations\n\nas described in more detail below, the approach outlined in this guidance is based on three main elements:\n\n- part 11 will be interpreted narrowly; we are now clarifying that fewer records will be considered subject to part 11.\n- for those records that remain subject to part 11, we intend to exercise enforcement discretion with regard to part 11 requirements for validation, audit trails, record retention, and record copying in the manner described in this guidance and with regard to all part 11 requirements for systems that were operational before the effective date of part 11 (also known as legacy systems).\n- we will enforce all predicate rule requirements, including predicate rule record and recordkeeping requirements.\n\nit is important to note that fdas exercise of enforcement discretion as described in this guidance is limited to specified part 11 requirements (setting aside legacy systems, as to which the extent of enforcement discretion, under certain circumstances, will be more broad). we intend to enforce all other provisions of part 11 including, but not limited to, certain controls for closed systems in SS 11.10. for example, we intend to enforce provisions related to the following controls and requirements:\n\n- limiting system access to authorized individuals\n- use of operational system checks\n- use of authority checks\n- use of device checks\n- determination that persons who develop, maintain, or use electronic systems have the education, training, and experience to perform their assigned tasks\n- establishment of and adherence to written policies that hold individuals accountable for actions initiated under their electronic signatures\n- appropriate controls over systems documentation\n- controls for open systems corresponding to controls for closed systems bulleted above (SS 11.30)\n- requirements related to electronic signatures (e.g., SSSS 11.50, 11.70, 11.100, 11.200, and 11.300)\n\nwe expect continued compliance with these provisions, and we will continue to enforce them. furthermore, persons must comply with applicable predicate rules, and records that are required to be maintained or submitted must remain secure and reliable in accordance with the predicate rules.\n\n## details of approach - scope of part 11\n\n1. narrow interpretation of scope\n\nwe understand that there is some confusion about the scope of part 11. some have understood the scope of part 11 to be very broad. we believe that some of those broad interpretations could", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "98f45d6e-5483-4f2a-9fa7-45d308fba933": {"__data__": {"id_": "98f45d6e-5483-4f2a-9fa7-45d308fba933", "embedding": null, "metadata": {"page_label": "8", "file_name": "[17] FDA Guidance for Industry Part 11, Electronic Records; Electronic Signatures.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[17] FDA Guidance for Industry Part 11, Electronic Records; Electronic Signatures.pdf", "file_type": "application/pdf", "file_size": 44957, "creation_date": "2024-04-07", "last_modified_date": "2024-03-28", "document_title": "Regulations for the Management and Preservation of Electronic Records", "questions_this_excerpt_can_answer": "1. How does the FDA intend to interpret the scope of Part 11 regarding electronic records and signatures, and what impact does this interpretation have on the use of electronic records in lieu of paper records?\n \n2. What specific criteria does the FDA use to determine whether electronic records and signatures fall under the scope of Part 11, especially in relation to records required by predicate rules and their maintenance in electronic versus paper format?\n\n3. How does the FDA recommend organizations document their decisions on whether to rely on electronic records or paper records for performing regulated activities, and what examples of documentation methods are suggested?", "prev_section_summary": "This section discusses the FDA's enforcement discretion and compliance with Part 11 requirements for electronic records and signatures. Key topics include the narrow interpretation of Part 11, enforcement discretion for legacy systems, specific provisions and controls that will continue to be enforced, and the scope of Part 11. Entities involved are the FDA, industry stakeholders, and individuals responsible for developing, maintaining, or using electronic systems. The section emphasizes the importance of compliance with Part 11 provisions and predicate rule requirements to ensure secure and reliable electronic records.", "excerpt_keywords": "FDA, Part 11, Electronic Records, Electronic Signatures, Compliance"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[17] FDA Guidance for Industry Part 11, Electronic Records; Electronic Signatures.pdf\ncontains nonbinding recommendations\n\nlead to unnecessary controls and costs and could discourage innovation and technological advances without providing added benefit to the public health. as a result, we want to clarify that the agency intends to interpret the scope of part 11 narrowly.\n\nunder the narrow interpretation of the scope of part 11, with respect to records required to be maintained under predicate rules or submitted to fda, when persons choose to use records in electronic format in place of paper format, part 11 would apply. on the other hand, when persons use computers to generate paper printouts of electronic records, and those paper records meet all the requirements of the applicable predicate rules and persons rely on the paper records to perform their regulated activities, fda would generally not consider persons to be \"using electronic records in lieu of paper records\" under SSSS 11.2(a) and 11.2(b). in these instances, the use of computer systems in the generation of paper records would not trigger part 11.\n\n## definition of part 11 records\n\nunder this narrow interpretation, fda considers part 11 to be applicable to the following records or signatures in electronic format (part 11 records or signatures):\n\n- records that are required to be maintained under predicate rule requirements and that are maintained in electronic format in place of paper format. on the other hand, records (and any associated signatures) that are not required to be retained under predicate rules, but that are nonetheless maintained in electronic format, are not part 11 records. we recommend that you determine, based on the predicate rules, whether specific records are part 11 records. we recommend that you document such decisions.\n- records that are required to be maintained under predicate rules, that are maintained in electronic format in addition to paper format, and that are relied on to perform regulated activities. in some cases, actual business practices may dictate whether you are using electronic records instead of paper records under SS 11.2(a). for example, if a record is required to be maintained under a predicate rule and you use a computer to generate a paper printout of the electronic records, but you nonetheless rely on the electronic record to perform regulated activities, the agency may consider you to be using the electronic record instead of the paper record. that is, the agency may take your business practices into account in determining whether part 11 applies. accordingly, we recommend that, for each record required to be maintained under predicate rules, you determine in advance whether you plan to rely on the electronic record or paper record to perform regulated activities. we recommend that you document this decision (e.g., in a standard operating procedure (sop), or specification document).\n- records submitted to fda, under predicate rules (even if such records are not specifically identified in agency regulations) in electronic format (assuming the records have been identified in docket number 92s-0251 as the types of submissions the agency accepts in electronic format). however, a record that is not itself submitted, but is used", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "a3edaa72-e521-4bb1-b92a-e2322a0c194d": {"__data__": {"id_": "a3edaa72-e521-4bb1-b92a-e2322a0c194d", "embedding": null, "metadata": {"page_label": "9", "file_name": "[17] FDA Guidance for Industry Part 11, Electronic Records; Electronic Signatures.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[17] FDA Guidance for Industry Part 11, Electronic Records; Electronic Signatures.pdf", "file_type": "application/pdf", "file_size": 44957, "creation_date": "2024-04-07", "last_modified_date": "2024-03-28", "document_title": "FDA's Approach to Part 11 Requirements: Validation and Audit Trail Compliance", "questions_this_excerpt_can_answer": "1. How does the FDA approach the validation of computerized systems under Part 11 requirements, and what factors should companies consider when deciding to validate these systems?\n \n2. What is the FDA's stance on enforcing specific Part 11 requirements related to electronic signatures intended to be the equivalent of handwritten signatures, and under what conditions are these electronic signatures considered Part 11 compliant?\n\n3. Regarding audit trails, how does the FDA intend to exercise enforcement discretion for Part 11 requirements, and what are the expectations for companies in terms of documenting changes to records to ensure the trustworthiness and integrity of those records?", "prev_section_summary": "The section discusses the FDA's narrow interpretation of the scope of Part 11 regarding electronic records and signatures. It outlines specific criteria for determining when Part 11 applies to electronic records, especially in relation to records required by predicate rules. The section also recommends documenting decisions on whether to rely on electronic or paper records for regulated activities. Key entities mentioned include the FDA, electronic records, paper records, predicate rules, and regulated activities.", "excerpt_keywords": "FDA, Part 11, Electronic Records, Electronic Signatures, Validation"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[17] FDA Guidance for Industry Part 11, Electronic Records; Electronic Signatures.pdf\n## contains nonbinding recommendations\n\n204 in generating a submission, is not a part 11 record unless it is otherwise required to be maintained under a predicate rule and it is maintained in electronic format.\n\nelectronic signatures that are intended to be the equivalent of handwritten signatures, initials, and other general signings required by predicate rules. part 11 signatures include electronic signatures that are used, for example, to document the fact that certain events or actions occurred in accordance with the predicate rule (e.g. approved, reviewed, and verified).\n\n## approach to specific part 11 requirements\n\n### validation\n\nthe agency intends to exercise enforcement discretion regarding specific part 11 requirements for validation of computerized systems (SS 11.10(a) and corresponding requirements in SS 11.30). although persons must still comply with all applicable predicate rule requirements for validation (e.g., 21 cfr 820.70(i)), this guidance should not be read to impose any additional requirements for validation.\n\nwe suggest that your decision to validate computerized systems, and the extent of the validation, take into account the impact the systems have on your ability to meet predicate rule requirements. you should also consider the impact those systems might have on the accuracy, reliability, integrity, availability, and authenticity of required records and signatures. even if there is no predicate rule requirement to validate a system, in some instances it may still be important to validate the system.\n\nwe recommend that you base your approach on a justified and documented risk assessment and a determination of the potential of the system to affect product quality and safety, and record integrity. for instance, validation would not be important for a word processor used only to generate sops.\n\nfor further guidance on validation of computerized systems, see fdas guidance for industry and fda staff general principles of software validation and also industry guidance such as the gamp 4 guide (see references).\n\n### audit trail\n\nthe agency intends to exercise enforcement discretion regarding specific part 11 requirements related to computer-generated, time-stamped audit trails (SS 11.10 (e), (k)(2) and any corresponding requirement in SS11.30). persons must still comply with all applicable predicate rule requirements related to documentation of, for example, date (e.g., SS 58.130(e)), time, or sequencing of events, as well as any requirements for ensuring that changes to records do not obscure previous entries.\n\neven if there are no predicate rule requirements to document, for example, date, time, or sequence of events in a particular instance, it may nonetheless be important to have audit trails or other physical, logical, or procedural security measures in place to ensure the trustworthiness and integrity.", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "f9d9e3db-d651-4962-9df2-363cdf4390a8": {"__data__": {"id_": "f9d9e3db-d651-4962-9df2-363cdf4390a8", "embedding": null, "metadata": {"page_label": "10", "file_name": "[17] FDA Guidance for Industry Part 11, Electronic Records; Electronic Signatures.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[17] FDA Guidance for Industry Part 11, Electronic Records; Electronic Signatures.pdf", "file_type": "application/pdf", "file_size": 44957, "creation_date": "2024-04-07", "last_modified_date": "2024-03-28", "document_title": "Enforcement Discretion and Recommendations for Legacy Systems and Copies of Records under Part 11 Requirements: A Comprehensive Guide", "questions_this_excerpt_can_answer": "1. What criteria must a legacy system meet to qualify for enforcement discretion under the FDA's Part 11 requirements, as outlined in the \"Enforcement Discretion and Recommendations for Legacy Systems and Copies of Records under Part 11 Requirements: A Comprehensive Guide\"?\n\n2. How does the FDA recommend providing copies of electronic records to an investigator during an inspection, according to the guidance provided in the document titled \"Enforcement Discretion and Recommendations for Legacy Systems and Copies of Records under Part 11 Requirements: A Comprehensive Guide\"?\n\n3. What is the FDA's stance on applying Part 11 controls to systems that have been changed since August 20, 1997, as detailed in the \"Enforcement Discretion and Recommendations for Legacy Systems and Copies of Records under Part 11 Requirements: A Comprehensive Guide\"?", "prev_section_summary": "The section discusses the FDA's approach to Part 11 requirements, specifically focusing on validation of computerized systems and audit trail compliance. Key topics include the validation of systems based on impact on meeting predicate rule requirements, the importance of risk assessment in determining the extent of validation, and the exercise of enforcement discretion for audit trails to ensure trustworthiness and integrity of records. Entities mentioned include electronic signatures, validation of computerized systems, audit trails, and the FDA's enforcement discretion.", "excerpt_keywords": "FDA, Part 11, Electronic Records, Electronic Signatures, Enforcement Discretion"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[17] FDA Guidance for Industry Part 11, Electronic Records; Electronic Signatures.pdf\ncontains nonbinding recommendations\n\nlegacy systems\nthe agency intends to exercise enforcement discretion wip respect to all part 11 requirements for systems pat operwise were operational prior to august 20, 1997, pe effective date of part 11, under pe circumstances specified below.\nthis means pat pe agency does not intend to take enforcement action to enforce compliance wip any part 11 requirements if all pe following criteria are met for a specific system:\n- the system was operational before pe effective date.\n- the system met all applicable predicate rule requirements before pe effective date.\n- the system currently meets all applicable predicate rule requirements.\n- you have documented evidence and justification pat pe system is fit for its intended use (including having an acceptable level of record security and integrity, if applicable).\nif a system has been changed since august 20, 1997, and if pe changes would prevent pe system from meeting predicate rule requirements, part 11 controls should be applied to part 11 records and signatures pursuant to pe enforcement policy expressed in pis guidance.\n\ncopies of records\nthe agency intends to exercise enforcement discretion wip regard to specific part 11 requirements for generating copies of records (SS 11.10 (b) and any corresponding requirement in SS11.30). you should provide an investigator wip reasonable and useful access to records during an inspection. all records held by you are subject to inspection in accordance wip predicate rules (e.g., SSSS 211.180(c), (d), and 108.35(c)(3)(ii)).\nwe recommend pat you supply copies of electronic records by:\n- producing copies of records held in common portable formats when records are maintained in pese formats\n- using established automated conversion or export mepods, where available, to make copies in a more common format (examples of such formats include, but are not limited to, pdf, xml, or sgml)\n\nvarious guidance documents on information security are available (see references).\n\nin this guidance document, we use the term legacy system to describe systems already in operation before the effective date of part 11.", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "e4205215-d8cb-41bd-bd50-eb11f25f2d14": {"__data__": {"id_": "e4205215-d8cb-41bd-bd50-eb11f25f2d14", "embedding": null, "metadata": {"page_label": "11", "file_name": "[17] FDA Guidance for Industry Part 11, Electronic Records; Electronic Signatures.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[17] FDA Guidance for Industry Part 11, Electronic Records; Electronic Signatures.pdf", "file_type": "application/pdf", "file_size": 44957, "creation_date": "2024-04-07", "last_modified_date": "2024-03-28", "document_title": "Best Practices for Record Retention and Preservation in Part 11 Compliance", "questions_this_excerpt_can_answer": "1. What are the FDA's recommendations regarding the capabilities of copies of Part 11 records when provided to the agency, especially in terms of search, sort, and trend functionalities?\n \n2. How does the FDA suggest organizations should decide on the method for maintaining records in compliance with Part 11, particularly in relation to predicate rule requirements and risk assessments?\n\n3. What is the FDA's stance on archiving required records in non-electronic formats or standard electronic file formats, and under what conditions can the original electronic version of these records be deleted?", "prev_section_summary": "The section discusses the FDA's enforcement discretion and recommendations for legacy systems and copies of records under Part 11 requirements. Key topics include criteria for legacy systems to qualify for enforcement discretion, providing copies of electronic records to investigators during inspections, applying Part 11 controls to systems changed since August 20, 1997, and recommendations for generating copies of records in common portable formats. Key entities mentioned are legacy systems, the FDA, investigators, and record holders.", "excerpt_keywords": "FDA, Part 11, Electronic Records, Electronic Signatures, Record Retention"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[17] FDA Guidance for Industry Part 11, Electronic Records; Electronic Signatures.pdf\ncontains nonbinding recommendations\n\n|291|in each case, we recommend that the copying process used produces copies that preserve the content and meaning of the record. if you have the ability to search, sort, or trend part 11 records, copies given to the agency should provide the same capability if it is reasonable and technically feasible. you should allow inspection, review, and copying of records in a human readable form at your site using your hardware and following your established procedures and techniques for accessing records.|\n|---|---|\n|298|record retention|\n|300|the agency intends to exercise enforcement discretion with regard to the part 11 requirements for the protection of records to enable their accurate and ready retrieval throughout the records retention period (SS 11.10 (c) and any corresponding requirement in SS11.30). persons must still comply with all applicable predicate rule requirements for record retention and availability (e.g., SSSS 211.180(c),(d), 108.25(g), and 108.35(h)).|\n|306|we suggest that your decision on how to maintain records be based on predicate rule requirements and that you base your decision on a justified and documented risk assessment and a determination of the value of the records over time.|\n|310|fda does not intend to object if you decide to archive required records in electronic format to nonelectronic media such as microfilm, microfiche, and paper, or to a standard electronic file format (examples of such formats include, but are not limited to, pdf, xml, or sgml). persons must still comply with all predicate rule requirements, and the records themselves and any copies of the required records should preserve their content and meaning. as long as predicate rule requirements are fully satisfied and the content and meaning of the records are preserved and archived, you can delete the electronic version of the records.|\n|317|in addition, paper and electronic record and signature components can co-exist (i.e., a hybrid situation) as long as predicate rule requirements are met and the content and meaning of those records are preserved.|\n\nexamples of hybrid situations include combinations of paper records (or other nonelectronic media) and electronic records, paper records and electronic signatures, or handwritten signatures executed to electronic records.", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "69ff0933-1b4c-4d8a-84ff-70bc77259a4e": {"__data__": {"id_": "69ff0933-1b4c-4d8a-84ff-70bc77259a4e", "embedding": null, "metadata": {"page_label": "12", "file_name": "[17] FDA Guidance for Industry Part 11, Electronic Records; Electronic Signatures.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[17] FDA Guidance for Industry Part 11, Electronic Records; Electronic Signatures.pdf", "file_type": "application/pdf", "file_size": 44957, "creation_date": "2024-04-07", "last_modified_date": "2024-03-28", "document_title": "Regulatory and Industry References for Software Development and Validation in Medical Devices: A Comprehensive Guide", "questions_this_excerpt_can_answer": "1. What specific FDA guidance document addresses the general principles of software validation for industry and FDA staff, including its publication year?\n2. Can you list a resource that provides a glossary of computerized system and software development terminology specifically for FDA regulatory affairs, including its publication year?\n3. What is the title of the industry reference guide that focuses on the validation of automated systems in manufacturing, including the organization that published it and the publication year?", "prev_section_summary": "This section discusses the FDA's recommendations for record retention and preservation in compliance with Part 11 regulations. Key topics include the capabilities of copies of Part 11 records provided to the agency, methods for maintaining records in compliance with Part 11, archiving required records in non-electronic formats or standard electronic file formats, and the conditions under which the original electronic version of records can be deleted. The section emphasizes the importance of preserving the content and meaning of records, complying with predicate rule requirements, conducting risk assessments, and allowing for the co-existence of paper and electronic record components.", "excerpt_keywords": "FDA, software validation, electronic records, industry references, medical devices"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[17] FDA Guidance for Industry Part 11, Electronic Records; Electronic Signatures.pdf\n## contains nonbinding recommendations\n\n### iv. references\n\nfood and drug administration references\n1. glossary of computerized system and software development terminology (division of field investigations, office of regional operations, office of regulatory affairs, fda 1995) (http://www.fda.gov/ora/inspect_ref/igs/gloss.html)\n2. general principles of software validation; final guidance for industry and fda staff (fda, center for devices and radiological healp, center for biologics evaluation and research, 2002) (http://www.fda.gov/cdrh/comp/guidance/938.html)\n3. guidance for industry, fda reviewers, and compliance on off-the-shelf software use in medical devices (fda, center for devices and radiological healp, 1999) (http://www.fda.gov/cdrh/ode/guidance/585.html)\n4. pharmaceutical cgmps for pe 21st century: a risk-based approach; a science and risk-based approach to product quality regulation incorporating an integrated quality systems approach (fda 2002) (http://www.fda.gov/oc/guidance/gmp.html)\n\nindustry references\n1. the good automated manufacturing practice (gamp) guide for validation of automated systems, gamp 4 (ispe/gamp forum, 2001) (http://www.ispe.org/gamp/)\n2. iso/iec 17799:2000 (bs 7799:2000) information technology - code of practice for information security management (iso/iec, 2000)\n3. iso 14971:2002 medical devices- application of risk management to medical devices (iso, 2001)", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "4fff1da4-8609-4869-928c-1e3da7e3d89e": {"__data__": {"id_": "4fff1da4-8609-4869-928c-1e3da7e3d89e", "embedding": null, "metadata": {"page_label": "1", "file_name": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_type": "application/pdf", "file_size": 453540, "creation_date": "2024-04-07", "last_modified_date": "2024-03-29", "document_title": "PIC/S Pharmaceutical Inspection Convention: Good Practices for Computerised Systems in Regulated Environments", "questions_this_excerpt_can_answer": "1. What is the official publication date of the PIC/S guidance document titled \"Good Practices for Computerised Systems in Regulated 'GXP' Environments\"?\n\n2. Can the PIC/S guidance document on good practices for computerised systems in regulated environments be reproduced for commercial purposes, according to the information provided in the document?\n\n3. Who is listed as the editor or contact point for inquiries regarding the PIC/S guidance document on computerised systems, and what is the official website for further information?", "excerpt_keywords": "PIC/S, Pharmaceutical Inspection Convention, computerised systems, regulated environments, GXP"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf\n## picis pharmaceutical inspection convention pharmaceutical inspection co-operation scheme pi 011-3 25 september 2007 pic/s guidance good practices for computerised systems in regulated \"gxp\" environments (c) pic/s september 2007 reproduction prohibited for commercial purposes. reproduction for internal use is authorised, provided that the source is acknowledged. editor: pic/s secretariat e-mail: info@picscheme.org web site:http://www.picscheme.org pi 011-3 25 september 2007", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "5ce07763-e371-406d-9fbc-f1fa976ea070": {"__data__": {"id_": "5ce07763-e371-406d-9fbc-f1fa976ea070", "embedding": null, "metadata": {"page_label": "2", "file_name": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_type": "application/pdf", "file_size": 453540, "creation_date": "2024-04-07", "last_modified_date": "2024-03-29", "document_title": "\"Blank Canvas: Exploring the Absence of Content in Art and Design\"", "questions_this_excerpt_can_answer": "Given the provided context, here are three questions that this specific context can provide specific answers to, which are unlikely to be found elsewhere:\n\n1. **What is the file size of the PDF document titled \"Blank Canvas: Exploring the Absence of Content in Art and Design\" located in the PharmaWise Engineer's PharmaWise CSV & Data Integrity raw data directory?**\n - This question is specific to the document's metadata, including its file size, which is detailed in the provided context.\n\n2. **What are the creation and last modified dates of the document named \"Blank Canvas: Exploring the Absence of Content in Art and Design\" stored in the PharmaWise Engineer directory on Google Drive?**\n - The context provides unique information regarding the document's creation and last modified dates, which is not commonly available and is specific to this document's file metadata.\n\n3. **What is the significance of the document titled \"Blank Canvas: Exploring the Absence of Content in Art and Design\" within the PharmaWise CSV & Data Integrity project, considering its file name suggests a focus on computerised systems recommendations?**\n - This question delves into the apparent discrepancy between the document's title and its expected content based on the file name and path provided. It seeks to understand the document's relevance or role within a project focused on computerised systems and data integrity, which is a context-specific inquiry unlikely to be answered without access to the document or project details provided here.\n\nThese questions leverage the unique details provided in the context, such as the document's metadata and its placement within a specific project directory, to formulate inquiries that are highly specific and unlikely to be answered by sources outside of this context.", "prev_section_summary": "The key topics of the section include the PIC/S guidance document titled \"Good Practices for Computerised Systems in Regulated 'GXP' Environments,\" the official publication date of September 25, 2007, and the restrictions on reproduction for commercial purposes. The document provides contact information for inquiries, listing the editor as the PIC/S secretariat and providing the official website for further information. Key entities mentioned include the Pharmaceutical Inspection Convention (PIC), the Pharmaceutical Inspection Co-operation Scheme (PIC/S), and the editor of the guidance document.", "excerpt_keywords": "Keywords: computerised systems, recommendations, data integrity, PDF document, metadata"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf\nno_content_here", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "e1f678a2-de73-49e8-91df-b3127499025c": {"__data__": {"id_": "e1f678a2-de73-49e8-91df-b3127499025c", "embedding": null, "metadata": {"page_label": "3", "file_name": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_type": "application/pdf", "file_size": 453540, "creation_date": "2024-04-07", "last_modified_date": "2024-03-29", "document_title": "Guidelines for Computerized System Implementation and Operation", "questions_this_excerpt_can_answer": "1. What specific guidelines does the document provide for the planning and life-cycle management of computerized systems within the pharmaceutical industry, as outlined on page 9 of the \"Guidelines for Computerized System Implementation and Operation\"?\n\n2. How does the document detail the approach to GAMP validation based on different categories of software products, and what page can this information be found on in the \"Guidelines for Computerized System Implementation and Operation\"?\n\n3. What are the key considerations for system security, including backup procedures, as recommended in the \"Guidelines for Computerized System Implementation and Operation,\" and on which page can these recommendations be found?", "prev_section_summary": "The section provides metadata details of a PDF document titled \"Blank Canvas: Exploring the Absence of Content in Art and Design\" stored in the PharmaWise Engineer's PharmaWise CSV & Data Integrity raw data directory. It includes information such as the file size, creation date, and last modified date of the document. The section also presents three specific questions that can be answered based on the provided context, focusing on the document's metadata and its relevance within the project.", "excerpt_keywords": "Guidelines, Computerized Systems, Implementation, GAMP Validation, System Security"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf\n|content|page number|\n|---|---|\n|document history|1|\n|part one - preamble|1|\n|purpose|1|\n|scope|2|\n|introduction|3|\n|part two - implementation of system|6|\n|implementation of computerised systems|6|\n|the structure and functions of the computer system(s)|7|\n|planning and life-cycle management|9|\n|management and responsibilities|9|\n|user requirement specifications (urs)|11|\n|functional specifications (fs)|12|\n|suppliers, software developers and quality management|13|\n|important qms and software standards attributes|14|\n|testing|15|\n|validation strategies and priorities|16|\n|gamp validation approach based on different categories of software products|18|\n|retrospective validation|19|\n|part three - system operation / inspection / references|21|\n|change management|21|\n|change control and error report system|22|\n|system security, including back-up|23|\n|data changes - audit trail/critical data entry|25|\n|electronic records and electronic signatures|26|\n|personnel|30|\n|inspection considerations|31|\n|checklists and aide memoires|34|\n|references for relevant standards and gmp guides / codes|40|\n|suggested further reading|42|\n|glossary of terms|43|\n|abbreviations used in the document|49|\n|revision history|50|", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "444d0e6c-7c01-48df-9d16-da8bd706ad26": {"__data__": {"id_": "444d0e6c-7c01-48df-9d16-da8bd706ad26", "embedding": null, "metadata": {"page_label": "4", "file_name": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_type": "application/pdf", "file_size": 453540, "creation_date": "2024-04-07", "last_modified_date": "2024-03-29", "document_title": "\"Blank Canvas: A Collection of Unique Entities and Themes\"", "questions_this_excerpt_can_answer": "Given the provided context, here are three questions that this specific context can provide specific answers to, which are unlikely to be found elsewhere:\n\n1. **What is the file size of the PDF document titled \"Blank Canvas: A Collection of Unique Entities and Themes\" related to recommendations on computerized systems within the PharmaWise Engineer project?**\n - This question targets the specific detail of the file size within the given context, which is 453540 bytes or approximately 453 KB. This detail is unique to this document and its metadata.\n\n2. **What are the creation and last modification dates of the document named \"Blank Canvas: A Collection of Unique Entities and Themes\" found in the PharmaWise CSV & Data Integrity project's raw data?**\n - The answer to this question would provide insight into the document's timeline, specifically that it was created on April 7, 2024, and last modified on March 29, 2024. This information is unique to the document's metadata provided in the context.\n\n3. **Where can the PDF document [35] PIC_011_3_recommendation_on_computerised_systems.pdf, associated with the PharmaWise Engineer project, be located within a file storage system?**\n - This question seeks the specific file path for locating the document within a digital storage system, which is \"/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[35] PIC_011_3_recommendation_on_computerised_systems.pdf\". This detail is unique to the document's storage and organization context provided.\n\nThese questions are tailored to extract unique information from the given context, focusing on metadata and document management details specific to the \"Blank Canvas: A Collection of Unique Entities and Themes\" document within a pharmaceutical development project.", "prev_section_summary": "The section provides guidelines for the implementation and operation of computerized systems in the pharmaceutical industry. Key topics include planning and life-cycle management, GAMP validation approach based on software categories, system security including backup procedures, change management, data changes, electronic records, personnel, inspection considerations, and references for relevant standards and GMP guides. Key entities mentioned are user requirement specifications, functional specifications, suppliers, software developers, quality management, testing, validation strategies, and personnel responsibilities.", "excerpt_keywords": "PharmaWise Engineer, computerized systems, recommendations, pharmaceutical industry, GAMP validation"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf\nno_content_here", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "1133e754-3cf3-4d95-afe4-58cfe4c7deac": {"__data__": {"id_": "1133e754-3cf3-4d95-afe4-58cfe4c7deac", "embedding": null, "metadata": {"page_label": "5", "file_name": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_type": "application/pdf", "file_size": 453540, "creation_date": "2024-04-07", "last_modified_date": "2024-03-29", "document_title": "PIC/S Guide to Good Manufacturing Practices for Computerised Systems: Recommendations and Background Information for Inspectors", "questions_this_excerpt_can_answer": "1. What is the purpose of the PIC/S Guide to Good Manufacturing Practices, specifically its Annex 11 on computerised systems, in the context of GMP inspections?\n \n2. How does the document address the needs of companies outside the regulated pharmaceutical sector, particularly those subjected to GLP inspections, in terms of guidance on computerised systems?\n\n3. What collaborative efforts are highlighted in the document for the creation of harmonised guidance on the implementation, management, and operation of computerised systems in the regulated sector?", "prev_section_summary": "The key topics of the section include recommendations on computerized systems within the PharmaWise Engineer project, details about the PDF document titled \"Blank Canvas: A Collection of Unique Entities and Themes,\" and metadata information such as file size, creation date, last modification date, and file path. The entities mentioned are the document itself, the project names (PharmaWise Engineer and PharmaWise CSV & Data Integrity), and the specific file path within a digital storage system. The section focuses on providing unique details and insights related to document management and metadata within a pharmaceutical development project.", "excerpt_keywords": "PIC/S, Good Manufacturing Practices, Computerised Systems, GMP inspections, Regulatory agencies"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf\n## document history\n\n|adoption by pic/s committee|2-3 june 2003|\n|---|---|\n|entry into force|1 september 2003|\n\n## part one - preamble\n\npurpose\n\n2.1 the pic/s guide to good manufacturing practices is the basis for gmp inspections. in particular its annex 11, computerised systems is used when inspecting such systems.\n\n2.2 the purpose of this document is to provide recommendations and background information concerning computerised systems that will be of assistance to inspectors for training purposes and during the inspection of computerised systems. the document will be of assistance to all good practice inspectors responsible for inspecting applications in the regulated pharmaceutical sector; hence the use of the acronym gxp in the title. it is recognised that not all companies subjected to glp inspections are linked to the regulated pharmaceutical sector. however, it is considered that the guidance contained within this pic/s document may also be beneficial to companies subjected to other regulatory frameworks and glp inspection.\n\n2.3 gdp defines the scope of compliance requirements for wholesaling and distribution practice. where automated systems and electronic records are used for such applications then inspectors will expect such regulated users to have in place the sorts of controls and disciplines outlined in this document, or a best practice alternative. vertically integrated companies (r&d, manufacturing and distribution) will already apply such controls and compliance measures.\n\n2.4 international regulatory agencies have collaborated to produce this harmonised guidance for the implementation, management and operation of computerised systems. it is intended as a reference for regulated users, including their suppliers, in addition to regulatory inspectors and investigators.\n\n2.5 this guidance document is intended to provide a logical explanation of the basic requirements for the implementation, validation and operation of computerised systems. additionally, the document may be adapted to identify the criteria that would be expected to be considered if a regulated user, or a regulatory agency, were to conduct an inspection of the implemented computerised system(s), against gxp compliance requirements and/or perceived risks.\n\n2.6 this guidance document provides details of good practices, which should support new technology and technical innovations.\n\nthroughout this document the users (owners of the good practice computerised systems being inspected) are collectively referred to as regulated users for clarity.\n\npi 011-3 page 1 of 50 25 september 2007", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "ad005025-af1c-48d6-8457-2c4f30220144": {"__data__": {"id_": "ad005025-af1c-48d6-8457-2c4f30220144", "embedding": null, "metadata": {"page_label": "6", "file_name": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_type": "application/pdf", "file_size": 453540, "creation_date": "2024-04-07", "last_modified_date": "2024-03-29", "document_title": "Implementation and Validation of Computerized Systems in Regulated Industries: A Comprehensive Guide", "questions_this_excerpt_can_answer": "1. What does the document recommend regarding the role of national legislation in the applicability of its provisions for computerized systems in regulated industries?\n \n2. How does the document suggest auditors or inspectors assess compliance with its guidelines for computerized systems in regulated environments?\n\n3. What future contributions does the document anticipate from the PIC/S Expert Circle on Computerised Systems in terms of training materials and interpretations of GxP for the inspection of common GxP systems and sector-specific applications?", "prev_section_summary": "The section discusses the purpose of the PIC/S Guide to Good Manufacturing Practices, specifically focusing on its Annex 11 on computerised systems for GMP inspections. It highlights the recommendations and background information provided in the document for inspectors in the regulated pharmaceutical sector, as well as companies subjected to GLP inspections. The collaborative efforts of international regulatory agencies in creating harmonised guidance on the implementation, management, and operation of computerised systems are also emphasized. Key topics include the scope of compliance requirements, the use of automated systems and electronic records, and the basic requirements for the implementation, validation, and operation of computerised systems. The document aims to support new technology and technical innovations in the regulated sector.", "excerpt_keywords": "Implementation, Validation, Computerized Systems, Regulated Industries, GxP"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf\n## 2.7\n\nit should be noted that it is important for national legislation to be referred to when determining the extent to which the provisions laid down in this document may be applicable.\n\n## 2.8\n\nan auditor or an inspector may wish to consider evidence for compliance as indicated in italicised text throughout this document.\n\n## 2.9\n\nit is to be hoped that the pic/s expert circle on computerised systems will build on this consensus reference document, to deliver simplified training and aide memoires for the inspection of common gxp systems, as well as sector-specific applications. as technology continues its relentless advance the expert circle could also provide interpretation of gxp and recommend changes, if appropriate. such materials could provide further sub-set appendices to section 24 (inspection tabulated checklists and aide memoires).\n\n## 2.10\n\nsome repetition is inevitable in a document that has evolved over many years and through various working party multinational iterations. it is not intended that this document is read from cover to cover, but should be dipped into as a reference source when needed and for that reason some sections have to stand-alone.\n\n## 3. scope\n\n### 3.1\n\nit is acknowledged that the field of computer technology continues to develop at a considerable speed and the regulated user has to ensure that the software and systems have been developed to best engineering practices in a quality assured manner. it will be for regulated users to define relevant applications, impacted business units and corresponding deliverables for such applications. this document sheds some light on the techniques and controls required for this.\n\n### 3.2\n\nat the time of issue this document reflected the current state of the art. it is not intended to be a barrier to technical innovation or the pursuit of excellence. the advice in this guidance is not mandatory for industry. however, industry should consider these recommendations as appropriate.\n\n### 3.3\n\nfor hardware, peripherals, integrated process links and system functionality in general, the controls and testing arrangements are by comparison to software, fairly mature, logically more visible and the failure modes more predictable.\n\n### 3.4\n\nas a result, we have tried to keep the contents of this document practical and principle-oriented, to ensure that it retains relevance for as long as possible. however, value judgements and consensus between parties can be difficult to achieve at times in this complicated field.\n\n### 3.5\n\nthe scope of the document is broad, covering necessary steps and the documentation needed for the implementation and validation of a computerised system. management of such projects requires the linking of important aspects of management policies, documentation and record systems embracing the\n\nfor successful project management these links should be established between the supplier(s) [developer(s) and producer(s) of individual components or complete computerised system] and the regulated user [purchaser and user of the computerised system].\n\npi 011-3 page 2 of 50 25 september 2007", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "33785cca-ddb8-4494-9e14-7dfc57d3cd36": {"__data__": {"id_": "33785cca-ddb8-4494-9e14-7dfc57d3cd36", "embedding": null, "metadata": {"page_label": "7", "file_name": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_type": "application/pdf", "file_size": 453540, "creation_date": "2024-04-07", "last_modified_date": "2024-03-29", "document_title": "Guidance for GxP Compliance and Validation of Computerised Systems: A Comprehensive Approach", "questions_this_excerpt_can_answer": "1. What specific guidance does the document provide for suppliers and developers of software and automated systems to achieve GxP compliance?\n \n2. How does the document propose handling the validation of legacy computerised systems, and which sections specifically address strategies and approaches for this process?\n\n3. What are the anticipated benefits of using validated, GxP controlled computerised systems in terms of quality assurance of regulated materials/products and data/information management, as outlined in the document?", "prev_section_summary": "The section discusses the importance of national legislation in determining the applicability of provisions for computerized systems in regulated industries, recommendations for auditors or inspectors to assess compliance with guidelines, future contributions anticipated from the PIC/S Expert Circle on Computerised Systems, the scope of the document in terms of technology development, controls and testing arrangements for hardware and software, and the broad coverage of necessary steps and documentation for implementing and validating computerized systems. Key entities mentioned include national legislation, auditors, inspectors, the PIC/S Expert Circle, regulated users, industry, hardware, peripherals, integrated process links, system functionality, management policies, documentation, record systems, suppliers, developers, producers, and purchasers.", "excerpt_keywords": "GxP compliance, Validation, Computerised systems, Quality assurance, Regulatory requirements"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf\n## 3.6\n\nof necessity this guidance contains some how to achieve gxp compliance advice for suppliers and developers of software and automated systems, in addition to guidance for the regulated users. this is because of the iterative nature of software development and the requirement for quality and functionality to be built into the software in a disciplined manner, to ensure structural integrity, consistency, robustness and reliability. this will often be outside of the direct control of the regulated user (as purchaser/customer). there will normally be a need to manage and control the split responsibilities of contracted suppliers (whether in-house or external party) and regulated user businesses (customers), for project management, product specifications, quality assurance standards and performance.\n\n## 3.7\n\nthis document also identifies the important aspects of validation of computerised systems. descriptions of strategies that may be used for different categories of computer systems are described as well as identifying the approach that might be taken for the retrospective validation of legacy (old) systems. (see in particular sections 4.5 and 6.2 (figure:1) and 16 of this document).\n\n## 3.8\n\npic/s considers that adoption of the principles, guidance, reporting and life cycle documentation best practices, outlined in this document, will enable users of computerised systems to establish quality assurance systems and records capable of demonstrating compliance with current gxp requirements and related guidance.\n\n## 4. introduction\n\n### 4.1\n\nthe structure of the document is designed to identify discrete subsections and their interrelationship within the principal topics concerning the implementation, validation and operation of computerised systems. a reference section, together with a glossary of terms commonly used in this industry sector will be found at the end of this document. section 26 further reading suggests a number of textbooks, technical reports and guidelines that amplify the science, technology and practices underpinning this guideline. the 1994 publication by stokes et al (further reading ref: 1) provides insight into the requirements for computerised systems in gcp, glp and gmp, together with a historical perspective on validation and international regulatory requirements.\n\n### 4.2\n\nin recent years there has been an increasing trend to integrate electronic record and business management systems across all operational areas. in the future it is expected that our reliance on computer systems will continue to grow, rather than diminish. the use of validated, effective, gxp controlled computerised systems should provide enhancements in the quality assurance of regulated materials/products and associated data/information management. the extent of the validation effort and control arrangements should not be underestimated and a harmonised approach by industry and regulators is beneficial.\n\n### 4.3\n\ncommercial off the shelf, standard, or proprietary systems can be particularly difficult to assess from a quality and performance point of view. for gxp", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "171233c8-3e39-40b2-b9cc-4b0373a7fcc3": {"__data__": {"id_": "171233c8-3e39-40b2-b9cc-4b0373a7fcc3", "embedding": null, "metadata": {"page_label": "8", "file_name": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_type": "application/pdf", "file_size": 453540, "creation_date": "2024-04-07", "last_modified_date": "2024-03-29", "document_title": "Regulated User Requirements and Risk Analysis for Computerized Systems Validation: A Comprehensive Guide", "questions_this_excerpt_can_answer": "1. How does the document recommend regulated users approach the selection and assessment of computerized systems to ensure they are fit for purpose within regulated environments, particularly in terms of supplier assessment and risk analysis?\n \n2. What specific guidance does the document offer for assessing complex automated equipment, such as high-output tabletting machinery with in-process monitoring and feedback control functionality, especially regarding the role of supplier cooperation in the validation process?\n\n3. In the context of a GxP inspection, what elements of an installed computerised system are inspectors likely to evaluate to assess its fitness for purpose, and how does the document suggest regulated users prepare their validation documentation to meet these inspection criteria?", "prev_section_summary": "This section provides guidance on achieving GxP compliance for suppliers and developers of software and automated systems, as well as for regulated users. It discusses the importance of validation of computerised systems, including strategies for different categories of systems and retrospective validation of legacy systems. The document emphasizes the adoption of principles and best practices outlined to establish quality assurance systems and demonstrate compliance with current GxP requirements. Additionally, it highlights the increasing integration of electronic record and business management systems, the benefits of using validated computerised systems for quality assurance, and the challenges in assessing commercial off-the-shelf systems.", "excerpt_keywords": "Regulated User Requirements, Risk Analysis, Computerized Systems Validation, Supplier Assessment, GxP Inspection"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf\n#### regulated applications\n\nit is essential for the regulated user to define a requirement specification prior to selection and to carry out a properly documented supplier assessment and risk analysis for the various system options. information for such exercises may come from supplier audits and research into the suppliers product versions in the user community and literature. this risk-based approach is one way for a firm to demonstrate that they have applied a controlled methodology, to determine the degree of assurance that a computerised system is fit for purpose. it will certainly be useful evidence for consideration by an inspector. (note: what constitutes a critical application may vary considerably, depending on the situation - perhaps more so in glp than in other disciplines).\n\n#### 4.4\n\nwhilst much of the detailed industry guidance relates to bespoke and configured applications there are a number of tools and assessment techniques recommended for commercial packages and standard automated equipment. complex automated state of the art processing equipment (such as high output tabletting machinery with in-process monitoring and feedback control functionality), or complex analytical instrumentation, for example, is difficult to assess without the suppliers help. the co-operation of the supplier is essential and it is important for suppliers to anticipate the needs of regulated users for relevant product development life cycle quality and validation information. such an approach also provides added value for the automated products. the qa and validation aspects for large automation aspects will inevitably be complex and may be subsumed in major engineering projects activated by the potential regulated user. inspectors will be interested in the evidence relating to the firms assessment of the suppliers critical automated features as well as the traditional engineering, qualification and process performance aspects. much of the guidance given in the gamp guide (ref: 4), for example, is scaleable to complex projects and equipment with sub-contracted features. (note: the risk assessment described in 4.3 above should identify critical features and functions for both the project team and the inspector).\n\n#### 4.5\n\nwhen a gxp inspector has to assess an installed computerised system at a regulated users site, s/he may consider some, or all, of the elements shown in figure 1: \"computerised system\", (viz.: the controlling system and the controlled process in an operating environment). the inspector will consider the potential risks, from the automated system to product/material quality or data integrity, as identified and documented by the regulated user, in order to assess the fitness for purpose of the particular system(s). the companys risk assessment records may also be referred to as part of this process. the inspectors assessment may also involve a consideration of system life cycle, quality assurance measures, validation and operational control evidence for the controlling system, as well as validation and operational experience with the controlled process.\n\n#### 4.6\n\nthe validation documentation should cover all the steps of the life-cycle with appropriate methods for measurement and reporting, (e.g. assessment reports and details of quality and test measures), as required. regulated users should be able to justify and defend their standards, protocols, acceptance criteria, procedures and records in the light of their own documented risk and complexity assessments, aimed at ensuring fitness for purpose and regulatory compliance.\n\npi 011-3 page 4 of 50 25 september 2007", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "16689edc-72f5-4489-9086-34c9fd4ba2ee": {"__data__": {"id_": "16689edc-72f5-4489-9086-34c9fd4ba2ee", "embedding": null, "metadata": {"page_label": "9", "file_name": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_type": "application/pdf", "file_size": 453540, "creation_date": "2024-04-07", "last_modified_date": "2024-03-29", "document_title": "Comprehensive Guide to Pharmaceutical Industry Systems Validation and Compliance: GAMP Supplier Guide, User Acceptance Testing, Performance Qualification, Computerized Systems, and Regulatory Responsibilities", "questions_this_excerpt_can_answer": "1. What specific guide does the pharmaceutical industry systems validation forum in the UK develop to assist software suppliers in implementing an appropriate quality management system for automated manufacturing practices?\n\n2. How does the GAMP guide recommend handling user acceptance testing (OQ) in relation to the functional specification, and what additional testing is suggested for the regulated user in terms of system performance qualification?\n\n3. What are the three main application types of computerized systems as identified in the document, and what is recommended for critical systems in terms of validation evidence and inspector review?", "prev_section_summary": "The section discusses the importance of regulated users defining requirement specifications, conducting supplier assessments, and risk analysis for computerized systems. It emphasizes the need for a risk-based approach to demonstrate that a system is fit for purpose and highlights the role of supplier cooperation in assessing complex automated equipment. The section also outlines elements that inspectors may evaluate during a GxP inspection of a computerized system and stresses the importance of validation documentation covering all lifecycle steps to ensure regulatory compliance. Key topics include regulated applications, supplier cooperation, risk assessment, inspection criteria, and validation documentation. Key entities mentioned are regulated users, suppliers, inspectors, automated equipment, and validation documentation.", "excerpt_keywords": "pharmaceutical industry, systems validation, GAMP, computerized systems, regulatory compliance"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf\n#### 4.7\n\nthe pharmaceutical industry systems validation forum in the uk developed the good automated manufacturing practice (gamp) supplier guide to assist software suppliers in implementing an appropriate quality management system. the gamp guide (and appendices) has evolved largely to define best practices in specifying, designing, building, testing, qualifying and documenting these systems to a rigorous validation management scheme, largely for the controlling system. gamp forum is now sponsored by ispe and has international membership and participation, including gamp americas. (websites: www.gamp.org and www.ispe.org)\n\n#### 4.8\n\napart from user acceptance testing (oq) versus the functional specification, which may include factory acceptance testing (fat), for example, at the supplier, the regulated user also has responsibility for the (pq) performance qualification of the system. in this context the pq3 user acceptance test of the system is in its operating environment, and will again be against a user requirements specification (urs) that will include protocols and criteria for the performance and quality acceptance, not only for the controlling system but also for the controlled (pharmaceutical related) process application. cross-references to any related, relevant process validation documentation should be clearly stated in respect of the latter. the gamp guide and pda technical report no 18 (further reading ref: 6) provide good practice guidance to drafting and using a urs, whereas pharmaceutical process validation guidance is given elsewhere (see pic/s pi 006 and related eu/usfda documents).\n\n#### 4.9\n\ncomputerised systems may simplistically be considered to exist as three main application types, i.e.: process control systems, data processing systems, (including data collection/capture) and data record/storage systems. there may be links between these three types of system, described as interfaces. for critical systems, the inspector should study the users specifications, reports, data, acceptance criteria and other documentation for various phases of the project. the regulated user should be able to demonstrate through the validation evidence that they have a high level of confidence in the integrity of both the processes executed within the controlling computer system and in those processes controlled by the computer system within the prescribed operating environment.\n\n#### 4.10\n\nthe simplification of application system types may at first sight seem to be misleading for some readers. for gcp, examples of specific clinical systems have been described in computer systems validation in clinical research section 9 (further reading ref: 12). it can be seen that many of these systems have much in common with requirements for other gxp sectors, (e.g. electronic transfer of data and/or software systems, (clinical) database management systems, statistical systems, derived data systems, electronic document management systems, electronic records and electronic signatures).\n\n#### 4.11\n\nthe regulated users of the system have the ultimate responsibility for ensuring that documented validation evidence is available to gxp inspectors for review.\n\nlarge enterprise or mrp-ii systems may be tested in a pilot mode environment initially, followed by controlled roll-out to the user environment.\n\npi 011-3 page 5 of 50 25 september 2007", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "9287a61e-86c9-4048-a6ab-a6fea588b423": {"__data__": {"id_": "9287a61e-86c9-4048-a6ab-a6fea588b423", "embedding": null, "metadata": {"page_label": "10", "file_name": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_type": "application/pdf", "file_size": 453540, "creation_date": "2024-04-07", "last_modified_date": "2024-03-29", "document_title": "Ensuring Reliability and Quality in Computerised Systems Development and Implementation: A Comprehensive Guide", "questions_this_excerpt_can_answer": "1. What specific guidance documents and annexes are referenced for assessing the basic operational controls, quality system, and security features of computerised systems in the pharmaceutical industry, as per the document?\n \n2. How does the document suggest customers should evaluate the reliability of a supplier's software products in the context of pharmaceutical computerised systems development and implementation?\n\n3. What are the recommended actions for pharmaceutical companies when dealing with software of uncertain pedigree (SOUP), according to the document's reference to ISO15504 and the GAMP 4 appendix M2 guideline for supplier audit?", "prev_section_summary": "The section discusses the development of the GAMP supplier guide by the pharmaceutical industry systems validation forum in the UK to assist software suppliers in implementing quality management systems for automated manufacturing practices. It also covers the recommendations for user acceptance testing (OQ) and performance qualification (PQ) of computerized systems, as well as the three main application types of computerized systems: process control systems, data processing systems, and data record/storage systems. The section emphasizes the importance of validation evidence for critical systems and the ultimate responsibility of regulated users to provide this evidence for inspection. Additionally, it mentions the need for documentation and validation evidence for GXP inspectors to review, especially in the context of large enterprise or MRP-II systems.", "excerpt_keywords": "computerised systems, reliability, software engineering, supplier audit, quality methodology"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf\n## 4.12\n\nin addition to the validation considerations, the inspector will also be concerned with assessing the basic operational controls, quality system, and security features for these systems, as indicated in the pic/s gmp annex 11 and amplified in the apv guidance, q.v. for a copy of the apv guidance, see gamp 4 appendix 09 (further reading ref: 15).\n\n## part two - implementation of system\n\n### 5. implementation of computerised systems\n\n### 5.1\n\nthe assurance of the reliability of a suppliers software products is attributable to the quality of the software engineering processes followed during development. this should include design, coding, verification testing, integration, and change control features of the development life cycle, (including after-sales support). in order for customers to have confidence in the reliability of the products, they should evaluate the quality methodology of the supplier for the design, construction, supply, and maintenance of the software. a formal, extensive review of the history of the supply company and the software package may be an option to consider where an additional degree of assurance of the reliability of the software is needed. this should be documented in a supplier audit report. prospective purchasers should consider any known limitations and problems for particular software packages or versions and the adequacy of any corrective actions by the supplier. appropriate, comprehensive documented customer acceptance testing should support the final selection of the software package. errors often come to light after implementation, and it is important for the supplier to advise/assist the customer concerning any problems and modifications to resolve errors. for so-called standard software packages and cots (as referenced in the gamp guide and commercial literature), it is important that purchasers are vigilant in maintaining reliable systems. this may include documented reviews of their own experiences, (e.g. log books and error reporting and resolution), from reading relevant literature or from interacting with application user groups to identify and resolve any serious problems. conclusions and recommendations from such activities should be recorded.\n\n### 5.2\n\nwhere the reliability and structural integrity of complex software products cannot be directly assessed, or completely evaluated, then it is even more important to assure that a good construction process has been used and has been properly documented. it is recognized that complex commercial proprietary applications can be extremely difficult to assess due to commercial secrecy and rivalry between suppliers, competing for market share. market. refer also to iso15504 (1998) information technology software process assessment and see gamp 4 appendix m2 guideline for supplier audit. a minority of suppliers are not responsive to requests for an audit. the need to perform a supplier audit should be linked to the regulated users risk assessment and quality assurance standards. the uk governments interdepartmental committee on software engineering (icse) and the real-time engineering group have referred to such software as soup (software of uncertain pedigree) (1999).", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "a36935ed-e2e8-4694-8ada-b99beb0e4b16": {"__data__": {"id_": "a36935ed-e2e8-4694-8ada-b99beb0e4b16", "embedding": null, "metadata": {"page_label": "11", "file_name": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_type": "application/pdf", "file_size": 453540, "creation_date": "2024-04-07", "last_modified_date": "2024-03-29", "document_title": "Quality Assurance and Auditing in Computerized System Validation: A Comprehensive Guide", "questions_this_excerpt_can_answer": "1. What are the three basic principles of quality assurance in software engineering as identified by a recent USFDA document, and how do they apply to the development of computerized systems in regulated environments?\n\n2. How does the document recommend handling the documentation and records for the design phase, implementation, and validation of computerized systems to ensure compliance with regulatory standards?\n\n3. What specific advice and guidance do the GAMP forum and PDA provide regarding the assessment of suppliers and software products in the context of GxP criticality and risks?", "prev_section_summary": "This section discusses the importance of assessing basic operational controls, quality systems, and security features of computerised systems in the pharmaceutical industry, referencing PIC/S GMP Annex 11 and APV guidance. It emphasizes the need for customers to evaluate the reliability of supplier's software products through quality methodology, supplier audits, and customer acceptance testing. The document also highlights the challenges in assessing complex software products and recommends following ISO15504 and GAMP 4 guidelines for supplier audits, especially for software of uncertain pedigree (SOUP). It stresses the importance of maintaining reliable systems and documenting reviews and recommendations for resolving any issues that may arise post-implementation.", "excerpt_keywords": "Quality Assurance, Computerized Systems, Software Engineering, Regulatory Standards, Supplier Assessment"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf\n## research plus focused quality system and product specific audits 7 of the suppliers by the regulated user (or by an accredited third party auditor) may be beneficial here. the business/gxp criticality and risks relating to the application will determine the nature and extent of any assessment of suppliers and software products. gamp forum and pda have provided advice and guidance in the gxp field on these matters.\n\n## 5.3\n\nat all times there is a need for complete and accurate documentation and records to cover all aspects of the design phase, implementation & validation of the computerised system(s). operating and reporting requirements for the important phases of the software development life cycle related qualifications and testing exercises and commissioning should be covered by comprehensive standard operating procedures or quality plans. the need for control and documentation of the development, implementation and operation of computer systems is extremely important for the validation of the system. there needs to be a strong emphasis on quality assurance in the development stages. it is fundamental for system life cycle documents to be controlled and maintained (version, audit trails as appropriate), within a quality assured document management system and available for inspection, if necessary. regulated users may choose to implement these requirements using either robust paper, electronic or hybrid systems.\n\n## 6. the structure and functions of the computer system(s)\n\n## 6.1\n\na recent usfda document 8 identifies three premises that constitute the basic principles of quality assurance, which apply to software engineering:\n\n- quality, safety and effectiveness must be designed and built into the software.\n- quality cannot be inspected or tested into the finished software.\n- each phase of the development process must be controlled to maximise the probability that the finished software meets all quality and design specifications.\n\n## 6.2\n\na computerised system is composed of the computer system and the controlled function or process. the computer system is composed of all computer hardware, firmware, installed devices, and software controlling the operation of9 the computer. the controlled function may be composed of equipment to be controlled and operating procedures that define the function of such equipment, or it may be an operation, which does not require equipment other than the hardware in the computer system. interfaces and networked functions through lan and wan are aspects of the computerised system and operating environment potentially linking a multitude of computers and applications. a firms gxp system environment, functionality and interactions with other system(s) needs to be clearly defined and controlled in respect of gmp annex.\n\naudits are not mandatory but are considered good practice, and it is for the regulated user to determine any auditing needs, scope and standards.\n\nfinal guidance for industry and fda staff: general principles of software validation, cdrh, january 2002 (further reading ref. 5).\n\ne.g. automated equipment and laboratory or process related instrumentation.\n\npi 011-3 page 7 of 50 25 september 2007", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "2ae5710b-b799-47bc-9d1e-e99133644de2": {"__data__": {"id_": "2ae5710b-b799-47bc-9d1e-e99133644de2", "embedding": null, "metadata": {"page_label": "12", "file_name": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_type": "application/pdf", "file_size": 453540, "creation_date": "2024-04-07", "last_modified_date": "2024-03-29", "document_title": "Enhancing Computerised System Security and Validation in Regulated User Organisations: A Comprehensive Guide", "questions_this_excerpt_can_answer": "1. What specific security and design measures are recommended for personal PC applications and internet/email/personal data filing systems to ensure the protection of GxP systems while allowing authorized users to control their desktop PCs?\n\n2. How does the document describe the relationship between software, hardware, and operating procedures and people within the operating environment of a computerised system, according to the schematic provided?\n\n3. What are the guidelines for regulated user organisations regarding the inventory, ownership, supplier/developer, functionality, links, and validation status of their computerised systems, as well as the requirements for a policy and validation master plan for these systems?", "prev_section_summary": "This section discusses the importance of quality assurance in computerized system validation, focusing on the three basic principles identified by a recent USFDA document. It emphasizes the need for complete and accurate documentation throughout the design, implementation, and validation phases of computerized systems. The section also touches on the structure and functions of computer systems, including the components of a computerized system and the importance of controlling and defining the system environment. Additionally, it mentions the guidance provided by the GAMP forum and PDA on assessing suppliers and software products in relation to GxP criticality and risks.", "excerpt_keywords": "Computerised systems, Security measures, Validation, Regulated user organisations, GxP systems"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf\n11 (4). it may be necessary to equip personal pc applications and internet/ e-mail/ personal data filing/ etc., with appropriate security and design measures to protect gxp systems whilst permitting authorised users to control the personal applications on their desktop pcs.\n\nfigure 1 schematic (below) identifies the relationship of the various components of a computerised system in its operating environment.\n\n|software|hardware|operating procedures and people|\n|---|---|---|\n|firmware|computer system (controlling system)|controlled function or process|\n|computerised system operating environment (including other networked, or standalone computerised systems, other systems, media, people, equipment and procedures)| | |\n\n6.3 a large variety of computer systems are used in regulated user organisations. these range from the simple standalone to large integrated and complex systems. for example, a significant proportion of programmable electronic systems and proprietary automated equipment for manufacturing, laboratory or clinical use, contains firmware with embedded software in place (for further details on firmware and embedded software refer to the glossary. also, see section 15.1 of this document for approaches to be taken with different systems. firmware and operating systems are usually qualified for the intended use (including version, release or related criteria) as part of performance qualification / process validation. regulated users should have an inventory of all their computerised systems, ownership, supplier/developer, functionality, links and validation status. a policy and validation master plan for computerised systems should also be available for inspection.\n\npi 011-3 page 8 of 50 25 september 2007", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "88a9d046-e41a-4247-ae8c-a0d02c781139": {"__data__": {"id_": "88a9d046-e41a-4247-ae8c-a0d02c781139", "embedding": null, "metadata": {"page_label": "13", "file_name": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_type": "application/pdf", "file_size": 453540, "creation_date": "2024-04-07", "last_modified_date": "2024-03-29", "document_title": "Quality Assurance and Validation of Computerized Systems in Regulated Environments: A Comprehensive Guide", "questions_this_excerpt_can_answer": "1. What specific ISO standards and guidelines are recommended for ensuring quality assurance and reliability in the design, development, production, installation, and servicing of computerized systems within regulated environments, as outlined in the document \"Quality Assurance and Validation of Computerized Systems in Regulated Environments: A Comprehensive Guide\"?\n\n2. How does the document \"Quality Assurance and Validation of Computerized Systems in Regulated Environments: A Comprehensive Guide\" suggest regulated users should structure their Validation Master Plan (VMP) to address the validation of computerized systems, including the identification of systems subject to validation and the definition of validation strategies and protocols?\n\n3. What are the specific responsibilities and management practices recommended for regulated users in the specification, purchase, development, and implementation of computerized systems that impact GxP requirements, as detailed in the document \"Quality Assurance and Validation of Computerized Systems in Regulated Environments: A Comprehensive Guide\"?", "prev_section_summary": "The section discusses the importance of implementing security and design measures for personal PC applications and internet/email/personal data filing systems to protect GxP systems while allowing authorized users to control their desktop PCs. It also describes the relationship between software, hardware, operating procedures, and people within the operating environment of a computerized system. Additionally, it outlines guidelines for regulated user organizations regarding the inventory, ownership, supplier/developer, functionality, links, and validation status of their computerized systems, as well as the requirements for a policy and validation master plan for these systems. The section emphasizes the need for qualified firmware and operating systems for different computer systems used in regulated user organizations and the importance of having a comprehensive inventory and validation plan in place.", "excerpt_keywords": "Quality Assurance, Validation, Computerized Systems, Regulated Environments, ISO Standards"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf\n## planning and life-cycle management\n\n7.1 a high level of assurance of quality and reliability cannot be attributed to a computerised system based simply on a series of tests solely designed to confirm the correct function of the software and its interaction with hardware. there needs to be a formal planned approach by the developer to assure that quality is built into the product. iso 9001 provides a quality system model for quality assurance in design, development, production, installation and servicing. the objective of testing during software development at the supplier should be to try to break the structural integrity of the software and find any weaknesses through a rigorous testing regime. audits of suppliers conducted by or on behalf of regulated users should cover these issues when project related risk analyses deem it to be necessary.\n\n7.2 iso/iec 12207:1995 provides guidance on acceptable practices for information technology - software life cycle processes and iso 9004, iso 10005 and iso 10007 provide guidance on quality management and system elements, including quality plans and configuration management. ieee 1298 is specific and prescriptive on what should be addressed in planning. iso 9126 concerns software quality and defines the quality attributes for critical applications. the gamp guide also provides relevant guidance for the pharmaceutical sector.\n\n7.3 it would be expected that the regulated users validation policy or validation master plan (vmp) should identify the companys approach to validation and its overall philosophy with respect to computerised systems. the vmp should:\n\n- identify which computerised systems are subject to validation.\n- provide brief descriptions of the validation strategies for different categories of computerised systems as well as other validation activities.\n- outline protocols and related test procedures for all validation activities including computer systems.\n- define reporting requirements to document validation exercises and related results.\n- identify key personnel and their responsibilities as part of the validation program.\n\n## management and responsibilities\n\n8.1 it is important for a regulated user to have in place a comprehensive policy and procedures for the specification, purchase, development and implementation of computerised systems. ideally these procedures would cover all computerised systems; this pic/s document will only concern itself with those systems that have an impact on gxp requirements.\n\nrefer to gmp annex 15 for more details concerning the vmp requirements. it may be appropriate to refer to established policies, sops or individual validation plans to meet these requirements.", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "54d2df81-ab80-4b70-9fb3-6e9f2a9aea01": {"__data__": {"id_": "54d2df81-ab80-4b70-9fb3-6e9f2a9aea01", "embedding": null, "metadata": {"page_label": "14", "file_name": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_type": "application/pdf", "file_size": 453540, "creation_date": "2024-04-07", "last_modified_date": "2024-03-29", "document_title": "Project Management and Quality Assurance in Computerised Systems: A Comprehensive Guide", "questions_this_excerpt_can_answer": "1. What specific industry standards and forums does the document recommend for regulated users to ensure their suppliers' management policies and systems meet quality, performance, and reliability objectives in the context of computerised systems?\n\n2. According to the document, what factors determine the scope and level of documentation and records required for project management of critical computerised systems?\n\n3. What specific guidance does the document refer to for adopting comprehensive controls and measures for information security management within the context of computerised systems in regulated environments?", "prev_section_summary": "The section discusses the importance of planning and life-cycle management for computerized systems in regulated environments. It emphasizes the need for a formal planned approach to assure quality is built into the product, with references to ISO standards such as ISO 9001, ISO/IEC 12207, ISO 9004, ISO 10005, and ISO 10007. The section also highlights the significance of a Validation Master Plan (VMP) to address the validation of computerized systems, including identifying systems subject to validation, defining validation strategies and protocols, and outlining reporting requirements. Additionally, it outlines the specific responsibilities and management practices recommended for regulated users in the specification, purchase, development, and implementation of computerized systems that impact GxP requirements.", "excerpt_keywords": "project management, quality assurance, computerised systems, information security management, documentation and records"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf\n## 8.2\n\nthe organisation should regard disciplines related to the introduction of a computerised system as in accord with the basic principles of project management. achieving the quality, performance and reliability objectives for any project requires competence in engineering and design. where regulated users do not have the resources for engineering and design within their own organisation, there is a heavy reliance on the supplying companys resources.\n\n## 8.3\n\nto satisfy the quality, performance and reliability objectives, the regulated user needs to assure that the suppliers management policies; systems and related procedures will achieve the desired objectives. enlightened suppliers should provide such evidence and added value to all customers, whether large or small, through the recognition of industry standards from gamp forum, supplier forum, pda, ispe, etc., and also through shared audits, user groups, and product certification arrangements.\n\n## 8.4\n\nit is important to acknowledge that the scope and level of documentation and records needed to formalise and satisfy basic project management requirements for critical systems will be dependent upon:\n\n- the complexity of the system and variables relating to quality and performance;\n- the need to ensure data integrity;\n- the level of risk associated with its operation;\n- the gxp impact areas involved.\n\n## 8.5\n\nwithin the regulated user organisation there should be clearly defined responsibilities for the management of all ict products, computerised systems and projects. management should cover the full spectrum, from simple input/output devices and programmable logic controllers (plcs) through to integrated supervisory or information systems and business management levels. these responsibilities should involve development and administration of policies on purchase of it products, as well as the introduction, commissioning and maintenance of it products. the responsibilities should extend to development and implementation of formal monitoring, auditing and servicing of each system and designate the related documentation and records for such activities.\n\n## 8.6\n\nbs 7799: 1999, is issued in two parts (part 1: code of practice for information security management, and part 2: specification for information security management systems) and provides recommended guidance on a comprehensive set of controls comprising best practices in information security. these controls and measures (or the equivalent) are recommended for adoption within this pic/s guidance. they will assist in drafting the internal control standards and procedures to be implemented by it management and administration departments.\n\nict = information and communications technology\n\nrelevant recent guidance is also provided in iso/iec17799:2000 on information technology - \"code of practice for information security management\" and also in the pre-amble to fdas 21 cfr part 11.\n\npi 011-3 page 10 of 50 25 september 2007", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "b8da9af6-3f20-47b7-acb3-82a93ba1d026": {"__data__": {"id_": "b8da9af6-3f20-47b7-acb3-82a93ba1d026", "embedding": null, "metadata": {"page_label": "15", "file_name": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_type": "application/pdf", "file_size": 453540, "creation_date": "2024-04-07", "last_modified_date": "2024-03-29", "document_title": "Regulated Environment Documentation: User Requirement Specifications (URS) and System Control Documentation", "questions_this_excerpt_can_answer": "1. What are the key components that should be included in the User Requirement Specifications (URS) for a computerised system within a regulated environment, according to the document \"Regulated Environment Documentation: User Requirement Specifications (URS) and System Control Documentation\"?\n\n2. How does the document \"Regulated Environment Documentation: User Requirement Specifications (URS) and System Control Documentation\" suggest handling the development and maintenance documentation for large complex systems within a regulated environment?\n\n3. What criteria does the document \"Regulated Environment Documentation: User Requirement Specifications (URS) and System Control Documentation\" outline for the URS to ensure they meet GxP expectations and are capable of being verified objectively?", "prev_section_summary": "The section discusses the importance of project management principles in introducing computerised systems to achieve quality, performance, and reliability objectives. It emphasizes the need for regulated users to ensure that suppliers' management policies and systems meet industry standards from forums such as GAMP, PDA, ISPE, etc. The level of documentation and records required for project management of critical systems depends on factors like system complexity, data integrity, risk, and GxP impact areas. Responsibilities for managing ICT products and computerised systems within an organization are outlined, including the development of policies, monitoring, auditing, and servicing. The section also recommends adopting controls and measures from standards like BS 7799 and ISO/IEC 17799 for information security management within the context of computerised systems in regulated environments.", "excerpt_keywords": "Regulated Environment, User Requirement Specifications, System Control Documentation, GxP Expectations, Computerised Systems"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf\n## user requirement specifications (urs)\n\n9.1 when utilising a computerised system within a regulated environment it is appropriate to establish system control documentation or a system description, [e.g. as required by gmp annex 11(4)], giving a written detailed description of the system, also covering development and maintenance. this system control document may include a record of, or a reference to, the documented user requirement specifications (urs), or other life-cycle documents. it should also be the definitive statement of what the system must or must not do. this document is also important for legacy systems and those systems under development.\n\n9.2 when properly documented, the urs should be complete, realistic, definitive and testable. establishment and agreement to the requirements for the software is of paramount importance. requirements also need to define non-software (e.g. sops) and hardware.\n\n9.3 \"user requirement specifications\", (urs), requirements should satisfy the following criteria:\n\n- each requirement document should be reviewed, authorised and uniquely catalogued.\n- there should be no conflict between requirements.\n- each requirement, particularly those to be met to satisfy gxp expectations, should be specified in a manner such that compliance with the requirements is capable of being verified objectively by an authorised method, e.g. inspection, analysis or test.\n- the urs, although independent of the supplier should be understood and agreed by both user and supplier. there should be a clear distinction between mandatory regulatory requirements and optional features.\n- the urs should contain functional and non-functional requirements: functionality, effectiveness, maintainability, usability, etc. requirements should be objectively verifiable.\n\nlinked, approved system life-cycle records may very well meet the requirements for the system control documentation/system description. development and maintenance information may often be held in separate (referenced) documents for large complex systems. risk assessment in the urs phase also needs to be addressed.\n\nnote: this is straightforward for a bespoke system. however, for marketed proprietary systems or configurable packages then it is for prospective users, integrators and suppliers to discuss and review proposed user requirements, versus package functionality. it is essential to determine the degree of fit and then control any necessary configuration work, modification, coding, testing and validation requirements in line with this guidance. when choosing a standard product or component, the urs may be developed compiling required features from the suppliers specifications.\n\npi 011-3 page 11 of 50 25 september 2007", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "f1ecb6f8-1092-43ce-9dba-8488ee42abec": {"__data__": {"id_": "f1ecb6f8-1092-43ce-9dba-8488ee42abec", "embedding": null, "metadata": {"page_label": "16", "file_name": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_type": "application/pdf", "file_size": 453540, "creation_date": "2024-04-07", "last_modified_date": "2024-03-29", "document_title": "Evaluation, Validation, and Functional Specification of Computerized Systems", "questions_this_excerpt_can_answer": "1. How does the document recommend identifying the GxP requirements covered by a computerized system during the evaluation of the URS and functional specifications?\n \n2. What does the document specify about the necessity and process for re-qualification and revalidation of computerized systems in response to modifications, enhancements, integration, or regulatory requirements?\n\n3. According to the document, how should the regulated user document the computer system(s) in the context of the EU's GMP Annex 11 requirements, and what specific types of schematics or diagrams are suggested to align with the functional specification and be traceable to the URS?", "prev_section_summary": "The section discusses the importance of User Requirement Specifications (URS) for computerized systems in regulated environments. It emphasizes the need for complete, realistic, definitive, and testable requirements that are reviewed, authorized, and cataloged. The document outlines criteria for URS to meet GxP expectations and be objectively verifiable. It also mentions the importance of system control documentation, development and maintenance information, and risk assessment in the URS phase. Additionally, it highlights the need for clear communication and agreement between users and suppliers, as well as the distinction between mandatory regulatory requirements and optional features.", "excerpt_keywords": "Evaluation, Validation, Functional Specification, Computerized Systems, GxP Requirements"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf\n## 9.4 evaluation of the urs and functional specifications\n\nthe evaluation of the urs and the functional specifications should allow identification of the gxp requirements covered by the system. additionally, the urs will provide information on important interfaces between the system and manual operations. the urs should also form the basis for a risk assessment of the system for gxp compliance requirements and other risks such as safety. the risk analysis may be based on the fs related to the urs for bespoke systems. the risk assessment results, including reasons for ranking as critical or not critical, should be documented. the nature of any gxp risks should be clearly stated.\n\n## 9.5 prospective validation or qualification\n\nall computerized systems should undergo documented prospective validation or qualification. refer to section 15 for validation strategies for different software and systems categories. as user systems evolve through modification, enhancement, integration, and in response to regulatory requirements, additional re-qualification and revalidation work on existing systems may be necessary. the urs and system description document should be updated accordingly as validation life cycle evidence. figure 2 shows the relationship between urs and performance qualification (pq).\n\n## 10. functional specifications (fs)\n\nfrom the urs, the supplier (including in-house developers) of the software can develop functional specifications for bespoke programs or identify functional specifications for off-the-shelf systems. the functional specifications should define a system to meet the urs, i.e., the customers needs. they should provide a precise and detailed description of essential requirements, functions, performances, design constraints, and attributes. for certain systems, a combined urs and fs may be appropriate. further details on validation strategies for different software categories are provided in section 14.\n\nthe regulated user should provide documentation describing the computer system(s), including logic flow or block diagrams where practical, hardware layout, networks, and interaction. these schematics should align with the functional specification and be traceable to the urs. in the eu, this information is typically held within the controlled system description document required by gmp annex 11.\n\nrisk assessments and analyses are useful at various stages during the system life-cycle, not just for the fs or urs (refer to gamp 4 m3).", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "0c65ded1-be58-481c-baab-1bf1fdf02c01": {"__data__": {"id_": "0c65ded1-be58-481c-baab-1bf1fdf02c01", "embedding": null, "metadata": {"page_label": "17", "file_name": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_type": "application/pdf", "file_size": 453540, "creation_date": "2024-04-07", "last_modified_date": "2024-03-29", "document_title": "Quality Management and Software Development in Regulated Environments: Best Practices and Guidelines", "questions_this_excerpt_can_answer": "1. What are the key specification and qualification elements involved in the development and production of software and hardware for computer systems as outlined in the document \"Quality Management and Software Development in Regulated Environments: Best Practices and Guidelines\"?\n\n2. How does the document \"Quality Management and Software Development in Regulated Environments: Best Practices and Guidelines\" describe the importance of quality controls, quality assurance procedures, documentation, and records in the context of software and hardware development for computer systems?\n\n3. What specific models for software development does the document \"Quality Management and Software Development in Regulated Environments: Best Practices and Guidelines\" mention, and how does it position the GAMP guide's adoption of the \"V\" framework in relation to these models?", "prev_section_summary": "This section discusses the evaluation of User Requirement Specifications (URS) and Functional Specifications (FS) for computerized systems, the importance of identifying GxP requirements, conducting risk assessments, and the necessity for validation and re-qualification of systems. It also emphasizes the need for documentation of computer systems, including logic flow diagrams, hardware layout, and networks, in alignment with the functional specification and traceable to the URS. The section highlights the relationship between URS and Performance Qualification (PQ) and provides guidance on validation strategies for different software categories. Additionally, it mentions the requirements of the EU's GMP Annex 11 for documenting computer systems.", "excerpt_keywords": "Quality Management, Software Development, Regulated Environments, GAMP Guide, Validation Strategies"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf\n## suppliers, software developers and quality management\n\nfigure 2 below maps the relationships between the key specification and qualification elements as the system is specified, designed, built and tested.\n\n|user requirements|specification|verifies|pq|\n|---|---|---|---|\n|functional specification|verifies|oq| |\n|design specifications|verifies|iq| |\n|system build| | | |\n\nfigure 2. basic framework for specification and qualification (based on figure 6.220 of gamp-4)\n\n### 11.1\n\nthe quality controls and quality assurance procedures, documentation and records related to the development and production of the software and hardware for computer systems are of critical importance. there are a number of accepted models for software development, e.g. the spiral model of development, the waterfall model and the life cycle model. all models have their own special attributes. as an example the gamp guide adopts, but does not mandate a \"v\" framework (see figure 2 above). (note: the urs and fs may be combined for smaller projects. these are related to the oq.)\n\n### 11.2\n\nsupplier and developer reputations and trading histories for the software product provide some guidance to the level of reliability that may be assigned to the product supplied. the pharmaceutical regulated user therefore should have in place procedures and records that indicated how and on what basis suppliers were selected.\n\n### 11.3\n\ncompliance with a recognised quality management system (qms) may provide the regulated user and regulatory agencies with the desired confidence in the structural integrity, operational reliability and on-going support for software and hardware products utilised in the system. the accreditation assessment schedule and scope of certification needs to be relevant to the nature of the proposed application. structural integrity and the application of good software and hardware engineering practices are important for critical systems.\n\n20 this is an example only. regulated users would be expected to comment on their own particular model. they should also interpret and define the relationships between various life-cycle elements as appropriate.\n\npi 011-3 page 13 of 50 25 september 2007", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "0b56eba7-7f0c-499f-a5df-fd4cc886fa7a": {"__data__": {"id_": "0b56eba7-7f0c-499f-a5df-fd4cc886fa7a", "embedding": null, "metadata": {"page_label": "18", "file_name": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_type": "application/pdf", "file_size": 453540, "creation_date": "2024-04-07", "last_modified_date": "2024-03-29", "document_title": "Quality Management Systems and Software Standards in Critical Systems Development: A Comprehensive Guide", "questions_this_excerpt_can_answer": "1. What specific certifications and standards are recommended for ensuring the structural integrity of software and hardware development methodologies within the context of Quality Management Systems in critical systems development, as outlined in the document?\n\n2. How does the document suggest regulated users should proceed when a supplier's Quality Management System (QMS) and recognized certifications are deemed inadequate or inappropriate for critical systems, especially in the pharmaceutical sector?\n\n3. What are the key features and requirements outlined by ISO 9001, ISO 9126, and IEEE 1298 standards regarding the development, testing, and documentation for software design, production, and installation, as mentioned in the document?", "prev_section_summary": "The section discusses the key specification and qualification elements involved in the development and production of software and hardware for computer systems, emphasizing the importance of quality controls, quality assurance procedures, documentation, and records. It mentions different models for software development such as the spiral model, waterfall model, and life cycle model, with the GAMP guide adopting a \"V\" framework. The section also highlights the significance of supplier and developer reputations, selection procedures, compliance with quality management systems, and the structural integrity and operational reliability of software and hardware products in regulated environments.", "excerpt_keywords": "Quality Management Systems, Software Standards, Critical Systems Development, ISO 9001, GAMP Guide"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf\n## 11.4\n\nconfidence in the structural integrity may be based to some extent on the recognition of relevant certification of a companys software and hardware development methodology and qms to iso 9001 standard, such as (for example) tickit certification and utilization of iso 9000 related guidance. however, it is essential that the assessment scope and schedules applied by the certifying auditors for these schemes should cover the engineering quality standards, actual practices, controls and records in place including non-conforming product (error feedback from the market), corrective actions, change management and so forth for particular products and versions. these can be very useful benchmarks for the design engineering, replication and maintenance standards in place at suppliers of large proprietary packages and can assist pharmaceutical clients with short listing and selection criteria.\n\n## 11.5\n\nhowever, an assessment of the suppliers qms and recognized certification alone is unlikely to be the final arbiter for critical systems. the certification may very well be inadequate, or inappropriate. in such cases, the regulated user may wish to consider additional means of assessing fitness for purpose against predetermined requirements, specifications and anticipated risks. techniques such as supplier questionnaires, (shared) supplier audits and interaction with user and sector focus groups can be helpful. this may also include the specific conformity assessment of existing, as well as bespoke software and hardware products. gamp and pda guideline documents identify a need to audit suppliers for systems carrying a high risk and have detailed guidance on supplier auditing procedures/options.\n\n## 11.6\n\nappendix o9 of the gamp 4 guide incorporates an independent commentary on pic/s gmp annex 11 and provides specific advice on quality and operational matters to help ensure compliance with the pic/s and eu gmp. users and suppliers need to ensure that software, hardware and systems are:\n\n- quality assured;\n- fit for their intended purpose; and\n- supported by appropriate documentation for quality and validation traceability.\n\n## 12. important qms and software standards attributes\n\n## 12.1\n\nthe standards iso 9001, iso 9126 & ieee 1298 have a number of important features that can be summarized in the following points:\n\n- they are structured around a qms approach to the development, testing and documentation for software design, production and installation.\n- compliance with the standard requires formal systems for control, traceability and accountability of product(s) and personnel.\n- the standard outlines the features and requirements of a life cycle approach to software production (\"manufacture\"), with emphasis on the importance of a change control procedure.\n- the need for, and importance of, testing of software product/s is identified by the standard as it requires a tiered approach to testing and identifies three levels of testing for software:", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "432d1d2a-9cf2-4430-8401-cfc1bd4ff098": {"__data__": {"id_": "432d1d2a-9cf2-4430-8401-cfc1bd4ff098", "embedding": null, "metadata": {"page_label": "19", "file_name": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_type": "application/pdf", "file_size": 453540, "creation_date": "2024-04-07", "last_modified_date": "2024-03-29", "document_title": "Software Quality Management and Testing Practices in the GAMP Guide: A Comprehensive Overview", "questions_this_excerpt_can_answer": "1. What specific software testing methodologies and standards are recommended by the GAMP guide for ensuring the reliability of software in the context of quality management systems?\n \n2. How does the document describe the role of management commitment and quality assurance disciplines in the development, production, and installation of software products within a quality management system (QMS) approach?\n\n3. What advantages does the document outline for conducting code reviews (walk-throughs) before formal unit code testing in the software development process, and how does this practice impact the cost and efficiency of error correction?", "prev_section_summary": "The section discusses the importance of certifications and standards in ensuring the structural integrity of software and hardware development methodologies within Quality Management Systems in critical systems development. It highlights the need for assessing suppliers' Quality Management Systems and certifications, and suggests additional means of assessing fitness for purpose. The section also outlines the key features and requirements of ISO 9001, ISO 9126, and IEEE 1298 standards in software design, production, and installation, emphasizing the importance of quality assurance, fitness for purpose, and appropriate documentation for validation traceability.", "excerpt_keywords": "Software Quality Management, Testing Practices, GAMP Guide, Quality Assurance, Code Reviews"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf\nunit code testing;\n\nintegrated module testing; and\n\ncustomer acceptance testing.\n\nthe gamp guide is also widely used as an industry standard of relevance here.\n\n## 12.2\n\nthere are a number of advantages in organisations utilising a qms approach for development and changes to software product. it would be expected that this approach if utilised by developers and producers of software should ensure (within the limitations of the quality management system approach) the following:\n\n- management commitment to quality and design control by instituting systems for quality control, documentation and quality assurance.\n- development, production and installation based on quality plans, verified by quality records. the qms requires development, testing and programming standards.\n- adherence to quality assurance disciplines such as internal audits of the processes, corrective & preventative action procedures and control of non-conforming product.\n- qms methodology to establish requirements for purchased testing(subcontracted) software product.\n\n## 13. testing\n\n## 13.1\n\nassurance of reliability of software is achieved by execution of quality plans and testing during the software development process. this involves unit code testing and integration testing in accordance with the principles of iso 12207, ieee 1298 and ieee 829 software test documentation. see also the corresponding sections in the gamp guide. the development and testing of hardware and software should be done under a quality assurance system, documented and formally agreed between the various parties. this can ultimately provide evidence in support of gxp quality compliance (e.g. annex 11(5)). locations and responsibilities for testing (depending on the category of the software and system) are outlined in the gamp guide, qv.\n\n## 13.2\n\none of the most critical aspects of development of software is the integration testing phase where individual elements of software code (and hardware, where applicable), are combined and tested during or prior to this stage until the entire system has been integrated. extra benefits may be achieved by code walk-throughs including evaluation of critical algorithms and/or routines, prior to testing. errors found at the integration testing phase are much cheaper to correct than errors found at a later stage of testing. code review (walk-through) is best done as early in the process as possible, preferably before submitting a module to test. code reviews are best performed before formal unit code testing (i.e. before a unit or module is frozen and enters formal testing).\n\nthis testing is defined as verification of the software element. verification is defined as the process of determining whether or not the products of a given phase of the software development cycle fulfil the requirements established during the previous phase.\n\npi 011-3 page 15 of 50 25 september 2007", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "1911d2ef-e196-47a4-b88f-ed6118842f0a": {"__data__": {"id_": "1911d2ef-e196-47a4-b88f-ed6118842f0a", "embedding": null, "metadata": {"page_label": "20", "file_name": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_type": "application/pdf", "file_size": 453540, "creation_date": "2024-04-07", "last_modified_date": "2024-03-29", "document_title": "Validation and Assurance of Computerised Systems in GxP Environment: A Comprehensive Guide", "questions_this_excerpt_can_answer": "1. What specific types of testing are recommended for simpler GxP systems, such as PLCs and systems based on basic algorithms or logic sets, to ensure their reliability within a GxP environment?\n \n2. How should test scripts be developed and utilized to confirm the design validation of computerised systems in the context of GxP compliance, and how should these scripts relate to user requirements and functional specifications?\n\n3. What approach is suggested for validating computerised systems that control or are related to processing equipment and activities within a GxP environment, including the integration of IQ, OQ, and PQ testing regimes?", "prev_section_summary": "This section discusses software quality management and testing practices in the context of the GAMP guide. Key topics include software testing methodologies, management commitment, quality assurance disciplines, code reviews, unit code testing, integrated module testing, customer acceptance testing, and the importance of a quality management system (QMS) approach. The section emphasizes the importance of adherence to quality standards, documentation, and quality assurance processes in software development. It also highlights the benefits of conducting code reviews before formal unit code testing to improve efficiency and reduce costs in error correction.", "excerpt_keywords": "Validation, Computerised Systems, GxP, Testing, Quality Management"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf\n### 13.3\n\nfor some simpler gxp systems, for example certain plcs and systems based on basic algorithms or logic sets, the functional testing may provide adequate assurance of reliability of the computerised system. for critical and/or more complex systems the verification testing that is conducted at the iq, oq & pq stages provides only a limited level of assurance that the system does what it purports to do, reliably. this level of testing provides only limited assurance of the operation and reliability of hidden functions and code. for complex systems there should also be a high level of assurance that the development of the software has ensured delivery and operation of a quality product that is structurally sound, clearly defined and controlled.\n\n### 13.4\n\ntest scripts should be developed, formally documented and used to demonstrate that the system has been installed, and is operating and performing satisfactorily. these test scripts should be related to the user requirements specifications and the functional specifications for the system. this schedule of testing should be specifically aimed at demonstrating the validation of the system. in software engineering terms satisfactory results obtained from the testing should confirm design validation.\n\n### 13.5\n\nany processing equipment and activities related to or controlled by the computer system would require additional iq, oq and pq testing regimes. it may be appropriate to combine test phases and test scopes for a group of equipment or activities, and this should be defined in a test plan or strategy.\n\n### 13.6\n\nregulated users should be able to demonstrate formal acceptance of systems after testing and controlled transfer into the live operational environment.\n\n### 14. validation strategies and priorities\n\n### 14.1\n\nregulated users need to be able to provide evidence for their computerised systems to demonstrate their range, complexity, functionality, control and validation status.\n\n### 14.2\n\nfor the validation of computerised systems there should be a system in place that assures the formal assessment and reporting of quality and performance measures for all the life-cycle stages of software and system development, its implementation, qualification and acceptance, operation, modification, re-qualification, maintenance and retirement. this should enable both the regulated user, and competent authority, to have a high level of confidence in the integrity of both the processes executed within the controlling computer system(s) and in those processes controlled by and/or linked to the computer.\n\n22 the supplier/developer should draft test scripts according to the project quality plan to verify performance to the functional specifications. the scripts should stress test the structural integrity, critical algorithms and boundary value aspects of the integrated software. the test scripts related to the user requirements specification are the responsibility of the regulated users.\n\n23 tools and controls within the qms, such as audits, change controls, configuration management and continuous improvement programmes may feature here.\n\npi 011-3 page 16 of 50 25 september 2007", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "f6a56897-9a7b-4991-ae21-97fb4c7c0937": {"__data__": {"id_": "f6a56897-9a7b-4991-ae21-97fb4c7c0937", "embedding": null, "metadata": {"page_label": "21", "file_name": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_type": "application/pdf", "file_size": 453540, "creation_date": "2024-04-07", "last_modified_date": "2024-03-29", "document_title": "Validation and Compliance of Computerised Systems in GxP Environments: A Comprehensive Guide", "questions_this_excerpt_can_answer": "1. What are the key components that need to be included in a consolidated written validation program for computerised systems in GxP environments, as recommended in the document?\n \n2. How does the document suggest prioritizing computerised systems and their features for validation based on their potential impact on product/process quality and data integrity in GxP environments?\n\n3. What specific aspects and activities related to computerised systems does the document identify as essential for demonstrating GxP compliance evidence?", "prev_section_summary": "This section discusses the validation and assurance of computerized systems in a GxP environment. Key topics include the types of testing recommended for simpler GxP systems, the development and utilization of test scripts for design validation, and the approach for validating systems related to processing equipment. The section emphasizes the importance of formal testing, documentation, and assurance of system reliability and quality throughout the software development life cycle. Entities mentioned include PLCs, test scripts, user requirements specifications, functional specifications, IQ, OQ, PQ testing regimes, regulated users, and supplier/developer responsibilities.", "excerpt_keywords": "Validation, Compliance, Computerised Systems, GxP Environments, Risk Analysis"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf\n## 14.3\n\nthe regulated users range of computerised systems needs to be formally listed in an inventory and the scope/extent of validation for each detailed in a consolidated written validation programme. validation scope should include gxp compliance criteria, ranked for product/process quality and data integrity risk criticality, should the system fail or malfunction. this process represents one of the most important pre-requisites of validation master planning (see pic/s doc. pi 006), in that it is essential to assign priorities and attention to those systems (and features within systems) that represent the highest potential for disaster, should they malfunction or become inoperative. the risk analyses and the results, together with reasoning for critical or non-critical classifications, should be documented. risks potentially impacting on gxp compliance should be clearly identified. there are a number of techniques to help identify and analyse risks and to select risk reduction and control measures. for further information refer to the gamp guide appendix and the gamp forum special interest group paper on functional risk assessment.\n\n## 14.4\n\ngxp compliance evidence is essential for the following aspects and activities related to computerised systems:\n\n- data input (capture and integrity), data filing, data-processing, networks, process control and monitoring, electronic records, archiving, retrieval, printing, access, change management, audit trails and decisions associated with any automated gxp related activity;\n- in this context, examples of gxp related activities might include: regulatory submissions, r&d, clinical trials, procurement, dispensing/weighing, manufacturing, assembly, testing, quality control, quality assurance, inventory control, storage and distribution, training, calibration, maintenance, contracts/technical agreements and associated records and reports.\n\n## 14.5\n\nhistorically, these systems have relied on manual systems, some electro-mechanical controls and paper-based documentation. the introduction of computerised systems does not diminish the need for compliance with gxp requirements and guidelines.\n\n24 the italicised-bold part of this definition should be interpreted as requiring controlled documented methodology and records based on best compliance practices. this is to ensure that firms have generated documented evidence (electronic and/or paper-based), that gives a high level of assurance that both the computer system and the computerised system, will consistently perform as specified, designed, implemented and validated. related validation dossiers for complex integrated projects should be clearly cross-linked for audit purposes.\n\nthe scope or extent of validation for each system can be detailed in individual validation plans. a hierarchy of linked validation plans may be appropriate as outlined in gamp 4 guidance appendix m1: guideline for validation planning.\n\nthese examples are intended to be illustrative, not exhaustive.", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "5f968704-cb25-4d0c-8a8a-6791178eb2a0": {"__data__": {"id_": "5f968704-cb25-4d0c-8a8a-6791178eb2a0", "embedding": null, "metadata": {"page_label": "22", "file_name": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_type": "application/pdf", "file_size": 453540, "creation_date": "2024-04-07", "last_modified_date": "2024-03-29", "document_title": "GAMP Supplier Guide: Validation Approach for Software Products", "questions_this_excerpt_can_answer": "1. What specific guidance does the GAMP Supplier Guide offer to suppliers of software in the pharmaceutical industry regarding the validation approach for different categories of software products?\n\n2. How does the GAMP Supplier Guide suggest handling the validation of firmware, particularly distinguishing between non-configurable and configurable firmware, in the context of automated manufacturing practices?\n\n3. According to the GAMP Supplier Guide, what are the recommended actions for validating custom (bespoke) software used in the pharmaceutical industry, and how does this differ from the approach for standard and configurable software packages?", "prev_section_summary": "The section discusses the importance of listing computerised systems in an inventory and creating a consolidated written validation program for each system in GxP environments. It emphasizes the need to prioritize systems based on their potential impact on product/process quality and data integrity. The document also highlights the essential aspects and activities related to computerised systems for demonstrating GxP compliance evidence, such as data input, processing, electronic records, and audit trails. It stresses the continued importance of compliance with GxP requirements even with the introduction of computerised systems. The section also mentions the need for controlled documented methodology and records to ensure consistent performance of computer systems.", "excerpt_keywords": "GAMP Supplier Guide, Validation Approach, Software Products, Firmware, Custom Software"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf\n## 14.6 the current good automated manufacturing practice (gamp) supplier guide\n\nthe current good automated manufacturing practice (gamp) supplier guide provides essential guidance to suppliers of software to the industry. the guide also provides a concise explanation of the interrelationship between various stages of software development and the requirements for installation, operational & performance qualification. the gamp guide identifies five different categories of software.\n\n## 15. gamp validation approach based on different categories of software products\n\nthe gamp guide may be referred to as appropriate for detailed guidance both in the core project management section, the quality narrative and the specific appendices. the following are category summaries from gamp 4:\n\n|category|software type|validation approach|\n|---|---|---|\n|1|operating system|record version (including service pack). the operating system will be challenged indirectly by the functional testing of the application.|\n|2|firmware|for non-configurable firmware record version. calibrate instruments as necessary. verify operation against user requirements. for configurable firmware record version and configuration. calibrate instruments as necessary and verify operation against user requirements. manage custom (bespoke) firmware as category 5 software.|\n|3|standard software packages|record version (and configuration of environment) and verify operation against user requirements. consider auditing the supplier for critical and complex applications.|\n|4|configurable software packages|record version and configuration, and verify operation against user requirements. normally audit the supplier for critical and complex applications. manage any custom (bespoke) programming as category 5.|\n|5|custom (bespoke) software|audit supplier and validate complete system.|\n\nreproduced from the gamp 4 guide (with permission) appendix m4\n\npi 011-3 software page 18 of 50 25 september 2007", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "1b61caa5-53ec-406d-8e50-f0f17f93fca0": {"__data__": {"id_": "1b61caa5-53ec-406d-8e50-f0f17f93fca0", "embedding": null, "metadata": {"page_label": "23", "file_name": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_type": "application/pdf", "file_size": 453540, "creation_date": "2024-04-07", "last_modified_date": "2024-03-29", "document_title": "Validation and Documentation Requirements for Computerised Systems", "questions_this_excerpt_can_answer": "1. How does the document recommend handling the validation of complex integrated computerised systems that span multiple GAMP category levels, and what approach is suggested for systems that do not fit readily into predefined categories?\n \n2. What specific types of documentation and records are identified as necessary to support the validation exercise of a computerised system, particularly in relation to ongoing evaluation and system maintenance?\n\n3. What stance does the document take on retrospective validation for existing computerised systems that have been inadequately documented for validation purposes, and what steps are suggested for firms to justify the continued use of such systems?", "prev_section_summary": "The section discusses the GAMP Supplier Guide and its guidance for suppliers of software in the pharmaceutical industry regarding the validation approach for different categories of software products. It outlines the five categories of software identified by the guide and provides validation approaches for each category, including operating systems, firmware (both non-configurable and configurable), standard software packages, configurable software packages, and custom (bespoke) software. The section emphasizes the importance of auditing suppliers and validating complete systems for custom software. Key entities mentioned include the GAMP Supplier Guide, software categories, validation approaches, operating systems, firmware, standard software packages, configurable software packages, and custom software.", "excerpt_keywords": "Validation, Computerised Systems, GAMP, Documentation, Retrospective Validation"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf\n## 15.2\n\nhowever, this pre-defined category approach may be difficult to apply to complex integrated computerised systems where different gamp category levels are effectively combined. many systems span the category levels. for all critical systems a holistic risk-based approach is necessary. this should consider the risks from the entire pharmaceutical application. quality assurance controls, qualification work and risk reduction measures can cascade from this to consider each of the elements comprising the computerised system. gamp guidance is considered to be scaleable for large, medium and small, complex and simple systems. where software and systems do not appear to fit readily into this category system then it is for users to apply judgement in determining particular quality measures, validation strategies and acceptance criteria. for instance, under particular circumstances the operating system configuration may contribute to the overall risk of the system and the level of validation should reflect this. inspectors will be interested in the companys approach to identifying gxp risks and the criteria for assessing the fitness for purpose of the system application.\n\n## 15.3\n\nthere are a number of additional important aspects that would be required in the documentation and records necessary to support a validation exercise. these aspects relate to on-going evaluation and system maintenance. as a result the documentation and records for validation of a computer system would also require information and records for the following aspects of system control:\n\n- evaluation records to demonstrate that the system works as described in the urs (verification stage and on-going monitoring).\n- records of operator training (introduction and on-going training).\n- procedure for on-going monitoring, this procedure would interlink the error report system and the deviation reports system with the change control procedure.\n- maintenance of user manuals and sops for all systems.\n\n## 16. retrospective validation\n\n## 16.1\n\nretrospective validation is not equivalent to prospective validation and is not an option for new systems. firms will be required to justify the continued use of existing computerised systems that have been inadequately documented for validation purposes. some of this may be based on historical evidence but much will be concerned with re-defining, documenting, re-qualifying, prospectively validating applications and introducing gxp related life-cycle controls. reference should also be made to gamp forums forthcoming guidance on legacy systems. inspectors may be interested in seeing whether system descriptions are available and that documented evidence exists that the system has been checked/tested against urs and other specifications. risk and criticality analysis and assessment of supplier may also be relevant. a documented evaluation of system history i.e. error logs, changes made, evaluation of user manuals and sops would also be expected to provide some of the documentation relating to the controlled system in place of formal validation evidence.", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "24e4a9e6-8069-4bf2-b666-874ab98788d0": {"__data__": {"id_": "24e4a9e6-8069-4bf2-b666-874ab98788d0", "embedding": null, "metadata": {"page_label": "24", "file_name": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_type": "application/pdf", "file_size": 453540, "creation_date": "2024-04-07", "last_modified_date": "2024-03-29", "document_title": "Retrospective Validation and Maintenance of Legacy Computer Systems in GXP Environments: A Comprehensive Guide", "questions_this_excerpt_can_answer": "1. What specific approach is recommended for validating legacy computer systems in GXP environments that lack prospective validation evidence, according to the document titled \"Retrospective Validation and Maintenance of Legacy Computer Systems in GXP Environments: A Comprehensive Guide\"?\n\n2. How does the document suggest handling the validation of legacy systems that have undergone significant changes or do not have historical data covering the current range of operating parameters?\n\n3. What are the key elements that the document outlines should be included in the ongoing evaluation and validation exercise for legacy systems to ensure compliance with current GXP requirements and quality management systems?", "prev_section_summary": "This section discusses the validation and documentation requirements for computerised systems. Key topics include handling the validation of complex integrated systems that span multiple GAMP category levels, the necessary documentation and records for system validation, and the approach to retrospective validation for existing systems that have been inadequately documented. Entities mentioned include the need for a holistic risk-based approach for critical systems, the importance of ongoing evaluation and system maintenance documentation, and the justification for continued use of inadequately documented systems through re-defining, re-qualifying, and prospectively validating applications.", "excerpt_keywords": "retrospective validation, legacy systems, computerised systems, GXP environments, quality management system"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf\n## 16.2\n\na significant number of legacy systems may operate satisfactorily and reliably, however, this does not preclude them from a requirement for validation. the approach to be taken is to provide data and information to support the retrospective documentation of the system to provide validation and re-qualification evidence. gxps have required the validation of computerised systems for many years. it should therefore be noted that a lack of prospective validation evidence for computerised systems would increasingly be seen as a serious deviation from gxps by a number of regulatory authorities. however, retrospective validation might be justified if a non-gxp system is newly classified as a gxp system.\n\n## 16.3\n\nthe principles identified above for computer systems validation should be addressed where a retrospective validation approach has been undertaken for a legacy system. for legacy systems, because of their age and unique characteristics, the system development documentation and records appropriate for validation may not be available. as a result the approach taken to establish and document system reliability and on-going assurance based on the \"build-in-quality\" concept for software development would, of necessity, be different to a current system.\n\n## 16.4\n\nnevertheless, the validation strategy would be consistent with the principles established for classic retrospective validation where the assurances are established, based on compilation and formal review of the history of use, maintenance, error report and change control system records and risk assessment of the system and its functions. these activities should be based on documented urss. if historical data do not encompass the current range of operating parameters, or if there have been significant changes between past and current practices, then retrospective data would not of itself support validation of the current system.\n\n## 16.5\n\nthe validation exercise for on-going evaluation of legacy systems should entail inclusion of the systems under all the documentation, records and procedural requirements associated with a current system. for example, change control, audit trail(s), (where appropriate), data & system security, additional development or modification of software under a qms, maintenance of data integrity, system back up requirements, operator (user) training and on-going evaluation of the system operations.\n\ncompared with 10 to 20 years ago, when gxp related applications were often rudimentary and standalone, there are now many more integrated, infrastructure computer systems to consider, especially when regulated users are striving to achieve so-called paperless systems. some specific national gxp compliance regulations, such as the us fdas 21 cfr part 11: electronic records and electronic signatures have set specific requirements in this field. for legacy systems, firms often have to consider retrospective validation, upgrading or replacement.\n\nexperience reports supported by additional testing have reportedly been used to retrospectively derive a urs.\n\nqms = quality management system", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "6ddc9efb-0216-4d24-97c0-3127192bb08f": {"__data__": {"id_": "6ddc9efb-0216-4d24-97c0-3127192bb08f", "embedding": null, "metadata": {"page_label": "25", "file_name": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_type": "application/pdf", "file_size": 453540, "creation_date": "2024-04-07", "last_modified_date": "2024-03-29", "document_title": "Regulated User Change Management System: A Comprehensive Guide", "questions_this_excerpt_can_answer": "1. What are the key components that regulated users must demonstrate to ensure their computerized systems meet GxP requirements according to the \"Regulated User Change Management System: A Comprehensive Guide\"?\n\n2. How does the \"Regulated User Change Management System: A Comprehensive Guide\" suggest handling change management during the design phase of a computerized system project, and how does this approach evolve once the project reaches the specification development stage?\n\n3. According to the document, what is the significance of integrating the change control procedure for a computerized system project with the master change control procedure of the regulated user organization, and how should this integration address the involvement of suppliers, integrators, and other contracted parties?", "prev_section_summary": "The section discusses the retrospective validation and maintenance of legacy computer systems in GXP environments. Key topics include the approach to validating legacy systems, handling systems without historical data, key elements for ongoing evaluation and validation, principles for validation, documentation requirements, system reliability, risk assessment, change control, data integrity, system security, operator training, and compliance regulations. The section emphasizes the importance of ensuring compliance with current GXP requirements and quality management systems for legacy systems.", "excerpt_keywords": "Regulated User, Change Management, Computerized Systems, GxP Requirements, Validation"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf\n## 16.6\n\nultimately, regulated users have to be able to demonstrate:\n\n- defined requirements\n- system description, or equivalent\n- verification evidence that the system has been qualified and accepted and that gxp requirements are met\n\n## 16.7\n\nin the absence of adequate retrospective qualification or validation evidence this could be a reason to suspend, discontinue or turn-off any legacy system(s).\n\n## part three - system operation / inspection / references\n\n## 17. change management\n\n17.1 it is important for proper control that a comprehensive change management system is instituted. this may take two forms in that during the design phase it may only be necessary to keep records pertaining to the project up-to-date without formal \"sign-off\" approvals for all changes. however, once the project reaches a point where specifications are under development and conceptual aspects have been finalised, then a formal change control procedure should be established which will require clear, prescriptive and accurate documentation and records. it is important for the responsibilities of participants in the change control procedure to be carefully defined.\n\n17.2 as discussed previously, it is appropriate for regulated users to have a system control document or some other record system to achieve a documented baseline record for the description of the computerised system. the system control documentation should be the definitive statement of what the system must do. the control document should also provide a record of the user requirement specifications. the change control procedure for the computerised system \"project\" should be integrated with the master change control procedure for the regulated user organisation. the change control procedure will need to take account of the corresponding procedures and records used by suppliers, integrators and other parties contracted to support the particular system and applications. validated decentralised arrangements for change control may be a feature in large complex regulated user companies.\n\n17.3 common it infrastructure features may need to be controlled centrally by it systems and security management. key roles, responsibilities and procedures need to be clearly documented in relevant internal and external service level agreements, (slas), or equivalent documents.\n\nit is important for regulated users to ensure that change control management is in place during all system life cycle phases, i.e. from design and development through operation, maintenance, modification and retirement. the arrangements should be described in the validation plans for the project. records should be kept with the project files.", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "16d2509d-df9a-49af-9a24-03b8a410a0e8": {"__data__": {"id_": "16d2509d-df9a-49af-9a24-03b8a410a0e8", "embedding": null, "metadata": {"page_label": "26", "file_name": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_type": "application/pdf", "file_size": 453540, "creation_date": "2024-04-07", "last_modified_date": "2024-03-29", "document_title": "Change Control and Error Reporting System in Computer Systems: A Comprehensive Guide", "questions_this_excerpt_can_answer": "1. What specific steps and considerations should be included in a formal change control procedure for computer systems according to the document titled \"Change Control and Error Reporting System in Computer Systems: A Comprehensive Guide\"?\n\n2. How does the document recommend handling changes that arise from system enhancements or identified errors, deviations, or problems during the use of computer systems, including the documentation requirements for emergency changes?\n\n3. What guidance does the document provide regarding the interaction between a user's change control system and a software supplier's change control system, especially in the context of software modifications?", "prev_section_summary": "The section discusses the key components that regulated users must demonstrate to ensure their computerized systems meet GxP requirements, including defined requirements, system description, and verification evidence. It emphasizes the importance of a comprehensive change management system, detailing the evolution of change management from the design phase to the specification development stage. The integration of the change control procedure with the master change control procedure of the regulated user organization is highlighted, addressing the involvement of suppliers, integrators, and other contracted parties. The section also stresses the need for clear documentation, defined responsibilities, and centralized control of IT infrastructure features throughout the system life cycle phases.", "excerpt_keywords": "Change Control, Error Reporting System, Computer Systems, Documentation Requirements, Software Supplier"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf\n## change control and error report system\n\n18.1 the formal change control procedure should outline the necessary information and records for the following areas:\n\n- records of details of proposed change(s) with reasoning.\n- system status and controls impact prior to implementing change(s).\n- review and change authorization methods (also see 12.5).\n- records of change reviews and sentencing (approval or rejection).\n- method of indicating change status of documentation.\n- method(s) of assessing the full impact of change(s), including regression analysis and regression testing, as appropriate (ieee).\n- interface of change control procedure with configuration management system.\n\n18.2 the procedure should accommodate any changes that may come from enhancement of the system, i.e. a change to the user requirements specifications not identified at the start of the project. or alternatively a change may be made in response to an error, deviation or problem identified during use of the system. the procedure should define the circumstances and the documentation requirements for emergency changes (\"hot-fixes\"). each error and the authorized actions taken should be fully documented. the records should be either paper-based or electronically filed.\n\n18.3 computer systems seldom remain static in their development and use. for documentation and computer system control it should be recognized that there are several areas that would initiate change or a review for change. these are:\n\n- a deviation report;\n- an error report; or\n- a request for enhancement of the computer system;\n- hardware and software updates.\n\n18.4 the results of periodic reviews may be helpful, e.g. in indicating process drifts and the need for change. quality systems procedures should ensure that the changes are clearly documented and closed out after actions have been completed. the change control procedure should complement and link with the deviation and errors report system. various gamp 4 operation appendices include guidance in these areas.\n\n18.5 the supplier of the software should have its own change control system in place and there should be clear and agreed procedures covering the interrelationship of the suppliers and users change control system. where changes are made then the modifications of software should be undertaken following formal qms documentation, records and procedural requirements.\n\npi 011-3 page 22 of 50 25 september 2007", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "7222d51f-177b-4f73-8cb0-dac24dd2b87b": {"__data__": {"id_": "7222d51f-177b-4f73-8cb0-dac24dd2b87b", "embedding": null, "metadata": {"page_label": "27", "file_name": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_type": "application/pdf", "file_size": 453540, "creation_date": "2024-04-07", "last_modified_date": "2024-03-29", "document_title": "System Security and Change Management in Computerised Systems: A Comprehensive Guide", "questions_this_excerpt_can_answer": "1. What specific steps should be taken to ensure the security and integrity of data within a computerised system according to the document titled \"System Security and Change Management in Computerised Systems: A Comprehensive Guide\"?\n\n2. How does the document recommend handling changes to validated computerised systems to maintain compliance with user requirements and regulatory standards?\n\n3. What are the key responsibilities and procedures outlined for managing system security and access control within regulated computerised systems, as per the guidelines provided in the document?", "prev_section_summary": "The section discusses the importance of a formal change control procedure for computer systems, outlining necessary information and records such as proposed changes, system status, review methods, and change authorization. It also addresses handling changes from system enhancements or identified errors, deviations, and problems, including documentation requirements for emergency changes. The document emphasizes the need for clear documentation and interaction between a user's change control system and a software supplier's change control system, ensuring modifications are undertaken following formal quality management system requirements.", "excerpt_keywords": "Computerised systems, System security, Change management, Data integrity, Access control"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf\n## 18.6\n\nany changes to the validated computerised system should not be undertaken without review and authorisation on behalf of all stakeholders responsible for the current user requirements. it may be appropriate for this to be undertaken by the system owner and qa representative. test scripts, determined by the project plan, q.v., (of defined test type and extent of tests), should be used to verify the acceptability of the software element developed in response to a change request. integration testing may also be necessary before release of the new software version.\n\n## 19. system security, including back-up\n\n19.1 the security of the system and security of the data is very important and the procedures and records pertaining to these aspects should be based on the it policies of the regulated user and in conformance with the relevant regulatory requirements. the use of a computerised system does not reduce the requirements that would be expected for a manual system of data control and security. system owners responsibilities will include the management of access to their systems and for important systems the controls will be implemented through an information security management system (isms).\n\n19.2 it is very important for the regulated user to maintain the procedures and records related to the access to the system(s). there should be clearly defined responsibilities for system security management, suitable for both small and complex systems, including:\n\n- the implementation of the security strategy and delegation\n- the management and assignment of privileges\n- levels of access for users\n- levels of access for infrastructure (firewall, backup, re-booter, etc.).\n\n19.3 the examination of the procedures and records should assure that the following basic requirements are satisfied:\n\n- access rights for all operators are clearly defined and controlled, including physical and logical access.\n- basic rules exist and are documented to ensure security related to personal passwords or pass cards and related system/data security requirements are not reduced or negated.\n- correct authority and responsibilities are assigned to the correct organisational level.\n- procedures are in place to ensure that identification code and password issuance are periodically checked, recalled or revised.\n- loss management procedures exist to electronically invalidate lost, stolen or potentially compromised passwords. the system should be capable of enforcing regular changes of passwords. precise change rates to be justified within the isms.\n\nit may be necessary to regard proposed changes to infrastructure as a special case and define a set of stakeholders.\n\npi 011-3 page 23 of 50 25 september 2007", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "b0e795aa-31e8-44b3-afa2-2d0a18362603": {"__data__": {"id_": "b0e795aa-31e8-44b3-afa2-2d0a18362603", "embedding": null, "metadata": {"page_label": "28", "file_name": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_type": "application/pdf", "file_size": 453540, "creation_date": "2024-04-07", "last_modified_date": "2024-03-29", "document_title": "Data Security and Recovery Procedures in GxP Environments: A Comprehensive Guide", "questions_this_excerpt_can_answer": "1. What specific measures does the document recommend for addressing breaches of password security within GxP environments?\n \n2. How does the document propose handling access to encrypted GxP data by inspectorates of national competent authorities, and what provisions are made for decryption?\n\n3. What are the detailed requirements outlined for back-up and disaster recovery procedures to ensure the maintenance and integrity of GxP relevant documentation and data, according to the document?", "prev_section_summary": "The key topics of the section include the importance of system security and change management in validated computerised systems. It emphasizes the need for review and authorization of changes by stakeholders, the use of test scripts for verification, and integration testing before releasing new software versions. The section also discusses system security and data backup, highlighting the responsibilities of system owners in managing access, implementing security strategies, assigning privileges, and maintaining access levels for users and infrastructure. It outlines basic requirements for access rights, password security, authority assignments, password management procedures, and the enforcement of regular password changes. The section also mentions the need to consider proposed changes to infrastructure as a special case and define stakeholders accordingly.", "excerpt_keywords": "Data Security, GxP Environments, Password Security, Disaster Recovery, System Security"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf\n## procedures identify prohibited passwords.\n\nan audit log of breaches of password security should be kept and measures should be in place to address breaches of password security.\n\nthe system should enforce revoking of access after a specified number of unsuccessful logon attempts.\n\nmeasures are needed to ensure the validated recovery of original information and data following back up, media transfer, transcription, archiving, or system failure.\n\nattempted breaches of security safeguards should be recorded and investigated.\n\nsome equipment, such as standalone computerized systems and dedicated operator equipment interfaces and instruments may lack logical (password etc.) capabilities. these should be listed, justified and subjected to other procedural controls.\n\n## 19.4\n\nit should be realized that when absolutely necessary inspectorates of the national competent authorities may need to be able to access a firms encrypted gxp data. in such circumstances, either keys for decryption would need to be made readily available to the inspectors working for the competent authorities, or decryption would have to take place under the inspectors supervision.\n\n## 19.5\n\nthe validated back-up procedure including storage facilities and media should assure data integrity. the frequency of back up is dependent on the computer system functions and the risk assessment of a loss of data. in order to guarantee the availability of stored data, back-up copies should be made of such data that are required to re-construct all gxp-relevant documentation (including audit trail records).\n\n## 19.6\n\nthere should be written procedures for recovery of the system following a breakdown; these procedures should include documentation and record requirements to assure retrieval and maintenance of gxp information. the examination of the procedures and records should assure that the following basic back up and disaster recovery requirements are satisfied:\n\n- there should be procedures to assure routine back-up of data to a safe storage location, adequately separated from the primary storage location, and at a frequency based on an analysis of risk to gxp data.\n- the back-up procedure including storage facilities and media used should assure data integrity. there should be a log of backed up data with references to the media used for storage. media used should be documented and justified for reliability.\n- all gxp related data, including audit trails should be backed-up.\n- procedure for regular testing, including a test plan, for back up and disaster recovery procedures should be in place.\n- a log of back up testing including date of testing and results should be kept. a record of rectification of any errors should be kept.\n\n## 19.7\n\nthe physical security of the system should also be adequate to minimize the possibility of unauthorized access, willful or accidental damage by personnel or loss of data.", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "413980b2-6b97-4280-b9d9-6f2d7d9f8ebc": {"__data__": {"id_": "413980b2-6b97-4280-b9d9-6f2d7d9f8ebc", "embedding": null, "metadata": {"page_label": "29", "file_name": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_type": "application/pdf", "file_size": 453540, "creation_date": "2024-04-07", "last_modified_date": "2024-03-29", "document_title": "Data Integrity and Audit Trail Management in Information Security: A Comprehensive Guide", "questions_this_excerpt_can_answer": "1. What specific functions and features should be included in the audit trail for ensuring data integrity according to the document \"Data Integrity and Audit Trail Management in Information Security: A Comprehensive Guide\"?\n\n2. How does the document recommend handling critical data entry, including the verification process, and what are the suggested methods for ensuring the accuracy of such entries?\n\n3. What standards and regulatory requirements does the document reference for the design, implementation, and control of information security management systems, particularly in relation to audit trails and data integrity?", "prev_section_summary": "The section discusses recommendations for data security and recovery procedures in GxP environments. Key topics include measures for addressing breaches of password security, handling access to encrypted GxP data by inspectorates, requirements for back-up and disaster recovery procedures, and physical security of the system. Entities mentioned include audit logs, revoking access after unsuccessful logon attempts, decryption of encrypted data for inspectorates, back-up frequency and data integrity, procedures for system recovery, testing of back-up procedures, and physical security measures.", "excerpt_keywords": "data integrity, audit trail, information security, computerised systems, regulatory requirements"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf\n## data changes - audit trail/critical data entry\n\n20.1 where applicable, the audit trail for the data integrity may need to include functions such as authorised user, creations, links, embedded comments, deletions, modifications/corrections, authorities, privileges, time and date, inter alia. all linked components are to be immutably linked in an it system security controlled audit trail. all original data records and masters and any subsequent alterations, additions, deletions or modifications are to be retained accurately and comprehensively within the retrievable audit trail. the nature and context of transactions logged in the audit trail to be deducible from and in agreement with, the firms approved standard operating procedures for information security management for the particular computerised applications and users authorities. firms will need clearly documented policies, standard operating procedures, validation reports and training records covering such system controls. information security management standards such as iso/iec 17799:2000 may be of assistance with the design, implementation and control of such systems.\n\n20.2 where applicable, there should be special procedures for critical data entry requiring a second check, for example the data entry and check for a manufacturing formula or the keying in of laboratory data and results from paper records. a second authorised person with logged name and identification, with time and date, may verify data entry via the keyboard. for other automated systems featuring direct data capture linked to other databases and intelligent peripherals then the second check may be part of validated system functionality (e.g. in a dispensary). special access, system control features and/or special devices such as identification code bars, and the inclusion and use of an audit trail to capture the diversity of changes possibly impacting the data may facilitate this check.\n\n20.3 the records pertaining to the audit trail events should be documented, ideally as features of the operating system, database management system (dbms), document management system (dms) and other major applications. time-linked audit trail records should be available, if required, in a human readable form as required by the inspector. gxp inspectors may see evidence for different forms of audit trail depending on the regulations prevailing in the intended regulated markets for the products or data.\n\n32 penguin english dictionary: immutable [imewtabl] adj unchangeable; without variation\n\n33 - immutably adv. the systematic contextual labelling of transactions in the electronic audit trail log is recommended as it can have automated functional feedback control links with security validation features.\n\n34 information technology - - \"code of practice for information security management\" bsi/disc and national standards bodies. other guidance will be found in the guidelines supporting fdas 21 cfr part 11.\n\n35 this is an established compliance requirement in the gmp discipline. it should be noted that for the usa market it may be a requirement in for audit trails to be available in electronic form, not just paper, but the implementation and enforcement of compliance with 21 cfr part 11 is under review by fda in 2003, (see ref. 11).\n\npi 011-3 page 25 of 50 25 september 2007", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "3be31d72-c9ab-4026-8b2b-c56d8811dd7c": {"__data__": {"id_": "3be31d72-c9ab-4026-8b2b-c56d8811dd7c", "embedding": null, "metadata": {"page_label": "30", "file_name": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_type": "application/pdf", "file_size": 453540, "creation_date": "2024-04-07", "last_modified_date": "2024-03-29", "document_title": "Regulations and Requirements for Electronic Records and Signatures in GMP Compliance: A Comprehensive Guide", "questions_this_excerpt_can_answer": "1. What specific legal requirements does EC Directive 91/356 establish for the maintenance and protection of electronic records and signatures within the EU GMP compliance framework, as outlined in the document \"Regulations and Requirements for Electronic Records and Signatures in GMP Compliance: A Comprehensive Guide\"?\n\n2. How does the document detail the implementation of good practice measures for protecting electronic data in GMP-regulated environments, particularly in relation to access control, data backup, and the independent checking of critical data?\n\n3. What are the main considerations and requirements for ensuring that electronic records and signatures are accurately maintained, protected against loss or unauthorized alteration, and provide a clear audit trail throughout the manufacturing process, as emphasized in the document in the context of Directive 91/356 and GMP documentation guidelines?", "prev_section_summary": "This section discusses the importance of audit trails for ensuring data integrity in computerized systems. It outlines specific functions and features that should be included in the audit trail, such as authorized user information, time and date stamps, and the retention of original data records. The document recommends special procedures for critical data entry, including a second check by an authorized person to verify data accuracy. It also references standards and regulatory requirements for the design, implementation, and control of information security management systems, such as ISO/IEC 17799:2000 and FDA's 21 CFR Part 11. The section emphasizes the need for documented policies, standard operating procedures, and training records to ensure compliance with data integrity and audit trail management practices.", "excerpt_keywords": "GMP compliance, electronic records, electronic signatures, audit trail, data integrity"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf\n## 20.4\n\nit is expected that appropriate controls will exist such as the maintenance of a register of authorised users, identification codes, scope of authorised actions, in support of gxp electronic records and electronic signatures.\n\n## 20.5\n\nthere should be records of checks that the data/control/monitoring interface(s) between the system and equipment ensure correct input and output transmission.\n\n## 21. electronic records and electronic signatures\n\n21.1 ec directive 91/356 sets out the legal requirements for eu gmp. the gmp obligations include a requirement to maintain a system of documentation, (article 9). the main requirements here being that the regulated user has validated the system by proving that the system is able to store the data for the required time, that the data is made readily available in legible form and that the data is protected against loss or damage.\n\n21.2 the guidelines relating to documentation in the gmp guide are in chapter 4 and there is no requirement here that documents be in writing. indeed in paragraph 4.9 the section amplifies article 9.2 (see above). it references electronic data processing (edp) systems and implies a number of good practice measures that should be in place to protect the data:\n\n- access by authorised personnel only\n- use of passwords\n- creation of backup copies\n- independent checking of critical data\n- safe storage of data for the required time\n\nsuch systems also require evidence to demonstrate:\n\n(fundamental) the use of validated, secure computerised systems\nthe systematic use of an accurate, secure, audit trail, (where appropriate)\n\n## 21.3\n\nthe central consideration here as in directive 91/356, is that records are accurately made and protected against loss or damage or unauthorised alteration so that there is a clear and accurate audit trail throughout the manufacturing process available to the licensing authority for the appropriate time.\n\nthe main requirements in article 9.1 are that documents are clear, legible and up to date, that the system of documentation makes it possible to trace the history of manufacture (and testing) of each batch and that the records are retained for the required time. article 9.2 envisages that this documentation may be electronic, photographic or in the form of another data processing system, rather than written.", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "1dabe786-dd0b-49cd-be75-8f5eaff08aa9": {"__data__": {"id_": "1dabe786-dd0b-49cd-be75-8f5eaff08aa9", "embedding": null, "metadata": {"page_label": "31", "file_name": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_type": "application/pdf", "file_size": 453540, "creation_date": "2024-04-07", "last_modified_date": "2024-03-29", "document_title": "Regulations and Requirements for Electronic Records and Signatures in Wholesale Distribution: A Comprehensive Guide", "questions_this_excerpt_can_answer": "1. What specific requirements must authorized wholesale distributors adhere to regarding the traceability and availability of records covering purchases/sales invoices, according to the document \"Regulations and Requirements for Electronic Records and Signatures in Wholesale Distribution: A Comprehensive Guide\"?\n\n2. How does the document address the use of electronic records and signatures in GxP applications by regulated user companies, including the necessity for these companies to justify the technologies and controls in place for electronic records to be considered legally binding and equivalent to their paper-based counterparts?\n\n3. What are the guidelines provided in the document for the use of electronic signatures in GxP systems, particularly in relation to ensuring the uniqueness of the signature to the owner and the possibility of maintaining a single signature across multiple systems?", "prev_section_summary": "This section discusses the regulations and requirements for electronic records and signatures in GMP compliance, specifically focusing on EC Directive 91/356. Key topics include the maintenance of a register of authorized users, validation of systems for data storage, protection against loss or damage, access control, data backup, independent checking of critical data, and the creation of an accurate audit trail. The section emphasizes the importance of accurately maintaining and protecting electronic records and signatures throughout the manufacturing process to ensure compliance with GMP guidelines.", "excerpt_keywords": "Regulations, Electronic Records, Signatures, Wholesale Distribution, GxP applications"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf\n## 21.4\n\nthe situation for an authorised wholesale distributor is similar for records covering purchases/sales invoices, (on paper or on computer, or any other form) 38. the requirements for records are clear: \"records should be made... in such a way that all significant activities or events are traceable... and are clear and readily available\".\n\n## 21.5\n\nregulated user companies generally have a choice as to whether to use electronic records or electronic signatures instead of paper-based records. when regulated users elect to use electronic records for gxp applications then it will be necessary for the companies to identify the particular regulations being applied and whether they are to be considered legally binding and equivalent to their paper-based counterparts. regulations applicable to particular gxp disciplines may impose specific rules e.g. when electronic records and electronic signatures are used as a primary source of data, records and/or evidence. it is for the regulated user to explain and justify the technologies and controls in place. an appropriate form of electronic signature or authentication / identification should be applied where external access can be made to a computerized gxp system, the system electronically generates gxp regulatory records, or key decisions and actions are able to be undertaken through an electronic interface.\n\n## 21.6\n\ngenerally there is no requirement for records and documents created and maintained, as part of gxp, to be in writing, 41 and validated, secure electronic versions are permitted. in the absence of provisions to the contrary this will arguably extend to \"electronic signatures\". certainly, where regulated users have elected to use electronic records in place of paper-based media, then it can be argued, (from the forgoing requirements) that for accurate, authorized, secure electronic record systems these systems would logically require an attached immutable audit trail identifying person, time and date and linking to particular transactions. however, some systems may utilize a combination of human actions together with other automated functions and a variety of media for gxp data processing, records and information. such systems may be described as hybrid and in such cases documented procedural controls with.\n\n|38|the relevant ec directive being 92/25, article 6(e), as amplified in the gdp guidelines (94/c 63/03). article 8 of 92/25 requires that the documentation system makes it possible to trace the distribution path for every product.|\n|---|---|\n|39|it has been proposed via industry comments that a signature should be unique to the owner of that signature but not necessarily unique to the system. it has also been argued that it may be desirable to issue and maintain only one signature across a multitude of systems. regulated users may need to explain and justify such arrangements, controls and logic.|\n|40|the regulated user is expected to justify the choice of methods to be used to ensure compliance with regulations and gxp, (see glossary advanced electronic signature, electronic signature (3) etc.|\n|41|in this context writing meaning written by hand and/or signed by hand on paper media.|\n\npi 011-3 page 27 of 50 25 september 2007", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "88a5459e-ab9f-46d5-820d-2e36590a7eea": {"__data__": {"id_": "88a5459e-ab9f-46d5-820d-2e36590a7eea", "embedding": null, "metadata": {"page_label": "32", "file_name": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_type": "application/pdf", "file_size": 453540, "creation_date": "2024-04-07", "last_modified_date": "2024-03-29", "document_title": "Electronic Signature Compliance in GXP Regulations: A Comprehensive Guide", "questions_this_excerpt_can_answer": "1. What specific requirements does the EC Directive 2001/83 impose regarding the certification of batches for release in the context of electronic signatures and computerized systems, and how does this document interpret those requirements?\n\n2. How does the document outline the control and management of infrastructure, system, and specific application aspects for ensuring GXP compliance when using electronic signatures in computerized systems?\n\n3. What considerations does the document suggest are important when assessing GXP compliance in the use of electronic signatures, particularly regarding security measures for digital signatures and the management of authorized entities?", "prev_section_summary": "The section discusses the requirements for authorized wholesale distributors regarding the traceability and availability of records, the use of electronic records and signatures in GxP applications by regulated user companies, guidelines for electronic signatures in GxP systems, and the justification of technologies and controls for electronic records to be legally binding. Key entities mentioned include authorized wholesale distributors, regulated user companies, electronic records, electronic signatures, GxP applications, and regulatory requirements.", "excerpt_keywords": "Electronic signatures, GXP compliance, Infrastructure control, Security measures, Digital signature"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf\nrecorded links, by reference and signatures may have to be used to complete the audit trail across, for example, a mixture of paper based records and electronic files.\n\n21.7 whilst ec directive 2001/83 requires a qualified person to \"certify\" in a register that batches for release meet the required condition we are not aware of any provisions that would restrict this activity to paper based media and a handwritten certifying signature. validated and secure electronic data processing systems may therefore be used in this context.\n\n21.8 the key aspects of infrastructure, system and specific application to be controlled and managed are:\n\n- the authorised user log-on for a specific application\n- a unique combination of user id and password called for by the computerised system and linked to the users authorised account for the use of a specific application\n- permitted task functionality for that user\n- the system to have defined time zone(s) and date standard referencing with relative transaction linking, (complex systems may span several time zones)\n- the audit trail\n- other physical and logical system information security infrastructure control features.\n\n21.9 issues to consider when assessing gxp compliance in the use of electronic signatures include that:\n\n- documentary evidence of compliance exists for all aspects of infrastructure, system and specific application.\n- where risk assessment concludes that the use of a digital signature may be necessary (e.g. certification to a third party or in gcp field data collection and transmission) that adequate security measures exist to protect the key to a digital signature. the level of security that is appropriate depends on the sensitivity of the transaction and the possible impact of the unauthorised use of the key. public key infrastructure (pki) may be appropriate where risk assessment indicates that a high level of security is required.\n- a register of entities that are authorised is being maintained.\n- there are procedures that ensure that entities authorised to use electronic signatures are aware of their responsibilities for actions initiated under their electronic signatures.\n- personnel administering the systems have appropriate security clearances, training, skills and knowledge.\n\nincluding printouts from computerised systems.\n\nsuperseding 75/319 article 22 following codification.\n\nsee previous section (20.1).\n\npi 011-3 page 28 of 50 25 september 2007", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "28aaa332-8756-4f1c-8185-09160dcc96bb": {"__data__": {"id_": "28aaa332-8756-4f1c-8185-09160dcc96bb", "embedding": null, "metadata": {"page_label": "33", "file_name": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_type": "application/pdf", "file_size": 453540, "creation_date": "2024-04-07", "last_modified_date": "2024-03-29", "document_title": "\"Ensuring Compliance and Security in Electronic Record Keeping and External Access: Best Practices and Guidelines\"", "questions_this_excerpt_can_answer": "1. What specific procedures are recommended to ensure the integrity and security of electronic signatures in GxP-compliant systems, as outlined in the document \"Ensuring Compliance and Security in Electronic Record Keeping and External Access: Best Practices and Guidelines\"?\n\n2. How does the document address the management and security of GxP data when it comes to archiving, accuracy, and access control, particularly in the context of electronic record systems?\n\n3. What are the guidelines provided for managing external access to GxP systems, including the verification of authorized clients and the handling of data that fails to meet security conditions, as detailed in the document?", "prev_section_summary": "The section discusses the requirements of EC Directive 2001/83 regarding the certification of batches for release using electronic signatures and computerized systems. It outlines the key aspects of infrastructure, system, and specific application control and management for ensuring GXP compliance with electronic signatures. The document also highlights considerations for assessing GXP compliance in the use of electronic signatures, such as security measures for digital signatures, management of authorized entities, and personnel training and security clearances.", "excerpt_keywords": "Electronic signatures, GxP compliance, Data integrity, External access, Security measures"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf\nprocedures are in place to record the printed name, or identity, of the signer, the date and time when the signature was executed and the meaning associated with the signature.\n\nprocedures exist to try to detect the unauthorized use of an electronic signature or compromised id password combinations.\n\n## issues to consider where electronic records are used to retain gxp data:\n\ndocumentary evidence of compliance exists\narchiving procedures are provided and records of use exist\nprocedures exist to ensure accuracy, reliability and consistency in accordance wip pe validation exercise reported for pe electronic record system\nsystem controls and detection measures (supported by procedures) exist to enable pe identification, quarantining and reporting of invalid or altered records\nprocedures exist to enable pe retrieval of records proughout pe retention period\nthe ability exists to generate accurate and complete copies of records in bop human readable and electronic form\naccess to records is limited to auporized individuals\nsecure, computer-generated, time-stamped audit trails to independently record gxp related actions following access to pe system are used\n\nprocedures exist to ensure that change-control and revision (additions, modifications, deletions) transactions are documented in the audit trail.\n\n## issues to consider when the gxp system has a provision for external access:\n\n- the system has a method of ensuring that external access and inputs come only from authorized clients and that they come in the correct format, for example as encrypted, digitally signed mail or data packets. a mechanism must exist to quarantine external inputs where security conditions are not met. the information security management arrangements need to cover the quarantine, notification and the final sentencing of such inputs.\n- mechanisms are in place to ensure that all external access can be tracked. each element of the processing stage should incorporate logging and monitoring facilities. however, inspectors may expect to see less onerous tracking for read only access to a suitably secure and protected system.\n- the capacity should exist to keep copies of data and to re-send them from one stage to another if they get \"lost\" or corrupted at a later stage of processing.\n\na database management system (dbms) will have this included as an optional feature, but for other systems it may be necessary to ensure that it is an added function. regulated users will then need to ensure that it is left switched on. sometimes referred to as open systems", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "042bf557-79a1-4912-8f69-4fedb04dcf74": {"__data__": {"id_": "042bf557-79a1-4912-8f69-4fedb04dcf74", "embedding": null, "metadata": {"page_label": "34", "file_name": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_type": "application/pdf", "file_size": 453540, "creation_date": "2024-04-07", "last_modified_date": "2024-03-29", "document_title": "Security and Qualifications Management in GXP Computerised Systems and Personnel", "questions_this_excerpt_can_answer": "1. What specific international initiatives are influencing the requirements for additional security arrangements in GXP computerised systems, particularly those that generate regulatory records or allow external access?\n \n2. How does the document suggest assessing staff qualifications for managing and developing GXP computerised systems, and what criteria are emphasized for determining these qualifications?\n\n3. In the transition from manual to automated processes within GXP computerised systems, what specific regulatory frameworks are mentioned as providing criteria for considering electronic records and signatures equivalent to their paper counterparts, and what is their significance in the context of risk assessment and quality assurance?", "prev_section_summary": "The section discusses procedures for ensuring the integrity and security of electronic signatures in GxP-compliant systems, including recording the signer's identity, date, and time of signature. It also addresses issues related to the management and security of GxP data in electronic record systems, such as archiving, accuracy, access control, and change-control transactions. Additionally, guidelines are provided for managing external access to GxP systems, including verification of authorized clients, handling of data that fails security conditions, tracking external access, and maintaining copies of data for re-sending if needed. The section emphasizes the importance of secure audit trails, limited access to records, and mechanisms for tracking and monitoring external access.", "excerpt_keywords": "Security, Qualifications Management, GXP Computerised Systems, Personnel, Electronic Signatures"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf\n## 21.13 additional security arrangements\n\nadditional security arrangements and controls will be needed for gxp computerised systems which electronically generate regulatory records, allow external access, or enable key decisions and actions to be undertaken through electronic interfaces. these requirements are being determined largely by international initiatives to establish electronic commerce. however, where firms are interfacing such open system (external access) functionality, in whole or in part, with their gxp systems, then the security, control, and validation information will need to be documented and available to gxp inspectors.\n\n## 22. personnel\n\nnote: 22.1 to 22.7 is based largely on the apv guideline, with judicious editing where necessary to fit the context of this document.\n\n### 22.1 sufficient qualified staff\n\nthere should be sufficient, qualified staff with the relevant experience to carry out tasks for which the regulated user is responsible in connection with the planning, introduction, application (operation), application consultancy on, and regular monitoring of computerised systems.\n\n### 22.2 staff qualifications\n\nideally staff qualifications should be assessed on the basis of professional training, education, and experience in handling and developing computerised systems. the field of work in which the staff will be operating should determine qualification requirements. staff should only be deployed in areas suited to their skills and training.\n\n### 22.3 areas of responsibility\n\nthe individual areas of responsibility should be laid down in writing and be clearly understandable to every member of staff. the fact that computerised systems may take over decision-making functions does not affect the legally prescribed responsibilities of the persons in key positions.\n\n### 22.4 risk assessment\n\nprior to converting a process from manual to automated control (or the introduction of a new automated operation), it is important that project staff consider any quality assurance and safety issues as part of an impact assessment of risks. risk reduction measures may need to be incorporated into the systems design and operation. additional risks to the quality of gxp related products/materials should not be introduced as a result of reducing the manual involvement in the process.\n\nincluding 21 cfr part 11. title 21 code of federal regulations part 11 (21 cfr part 11), which was issued by the us fda in 1997 and provides criteria under which that agency considers electronic records and electronic signatures to be equivalent to paper records and handwritten signatures. in europe ec directive 1999/93/ec (december 1999) on a community framework for electronic signatures and ec directive 2000/31/ec (may 2000) on electronic commerce in the internal market are important. these directives were implemented during 2001. it is not the purpose of gxp guides to reproduce such business and commerce requirements.\n\nsection 22.4 has been substantially re-worded compared with the original (english language version) apv guidance, for clarity.\n\n\"account should be taken of the risk of certain aspects of the previous procedures such as quality or safety being lost as a result of reduced operator involvement following the introduction of a computerised system.\" (to quote the apv document)\n\npi 011-3 page 30 of 50 25 september 2007", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "20ef6396-9c74-4d08-89c7-1c4533b70df2": {"__data__": {"id_": "20ef6396-9c74-4d08-89c7-1c4533b70df2", "embedding": null, "metadata": {"page_label": "35", "file_name": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_type": "application/pdf", "file_size": 453540, "creation_date": "2024-04-07", "last_modified_date": "2024-03-29", "document_title": "Regulated User Training and Inspection Guidelines for Computerised Systems", "questions_this_excerpt_can_answer": "1. What specific responsibilities do regulated users have in ensuring their staff are adequately trained in the use of computerised systems, according to the document \"Regulated User Training and Inspection Guidelines for Computerised Systems\"?\n\n2. How does the document \"Regulated User Training and Inspection Guidelines for Computerised Systems\" suggest the effectiveness of training programs for staff involved with computerised systems should be assessed?\n\n3. According to the \"Regulated User Training and Inspection Guidelines for Computerised Systems,\" how should inspectors approach the evaluation of GxP compliance in relation to computerised systems, especially in sites with high levels of automation and integrated systems?", "prev_section_summary": "The key topics of this section include additional security arrangements for GXP computerised systems, staff qualifications and responsibilities in managing and developing computerised systems, risk assessment in transitioning from manual to automated processes, and the regulatory frameworks such as 21 CFR Part 11 and EC Directives on electronic signatures and commerce. The section emphasizes the importance of qualified staff, clear areas of responsibility, and risk assessment in ensuring the quality and safety of GXP related products/materials in computerised systems.", "excerpt_keywords": "Regulated User, Training Guidelines, Computerised Systems, GxP Compliance, Inspection Considerations"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf\n## 22.5\n\nthe regulated user is responsible for ensuring all staff who have to perform tasks in connection with computerised systems are given the requisite training and relevant guidelines on computerised systems. that should also apply to system developers, maintenance and repair staff and staff whose work could affect the documented operability of the systems.\n\n## 22.6\n\napart from a basic training in computerised systems, newly recruited staff should also be trained in the tasks assigned to them personally. furthermore, ongoing/awareness training should also be undertaken according to standard training programs and the effectiveness of the training assessed periodically following implementation, (through testing).\n\n## 22.7\n\nin connection with training, the gxp and life-cycle concept and all measures to improve understanding and application of the concept should be explained. training measures and qualifications should be documented and stored as part of the life cycle documentation. (training records may be stored in accordance with regulated user procedures)\n\n## 23. inspection considerations\n\n## 23.1\n\nthe attention paid by inspectors to the assessment of the gxp implications of computerised systems on a site (and between sites), will be determined to some extent by the overall site history and risk assessment carried out by the inspector in preparing for the inspection. information computer technology management arrangements for the procurement and validation of software and systems may be centralized at the regulated users headquarter site rather than at the site of inspection. in such circumstances the controls, sops and records in place to ensure gxp compliance at inspection sites will need to be made available on site. in some circumstances it may also be necessary to consider an inspection at the hq site.\n\n## 23.2\n\nclearly where a site has a lot of automation and integrated computerised systems - and manufactures a range of sterile products - (for example), then the potential risks from a gxp failure, (whether computer related or otherwise) for the patient are high. however, where such automated systems are well designed, implemented, managed and controlled, then potential risks to product quality (and to patients) may be considerably reduced, compared with labour intensive operations, as the latter carry inherent risks from human variability and errors. inspectors have to come to a judgement on this by studying the firms evidence not just in relation to the technology aspects (through the application of gamp etc.) but also the gxp risks identified (through pq reports and such-like).\n\n## 23.3\n\nhumans design, build, test, implement and change these complex systems and there is opportunity for critical error with automated systems at any stage in the life-cycle unless properly managed. the gamp guide provides relevant guidance on these aspects.\n\n50 pq = performance qualification\n\npi 011-3 page 31 of 50 25 september 2007", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "c7bd7d93-9f47-4c00-ae50-f0695dee1d53": {"__data__": {"id_": "c7bd7d93-9f47-4c00-ae50-f0695dee1d53", "embedding": null, "metadata": {"page_label": "36", "file_name": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_type": "application/pdf", "file_size": 453540, "creation_date": "2024-04-07", "last_modified_date": "2024-03-29", "document_title": "Guidance on Inspecting and Validating GxP Critical Computerized Systems in Pharmaceutical Companies: A Comprehensive Approach", "questions_this_excerpt_can_answer": "1. What specific approach does the \"Guidance on Inspecting and Validating GxP Critical Computerized Systems in Pharmaceutical Companies\" recommend for inspectors when they are initially unfamiliar with a site's computerization level?\n\n2. How does the guidance document classify computerized systems in terms of their impact on product quality and patient safety, and what examples does it provide to illustrate systems that directly or indirectly affect these areas?\n\n3. What validation strategy does the guidance suggest for firms regarding their computerized systems, especially in terms of handling systems that have been in use for a long time versus those recently implemented, and how does it address systems that cannot be supported or validated by suppliers?", "prev_section_summary": "This section discusses the responsibilities of regulated users in ensuring staff are adequately trained in the use of computerised systems. It emphasizes the importance of training for all staff involved with computerised systems, including system developers, maintenance staff, and those whose work could affect system operability. The document suggests ongoing training and assessment of training effectiveness through testing. It also highlights the importance of understanding GxP and life-cycle concepts in training. The section further discusses inspection considerations, including the assessment of GxP implications of computerised systems at inspection sites with high levels of automation. It mentions the potential risks of GxP failure in sites with automated systems and the need for proper management to reduce risks to product quality and patient safety. The section also emphasizes the role of humans in designing, building, testing, implementing, and changing complex systems, and the importance of proper management to prevent critical errors.", "excerpt_keywords": "Computerized systems, Validation, GxP, Pharmaceutical companies, Inspections"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf\n## 23.4\n\nit is not intended that this guidance should be used as a blunt instrument for all on-site inspections but inspectors should use it selectively to build up a clear picture of a companys scale and complexity of on-site computerization (or automation) and investigate selectively the critical systems and risks. as stated in 2.7 of this pic/s guidance, inspectors may wish to consider evidence for compliance with gxp as indicated by italicised text throughout the document. table 1 (page 34) immediately following this section provides a suggested checklist for information to be considered prior to inspection.\n\n## 23.5\n\nwhere little is known about computerization on a site, then it may be necessary to use a pre-inspection questionnaire to amplify the site master file details.\n\n## 23.6\n\ninspectors should select the gxp critical computerised systems from the information provided and consider firstly the validation evidence for the selected system(s) and then the routine operational controls for maintaining a valid system that is accurate and reliable. inspectors may find that different departments in pharmaceutical companies will have responsibility for gxp aspects of commercial, or business (it systems) and lower level process control systems. look for evidence of inconsistency, or muddled standards.\n\n## 23.7\n\ngxp critical computerised systems are those that can affect product quality and patient safety, either directly (e.g. control systems) or the integrity of product related information (e.g. data/information systems relating to coding, randomisation, distribution, product recalls, clinical measures, patient records, donation sources, laboratory data, etc.). this is not intended as an exhaustive list.\n\n## 23.8\n\nit is essential that firms have a computerised systems validation policy together with linked sops and plans, including a listing, or inventory, of all their computerised systems - classified as to their use, criticality and validation status. for long standing systems, validation may have been carried out retrospectively and for systems purchased or implemented in the last few years, the validation should have been carried out (and recorded) prospectively. firms should have plans to complete any outstanding retrospective validation of gxp related computer systems within a reasonable time period depending on the risks and complexity of the systems. the continued use of critical systems that are unsupportable by suppliers and cannot be validated must be justified by regulated users, supported by alternative fail-safe arrangements and considered for urgent phased replacement.\n\n## 23.9\n\nthe firms validation approach should follow a life-cycle methodology, with management controls and documentation as outlined in this guidance, which contains consensus best practice guidelines.\n\n51 an electronic keyword search of gxp documents will reveal specific compliance requirements to assist in preparing for particular topic inspections. keywords such as: document, specification, formula, procedure, record, data, log book, instruction, written, sign, approve, writing, signature are particularly helpful for records, data, documentation, authorisation and signature issues.\n\npi 011-3 page 32 of 50 25 september 2007", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "45a3db3f-a51b-47d0-a1a3-6e26a7b58c36": {"__data__": {"id_": "45a3db3f-a51b-47d0-a1a3-6e26a7b58c36", "embedding": null, "metadata": {"page_label": "37", "file_name": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_type": "application/pdf", "file_size": 453540, "creation_date": "2024-04-07", "last_modified_date": "2024-03-29", "document_title": "Guidelines for Validation and Compliance Inspections of Automated Systems", "questions_this_excerpt_can_answer": "1. What specific documents and reports should inspectors review to assess the validation of a firm's computerised system according to the guidelines provided in the document titled \"Guidelines for Validation and Compliance Inspections of Automated Systems\"?\n\n2. How does the document \"Guidelines for Validation and Compliance Inspections of Automated Systems\" suggest inspectors assess the traceability of actions, tests, and the resolution of errors and deviations in the validation process of computerised systems?\n\n3. What criteria does the document \"Guidelines for Validation and Compliance Inspections of Automated Systems\" outline for determining whether the lack of certain documentation or evidence in the validation of computerised systems constitutes a critical or major deficiency during inspections?", "prev_section_summary": "This section provides guidance on inspecting and validating GxP critical computerized systems in pharmaceutical companies. Key topics include selectively investigating critical systems and risks, using pre-inspection questionnaires for sites with little known computerization, validating gxp critical computerized systems that impact product quality and patient safety, having a validation policy and plans for all computerized systems, and following a life-cycle methodology for validation. The section also emphasizes the importance of evidence for compliance with gxp, consistency in standards across departments, and justifying the use of critical systems that cannot be validated.", "excerpt_keywords": "Validation, Compliance, Computerised Systems, Inspections, Traceability"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf\n## 23.10 inspectors should review the firms validation summary report (vsr) for the selected system and refer as necessary to the system acceptance test specification and lower level documents. they should look for evidence that the qualification testing has been linked with the relevant specifications acceptance criteria, viz:\n\n|pq versus urs|53|\n|---|---|\n|oq versus fs|54|\n|iq versus ds or dr| |\n|supplier audit reports| |\n|validation and quality plans. e.g. validation master plan (vmp) or policy.| |\n\n(for big projects there should be a project quality plan and a qms for the documentation. for smaller projects established sops may suffice)\n\n## 23.11 inspectors should look for the traceability of actions, tests and the resolution of errors and deviations in selected documents. if the firm has not got proper change and version controls over its system life-cycle and validation documents, then the validation status is suspect.\n\n## 23.12 inspectors should consider all parts of pic/s gmp annex 11 for relevance to particular validation projects and in particular, the principle and items 1, 2, 3, 4, 5 and 7.\n\n## 23.13 the lack of a written detailed description of each system (kept up-to-date with controls over changes), its functions, security and interactions (a11.4); a lack of evidence for the quality assurance of the software development process (a11.5), coupled with a lack of adequate validation evidence to support the use of gmp related automated systems may very well be either a critical or a major deficiency. the ranking will depend on the inspectors risk assessment judgement for particular cases. (nb. since 1983, the gmps have called for validated electronic data-processing systems and since 1992 for the validation of all gmp related computer systems).\n\n## 23.14 if satisfied with the validation evidence, inspectors should then study the system when it is being used and calling for printouts of reports from the system and archives as relevant. all points in annex 11 (6, 8-19) may be relevant to this part of the assessment. look for correlation with validation work, evidence of change control, configuration management, accuracy and reliability. security, access controls and data integrity will be relevant to many of the systems particularly edp (i.e.: electronic data processing) systems.\n\nvsr=a best practice high level report, summarising pe validation exercise, results and conclusions, linking via cross referencing to lower level project records, detailed reports and protocols. this is useful for briefing bop senior managers, in regulated user organisations and for reference by auditors/ inspectors.\noq = operational qualification; fs = functional specification\niq = installation qualification; ds= design specification; dr = design review", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "a6ca2a85-9915-433f-b84a-f0af9ee8de0f": {"__data__": {"id_": "a6ca2a85-9915-433f-b84a-f0af9ee8de0f", "embedding": null, "metadata": {"page_label": "38", "file_name": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_type": "application/pdf", "file_size": 453540, "creation_date": "2024-04-07", "last_modified_date": "2024-03-29", "document_title": "\"Comprehensive Guide for IT/Computer Services Inspection in Regulated Environments\"", "questions_this_excerpt_can_answer": "1. What specific regulatory and guidance documents are referenced for the electronic data processing (EDP) systems in the context of IT/Computer Services Inspection in regulated environments?\n \n2. How are deficiency ratings determined by inspectors during the inspection of IT/computer services in regulated environments according to the document?\n\n3. What detailed information and documentation are inspectors preparing for an inspection expected to review or collect regarding the management, validation, and operation of computerized systems in GXP areas as outlined in the document?", "prev_section_summary": "The section discusses the guidelines for validation and compliance inspections of automated systems. Key topics include reviewing validation summary reports, traceability of actions and resolution of errors, relevance of PIC/S GMP Annex 11, lack of documentation as a deficiency, and studying the system in use. Entities mentioned include validation summary reports, qualification testing, acceptance criteria, change and version controls, system life-cycle, validation status, GMP related automated systems, electronic data-processing systems, and validation evidence.", "excerpt_keywords": "Regulatory documents, Electronic data processing systems, IT/computer services inspection, Validation and compliance, GXP areas"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf\n## 23.15\n\nconsider also pic/s gmp 4.9 and ec directive 91/356/eec article 9(2) for edp systems. guidance on the common industry interpretation of annex 11 is given in the gamp guide, from the german apv.\n\n## 23.16\n\ndeficiency ratings applied by inspectors will be based on the relative risk of the application and their judgement of risk criticality.\n\n## 24. checklists and aide memoires\n\ninspectors - preparing for an inspection\n1. details of pe organisation and management of it/computer services and project engineering on site.\n2. the regulated users policies on procurement of hardware, software and systems for use in gxp areas.\n3. the regulated users policy on pe validation of gxp computerised systems\n4. a list of it/computer services standards and sops.\n5. the project management standards and procedures pat have been applied to pe development of pe various applications.\n6. identify work contracted out routinely for systems support and maintenance.\n7. a list, or inventory, of all computerised systems on site by name and application for business, management, information and automation levels. the list should also indicate validation status and risk ranking. (include basic schematics of installed hardware and networks).\n8. identify and list pose systems, sub-systems, modules and/or programs pat are relevant to gxp and product quality. cross-refer to pe lists provided for 6 above.\n9. for pe gxp significant elements and systems identified in 7 please provide additional information as below:\n10. details of disaster-recovery, back up, change-controls, information security, and configuration management.\n11. a summary of documentation pat generally exists to provide up-to-date descriptions of pe systems and to show physical arrangements, data flows, interactions wip oper systems and life cycle and validation records. the summary should indicate wheper all of pese systems have been fully documented and validated and confirm pe existence of controlled system description documents as required by eu gmp a11 (4).\n12. a statement on pe qualifications and training background of personnel engaged in design, coding, testing, validation, installation and operation of computerised systems, including consultants and sub-contractors, (specifications, job descriptions, training logs).\n13. state pe firms approach to assessing potential suppliers of hardware, software and systems.\n14. specify how pe firm determines wheper purchased or \"in-house\" software has been produced in accordance wip a system of qa and how validation work is undertaken.\n15. document pe approach pat is taken to pe validation and documentation of older systems where original records are inadequate.\n16. summarise pe significant computer system changes made since pe last inspection and plans for future developments.\n17. ensure pat records relating to pe various systems are readily available, well organised, and key staff are prepared to present, discuss and review pe detail, as necessary.", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "8fb68cd1-e8c6-4030-a519-b96d22f19cfb": {"__data__": {"id_": "8fb68cd1-e8c6-4030-a519-b96d22f19cfb", "embedding": null, "metadata": {"page_label": "39", "file_name": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_type": "application/pdf", "file_size": 453540, "creation_date": "2024-04-07", "last_modified_date": "2024-03-29", "document_title": "Software Development and Maintenance Process Requirements and Documentation Guide", "questions_this_excerpt_can_answer": "1. What specific documents are required as evidence for review during the development stage of the software life cycle according to the PIC_011_3 recommendation on computerised systems?\n\n2. How does the PIC_011_3 recommendation address the handling and documentation of software testing, particularly in terms of module testing and integrated module testing?\n\n3. What contingency measures does the PIC_011_3 recommendation suggest for regulated users in the event that access to the software's source code cannot be guaranteed due to the business failure of the supplier?", "prev_section_summary": "The section provides guidance on regulatory and guidance documents for electronic data processing (EDP) systems in regulated environments, including references to PIC/S GMP 4.9 and EC Directive 91/356/EEC Article 9(2). It also discusses how deficiency ratings are determined by inspectors based on risk assessment. The section outlines the detailed information and documentation inspectors should review during an inspection, such as organization and management of IT/computer services, procurement policies, validation of computerized systems, project management standards, disaster recovery, documentation of systems, personnel qualifications, supplier assessment, and system validation processes.", "excerpt_keywords": "Software Development, Maintenance Process, Documentation Guide, Computerised Systems, PIC_011_3 Recommendation"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf\n|life cycle stage|project stage activity|evidence for review|\n|---|---|---|\n|development|develop urs/fs/ds|urs/fs/ds documents|\n|development|plan testing|test plan and test scripts|\n|development|plan documentation of testing|written document describing how testing should be documented.|\n|implementing|select programming language and tools|document recording programming choices|\n|implementing|write/create software program.|documented source code with comments; explanation of function; in-data and expected out-data for each structured module. how modules influence each other. if program is purchased, how is access to source code guaranteed?|\n|testing (modules)|make sure each module only accepts allowed in-data and gives only allowed out-data.|sample reports from testing if possible. has testing covered boundaries of limits and also the input of invalid data? have all tests been documented? have all errors/failures been followed up?|\n|testing (integrated modules)|same type of tests but applied after integrating the modules.|same kind of review of evidence. if the program is purchased, then validation proof needs to have been assessed by regulated user.|\n|maintenance|correct errors, update versions when needed.|formal routines and records for configuration management and change control. regression testing and periodic evaluation (as a system goes through multiple changes over time)|\n|documentation|system documentation (including software) correct and updated.|user handbook, supporting sops, correct versions.|\n|re-validation|re-validate when changes are made to the program.|changes are reviewed and decisions documented. routines and records are in-place, scoped dependent on the size/complexity of the changes|\n|other matters|alternative routines are put in place for system failure and training includes this.|the alternative routines are documented, including training records.|\n\nsome of the details below are not relevant for cots but it is necessary to have clearly defined the requirements for intended use and to have assessed the applications fitness for purpose.\n\nunder some circumstances, access to source code cannot be guaranteed. regulated users are expected to have assessed the business risks and put in place contingency measures in the event of the business failure of the supplier.\n\npi 011-3 page 35 of 50 25 september 2007", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "b81199f1-9a7b-4916-b548-689db655094f": {"__data__": {"id_": "b81199f1-9a7b-4916-b548-689db655094f", "embedding": null, "metadata": {"page_label": "40", "file_name": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_type": "application/pdf", "file_size": 453540, "creation_date": "2024-04-07", "last_modified_date": "2024-03-29", "document_title": "Validation and Control Measures for System Documentation and Testing: A Comprehensive Guide", "questions_this_excerpt_can_answer": "1. What specific elements and control measure checks are outlined in the \"Validation and Control Measures for System Documentation and Testing: A Comprehensive Guide\" for ensuring the integrity and functionality of computerized systems in a pharmaceutical context?\n\n2. How does the guide recommend verifying the correctness and completeness of data and documentation in the validation process of computerized systems, and what role does the regulated user play in this verification according to the document titled \"Validation and Control Measures for System Documentation and Testing: A Comprehensive Guide\"?\n\n3. What procedures does the \"Validation and Control Measures for System Documentation and Testing: A Comprehensive Guide\" suggest for the ongoing evaluation of computerized systems, including change control procedures, to maintain compliance and effectiveness within the pharmaceutical industry?", "prev_section_summary": "The section discusses the software development and maintenance process requirements and documentation guide according to the PIC_011_3 recommendation on computerised systems. Key topics include the evidence required for review during the development stage, handling and documentation of software testing, contingency measures for regulated users in case of supplier failure, and specific activities and documentation needed for each stage of the software life cycle such as development, testing, maintenance, and re-validation. Entities mentioned include documents like user requirements specifications (URS), functional specifications (FS), design specifications (DS), test plans, test scripts, source code, testing reports, configuration management records, user handbooks, and training records. Contingency measures and alternative routines for system failure are also highlighted.", "excerpt_keywords": "Validation, Control Measures, Computerized Systems, Pharmaceutical Industry, Documentation"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf\n|number|element|control measure checks|\n|---|---|---|\n|1.|define|is the system defined? what should it do? is there a written validation plan? are there full specifications? are there written protocols? (including acceptance criteria).|\n|2.|testing|do the test records show that in and out data meets the specifications?|\n|3.|documented results|are the results complete and documented?|\n|4.|verify correctness|are data and documentation correct and complete? have these been verified by the regulated user?|\n|5.|compare with acceptance criteria|have competent responsible personnel carried out the validation and review work? is this all documented?|\n|6.|conclusions|are conclusions complete, meaningful and based on results? are acceptance criteria fulfilled? are there any conditional conclusions?|\n|7.|approval|has approval been formally recorded? was there any qa/qc involvement at the regulated user?|\n|8.|on-going evaluation|what is the procedure to ensure on-going evaluation of the system? what are the change control procedures?|", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "c4a8887c-2b75-4658-bccb-53534e7d1046": {"__data__": {"id_": "c4a8887c-2b75-4658-bccb-53534e7d1046", "embedding": null, "metadata": {"page_label": "41", "file_name": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_type": "application/pdf", "file_size": 453540, "creation_date": "2024-04-07", "last_modified_date": "2024-03-29", "document_title": "Computerized System Validation and Compliance Requirements: A Comprehensive Guide", "questions_this_excerpt_can_answer": "1. What specific criteria do inspectors use to evaluate the cooperation of key personnel and computer specialists in the context of computerized system validation and compliance?\n \n2. How does the document detail the requirements for managing changes to system and programs, including the necessary steps for re-validation and approvals, in the realm of computerized systems within pharmaceutical environments?\n\n3. What are the outlined procedures and requirements for ensuring the physical and logical protection of data, specifically in relation to information security management and change management, as per the guide on Computerized System Validation and Compliance Requirements?", "prev_section_summary": "The section discusses the validation and control measures for system documentation and testing in the context of computerized systems in the pharmaceutical industry. Key topics include defining the system, testing, documenting results, verifying correctness of data and documentation, comparing with acceptance criteria, drawing conclusions, obtaining approval, and ongoing evaluation procedures such as change control. The regulated user plays a crucial role in verifying data and documentation correctness and completeness throughout the validation process. The section emphasizes the importance of thorough documentation, testing, and evaluation to ensure compliance and effectiveness of computerized systems in pharmaceutical settings.", "excerpt_keywords": "Computerized System Validation, Compliance Requirements, Pharmaceutical Environments, Information Security Management, Change Control"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf\n|point|requirement|inspectors check/comment|\n|---|---|---|\n|personnel (1)|key personnel/computer specialists cooperate.|check/comment|\n|personnel (1)|project and user personnel are trained and any necessary experts are involved.| |\n|validation (2)|life-cycle model; formal policy and procedures in place.| |\n|system (3)|influence of environment| |\n|(4)|there is a written, up to date, detailed description of the system.| |\n|(5)|software has been produced according to a quality assured system.| |\n|(6)|checks of data and calculations built in.| |\n|(7)|system tested and validated. verified against previous/or manual system being replaced.| |\n|(8)|data entry and change only by authorised personnel. password / security management.| |\n|(9)|critical data (gxp data) verified by a 2 person, or by a validated electronic method.| |\n|(10)|audit trail for data entry and processing.| |\n|(11)|alterations to system and programs subjected to rigorous change controls, including re-validation and approvals.| |\n|(12)|printed copies of electronically stored data available if needed?| |\n|(13) and gmp 4.9|physical and logical protection of data. information security management and change management.| |\n|(14)|data back up procedures; separate and secure media and locations.| |\n|(15)|alternative routine arrangements established in the event of system failure.| |\n|(16)|validated alternative arrangements (15) defined and documented. records of failures and remediation exist.| |\n|(17)|records show the analysis of errors and corrective actions taken.| |\n|(18)|service level agreements or contracts in place for services provided by outside agencies for computerised systems at regulated users sites.| |\n|(19)|responsibilities in chain of release of batches defined and linked to qp.| |", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "e646709c-3626-46b7-958c-1fd91cc3c615": {"__data__": {"id_": "e646709c-3626-46b7-958c-1fd91cc3c615", "embedding": null, "metadata": {"page_label": "42", "file_name": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_type": "application/pdf", "file_size": 453540, "creation_date": "2024-04-07", "last_modified_date": "2024-03-29", "document_title": "\"Guide to System Inspection and Maintenance: Key Considerations for Ensuring Optimal Performance\"", "questions_this_excerpt_can_answer": "1. What specific concerns should be addressed regarding personnel dependency in the context of computerized system inspections within pharmaceutical environments, as outlined in the \"Guide to System Inspection and Maintenance\"?\n\n2. How does the document \"Guide to System Inspection and Maintenance\" recommend involving management and quality organizations in the inspection process of computerized systems to ensure optimal performance?\n\n3. What are the recommended practices for maintaining and securing computerized systems, including validation, access control, and routine self-inspections, as detailed in the \"Guide to System Inspection and Maintenance\"?", "prev_section_summary": "The section discusses the criteria inspectors use to evaluate the cooperation of key personnel and computer specialists in computerized system validation and compliance. It also details requirements for managing changes to systems and programs, including re-validation steps. Additionally, the section outlines procedures for ensuring the physical and logical protection of data, including information security management and change management. Key topics include personnel training, system validation, data protection, change controls, data backup procedures, and service level agreements for computerized systems. Key entities mentioned are key personnel, computer specialists, project and user personnel, validated electronic methods, data entry controls, and service providers for computerized systems.", "excerpt_keywords": "personnel, organisation, data system, validation, security"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf\n|number|area|remember|\n|---|---|---|\n|1.|personnel|is there only one key person? (dependence on only one person may be catastrophic).|\n|2.|organisation|is management involved?|\n|3.|organisation|is the quality organisation involved?|\n|4.|data system|early during the inspection, ask for a complete overview of the system(s) including flow of data.|\n|5.|data system|the use of parallel systems may indicate grey areas and potential system weaknesses.|\n|6.|validation|has terminology actually been defined? is it used correctly?|\n|7.|security|how is access controlled? information security management?|\n|8.|maintenance|is there a maintenance manual of each system detailing what to do on a periodic basis? (daily, weekly, monthly etc). are there corresponding records of compliance?|\n|9.|control of system|routines for configuration management, and change control in place?|\n|10.|self-inspections|are self-inspection routines in place?|", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "e2a206ca-d30f-4d30-81bc-d29fd78f0ea2": {"__data__": {"id_": "e2a206ca-d30f-4d30-81bc-d29fd78f0ea2", "embedding": null, "metadata": {"page_label": "43", "file_name": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_type": "application/pdf", "file_size": 453540, "creation_date": "2024-04-07", "last_modified_date": "2024-03-29", "document_title": "Automated System Validation and Maintenance Process Guide", "questions_this_excerpt_can_answer": "1. What are the specific steps involved in the validation and maintenance process of automated systems as outlined in the \"Automated System Validation and Maintenance Process Guide\"?\n \n2. How does the guide recommend handling the assessment and categorization of system components during the validation strategy phase for automated systems?\n\n3. What criteria does the \"Automated System Validation and Maintenance Process Guide\" suggest for deciding whether a supplier audit is necessary during the validation process of automated systems?", "prev_section_summary": "The section provides recommendations for ensuring optimal performance of computerized systems in pharmaceutical environments. Key topics include addressing personnel dependency, involving management and quality organizations in inspections, maintaining and securing systems through validation, access control, and routine self-inspections. The section outlines specific areas to consider during system inspections, such as personnel, organization involvement, data systems, validation, security, maintenance, control of systems, and self-inspections. These recommendations aim to enhance the reliability and effectiveness of computerized systems in pharmaceutical settings.", "excerpt_keywords": "Automated systems, Validation process, Maintenance process, System components, Supplier audit"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf\n|step|task|description|\n|---|---|---|\n|1.|identify system|each automated system should be assessed and gxp regulated systems identified.|\n|2.|produce urs|the urs should define clearly and precisely what the user wants the system to do, state any constraints, and|\n|3.|determine validation strategy|- risk assessment - an initial risk assessment should be carried out during validation planning. further assessments should be performed as specifications are developed.\n- assessment of system components - system components should be assessed and categorized to determine the validation approach required. the output from this assessment will feed into the validation plan.\n- supplier assessment - suppliers should be formally assessed as part of the process of selecting a supplier and planning for validation. the decision whether to perform a supplier audit should be documented and based on a risk assessment and categorization of the system components.\n|\n|4.|produce validation plan|the validation plan should define the activities, procedures, and responsibilities for establishing the adequacy of the system. it typically defines what risk assessments are to be performed.|\n|5.|review and approve specifications, including the system description|the user should review and approve specifications produced by the supplier.|\n|6.|monitor development of system|the user should monitor development and configuration activities against an agreed plan.|\n|7.|review source code|the user should ensure that source code is adequately reviewed during system development.|\n|8.|review and approve test specifications|the user should review and approve test specifications prior to formal testing.|\n|9.|perform testing|the user may be involved in testing, as a witness during test execution, or as a reviewer of test results.|\n|10.|review and approve test reports|the user should approve the test reports and associated test results.|\n|11.|produce validation report|the validation report should summarize all deliverables and activities and provides evidence that the system is validated.|\n|12.|maintain system|once the system has been accepted, the user should establish adequate system management and operational procedures.|\n|13.|system retirement|the user should manage the replacement or withdrawal of the automated system from use.|\n\nrefer also to section 15 for context (validation strategy for different systems).\n\npi 011-3 page 39 of 50 25 september 2007", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "31aa0665-9219-43f8-bd70-46ad18650454": {"__data__": {"id_": "31aa0665-9219-43f8-bd70-46ad18650454", "embedding": null, "metadata": {"page_label": "44", "file_name": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_type": "application/pdf", "file_size": 453540, "creation_date": "2024-04-07", "last_modified_date": "2024-03-29", "document_title": "Comprehensive Guide to Good Manufacturing Practice (GMP) Standards and Regulations", "questions_this_excerpt_can_answer": "1. What specific ISO standards are referenced in the \"Comprehensive Guide to Good Manufacturing Practice (GMP) Standards and Regulations\" for the application of quality management and assurance in the development, supply, installation, and maintenance of computer software within the pharmaceutical manufacturing sector?\n\n2. How does the \"Comprehensive Guide to Good Manufacturing Practice (GMP) Standards and Regulations\" document integrate the PIC/S Guide to Good Manufacturing Practice for Medicinal Products, specifically referencing Annex 11, into its recommendations for computerized systems validation in the pharmaceutical industry?\n\n3. Can you detail the specific CFR sections related to electronic records and electronic signatures, hardware, software, quality system regulation, and good laboratory practice for non-clinical laboratory studies as outlined in the \"Comprehensive Guide to Good Manufacturing Practice (GMP) Standards and Regulations\" for ensuring compliance in pharmaceutical manufacturing?", "prev_section_summary": "The section outlines the specific steps involved in the validation and maintenance process of automated systems as per the \"Automated System Validation and Maintenance Process Guide.\" Key topics include identifying system components, producing user requirement specifications (URS), determining validation strategy through risk assessment and supplier assessment, producing a validation plan, reviewing and approving specifications and test reports, performing testing, maintaining the system, and managing system retirement. Entities mentioned include system components, suppliers, users, source code, test specifications, test reports, and validation reports.", "excerpt_keywords": "ISO standards, GMP guides, computerized systems, pharmaceutical manufacturing, electronic records"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf\n## references for relevant standards and gmp guides / codes\n\n|(1)|eu annex 11 to the eu guidelines of good manufacturing practice for medicinal products.|\n|---|---|\n|(2)|annex 11 to pic/s guide to good manufacturing practice for medicinal products, document ph 1/97 (rev. 3), pic/s secretariat, 9-11 rue de varembe, ch-1211 geneva 20|\n|(3)|gamp guide for validation of automated systems, gamp4 (ispe (gamp forum), 2001)|\n|(4)|australian code of gmp for medicinal products, august 2002.|\n|(5)|who guideline for gmp for manufacture of pharmaceutical products.|\n|(6)|relevant cfr sections of the usfda register: hardware 21 cfr 211.63, 67, 68 21 cfr part 11 electronic records: electronic signatures software 21 cfr 211.68, 180, 188, 192 21 cfr part 11 electronic records: electronic signatures quality system 21 cfr 820 quality system regulation glp 21 cfr 58 good laboratory practice for non-clinical laboratory studies|\n|(7)|iso standards: quality management and quality assurance iso 9000-1 part 1: guidelines for selection and use. iso 9000-3 part 3: guidelines for the application of iso9001:1994 to the development, supply, installation and maintenance of computer software. see also current tick-it guide for construction, software engineering, assessment and certification (see ref. 12 re:bsi disc london) quality management and quality system elements iso 9004-1 part 1: guidelines. iso 9004-2 part 2: guidelines for services. iso 9004-4 part 4: guidelines for quality improvement. iso 10005: 1995 quality management - guidelines for quality plans. iso 10007: 1995 quality management - guidelines for configuration management|", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "9e4b43b9-68e5-422d-8784-e46e9a8694ee": {"__data__": {"id_": "9e4b43b9-68e5-422d-8784-e46e9a8694ee", "embedding": null, "metadata": {"page_label": "45", "file_name": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_type": "application/pdf", "file_size": 453540, "creation_date": "2024-04-07", "last_modified_date": "2024-03-29", "document_title": "Software Life Cycle Management and Information Security Best Practices", "questions_this_excerpt_can_answer": "1. What specific standards and publications does the document recommend for managing the software life cycle and ensuring information security within the pharmaceutical industry, as outlined in the \"Software Life Cycle Management and Information Security Best Practices\" document?\n\n2. How does the document \"Software Life Cycle Management and Information Security Best Practices\" integrate IEEE standards with ISO/IEC norms and British Standards to provide a comprehensive framework for software life cycle management and information security in a pharmaceutical context?\n\n3. What are the specific parts and focus areas of the DISC PD 5000 series mentioned in the \"Software Life Cycle Management and Information Security Best Practices\" document, and how do they relate to electronic documents and e-commerce transactions within the pharmaceutical industry?", "prev_section_summary": "The section provides references to relevant standards and GMP guides/codes for the application of quality management and assurance in computerized systems within the pharmaceutical manufacturing sector. Key topics include ISO standards, EU guidelines, PIC/S Guide to Good Manufacturing Practice, GAMP guide for validation of automated systems, Australian Code of GMP, WHO guidelines, and CFR sections related to electronic records and signatures, hardware, software, quality system regulation, and good laboratory practice. The section emphasizes the importance of compliance with these standards for ensuring quality and regulatory compliance in pharmaceutical manufacturing.", "excerpt_keywords": "Software Life Cycle Management, Information Security, ISO/IEC Standards, IEEE Publications, British Standards"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf\n## life cycle management\n\n|iso/iec 12207:1995|information technology - software life cycle processes|\n|---|---|\n|iso/iec 17799:2000|(bs 7799-1:2000) information technology - code of practice for information security management.|\n|ieee publications:| |\n|ieee 729|glossary of software engineering terminology|\n|ieee 730|quality assurance plan|\n|ieee 828|software configuration management plans|\n|ieee 829|software test documentation|\n|ieee 830|guide to software requirements specification|\n|ieee 983|guide to software quality assurance planning|\n|ieee 1012|software verification plans|\n|ieee 1298|software quality management system part 1: requirements|\n|british standards:| |\n|bs 7799: 1999|information security management, bsi disc 389 chiswick high road, london w4 4al (tel:+44 181 995 7799 fax:+44 181 996 6411 http://www.bsi.org.uk/disc)|\n|bs 7799: 2000|information technology - code of practice for information management|\n|disc bsi guides| |\n|disc pd 5000 series of codes for electronic documents and e-commerce transactions as legally admissible evidence (including disc pd 0008:1999 in pt 1):| |\n|pt 1|information stored electronically|\n|pt 2|electronic communication and e-mail policy|\n|pt 3|identity signature and copyright|\n|pt 4|using certification authorities|\n|pt 5|using trusted third party archives|\n|disc pd 3002|guide to bs 7799 risk assessment and risk management (isbn 0 580 29551 6)|\n|disc pd 3005|guide on the selection of bs 7799 controls (isbn 0 580 33011 7)|\n|guidance for industry, part 11, electronic records; electronic signatures - scope and application, us dept. of health and human services and all fda centers/ offices, february 2003. (\\\\cds029\\cderguid\\5505dft.doc) - draft guidance for comment.| |\n\npi 011-3 page 41 of 50 25 september 2007", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "96163ac3-da6f-46d8-941c-6d0db53f4ecd": {"__data__": {"id_": "96163ac3-da6f-46d8-941c-6d0db53f4ecd", "embedding": null, "metadata": {"page_label": "46", "file_name": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_type": "application/pdf", "file_size": 453540, "creation_date": "2024-04-07", "last_modified_date": "2024-03-29", "document_title": "\"Best Practices for Computer Systems Validation in Pharmaceutical and Medical Industries: A Comprehensive Guide\"", "questions_this_excerpt_can_answer": "1. What are some key publications that provide guidance on best practices for computer systems validation specifically within the pharmaceutical and medical device industries, including their publication years and ISBNs?\n\n2. How does the document \"Best Practices for Computer Systems Validation in Pharmaceutical and Medical Industries: A Comprehensive Guide\" incorporate international standards and guidelines, such as those from the FDA, PDA, and ICH, into its recommendations for computerized system validation?\n\n3. Can you identify specific technical reports or guidelines that focus on the validation and qualification of computerized laboratory data acquisition systems and the auditing of suppliers providing computer products and services for regulated pharmaceutical operations, including their publication years and issuing organizations?", "prev_section_summary": "The section discusses software life cycle management and information security best practices within the pharmaceutical industry. It outlines specific standards and publications recommended for managing the software life cycle, such as ISO/IEC 12207 and IEEE publications. It also integrates IEEE standards with ISO/IEC norms and British Standards to provide a comprehensive framework for software life cycle management and information security. The section mentions the DISC PD 5000 series, focusing on electronic documents and e-commerce transactions within the pharmaceutical industry. It also references guidance for industry on electronic records and signatures.", "excerpt_keywords": "computer systems validation, pharmaceutical industry, medical device, software validation, regulatory guidelines"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf\ngood computer validation practices - common sense implementation [stokes, branning, chapman, hambloch & trill. interpharm press, usa: isbn: 0-935184-55-4]\ncomputer systems validation for pe pharmaceutical and medical device industries [chamberlain. isbn 0-9631489-0-8]\nvalidating automated manufacturing and laboratory applications, [wingate et al., interpharm press, usa: isbn 1-57491-037-x]\nvalidation of computerized analytical systems, interpharm press, l. huber, isbn: 0-935184-75-9, 1995\ngeneral principles of software validation - final guidance for industry and fda staff (fda, cdrh, january 2002)\npda technical report no 18, \"validation of computer-related systems\", pda journal of pharmaceutical science and technology, 1995 supplement, vol. 49, no.s1\npda technical report no. 32, \"report on pe auditing of suppliers providing computer products and services for regulated pharmaceutical operations\" (pda, 1999)\nvalidation of process control systems: a guideline by gma & namur, in section 5 of gamp-3 (1998) vol. 2, best practice for users and suppliers.\npda technical report no. 31: \"validation and qualification of computerised laboratory data acquisition systems\", pda journal of pharmaceutical science and technology, 1999 supplement, vol. 53, no.4\nguidance for industry - computerized systems used in clinical trials, us fda, april 1999\nglp consensus document the application of pe principles of glp to computerised systems, 1995, oecd/ ocde/gd (95) 115 (environment monograph no.116)\ncomputer systems validation in clinical research, 1997, acdm/ psi working party. (acdm, po box 129, macclesfield, cheshire sk11 8fg england)\nich topic e6: guideline for good clinical practice. (ich-gcp/cpmp/ich/135/95)\neu gmp guide annex 15, qualification and validation, european commission, july 2001, (based on pic/s recommendations)\napv guidance, appendix 9 to gamp4 guide for validation of automated systems, ispe (gamp forum), 2001", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "5a65c69f-02ce-46f4-99cf-b02d2567e403": {"__data__": {"id_": "5a65c69f-02ce-46f4-99cf-b02d2567e403", "embedding": null, "metadata": {"page_label": "47", "file_name": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_type": "application/pdf", "file_size": 453540, "creation_date": "2024-04-07", "last_modified_date": "2024-03-29", "document_title": "Electronic Signature and Software Terminology in GMP Compliance: A Comprehensive Guide", "questions_this_excerpt_can_answer": "1. What are the specific requirements that an electronic signature must meet according to the EU directive 1999/93/EC to be considered an advanced electronic signature, as outlined in the document \"Electronic Signature and Software Terminology in GMP Compliance: A Comprehensive Guide\"?\n\n2. How does the document \"Electronic Signature and Software Terminology in GMP Compliance: A Comprehensive Guide\" define \"application-specific software,\" and which technical report provides the basis for this definition?\n\n3. In the context of GMP compliance, how is a \"bespoke\" system characterized according to the document \"Electronic Signature and Software Terminology in GMP Compliance: A Comprehensive Guide,\" and which guideline provides the definition for this term?", "prev_section_summary": "This section provides a list of key publications and guidelines related to computer systems validation in the pharmaceutical and medical industries. It includes information on various publications, such as \"Good Computer Validation Practices,\" \"Validation of Computerized Analytical Systems,\" and \"Validation of Process Control Systems.\" The section also mentions guidelines from organizations like the FDA, PDA, ICH, and EU GMP Guide Annex 15. Overall, the excerpt highlights the importance of following best practices and standards when validating computerized systems in regulated industries.", "excerpt_keywords": "Electronic Signature, GMP Compliance, Computerised Systems, Bespoke System, Software Terminology"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf\n## glossary of terms\n\nthis glossary has been extracted predominantly from the eu gmp annex 15, qualification and validation document, [see further reading ref:14]; the gamp guide; and the pda technical report no 18. the list of definitions has been compiled to reflect the current terminology generally accepted internationally. inspectors may have to correlate or adapt the terms in the light of internal policies, standards and guidelines used by regulated users companies and relevant sdlc methodologies. the sources of each of the definitions have been identified in the following manner:\n\n- eu gmp annex 15 pic/s document definitions are recorded as (1);\n- gamp definitions are recorded as (2);\n- pda technical report no. 18 definitions are recorded as (3);\n- ec directive 1999/93/ec on a community framework for electronic signature, (official journal of the european communities, 19.1.2000), (4);\n- definitions elaborated in this pic/s document do not carry a suffix number.\n\n### advanced electronic signature\n\n(eu) means an electronic signature, which meets the following requirements:\n\n- (a) it is uniquely linked to the signatory;\n- (b) it is capable of identifying the signatory;\n- (c) it is created using means that the signatory can maintain under his control; and\n- (d) it is linked to the data to which it relates in such a manner that any change of the data is detectable. (4)\n\n### application-specific software\n\na software program developed or adapted to the specific requirements of the application. (3)\n\n### automated system\n\nterm used to cover a broad range of systems, including automated manufacturing equipment, control systems, automated laboratory systems manufacturing execution systems and computers running laboratory or manufacturing database systems. the automated system consists of the hardware, software and network components, together with the controlled functions and associated documentation. automated systems are sometimes referred to as computerised systems; in this guide the two terms are synonymous. (2) (gamp 4 (3) scope page 14)\n\n### bespoke\n\na system produced for a customer, specifically to order, to meet a defined set of user requirements. (2)\n\n### bug\n\na manifestation of an error in software (a fault). (2)", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "79ee2f24-3882-46e8-ab2b-562f0cbda043": {"__data__": {"id_": "79ee2f24-3882-46e8-ab2b-562f0cbda043", "embedding": null, "metadata": {"page_label": "48", "file_name": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_type": "application/pdf", "file_size": 453540, "creation_date": "2024-04-07", "last_modified_date": "2024-03-29", "document_title": "Change Control and Configuration Management in Computer Systems: A Comprehensive Guide", "questions_this_excerpt_can_answer": "1. What is the formal system called that involves the review of proposed or actual changes affecting a validated status of facilities, systems, equipment, or processes to ensure maintenance of a validated state, and how does the FDA relate to this process according to the document \"Change Control and Configuration Management in Computer Systems: A Comprehensive Guide\"?\n\n2. How does the document \"Change Control and Configuration Management in Computer Systems: A Comprehensive Guide\" define \"Commercial Off-The-Shelf (COTS)\" programs, and what distinguishes these programs from other software solutions in terms of customization?\n\n3. According to the document \"Change Control and Configuration Management in Computer Systems: A Comprehensive Guide,\" what constitutes a computerised system, and how does the document suggest expanding the traditional definition to accommodate the integration of computers with external influences in their operating environment?", "prev_section_summary": "The section discusses key terms related to electronic signatures and software terminology in GMP compliance. It covers definitions such as advanced electronic signature, application-specific software, automated system, bespoke system, and bug. The section also references sources for these definitions, including EU GMP Annex 15, the GAMP guide, and the PDA Technical Report No. 18. It provides a comprehensive glossary of terms commonly used in the industry and highlights the importance of understanding and applying these terms in the context of GMP compliance.", "excerpt_keywords": "Change Control, Configuration Management, Computerised Systems, Commercial Off-The-Shelf, Debugging"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf\n## change control\n\na formal system by which qualified representatives of appropriate disciplines review proposed or actual changes that might affect a validated status of facilities, systems, equipment or processes. the intent is to determine the need for action that would ensure that the system is maintained in a validated state. (1)\n\n[authors note: fda may specifically require evidence of pre and post implementation reviews of changes. the latter to detect any unauthorised changes that may have been made despite established procedures. these are quality assurance activities.]\n\n## commercial off-the-shelf (cots)\n\nconfigurable programs- stock programs that can be configured to specific user applications by \"filling in the blanks\", without (cots) altering the basic program. (3)\n\n## computer hardware\n\nvarious pieces of equipment in the computer system, including the central processing unit, the printer, the modem, the cathode ray tube (crt), and other related apparatus. (3) (see also figure 1, page 8, of this document).\n\n## computer system\n\ncomputer hardware components assembled to perform in conjunction with a set of software programs, which are collectively designed to perform a specific function or group of functions. (3) (see also figure 1, page 8, of this document).\n\n## computerised system\n\na computer system plus the controlled function that it operates. (3)\n\n[authors note: today this may be considered to be rather a narrow definition, especially in the context of integrated computers. the definition should therefore include all outside influences that interface with the computer system in its operating environment. these may typically include monitoring and network links, (to/from other systems or instruments), manual (keypad inputs), links to different media, manual procedures and automation. the term also covers automated instruments and systems. see also the definition for automated systems in this section and section 26, reference 11, the glp oecd consensus document. pic/s gmp annex 11(4) is relevant here regarding documenting the scope and interaction of systems.]\n\n## configuration\n\nthe documented physical and functional characteristics of a particular item, or system, e.g. software, computerised system, hardware, firmware and operating system. a change converts one configuration into a new one.\n\n## configuration management\n\nthe process of identifying and defining the configuration items in a system, controlling the release and change of these items throughout the system life cycle, recording and reporting the status of configuration items and change requests, and verifying the completeness and correctness of configuration items. (2)\n\n## debugging (ieee)\n\nthe process of locating, analysing, and correcting suspected faults. (2)\n\npi 011-3 page 44 of 50 25 september 2007", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "be9c0e9c-0ee0-429b-b828-abdca4eb0c52": {"__data__": {"id_": "be9c0e9c-0ee0-429b-b828-abdca4eb0c52", "embedding": null, "metadata": {"page_label": "49", "file_name": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_type": "application/pdf", "file_size": 453540, "creation_date": "2024-04-07", "last_modified_date": "2024-03-29", "document_title": "Electronic Signature and System Specifications in Computer Technology: A Comprehensive Guide", "questions_this_excerpt_can_answer": "1. How does the document define the term \"electronic signature\" in the context of both FDA and EU regulations, and how do these definitions compare to each other?\n \n2. What is the purpose of an embedded system as described in the document, and how is it distinguished from a standalone computer system?\n\n3. According to the document, what are the key components and processes involved in functional testing of a computerized system?", "prev_section_summary": "This section discusses the concepts of change control, commercial off-the-shelf (COTS) programs, computer hardware, computer systems, computerised systems, configuration, configuration management, and debugging. It defines these terms and explains their importance in maintaining the validated status of facilities, systems, equipment, and processes. The section also highlights the need to expand the traditional definition of computerised systems to include external influences in their operating environment. Additionally, it mentions the FDA's requirements for pre and post implementation reviews of changes to detect unauthorized changes.", "excerpt_keywords": "Electronic Signature, Embedded System, Executive Program, Firmware, Functional Testing"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf\n## electronic signature\n\nan electronic measure that can be substituted for a handwritten signature or initials for the purpose of signifying approval, authorisation or verification of specific data entries. see also definition for advanced electronic signature, above.\n\nelectronic signature (fda)\n\n21 cfr part11 defines this as: the computer data compilation of any symbol or series of symbols executed, adopted, or authorised by an individual to be the legally binding equivalent of the individuals hand-written signature.\n\nelectronic signature (eu)\n\n1999/93/ec states: electronic signature means data in electronic form which are attached to or logically associated with other electronic data and which serve as a method of authentication. (see also advanced electronic signature)\n\n## embedded system\n\na system, usually microprocessor or plc based, whose sole purpose is to control a particular piece of automated equipment. this is contrasted with a standalone computer system.\n\n## executive program (ansi/ieee/aso)\n\na computer program, usually part of the operating system, that controls the execution of other computer programs and regulates the flow of work in a data processing system.\n\n## firmware\n\na software program permanently recorded in a hardware device, such as an eprom. (note: eprom stands for erasable programmable read only memory)\n\n## functional requirements (ansi/ieee)\n\nstatements that describe functions a computer-related system must be capable of performing.\n\n## functional specifications\n\nstatements of how the computerised system will satisfy functional requirements of the computer-related system.\n\n## functional testing\n\na process for verifying that software, a system, or a system component performs its intended functions.\n\n## hardware acceptance test specification\n\nstatements for the testing of all key aspects of hardware installation to assure adherence to appropriate codes and approved design intentions and that the recommendations of the regulated user have been suitably considered.\n\n## hardware design specification (apv)\n\ndescription of the hardware on which the software resides and how it is to be connected to any system or equipment.\n\n## hybrid systems\n\nrefer to section 21.6 of this document\n\npi 011-3 page 45 of 50 25 september 2007", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "e83b0402-71b4-4dd5-8b7e-c31c63beee24": {"__data__": {"id_": "e83b0402-71b4-4dd5-8b7e-c31c63beee24", "embedding": null, "metadata": {"page_label": "50", "file_name": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_type": "application/pdf", "file_size": 453540, "creation_date": "2024-04-07", "last_modified_date": "2024-03-29", "document_title": "Comprehensive Guide to Computer System Development and Integration Testing in Legacy Systems with a Focus on Life Cycle Concept, Loop Testing, Network, Operating Environment, Operating System, and Public Key Infrastructure.", "questions_this_excerpt_can_answer": "1. What is the definition of integration testing according to the IEEE, and how does it apply to both software and hardware elements within computerized systems?\n \n2. How does the document describe the characteristics and challenges associated with legacy computerized systems, particularly in relation to GMP compliance and validation documentation?\n\n3. Can you explain the difference between a private and public PKI as outlined in the document, including their respective applications and benefits within secure communication frameworks?", "prev_section_summary": "The section discusses electronic signatures, embedded systems, executive programs, firmware, functional requirements, functional specifications, functional testing, hardware acceptance test specifications, hardware design specifications, and hybrid systems. It defines electronic signatures according to FDA and EU regulations, explains the purpose of embedded systems, and outlines the key components and processes involved in functional testing of computerized systems.", "excerpt_keywords": "integration testing, legacy computerised systems, life cycle concept, loop testing, public key infrastructure"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf\n## integration testing (ieee)\n\nan orderly progression of testing in which software elements, hardware elements, or both are combined and tested until the entire system has been integrated. (2)\n\n## interface (ansi/ieee)\n\na shared boundary. to interact or communicate with another system component. (2)\n\n## legacy computerised systems\n\nthese are regarded as systems that have been established and in use for some considerable time. for a variety of reasons, they may be generally characterised by lack of adequate gmp compliance related documentation and records pertaining to the development and commissioning stage of the system. additionally, because of their age there may be no records of a formal approach to validation of the system.\n\n## life cycle concept\n\nan approach to computer system development that begins with (pma csvc) identification of the users requirements, continues through design, integration, qualification, user validation, control and maintenance, and ends only when commercial use of the system is discontinued. (2)\n\n## loop testing\n\nchecking the installed combination of elements characterising each type of input/output loop. (2)\n\n## network (ansi/ieee & gamp)\n\n(a) an interconnected, or interrelated group of nodes.\n(b) an interconnected communications facility. a local area network (lan) is a high bandwidp (allowing a high data transfer rate) computer network operating over a small area such as an office or group of offices. (2)\n\n## operating environment\n\nthose conditions and activities interfacing directly or indirectly with the system of concern, control of which can affect the systems validated state. (3)\n\n## operating system\n\na set of software programs provided with a computer that function as the interface between the hardware and the applications program. (3)\n\n## public key infrastructure\n\npublic key infrastructure (pki) provides a framework for secure communication, using a combination of public-key cryptography and digital certificates. pkis can exist within many different domains but essentially there are two types: a private pki is deployed by a corporation for the benefit of its business and any related parties (e.g. customers, suppliers). public pkis (using trusted third parties) are deployed on open systems, such as the internet and facilitate security between previously unrelated parties.", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "3e6142f2-39cb-4f3f-aa3d-85dc703eed77": {"__data__": {"id_": "3e6142f2-39cb-4f3f-aa3d-85dc703eed77", "embedding": null, "metadata": {"page_label": "51", "file_name": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_type": "application/pdf", "file_size": 453540, "creation_date": "2024-04-07", "last_modified_date": "2024-03-29", "document_title": "Ensuring Data Integrity and Security in Computerized Systems: A Comprehensive Guide", "questions_this_excerpt_can_answer": "1. What definition does the document provide for \"raw data\" in the context of computerized systems, and how does it emphasize the importance of this data for the reconstruction and evaluation of work projects or studies?\n \n2. How does the document differentiate between a \"standalone system\" and an \"embedded system\" in terms of their functions and purposes within computerized environments?\n\n3. What specific requirements does the document mention regarding the retention of electronic records, including raw data, in compliance with FDA's 21 CFR Part 11, and how does it relate to the ability to reconstruct studies and reports from raw data?", "prev_section_summary": "The section discusses integration testing according to IEEE standards, legacy computerized systems, life cycle concept, loop testing, network, operating environment, operating system, and public key infrastructure. It defines integration testing as the combination and testing of software and hardware elements until the entire system is integrated. Legacy computerized systems are characterized by lack of GMP compliance documentation and validation records. The life cycle concept involves user requirements identification, design, integration, qualification, user validation, control, maintenance, and system discontinuation. Loop testing checks the installed combination of input/output loops. The network is defined as an interconnected group of nodes or communications facility. The operating environment includes conditions affecting the system's validated state. The operating system serves as the interface between hardware and applications. Public key infrastructure provides secure communication using public-key cryptography and digital certificates, with private PKI for corporations and public PKI for open systems like the internet.", "excerpt_keywords": "raw data, computerized systems, data integrity, electronic records, FDA regulations"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf\n## raw data\n\nany work-sheets, records, memoranda, notes, or exact copies thereof, that are the result of original observations and activities and which are necessary for the reconstruction and evaluation of a work project, process or study report, etc. raw data may be hard/paper copy or electronic but must be known and defined in system procedures.\n\n## regulated user\n\nthe regulated good practice entity, that is responsible for the operation of a computerised system and the applications, files and data held thereon. (see also user)\n\n## revalidation\n\nrepetition of the validation process or a specific portion of it.\n\n## security (ieee)\n\nthe protection of computer hardware and software from accidental or malicious access, use, modification, destruction or disclosure. security also pertains to personnel, data, communications and the physical protection of computer installations.\n\n## source code (pma csvc)\n\nan original computer program expressed in human-readable form (programming language), which must be translated into machine-readable form before it can be executed by the computer.\n\n## standalone system\n\na self-contained computer system, which provides data processing, monitoring or control functions but which is not embedded within automated equipment. this is contrasted with an embedded system, the sole purpose of which is to control a particular piece of automated equipment.\n\n## structural integrity (software)\n\nsoftware attributes reflecting the degree to which source code satisfies specified software requirements and conforms to contemporary software development practices and standards.\n\n## structural testing\n\nexamining the internal structure of the source code. includes low-level and high-level code review, path analysis, auditing of programming procedures and standards actually used, inspection for extraneous \"dead code\", boundary analysis and other techniques. requires specific computer science and programming expertise.\n\n## structural verification\n\nan activity intended to produce documented assurance that software has appropriate structural integrity.\n\n58 pic/s authors note on raw data- for information: fdas 21 cfr part 11 requires the retention of electronic records in electronic form (thus including raw data electronically captured or recorded). also, for all good practice disciplines regulated by competent authorities it must be possible to reconstruct studies and reports from raw data and the electronic records may be needed to support any paper printouts.\n\npi 011-3 page 47 of 50 25 september 2007", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "afa5438a-74b8-47a4-b607-515bea91b4b4": {"__data__": {"id_": "afa5438a-74b8-47a4-b607-515bea91b4b4", "embedding": null, "metadata": {"page_label": "52", "file_name": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_type": "application/pdf", "file_size": 453540, "creation_date": "2024-04-07", "last_modified_date": "2024-03-29", "document_title": "System Acceptance Test Specification and System Software Validation Document", "questions_this_excerpt_can_answer": "1. What are the key components that should be addressed in a system acceptance test specification according to the document \"System Acceptance Test Specification and System Software Validation Document\"?\n\n2. How does the document \"System Acceptance Test Specification and System Software Validation Document\" define the term \"unplanned (emergency) change\" in the context of validated computerised systems, and what is its alternative name?\n\n3. What guidance does the document \"System Acceptance Test Specification and System Software Validation Document\" offer regarding the approval process for the system acceptance test specification document?", "prev_section_summary": "The section discusses key topics related to computerized systems, data integrity, and security. It defines \"raw data\" as essential for reconstructing and evaluating work projects or studies. It differentiates between standalone and embedded systems in computerized environments. The section also mentions requirements for retaining electronic records, including raw data, in compliance with FDA's 21 CFR Part 11 to reconstruct studies and reports. Other topics covered include regulated users, revalidation, security, source code, structural integrity, structural testing, and structural verification. The importance of maintaining electronic records for reconstructing studies and reports is emphasized throughout the section.", "excerpt_keywords": "system acceptance test specification, system software, system specifications, unplanned change, validation of computerised systems"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf\n## system acceptance test specification\n\nthe system acceptance test specification is a description of those tests to be carried out to permit acceptance of the system by the user. typically it should address the following:\n\n- system functionality\n- system performance\n- critical parameters\n- operating procedures\n\nthe tests should ensure that the product operates as indicated in the functional specification and meets the user requirements as defined in the urs. the tests typically include limit, alarms and boundary testing.\n\nthe system acceptance test specification is a contractual document and, as such, should be approved by both the supplier/ developer/ integrator and the end user.\n\nan example procedure for producing a system acceptance test specification is given in a gamp guide appendix.\n\n## system software\n\nsoftware designed to facilitate the operation and maintenance of a computer system and its associated programs, such as operating systems, assemblers, utilities, network software and executive programs. system software is generally independent of the specific application.\n\n## system specifications (pma csvc)\n\ndescribe how the system will meet the functional requirements.\n\n## unplanned (emergency) change (pma csvc)\n\nan unanticipated necessary change to a validated system requiring rapid implementation, also known as a \"hot-fix\".\n\n## user\n\nthe company or group responsible for the operation of a system. (see also regulated user). the gxp customer, or user organisation, contracting a supplier to provide a product. in the context of this document it is, therefore, not intended to apply only to individuals who use the system, and is synonymous with customer.\n\n## utility software (ansi/ieee)\n\ncomputer programs or routines designed to perform some general support function required by other application software, by the operating system, or by system users.\n\n## validation of computerised systems\n\nsee text section 14.2 for definition.\n\nthis can be very risky. fix testing/ implementation work should ideally not be carried out initially in the live environment. all changes to the live validated system(s) must be subjected to the firms change control, configuration management and validation procedural controls, to ensure compliance with gmp and the maintenance of a validated state.\n\npi 011-3 page 48 of 50 25 september 2007", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "e88a91b2-6977-46ff-b678-fc2e5aae3f50": {"__data__": {"id_": "e88a91b2-6977-46ff-b678-fc2e5aae3f50", "embedding": null, "metadata": {"page_label": "53", "file_name": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_type": "application/pdf", "file_size": 453540, "creation_date": "2024-04-07", "last_modified_date": "2024-03-29", "document_title": "Standards and Practices in the Pharmaceutical Industry: A Comprehensive Guide", "questions_this_excerpt_can_answer": "1. What does the acronym \"GAMP\" stand for in the context of pharmaceutical industry standards and practices, and how is it defined according to the document titled \"Standards and Practices in the Pharmaceutical Industry: A Comprehensive Guide\"?\n\n2. In the document \"Standards and Practices in the Pharmaceutical Industry: A Comprehensive Guide,\" how is \"GxP\" described, and what does it encompass within the regulated pharmaceutical sector supply chain?\n\n3. According to the document \"Standards and Practices in the Pharmaceutical Industry: A Comprehensive Guide,\" what organizations or standards are associated with the acronyms \"ISPE\" and \"LIMS,\" and what do they represent within the pharmaceutical industry?", "prev_section_summary": "The section discusses the system acceptance test specification, system software, system specifications, unplanned (emergency) change, user, utility software, and validation of computerised systems. Key topics include the components of a system acceptance test specification, the definition of unplanned (emergency) change, and the importance of validation and compliance with GMP in making changes to validated systems. The section emphasizes the contractual nature of the system acceptance test specification and the need for approval by both the supplier/developer/integrator and the end user.", "excerpt_keywords": "GAMP, GxP, ISPE, LIMS, pharmaceutical industry"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf\n|ansi|american national standards institute|\n|---|---|\n|apv|arbeitsgemeinschaft fur pharmazeutische verfahrenstechnik e.v.|\n|bsi|british standards institute|\n|dcs|distributed control system|\n|dr|design review|\n|ds|design specification|\n|dq|design qualification|\n|edp|electronic data processing|\n|eu|european union|\n|fda|us food and drug administration|\n|fs|functional specification|\n|gamp|good automated manufacturing practice|\n|gcp|good clinical practice|\n|gdp|good distribution practice|\n|glp|good laboratory practice|\n|gmp|good manufacturing practice|\n|gxp|compliance requirements for all good practice disciplines in the regulated pharmaceutical sector supply chain from discovery to post marketing.|\n|iec|international electrical commission|\n|ieee|institute of electrical and electronics engineers, inc.|\n|iq|installation qualification|\n|isms|information security management system|\n|iso|international standards organisation|\n|ispe|international society for pharmaceutical engineering|\n|lims|laboratory information management system|\n|lan|local area network|", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "86379eec-d702-4fae-86e5-670bacecc4b4": {"__data__": {"id_": "86379eec-d702-4fae-86e5-670bacecc4b4", "embedding": null, "metadata": {"page_label": "54", "file_name": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[35] PIC_011_3_recommendation_on_computerised_systems.pdf", "file_type": "application/pdf", "file_size": 453540, "creation_date": "2024-04-07", "last_modified_date": "2024-03-29", "document_title": "Key Acronyms and Terms in Manufacturing and Quality Control Systems: A Comprehensive Guide", "questions_this_excerpt_can_answer": "1. What specific version of the PIC/S recommendation on computerised systems introduced a revision history, and what was the date of this introduction?\n \n2. As of the last modification date provided in the document, what are the key acronyms and terms related to manufacturing and quality control systems that are essential for understanding the pharmaceutical industry's regulatory environment?\n\n3. What was the reason for the update to version PI 011-3 of the PIC/S recommendation on computerised systems, and on what date was this version officially published?", "prev_section_summary": "The section provides a list of acronyms commonly used in the pharmaceutical industry, along with their definitions. Key topics include standards organizations such as ANSI, APV, BSI, and ISPE, as well as regulatory bodies like the FDA and EU. The acronyms cover various aspects of pharmaceutical operations, from manufacturing (GMP, GAMP) to clinical trials (GCP) and distribution (GDP). Additionally, the section mentions key systems like LIMS (Laboratory Information Management System) and ISMS (Information Security Management System) that are essential for maintaining data integrity and compliance within the industry.", "excerpt_keywords": "Keywords: PIC/S, computerised systems, pharmaceutical industry, regulatory environment, acronyms"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[35] PIC_011_3_recommendation_on_computerised_systems.pdf\n## mrp: materials requirements planning\n\n## mrp-ii: manufacturing resource planning\n\n## oq: operational qualification\n\n## pda: parenteral drug association\n\n## pic/s: pharmaceutical inspection co-operation scheme\n\n## pki: public key infrastructure\n\n## plc: programmable logic controller\n\n## pq: performance qualification\n\n## qms: quality management system\n\n## r&d: research and development\n\n## scada: supervisory control and data acquisition\n\n## sla: service level agreement\n\n## sops: standard operating procedures\n\n## urs: user requirements specification\n\n## vsr: validation summary report (see footnote to section 23.10)\n\n## wan: wide area network\n\n## revision history\n\n|date|version number|reasons for revision|\n|---|---|---|\n|1 july 2004|pi 011-2|added revision history|\n|25 september 2007|pi 011-3|changed editors co-ordinates|\n\npi 011-3 page 50 of 50 25 september 2007", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "0f948d95-6927-4ecb-a17b-6a6f53cfa6a2": {"__data__": {"id_": "0f948d95-6927-4ecb-a17b-6a6f53cfa6a2", "embedding": null, "metadata": {"page_label": "1", "file_name": "[36] PIC Revision of Annex 11 EU GMP.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[36] PIC Revision of Annex 11 EU GMP.pdf", "file_type": "application/pdf", "file_size": 241741, "creation_date": "2024-04-07", "last_modified_date": "2024-03-29", "document_title": "Guidelines for Good Manufacturing Practice for Medicinal Products - Computerised Systems", "questions_this_excerpt_can_answer": "1. What are the specific dates related to the public consultation process for the revision of Annex 11 of the Guidelines on Good Manufacturing Practice for Medicinal Products - Computerised Systems as outlined by the European Medicines Agency in 2022?\n\n2. Which two documents are set to be replaced by the proposed guideline on the revision of Annex 11 concerning computerised systems in the context of Good Manufacturing Practice for Medicinal Products, as agreed upon by the EMA GMP/GDP IWG and PIC/S?\n\n3. How can stakeholders submit their comments on the concept paper regarding the revision of Annex 11, and what is the official email address provided by the European Medicines Agency for the submission of these comments?", "excerpt_keywords": "Keywords: european medicines agency, gmp, medicinal product, annex 11, computerised systems"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[36] PIC Revision of Annex 11 EU GMP.pdf\n## european medicines agency\n\nscience medicine health pharmaceutical inspection convention pharmaceutical inspection co-operation scheme\n\n19 september 2022\n\nema/ins/gmp/781435/2022 ps/inf 94/2022\n\ngmp/gdp inspectors working group (gmp/gdp iwg)\n\nconcept paper on the revision of annex 11 of the guidelines on good manufacturing practice for medicinal products - computerised systems\n\nagreed by ema gmp/gdp iwg and pic/s\n\n31 october 2022\n\nstart of public consultation 16 november 2022\n\nend of consultation (deadline for comments) 16 january 2023\n\nthe proposed guideline will replace:\n\n- eudralex volume 4: annex 11 computerised systems\n- for pic/s participating authorities: pe 009-15: annex 11 - computerised systems\n\ncomments should be provided using this template. the completed comments form should be sent to adm-gmdp@ema.europa.eu\n\nkeywords: gmp, medicinal product, annex 11\n\nofficial address domenico scarlattilaan 6*1083 hs amsterdam*the netherlands\n\naddress for visits and deliveries refer to www.ema.europa.eu/how-to-find-us\n\nsend us a question go to www.ema.europa.eu/contact telephone +31 (0)88 781 6000 an agency of the european union\n\n(c) european medicines agency, 2022. reproduction is authorized provided the source is acknowledged.", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "efee2904-bec6-43be-bdbd-c54155bbce39": {"__data__": {"id_": "efee2904-bec6-43be-bdbd-c54155bbce39", "embedding": null, "metadata": {"page_label": "2", "file_name": "[36] PIC Revision of Annex 11 EU GMP.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[36] PIC Revision of Annex 11 EU GMP.pdf", "file_type": "application/pdf", "file_size": 241741, "creation_date": "2024-04-07", "last_modified_date": "2024-03-29", "document_title": "Enhancing Guidance on Computerised Systems in GMP Regulations: An Updated Annex 11", "questions_this_excerpt_can_answer": "1. What are the primary reasons for the proposed revision of Annex 11 of the Good Manufacturing Practice (GMP) Guide as outlined in the concept paper?\n \n2. How does the concept paper propose to address the challenges and requirements related to data integrity in the context of computerised systems within GMP regulations?\n\n3. In what ways does the concept paper suggest improving the guidelines for the validation and qualification of computerised systems, especially in relation to critical systems operated or validated by service providers like cloud services?", "prev_section_summary": "The section discusses the revision of Annex 11 of the Guidelines on Good Manufacturing Practice for Medicinal Products - Computerised Systems by the European Medicines Agency in 2022. It outlines the specific dates related to the public consultation process, the documents to be replaced by the proposed guideline, and how stakeholders can submit their comments on the concept paper. The section also provides the official email address for submitting comments and contact information for the European Medicines Agency. Key topics include GMP, medicinal products, Annex 11, and the public consultation process. Key entities mentioned are the European Medicines Agency, EMA GMP/GDP IWG, and PIC/S.", "excerpt_keywords": "GMP, Annex 11, Data Integrity, Computerised Systems, Validation"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[36] PIC Revision of Annex 11 EU GMP.pdf\n# introduction\n\nthis concept paper addresses the need to update annex 11, computerised systems, of the good manufacturing practice (gmp) guide. annex 11 is common to the member states of the european union (eu)/european economic area (eea) as well as to the participating authorities of the pharmaceutical inspection co-operation scheme (pic/s). the current version was issued in 2011 and does not give sufficient guidance within a number of areas. since then, there has been extensive progress in the use of new technologies.\n\nreasons for the revision of annex 11 include, but are not limited to the following (in non-prioritised order and with references to existing sections in sharp brackets). more improvements may prove to be necessary as inputs will be received by the drafting group:\n\n1. the document should be updated to replace relevant parts of the q&a on annex 11 and the q&a on data integrity on the ema gmp website.\n2. with regards to data integrity, annex 11 will include requirements for data in motion and data at rest (backup, archive and disposal). configuration hardening and integrated controls are expected to support and safeguard data integrity; technical solutions and automation are preferable instead of manual controls.\n3. an update of the document with regulatory expectations to digital transformation and similar newer concepts will be considered.\n4. the scope should not only cover where a computerised system \"replaces of a manual operation\", but rather, where it replaces another system or a manual process.\n5. references should be made to ich q9.\n6. the list of services should include to operate a computerised system, e.g. cloud services.\n7. for critical systems validated and/or operated by service providers (e.g. cloud services), expectations should go beyond that \"formal agreements must exist\". regulated users should have access to the complete documentation for validation and safe operation of a system and be able to present this during regulatory inspections, e.g. with the help of the service provider. see also notice to sponsors and q&a #9 on the ema gcp website and q&a on the ema gvp website.\n8. despite being mentioned in the glossary, the term \"commercial off-the-shelf products\" (cots) is not adequately defined and may easily be understood too broadly. critical cots products, even those used by \"a broad spectrum of users\" should be qualified by the vendor or by the regulated user, and the documentation for this should be available for inspection. the use of the term and the expectation for qualification, validation and safe operation of such (e.g. cloud) systems should be clarified.\n9. the meaning of the term validation (and qualification), needs to be clarified. it should be emphasised that both activities consist of a verification of required and specified functionality as described in user requirements specifications (urs) or similar.\n10. following a risk-based approach, system qualification and validation should especially challenge critical parts of systems which are used to make gmp decisions, parts which ensure product quality and data integrity and parts, which have been specifically designed or customised.\n11. it is not sufficiently clear what is implied by the sentence saying \"user requirements should be traceable throughout the life-cycle\". a user requirements specification, or similar, describing all the implemented and required gmp critical functionality which has been automated, and which the regulated user is relying on, should be the very basis for any qualification or validation of the system, whether performed by the regulated user or by the vendor. user requirements specifications should be kept updated and aligned with the implemented system throughout the system life-cycle and there should be a documented traceability between user requirements, any underlying functional specifications and test cases.\n12. it should be acknowledged and addressed that software development today very often follows agile development processes, and criteria for accepting such products and corresponding documentation, which may not consist of traditional documents, should be clarified.\n13. guidelines should be included for classification of critical data and critical systems.\n14. systems, networks and infrastructure should protect the integrity of gmp processes and data. examples should be included of measures, both physical and electronic, required to protect data against both intentional and unintentional loss of data integrity.\n\nconcept paper on the revision of gmp annex 11 - computerised systems ema/ins/gmp/781435/2022 page 2/5", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "a4a2e758-7c25-4e52-a771-c8a93dffb6e8": {"__data__": {"id_": "a4a2e758-7c25-4e52-a771-c8a93dffb6e8", "embedding": null, "metadata": {"page_label": "3", "file_name": "[36] PIC Revision of Annex 11 EU GMP.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[36] PIC Revision of Annex 11 EU GMP.pdf", "file_type": "application/pdf", "file_size": 241741, "creation_date": "2024-04-07", "last_modified_date": "2024-03-29", "document_title": "Enhancing Data Integrity and System Security: Best Practices for IT Security Controls and Data Protection", "questions_this_excerpt_can_answer": "1. What specific criteria should be considered when validating the long-term readability of backups on volatile media according to the best practices outlined in the document \"Enhancing Data Integrity and System Security\"?\n\n2. How does the document \"Enhancing Data Integrity and System Security\" redefine the expectations for audit trail functionality in GMP critical systems, particularly in terms of user identification and change logging?\n\n3. What new approach does the document \"Enhancing Data Integrity and System Security\" suggest for conducting configuration reviews of GMP critical systems, and how does it differ from traditional methods based on upgrade history?", "prev_section_summary": "The section discusses the proposed revision of Annex 11 of the Good Manufacturing Practice (GMP) Guide, focusing on the need to update guidance on computerised systems in the context of GMP regulations. Key topics include reasons for the revision, addressing challenges related to data integrity, improving guidelines for validation and qualification of computerised systems, and regulatory expectations for digital transformation. Entities mentioned include the European Union (EU), European Economic Area (EEA), Pharmaceutical Inspection Co-operation Scheme (PIC/S), and critical systems operated or validated by service providers like cloud services.", "excerpt_keywords": "Data Integrity, System Security, IT Security Controls, Audit Trail, Configuration Review"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[36] PIC Revision of Annex 11 EU GMP.pdf\n## 15. [7.2] testing of the ability to restore system data\n\n(and if not otherwise easily recreated, the system itself) from backup is critically important, but the required periodic check of this ability, even if no changes have been made to the backup or restore processes, is not regarded necessary. long-term backup (or archival) to volatile media should be based on a validated procedure (e.g. through accelerated testing). in this case, testing should not focus on whether a backup is still readable, but rather, validating that it will be readable for a given period.\n\n## 16. [7.2] important expectations to backup processes\n\nare missing, e.g. to what is covered by a backup (e.g. data only or data and application), what types of backups are made (e.g. incremental or complete), how often backups are made (all types), how long backups are retained, which media is used for backups, and where backups are kept (e.g. physical separation).\n\n## 17. [8] the section should include an expectation to be able to obtain data in electronic format\n\nincluding the complete audit trail. the requirement to be able to print data may be reconsidered.\n\n## 18. [9] an audit trail functionality which automatically logs all manual interactions on gmp critical systems\n\nwhere users, data or settings can be manually changed, should be regarded as mandatory; not just considered based on a risk assessment. controlling processes or capturing, holding or transferring electronic data in such systems without audit trail functionality is not acceptable; any grace period within this area has long expired.\n\n## 19. [9] the audit trail should positively identify the user who made a change\n\nit should give a full account of what was changed, i.e. both the new and all old values should be clearly visible, it should include the full time and date when the change was made, and for all other changes except where a value is entered in an empty field or where this is completely obvious, the user should be prompted for the reason or rationale for why the change was made.\n\n## 20. [9] it should not be possible to edit audit trail data or to deactivate the audit trail functionality\n\nfor normal or privileged users working on the system. if these functionalities are available, they should only be accessible for system administrators who should not be involved in gmp production or in day-to-day work on the system (see segregation of duties).\n\n## 21. [9] the concept and purpose of audit trail review is inadequately described.\n\nthe process should focus on a review of the integrity of manual changes made on a system, e.g. a verification of the reason for changes and whether changes have been made on unusual dates, hours and by unusual users.\n\n## 22. [9] guidelines for acceptable frequency of audit trail review should be provided.\n\nfor audit trails on critical parameters, e.g. setting of alarms in a bms systems giving alarms on differential pressure in connection with aseptic filling, audit trail reviews should be part of batch release, following a risk-based approach.\n\n## 23. [9] audit trail functionalities should capture data entries with sufficient detail and in true time\n\nin order to give a full and accurate picture of events. if e.g. a system notifies a regulated user of inconsistencies in a data input, by writing an error message, and the user subsequently changes the input, which makes the notification disappear; the full set of events should be captured.\n\n## 24. [9] it should be addressed that many systems generate a vast amount of alarms and event data\n\nand that these are often mixed up with audit trail entries. while alarms and events may require their own logs, acknowledgements and reviews, this should not be confused with an audit trail review of manual system interactions. hence, as a minimum, it should be possible to be able to sort these.\n\n## 25. [11] the concept of configuration review should be added.\n\ninstead of taking onset in the number of known changes on a system (upgrade history), it should be based on a comparison of hardware and software baselines over time. this should include an account for any differences and an evaluation of the need for re-qualification/validation.\n\n## 26.", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "8bd7e37b-8e8a-4e9d-9cbb-e79f58904473": {"__data__": {"id_": "8bd7e37b-8e8a-4e9d-9cbb-e79f58904473", "embedding": null, "metadata": {"page_label": "3", "file_name": "[36] PIC Revision of Annex 11 EU GMP.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[36] PIC Revision of Annex 11 EU GMP.pdf", "file_type": "application/pdf", "file_size": 241741, "creation_date": "2024-04-07", "last_modified_date": "2024-03-29", "document_title": "Enhancing Data Integrity and System Security: Best Practices for IT Security Controls and Data Protection", "questions_this_excerpt_can_answer": "1. What specific IT security controls are recommended in the PIC Revision of Annex 11 EU GMP document for enhancing data integrity and system security within pharmaceutical environments?\n \n2. How does the document align its recommendations for IT security controls with ISO 27001 standards, particularly in terms of system and data confidentiality, integrity, and availability?\n\n3. What are the shortcomings of the current version of the document regarding system access restrictions, and what detailed measures does it suggest to improve access control to computerised systems in pharmaceutical settings?", "prev_section_summary": "The section discusses the importance of testing the ability to restore system data from backups, expectations for backup processes, the necessity of audit trail functionality in GMP critical systems, criteria for audit trail review, guidelines for audit trail frequency, capturing data entries in true time, distinguishing between alarms/events and audit trail entries, and redefining configuration reviews based on hardware and software baselines. Key entities include backup processes, audit trail functionality, user identification, change logging, audit trail review, configuration review, and data integrity.", "excerpt_keywords": "IT security controls, data integrity, system security, pharmaceutical environments, ISO 27001 standards"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[36] PIC Revision of Annex 11 EU GMP.pdf\n[12.1] the current section has only focus on restricting system access to authorised individuals;\n\nhowever, there are other important topics. in line with iso 27001, a section on it security should include a focus on system and data confidentiality, integrity and availability.\n\n## 27. [12.1] the current version says that \"physical and/or logical controls should be in place to restrict access to computerised system to authorised persons\".\n\nhowever, it is necessary to be more specific and to name some of the expected controls, e.g. multi-factor authentication, firewalls, platform management, security patching, virus scanning and intrusion detection/prevention.", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "726fb600-4ad7-4c7c-88df-a93e1d527045": {"__data__": {"id_": "726fb600-4ad7-4c7c-88df-a93e1d527045", "embedding": null, "metadata": {"page_label": "4", "file_name": "[36] PIC Revision of Annex 11 EU GMP.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[36] PIC Revision of Annex 11 EU GMP.pdf", "file_type": "application/pdf", "file_size": 241741, "creation_date": "2024-04-07", "last_modified_date": "2024-03-29", "document_title": "Guidance on Computerised Systems in GMP with Emphasis on AI/ML Algorithms: A Comprehensive Approach", "questions_this_excerpt_can_answer": "1. What specific areas does the current Annex 11 fail to provide sufficient guidance on, and what new areas, becoming increasingly important to GMP, are planned to be covered in the revised document?\n \n2. How does the revised Annex 11 plan to address the application and acceptance of AI/ML algorithms in critical GMP applications, considering the lack of existing regulatory guidance in the pharmaceutical industry?\n\n3. What is the proposed timeline for the revision process of Annex 11, from the preparation of the draft concept paper to the adoption and publication by the European Community and PIC/S sub-committee on GMDP harmonisation?", "prev_section_summary": "The section discusses the importance of enhancing data integrity and system security within pharmaceutical environments through specific IT security controls. It highlights the need to align recommendations with ISO 27001 standards, focusing on system and data confidentiality, integrity, and availability. The section also points out shortcomings in the current version of the document regarding system access restrictions and suggests detailed measures to improve access control to computerized systems, such as multi-factor authentication, firewalls, platform management, security patching, virus scanning, and intrusion detection/prevention.", "excerpt_keywords": "Guidance, Computerised Systems, GMP, AI, ML"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[36] PIC Revision of Annex 11 EU GMP.pdf\n## discussion\n\nthe current annex 11 does not give sufficient guidance within a number of areas already covered, and other areas, which are becoming increasingly important to gmp, are not covered at all. the revised text will expand the guidance given in the document and embrace the application of new technologies which have gained momentum since the release of the existing version.\n\nif possible, the revised document will include guidelines for acceptance of ai/ml algorithms used in critical gmp applications. this is an area where regulatory guidance is highly needed as this is not covered by any existing regulatory guidance in the pharmaceutical industry and as pharma companies are already implementing such algorithms.\n\n## recommendation\n\nthe ema gmp/gdp inspectors working group and the pic/s sub-committee on gmdp harmonisation jointly recommends that the current version of annex 11, computerised systems, be revised according to this concept paper.\n\n## proposed timetable\n\n|preparation of draft concept paper|- from october 2021|\n|---|---|\n|approval of draft concept paper by ema gmp/gdp iwg|- october 2022|\n|release for consultation of draft concept paper (2 months consultation)|- october 2022|\n|deadline for comments on concept paper|- december 2022|\n|discussion in ema gmp/gdp iwg and pic/s committee drafting group|- from march 2023|\n|proposed release for consultation of draft guideline (3 months consultation)|- december 2024|\n|deadline for comments on guideline|- march 2025|\n|adoption by ema gmp/gdp iwg|- march 2026|\n|publication by european community|- june 2026|\n|adoption by pic/s sub-committee on gmdp harmonisation|- september 2026|", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}, "68d153e8-737f-415d-b308-4e4617615f17": {"__data__": {"id_": "68d153e8-737f-415d-b308-4e4617615f17", "embedding": null, "metadata": {"page_label": "5", "file_name": "[36] PIC Revision of Annex 11 EU GMP.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[36] PIC Revision of Annex 11 EU GMP.pdf", "file_type": "application/pdf", "file_size": 241741, "creation_date": "2024-04-07", "last_modified_date": "2024-03-29", "document_title": "Harmonising Expectations for Computerised Systems in Medicinal Product Manufacturing: A Revised Guide to GMP Annex 11", "questions_this_excerpt_can_answer": "1. What collaborative group has been established to oversee the drafting of the revised guide to GMP Annex 11, and which regulatory authorities are involved in providing support and expertise?\n\n2. How does the revised Annex 11 aim to benefit both the pharmaceutical industry and regulators, and what specific improvements or changes does it intend to introduce to the management of computerised systems in medicinal product manufacturing?\n\n3. Can you list the specific references and guidelines that the document cites as resources for understanding the expectations and requirements related to computerised systems and data integrity in the context of GMP Annex 11 revision?", "prev_section_summary": "The section discusses the need for revising Annex 11 of EU GMP to provide guidance on new technologies and areas not covered adequately in the current version. It highlights the importance of including guidelines for the acceptance of AI/ML algorithms in critical GMP applications, where regulatory guidance is lacking. The section also outlines a proposed timetable for the revision process, involving entities such as the EMA GMP/GDP Inspectors Working Group and the PIC/S Sub-Committee on GMDP Harmonisation.", "excerpt_keywords": "GMP, Annex 11, Computerised Systems, Regulatory Authorities, Data Integrity"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[36] PIC Revision of Annex 11 EU GMP.pdf\n## resource requirements for preparation\n\na drafting group has been established by ema gmp/gdp inspectors working group and the pic/s sub-committee on gmdp harmonisation with a rapporteur and supporting experts from other eu member regulatory authorities and from non-eu pic/s participating authorities.\n\nit is expected that most of the work will be completed by email and by teleconference.\n\n## impact assessment (anticipated)\n\nthe updated annex 11 is intended to benefit both industry and regulators by clarifying expectations to areas already covered, by broadening these to areas not yet covered, and by pushing the adoption of a common approach between eu and non-eu regulatory authorities. revision of annex 11 will facilitate a better understanding of expectations to the use of computerised systems within manufacturing of medicinal products, and thereby, enhance the quality and safety of products and the integrity of data.\n\nno unnecessary adverse impact on industry with respect to either resources or costs is foreseen, although there is always a cost associated with being in compliance (or quality). the revision may require some systems and processes to be modified over a period of time.\n\n## interested parties\n\n- ema gmp/gdp inspectors working group\n- pic/s committee, sub-committee on gmdp harmonisation\n- national competent authorities of eu/eea member states\n- pic/s participating authorities\n- pharmaceutical industry\n- international societies and interest groups within pharmaceutical industry, e.g. ispe gamp\n\n## references to literature, guidelines, etc.\n\n- ema gmp q&a on annex 11 and q&a on data integrity, link\n- ema gcp guideline on computerised systems and electronic data in clinical trials (draft), ema/226170/2021, link\n- ema gcp q&a no. 8, 9, and notice to sponsors on validation and qualification of computerised systems used in clinical trials on link\n- ema gvp q&a on level of validation/qualification needed to be performed by a mah when using an electronic system previously qualified by a provider link\n\nconcept paper on the revision of gmp annex 11 - computerised systems ema/ins/gmp/781435/2022 page 5/5", "start_char_idx": null, "end_char_idx": null, "text_template": "{metadata_str}\n\n{content}", "metadata_template": "{key}: {value}", "metadata_seperator": "\n", "class_name": "TextNode"}, "__type__": "1"}}, "docstore/metadata": {"5728cbd7-2018-4b09-9076-7b6146bdc50d": {"doc_hash": "06dc5fd4df0d0a65a7015ff5d9e2f61abf00b5e1806881b5355e4b7504301cd5"}, "8d810076-8b93-4240-803c-b4451848f4ff": {"doc_hash": "7daade5aecabc96d74edb22138fc7660af7b85fe378179b86da34817066eca2e"}, "31f4d830-13e3-4b6e-a3bc-73fb75c40bd9": {"doc_hash": "cc43c09634868a83682999421dbbe5a230d954a1f19eb206eff669d563cf558b"}, "98effcc6-a140-4126-935e-2a5f1150ce2c": {"doc_hash": "538cfd0f19e9b5bf6d9f4d7e48257ab63fd0f9291e72ebd3aa4a4e229aeeaf13"}, "23a87aaa-93fe-40e5-bd66-600e6a24d8cb": {"doc_hash": "b81948e026b62bdc05f6f70151b1b872072dc9fab9ae4dcb0ebc2884bf0ec422"}, "6505eda7-0f1d-47b2-a143-31e31e6775a7": {"doc_hash": "7d3bcd4bd25f3e7081c73941522ca415c2fdb1f4852d7416e8bcedd2888d52ef"}, "a1470842-4cbd-45fb-9e71-6004b63c1ff0": {"doc_hash": "84b698521f6491736ea450ff0b148d241943c2e065b29c3852a505ed84e18949"}, "93bc0650-55fc-4fe0-bc1c-0156df9181d9": {"doc_hash": "171913c1fc70cf5de627b950916d1e623bf4249ab8ded309b8ac42cdf843c80b"}, "de675a68-a1ae-4ede-8fc4-433c43bc3949": {"doc_hash": "d0aad9719cbb3329330e528f086eb4c51ac6142d07e68acbd76d4fd1031c7b53"}, "687ab5b3-dae8-4f13-925b-53e6cedc4206": {"doc_hash": "37ad23dbafc8f2f078feace4cde784e98e0df4b042e61386ee79b592c201e2ab"}, "92857046-d0f4-4b99-b507-f7c29b708f3a": {"doc_hash": "2b43bcd4c8a26d5558e3e4a31bd6d0fb72cdb5a817149bd04625563f93253144"}, "47efd296-7683-40a4-b25a-0289c44a5574": {"doc_hash": "96a7043686c8a84e166b117ae30a8fbb08a91f90ddd88a8a36ffc671f6a2e2aa"}, "de10bc30-2086-42c2-8663-02927d06037a": {"doc_hash": "1dd8e58d7bf084794a4a78f3d7ac553dbf686d71d6a475a6d26699f7a591e9e1"}, "c47cec4a-8287-44ea-9ff8-b420d6a06e5a": {"doc_hash": "f6e5038b1a935948dc24ae161b84ec98f5f639fc506d183fbaf65e103a0b5f30"}, "d6b0c4e5-6839-4563-a426-22e014cb89c6": {"doc_hash": "7520276939e5e89820a540bef441582ccafe4cf369bfc823da3dd9886680448d"}, "e0ce4149-ca7a-4d02-bdd5-178c88d4960f": {"doc_hash": "e947de719eb04b80c987341a1a30abb66d16ad03ad865f01bf611c0d9e0bfe37"}, "6eb0c7fe-c66c-4c46-a60c-340fa563b0b8": {"doc_hash": "1d682335557084ad5f7b38a3a4f3c9bbe7dd9fefad1bebb079419d078670c50c"}, "7eac6349-581a-477e-994a-78dd34402a46": {"doc_hash": "cfe05b1af7fed7a47949f9d16f5f9a4f3cafd6c929357382e41980f3af4f6f50"}, "bc4563ca-f838-435f-8c3e-3e1612d9e557": {"doc_hash": "1b4c52b5ec65e3bd7458214894e16f5b33955724484a0a80f6a9b300c10079a0"}, "46d21eb0-0c17-4ce1-a631-a8ba6450b7b8": {"doc_hash": "e03cc576f2133a6875d52c9bf162ad07f4456f81456e38d4315362f59d9558f7"}, "a4397009-231c-4e32-b5cc-7854efee7941": {"doc_hash": "4b2d1214fe032e47a06d1f01ca02537087b9ab2fbabccca5fadc425b057bb6da"}, "562f23dc-2d1b-43f2-af43-9a490f5619c7": {"doc_hash": "5829a4691d317b6f3422c046999c4eb91213140809b95311ee4f0993257bc916"}, "dad1a77a-856b-426c-b5e8-e220357d2c1f": {"doc_hash": "1d348f38e18a21187db7a79e5a1ebc7d066686b5d1b5d5dec0fef7f5790b9e17"}, "b1e3808e-20a3-45b5-9584-bf1fd562b5de": {"doc_hash": "30256f35f9feba2d69f577ad80d28538780932d9d834e6e67b0a918a37521a23"}, "75d1b5c5-9583-4f1f-8064-b0027c5e9992": {"doc_hash": "e44d78898ab9cfd70412f7a69e09789bd78cea427baf3aa6ea9669e381cbea1a"}, "27313fe2-2826-4aa8-af51-14d9d4290ea9": {"doc_hash": "777745e0f27b2a5911325f48993009cfded40b25945fe0dfebec716fa0758c38"}, "67e32622-7021-4188-bb39-981e2005d0f6": {"doc_hash": "e8388e6afc265d8d6f54f4455942a2915e31ea0fb9f0863e1bc22e2878dcef37"}, "b858c026-7a99-4411-b8be-85d3fc4c1e1c": {"doc_hash": "911dd41482d60c12bd49e58bebf47f55fc554e3af614ed7a5f7fe18611b4d269"}, "ebc26979-d7c2-4b0e-8463-22c806396e9d": {"doc_hash": "7e1dc37092288bf234290474a5854e89a51acfb75b5f5ad1f07335e2ccae967c"}, "9c56d074-d765-4c0a-8c20-6432648a8f4d": {"doc_hash": "87cd2d2887501c8ddadd07d1110a9331f8651f92068ed0d382bd8a135b8a66c9"}, "2611e357-48e7-44d7-9173-43b81777aa5e": {"doc_hash": "da60c6cb32fda08c01fb486859603396e4f805a9fba86cdca0b9f201f647da76"}, "88f29c14-e4ef-4b65-ae5f-b057fe58317d": {"doc_hash": "f8e576fdc604638149f09826c22137260e5f39e0b273d71e3ea23e49bc612388"}, "51df4e6d-658e-4a38-8217-01937b7c0499": {"doc_hash": "a4d68c782a80509c3320f918c14a12411ba2486770d99b737cb08d3d213c0d82"}, "5fe796f0-3943-42e1-8ae6-24986e98f68c": {"doc_hash": "65662e04316c2de04891b24540d9243041ad68d3ab3235321f8e181424d93614"}, "e5b1f2e6-4915-44a5-911e-08c035b9aec0": {"doc_hash": "7e92c9ba8bb7655449edb6c560d08b4de8060734e1daa25166a60dba5527b5a2"}, "d09a0fcf-8040-4491-ae81-e18556e69cdd": {"doc_hash": "246ec3d4862bc5c85ffe4b629fb7f5d04c1837f768a1a27869542405e29d5f83"}, "165767df-333e-48dc-9240-3ca266c1219d": {"doc_hash": "451546ae38b5822705ee827fc3b6afae5bd39da009de993943b226fe650ca7f9"}, "1debcfb7-f11f-4a67-bb33-fcf93d0cbafc": {"doc_hash": "7efd01f96d0f787d7468640800dfdd9259eafd779f13af82c3d27c6be497aab6"}, "3b51ceb5-d60b-4a17-8e08-8def1e3ae81f": {"doc_hash": "b09ab343895e605fec242e453e3c5a6c8cd5ef102b267e2e5df66d56904020da"}, "46fed1e5-288b-4e72-aee4-3a3ea5db184f": {"doc_hash": "ccf8a9f43e7d78d96c8cd53f124ac63c760e9f49a88f6c5c5dd78a3edba728cf"}, "50965ba4-9a99-49da-acd2-c245a4b9bd44": {"doc_hash": "8a9b6781b81ff2255957e319e9f6dc017d7ce0af96e5efebca9950970756186e"}, "99a8a15d-d23a-4b30-9615-5f714615d2fa": {"doc_hash": "3c3099149c513e8819468d20f77c285073c5e61cd7a8560071052d8664227589"}, "25808d54-1dd0-4a91-9e63-1cfa45511a98": {"doc_hash": "36c47be636784ec33ecc2487487a190634a61a96679fd3a6695b99ad7447de41"}, "c960cdeb-4e3b-4383-b10e-18db73a1be89": {"doc_hash": "7bf1cc592bb9ec7287f2a434c31bc9a6529d1093065a1b2c9812c62b6b614afe"}, "8d7962ee-44dd-4167-b6f3-4ef2bf0e8916": {"doc_hash": "782a22fe83b4f9ed4070e7d1e7d380262843917266ed79385bb276a4f5b15580"}, "06a6db1e-e6a0-481c-9373-dc660640b869": {"doc_hash": "484ea88e4fad695448c6a1261b8d0aa1657ff679da4c32f4d7aad6ded2166a8c"}, "728ae6a3-5f6d-4dba-be2d-9d4e12ec3ca1": {"doc_hash": "294a218d03e4107c9678559f76efb11c6e983701fbcf6535f3ffd952a8c745b5"}, "60231c92-ab4e-45a9-8298-8653957a1c17": {"doc_hash": "cea81f4b62d2241c717ad08eb53a30b774f8ddc65c4d6ac9e73931c509e8f4e8"}, "50bd9d5d-d7a4-402f-a9df-5ae4ef8d6e85": {"doc_hash": "5536c3edfc773fbe3c2c0bd6ee2085834444b4c90310ea09574978b84fadc409"}, "9bb0e330-3592-443c-80b9-dfebdb103684": {"doc_hash": "cc1ad7154e7e739a00d2312a31961db5a981374abb5d3abcd1b48466a5a9e203"}, "6d877aa0-717f-4328-b7e6-e30a55988d25": {"doc_hash": "7c9fa8a3a3a70183de3dc67a5df248b62dbd40fb16cd47069c7bfc284b976b06"}, "b52182b5-44f0-4c07-af38-0c23882a34f1": {"doc_hash": "77548b890fdc7bd213f9c03550d873f4de275838801d5a6cfbd598d6149a0058"}, "c9933559-d98d-4ad3-bedd-5b230a64b55c": {"doc_hash": "ab0e335830598d210b3b0d13eb0ebbb2089d4223986829c5f9359ac36532fa73"}, "687dabcd-fba8-4dd8-aa2d-b6cc3dd94a67": {"doc_hash": "2f4567121ec52f0aca7994cef000be5769d1d6b7e80ed18eef41df4ca7f6e16f"}, "5807dfb5-9407-472b-8015-50cd7141b07d": {"doc_hash": "fd0e143a067740953c67e5d94e26f46473990f76c0f2892ca4e2a44c10704c14"}, "a0725ad4-dbbe-46cb-b348-eb24e82dc5b4": {"doc_hash": "411ed5200025b277c186aa1582565722cbb7fa2c1d941468960bb6238c29b2cb"}, "ecbe8ea0-be22-453a-8f48-981ecd5f46ef": {"doc_hash": "e98a477eb5b321a5bce6f4c87051f179058fea32f40878a468538ba9e7680a3a"}, "3595b473-9b95-48f4-9ad3-4980b6194eb5": {"doc_hash": "0cf19a4827d373a56f112d922ca3bdb9caa953b4d37fedb9012ce25d86966155"}, "6ad84e08-8922-416e-a6fb-3692f4f190df": {"doc_hash": "d0ea2205ef8277b4e92578946ec88280abf55506efed260582735f301f591d99"}, "573fc8b8-dcf3-445a-bf2f-a2cfaf91606c": {"doc_hash": "6ef840a55d69df2a0fc7608282e179e25bb8a2c2b3ec4b062b2198c6b883c135"}, "336d948d-c386-40ae-bb68-d42bc4e3b648": {"doc_hash": "28dfcfaac835404bd76cbb16183dfc1fa3a4be09be05ce039b1e85c2bdabf37d"}, "1b47f575-c973-43f1-b00b-fec15a4bde70": {"doc_hash": "2684a5665dcc5fb339b0341cc61bf29aac2c2dcc54ce2bea91ccd86e36dd1810"}, "2f3cdfa7-b8ff-42d3-90f6-2b85e46bde0a": {"doc_hash": "e076bd3b03304a81cdf202f22603bf6329eb237bd4a85295a725f6eeabf55c3b"}, "41674149-3ff3-4381-adb5-303af6f10dcc": {"doc_hash": "018650f1ccd6a2af4d91db3755bad8389a85022c9280f065c18be376708e341d"}, "da8c2fec-8b55-43e0-9374-fc3a1323b2d8": {"doc_hash": "98fc79e40f92dd0e6a70b860fc9ca7d76b93fa7c01066995bcc6fc7a622dbeff"}, "98f45d6e-5483-4f2a-9fa7-45d308fba933": {"doc_hash": "ae01b4baca029feebffca3e8517a627c80f48734cc30cedb1747866543f76706"}, "a3edaa72-e521-4bb1-b92a-e2322a0c194d": {"doc_hash": "eab9d092c31f8ad7ef4429eb5a6e2ad7f0fcb12b92601839ff507cd942f6b7c5"}, "f9d9e3db-d651-4962-9df2-363cdf4390a8": {"doc_hash": "b0ddb6d7486ec38c17a1542ad896e80ddc3eb9b3695cbfdd982ed41052a463f6"}, "e4205215-d8cb-41bd-bd50-eb11f25f2d14": {"doc_hash": "7e1b609a4f63db9f09a252a64e85bf98365c38a5e4ed62efac5150f043427676"}, "69ff0933-1b4c-4d8a-84ff-70bc77259a4e": {"doc_hash": "80f4b9bf11cf7666a810f5162a1188f6456c740d67588f0dd2c2e42a16775ff6"}, "4fff1da4-8609-4869-928c-1e3da7e3d89e": {"doc_hash": "e3f4a78debf5125d967bc962361f0be7d6a34d4f0ba6312e438af77667613403"}, "5ce07763-e371-406d-9fbc-f1fa976ea070": {"doc_hash": "f403b858ea6b3050a8cd5b5bad2e64c00b594ce6bd4e8b620b51d4378637f9b3"}, "e1f678a2-de73-49e8-91df-b3127499025c": {"doc_hash": "1514b386caea55935d296a44f4ee7169c4fb92042d90e288f1282bc422821bcd"}, "444d0e6c-7c01-48df-9d16-da8bd706ad26": {"doc_hash": "0612e2e92d0613c250332631062d450d9cf3f08488d92ccf472bf5d5016bce09"}, "1133e754-3cf3-4d95-afe4-58cfe4c7deac": {"doc_hash": "e39474d56cf3d4e02023ec7ee63ba85089527d0287732e9894f7c97e0b216b6c"}, "ad005025-af1c-48d6-8457-2c4f30220144": {"doc_hash": "1e9ebf97a4c013cc721731fe3b630066683577210c97e01e40b9bef9869f4513"}, "33785cca-ddb8-4494-9e14-7dfc57d3cd36": {"doc_hash": "35e55139e3b0600f059765b6ebed23fff3ea33940a8bbc132e8f34bb10fb6ad2"}, "171233c8-3e39-40b2-b9cc-4b0373a7fcc3": {"doc_hash": "451e36cd70a71204e94f67fc26226e6a535c535aca8ee7641ba2e0da34b323b4"}, "16689edc-72f5-4489-9086-34c9fd4ba2ee": {"doc_hash": "bd8b8276f052f609bb400abb09fab22f52bd88481888a36d53484c60be760340"}, "9287a61e-86c9-4048-a6ab-a6fea588b423": {"doc_hash": "f7468813f74448f9243909c715fb513dc67b5379dd70ebafdb2decd69469bbec"}, "a36935ed-e2e8-4694-8ada-b99beb0e4b16": {"doc_hash": "e1d8aa9e557e350431083de5dd59a409d1bc18e75232981d3fabceb5b201244a"}, "2ae5710b-b799-47bc-9d1e-e99133644de2": {"doc_hash": "c3b317098058badbaae36bd7741e13681092eb5d1bafb9037bc8f9c3b401ab1f"}, "88a9d046-e41a-4247-ae8c-a0d02c781139": {"doc_hash": "4ed7d03e5594ab596a6398197b69d89ed5976815c3252b033009a29c6b3df906"}, "54d2df81-ab80-4b70-9fb3-6e9f2a9aea01": {"doc_hash": "ff3da398e9a37df59acf35f832afadd3bb42a2fec8492a57df2aaa269ba858f8"}, "b8da9af6-3f20-47b7-acb3-82a93ba1d026": {"doc_hash": "aee5cd16da583bb2b8912877afac5d40220e20f8a04320d8202d7409c0f241f6"}, "f1ecb6f8-1092-43ce-9dba-8488ee42abec": {"doc_hash": "60ed388a37d682bc2b36164719a6514d41a96a3de3fbe6edc43537ac003387b7"}, "0c65ded1-be58-481c-baab-1bf1fdf02c01": {"doc_hash": "b2eed4a95fceb12802aa1e418a86e81feda7477201d5a6577ba6529d4487af17"}, "0b56eba7-7f0c-499f-a5df-fd4cc886fa7a": {"doc_hash": "9b7c99f130c4443fa8d306e810ac8b28cc6781aa4acd558cae30c794b443ba61"}, "432d1d2a-9cf2-4430-8401-cfc1bd4ff098": {"doc_hash": "d6b1d199413735d6501fabadc6e085ee1b000e3f4bc0494a58e3c95d281e7dc3"}, "1911d2ef-e196-47a4-b88f-ed6118842f0a": {"doc_hash": "39e95800e1d73cac07cf6528fab1d0e2c2b26439e6c8b636c34a2e6c9c8b08d5"}, "f6a56897-9a7b-4991-ae21-97fb4c7c0937": {"doc_hash": "39301149ccbeb80a8439d6e63f7e9abf979fd453aaaf23c9e9cd006a3e9238b4"}, "5f968704-cb25-4d0c-8a8a-6791178eb2a0": {"doc_hash": "323a5e6422875d63e926bd47961b6931ffa6d287af00f6fac887b2eac34e3086"}, "1b61caa5-53ec-406d-8e50-f0f17f93fca0": {"doc_hash": "44878a05790eca8573160ee12e68a83269e5c6f13a7e26630518cc74ce741535"}, "24e4a9e6-8069-4bf2-b666-874ab98788d0": {"doc_hash": "4fcff1c59e42fc3522acc3a1419d8cf6506968077d5e94eed61d147c8829472b"}, "6ddc9efb-0216-4d24-97c0-3127192bb08f": {"doc_hash": "fb91aea2dca1f02ae932e9c3ca42066d3efb6c1d66f619f91f611bfd53e8ec29"}, "16d2509d-df9a-49af-9a24-03b8a410a0e8": {"doc_hash": "011e8605aa25d5194ad3e1030f2bf87b7c28081d0a70ce651a0adc9b8cd86bcc"}, "7222d51f-177b-4f73-8cb0-dac24dd2b87b": {"doc_hash": "cbba8c3ead10269f0efc9373305869401c0579bb65cfddd56cead00a9295c9da"}, "b0e795aa-31e8-44b3-afa2-2d0a18362603": {"doc_hash": "ce922513b8569c87b613758e5156aaa536c26cca74a51e183fff01e5590fdf9e"}, "413980b2-6b97-4280-b9d9-6f2d7d9f8ebc": {"doc_hash": "622bc21c24dc86b38f97a889f1d41dadfc399ceba2d9f1c13ccefeb7deb234ad"}, "3be31d72-c9ab-4026-8b2b-c56d8811dd7c": {"doc_hash": "e1fb78e892b4c449b6ae823932a6acdfb0f0307b1b9c0d4c5a6ca81d3092e3ee"}, "1dabe786-dd0b-49cd-be75-8f5eaff08aa9": {"doc_hash": "99bffe59a7ef4d804c290ea66c9d1cc0fbf0dd485bb7d7dbb7a4880132e8c449"}, "88a5459e-ab9f-46d5-820d-2e36590a7eea": {"doc_hash": "b63877c64ff1545ab417241d3ed6101a2f5be30308382524d5ca5c79c4191901"}, "28aaa332-8756-4f1c-8185-09160dcc96bb": {"doc_hash": "29fd5d264126163dc71acb93d584b3c95cae2ce2f64ff5454f77df73ed1ac5d0"}, "042bf557-79a1-4912-8f69-4fedb04dcf74": {"doc_hash": "8f9c9efbe25fca76c259e2355f1007b4d9f546e212db30b0453213d1f70c762e"}, "20ef6396-9c74-4d08-89c7-1c4533b70df2": {"doc_hash": "0f97ae3f0bdd4d08dc6da5e12da5bfdde57fa178db3f86a9b68ed44fe26538fc"}, "c7bd7d93-9f47-4c00-ae50-f0695dee1d53": {"doc_hash": "f83084bb072d86022472b4857945ade39023370ffa320d71e8acc82e1eac7879"}, "45a3db3f-a51b-47d0-a1a3-6e26a7b58c36": {"doc_hash": "b9bdfac7724635f73b3e8186c6123505840c06aea34f60b10bb8ddf9eacf500f"}, "a6ca2a85-9915-433f-b84a-f0af9ee8de0f": {"doc_hash": "929c8c6989fb10a47fa7f624d24b4bfbf873a4921aae568564ee74e57b5a0f9e"}, "8fb68cd1-e8c6-4030-a519-b96d22f19cfb": {"doc_hash": "c3568cfde1a5d675639a5719710744b49ec466744b345285f3f418661d02ab91"}, "b81199f1-9a7b-4916-b548-689db655094f": {"doc_hash": "0a82ce6a91040f14fb05bc97da6ed1f3260242e76adb632764ca5ecd8a6f1a74"}, "c4a8887c-2b75-4658-bccb-53534e7d1046": {"doc_hash": "4d03c00b34486ddaf3938800053459ff1b072056ee422617409cf741f46a1464"}, "e646709c-3626-46b7-958c-1fd91cc3c615": {"doc_hash": "8d3c34e91125b6b7431bea35dd4b4dc41c1549ac9d9f828bf454cccde5d4c259"}, "e2a206ca-d30f-4d30-81bc-d29fd78f0ea2": {"doc_hash": "92f28216c49fb2564d11742de38e0fb2ec2dad64cd10e1a79fcfabc753ccd775"}, "31aa0665-9219-43f8-bd70-46ad18650454": {"doc_hash": "e3a32661de2c9aa060e7fdff77705f1e7b309c211a9f0d7a0e0895ae983663ee"}, "9e4b43b9-68e5-422d-8784-e46e9a8694ee": {"doc_hash": "f5b2969f970a484976eabf86f453cb5996ac4c802451663dd889f5e6f803e963"}, "96163ac3-da6f-46d8-941c-6d0db53f4ecd": {"doc_hash": "dcbca1cd1e6070167ffc4a0759dd64b24bfad189dc895e56a64dc2e218f61c13"}, "5a65c69f-02ce-46f4-99cf-b02d2567e403": {"doc_hash": "b8ff9ef8a1892e11e9497a72b58a562b441a2366e1cfacabd447284d1ae26a73"}, "79ee2f24-3882-46e8-ab2b-562f0cbda043": {"doc_hash": "2200a9a8653482d48842c1c6d1eae991eac1d90aeb1814a8f344078f8602f8d2"}, "be9c0e9c-0ee0-429b-b828-abdca4eb0c52": {"doc_hash": "273892fa5de91dc82ee21913bb638ed213f712582c55b6d8edcadbddc407434b"}, "e83b0402-71b4-4dd5-8b7e-c31c63beee24": {"doc_hash": "e1e547134df2b2d0275f2400911e812e0d270566ca17f0c6259d245a71d9f4be"}, "3e6142f2-39cb-4f3f-aa3d-85dc703eed77": {"doc_hash": "efcdcb8a6c27e5c6b370a7e155ade0251bf9dca73105370b5ddc8756fac1f7f7"}, "afa5438a-74b8-47a4-b607-515bea91b4b4": {"doc_hash": "130981f540e2e142614e9f787340a16f0de71dd573329fc1e9d64671c265afbc"}, "e88a91b2-6977-46ff-b678-fc2e5aae3f50": {"doc_hash": "6e02fca13fb6bc39742e44257c5f7a8b0d4d07189d2b2d9475fceabc1b4074e1"}, "86379eec-d702-4fae-86e5-670bacecc4b4": {"doc_hash": "4ce3df3cf28a3d3eba94175c54c5e2e18c0602f4435ae9bdbed84c211b83a50e"}, "0f948d95-6927-4ecb-a17b-6a6f53cfa6a2": {"doc_hash": "08a3695e81e6a8471690855c2f4b44d19eba76345de4563fcb21521f01427c52"}, "efee2904-bec6-43be-bdbd-c54155bbce39": {"doc_hash": "850bdbe0d8ff0994370ab086760598f973719a0f88d3ede53c3da8736a7e6e70"}, "a4a2e758-7c25-4e52-a771-c8a93dffb6e8": {"doc_hash": "a0cb632abc83ddc44a11a81dbc034703e24a247802ed0aeceebd68d6bdd000ef"}, "8bd7e37b-8e8a-4e9d-9cbb-e79f58904473": {"doc_hash": "582045a472eb5e428deb6164227732cd23df50ebb2e80f16dfb712d8eb4fba9f"}, "726fb600-4ad7-4c7c-88df-a93e1d527045": {"doc_hash": "a4b44d8713a9928a47c3c3d7cb2ce02f73f5ab7d7411b05d5bdd366d51920385"}, "68d153e8-737f-415d-b308-4e4617615f17": {"doc_hash": "26104f5ed274b12697885d37d88750c6f7902ce9c2e1cd86f0c8132268f5f02d"}}}