{"docstore/data": {"29af9f8b-7367-4f59-95c9-f139d7370eb4": {"__data__": {"id_": "29af9f8b-7367-4f59-95c9-f139d7370eb4", "embedding": null, "metadata": {"page_label": "1", "file_name": "[4] FDA Data Integrity and Compliance With Drug CGMP (Q&A) Guidance for Industry.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[4] FDA Data Integrity and Compliance With Drug CGMP (Q&A) Guidance for Industry.pdf", "file_type": "application/pdf", "file_size": 212227, "creation_date": "2024-04-07", "last_modified_date": "2024-04-04", "document_title": "\"Ensuring Data Integrity and Compliance with Drug CGMP: FDA Guidance for Industry\"", "questions_this_excerpt_can_answer": "1. What specific guidance does the FDA provide for ensuring data integrity and compliance with drug Current Good Manufacturing Practices (CGMP) as of December 2018, particularly in relation to the pharmaceutical industry?\n\n2. How does the FDA's guidance for industry on data integrity and compliance with drug CGMP, issued in December 2018, address the roles and responsibilities of the Center for Drug Evaluation and Research (CDER), the Center for Biologics Evaluation and Research (CBER), and the Center for Veterinary Medicine (CVM)?\n\n3. What are the key components and recommendations outlined in the December 2018 FDA guidance document titled \"Ensuring Data Integrity and Compliance with Drug CGMP: FDA Guidance for Industry\" for maintaining pharmaceutical quality and manufacturing standards?", "excerpt_keywords": "FDA, Data Integrity, Compliance, Drug CGMP, Pharmaceutical Industry"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[4] FDA Data Integrity and Compliance With Drug CGMP (Q&A) Guidance for Industry.pdf\n# data integrity and compliance with drug cgmp questions and answers\n\nguidance for industry\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 veterinary medicine (cvm)\n\ndecember 2018\n\npharmaceutical quality/manufacturing standards (cgmp)", "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"}, "d1d8ba6b-32c9-42c4-95ee-587a31f57fed": {"__data__": {"id_": "d1d8ba6b-32c9-42c4-95ee-587a31f57fed", "embedding": null, "metadata": {"page_label": "2", "file_name": "[4] FDA Data Integrity and Compliance With Drug CGMP (Q&A) Guidance for Industry.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[4] FDA Data Integrity and Compliance With Drug CGMP (Q&A) Guidance for Industry.pdf", "file_type": "application/pdf", "file_size": 212227, "creation_date": "2024-04-07", "last_modified_date": "2024-04-04", "document_title": "FDA Guidance and Compliance Information for Drug Current Good Manufacturing Practice (CGMP)", "questions_this_excerpt_can_answer": "1. Where can additional copies of the FDA's guidance on data integrity and compliance with drug CGMP for the pharmaceutical industry be obtained?\n   \n2. What are the contact details for obtaining guidance on drug compliance and regulatory information from the FDA's Center for Drug Evaluation and Research?\n\n3. How can one access guidance documents related to compliance and regulatory information for biologics, blood, and vaccines from the FDA's Center for Biologics Evaluation and Research?", "prev_section_summary": "The section provides guidance from the FDA on ensuring data integrity and compliance with drug Current Good Manufacturing Practices (CGMP) in the pharmaceutical industry. It addresses the roles and responsibilities of the Center for Drug Evaluation and Research (CDER), the Center for Biologics Evaluation and Research (CBER), and the Center for Veterinary Medicine (CVM). The key components and recommendations outlined in the guidance document focus on maintaining pharmaceutical quality and manufacturing standards.", "excerpt_keywords": "FDA, data integrity, compliance, drug CGMP, guidance"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[4] FDA Data Integrity and Compliance With Drug CGMP (Q&A) Guidance for Industry.pdf\n## data integrity and compliance with drug cgmp questions and answers guidance for industry\n\n|additional copies are available from:|office of communications, division of drug information|\n|---|---|\n| |center for drug evaluation and research|\n| |food and drug administration|\n| |10001 new hampshire ave., hillandale bldg., 4th floor|\n| |silver spring, md 20993-0002|\n|phone:|855-543-3784 or 301-796-3400; fax: 301-431-6353|\n|email:|druginfo@fda.hhs.gov|\n|website:|https://www.fda.gov/drugs/guidancecomplianceregulatoryinformation/guidances/default.htm|\n| |and/or|\n|office of communication, outreach and development|center for biologics evaluation and research|\n| |food and drug administration|\n| |10903 new hampshire ave., bldg. 71, room 3128|\n| |silver spring, md 20993-0002|\n|phone:|800-835-4709 or 240-402-8010|\n|email:|ocod@fda.hhs.gov|\n|website:|https://www.fda.gov/biologicsbloodvaccines/guidancecomplianceregulatoryinformation/guidances/default.htm|\n| |and/or|\n|policy and regulations staff, hfv-6|center for veterinary medicine|\n| |food and drug administration|\n| |7500 standish place, rockville, md 20855|\n|website:|https://www.fda.gov/animalveterinary/guidancecomplianceenforcement/guidanceforindustry/default.htm|\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 veterinary medicine (cvm)\n\ndecember 2018\n\npharmaceutical quality/manufacturing standards (cgmp)", "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"}, "e15a963c-4c4a-4901-8a5d-4750cd2a5cb7": {"__data__": {"id_": "e15a963c-4c4a-4901-8a5d-4750cd2a5cb7", "embedding": null, "metadata": {"page_label": "3", "file_name": "[4] FDA Data Integrity and Compliance With Drug CGMP (Q&A) Guidance for Industry.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[4] FDA Data Integrity and Compliance With Drug CGMP (Q&A) Guidance for Industry.pdf", "file_type": "application/pdf", "file_size": 212227, "creation_date": "2024-04-07", "last_modified_date": "2024-04-04", "document_title": "Ensuring Data Integrity and Compliance in CGMP Records", "questions_this_excerpt_can_answer": "1. How does the FDA define \"data integrity\" and \"metadata\" within the context of CGMP records, and why are these definitions critical for compliance in the pharmaceutical industry?\n\n2. What specific guidance does the FDA provide regarding the management of audit trails and the use of electronic versus paper records in ensuring CGMP compliance, particularly in relation to data integrity and the verification of batch conformance?\n\n3. In what ways does the FDA address the handling of potential data falsification issues within CGMP environments, and what are the recommended practices for training personnel to prevent and detect data integrity problems?", "prev_section_summary": "The key topics of the section include data integrity and compliance with drug current good manufacturing practice (CGMP) for the pharmaceutical industry. The section provides information on where to obtain additional copies of FDA guidance on data integrity and compliance, contact details for obtaining guidance on drug compliance and regulatory information from the FDA's Center for Drug Evaluation and Research, and access to guidance documents related to compliance and regulatory information for biologics, blood, and vaccines from the FDA's Center for Biologics Evaluation and Research. The entities mentioned in the section include the Office of Communications, Division of Drug Information, Center for Drug Evaluation and Research, Center for Biologics Evaluation and Research, and Center for Veterinary Medicine under the U.S. Department of Health and Human Services, Food and Drug Administration.", "excerpt_keywords": "FDA, data integrity, compliance, CGMP, pharmaceutical industry"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[4] FDA Data Integrity and Compliance With Drug CGMP (Q&A) Guidance for Industry.pdf\n|content|page number|\n|---|---|\n|i. introduction|1|\n|ii. background|2|\n|iii. questions and answers|4|\n|1. please clarify the following terms as they relate to cgmp records:|4|\n|a. what is \"data integrity\"?|4|\n|b. what is \"metadata\"?|4|\n|c. what is an \"audit trail\"?|4|\n|d. how does fda use the terms \"static\" and \"dynamic\" as they relate to record formats?|5|\n|e. how does fda use the term \"backup\" in SS 211.68(b)?|5|\n|f. what are the \"systems\" in \"computer or related systems\" in SS 211.68?|5|\n|2. when is it permissible to invalidate a cgmp result and exclude it from the determination of batch conformance?|6|\n|3. does each cgmp workflow on a computer system need to be validated?|6|\n|4. how should access to cgmp computer systems be restricted?|7|\n|5. why is fda concerned with the use of shared login accounts for computer systems?|7|\n|6. how should blank forms be controlled?|7|\n|7. who should review audit trails?|8|\n|8. how often should audit trails be reviewed?|8|\n|9. can electronic copies be used as accurate reproductions of paper or electronic records?|8|\n|10. is it acceptable to retain paper printouts or static records instead of original electronic records from stand-alone computerized laboratory instruments, such as an ft-ir instrument?|9|\n|11. can electronic signatures be used instead of handwritten signatures for master production and control records?|9|\n|12. when does electronic data become a cgmp record?|10|\n|13. why has fda cited use of actual samples during \"system suitability\" or test, prep, or equilibration runs in warning letters?|11|\n|14. is it acceptable to only save the final results from reprocessed laboratory chromatography?|11|\n|15. can an internal tip or information regarding a quality issue, such as potential data falsification, be handled informally outside of the documented cgmp quality system?|12|\n|16. should personnel be trained in preventing and detecting data integrity issues as part of a routine cgmp training program?|12|", "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"}, "a8a3185f-a90a-4235-b764-951b2f5ea2bd": {"__data__": {"id_": "a8a3185f-a90a-4235-b764-951b2f5ea2bd", "embedding": null, "metadata": {"page_label": "4", "file_name": "[4] FDA Data Integrity and Compliance With Drug CGMP (Q&A) Guidance for Industry.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[4] FDA Data Integrity and Compliance With Drug CGMP (Q&A) Guidance for Industry.pdf", "file_type": "application/pdf", "file_size": 212227, "creation_date": "2024-04-07", "last_modified_date": "2024-04-04", "document_title": "FDA's Approach to Electronic Records and Data Integrity Issues: Ensuring Compliance and Quality Assurance in Regulated Industries", "questions_this_excerpt_can_answer": "1. What specific guidance does the FDA provide for the pharmaceutical industry regarding the management and inspection of electronic records to ensure compliance with Drug CGMP?\n   \n2. How does the FDA suggest pharmaceutical companies should rectify issues related to data integrity within their electronic record-keeping practices to maintain compliance with regulatory standards?\n\n3. In the context of the FDA's oversight of electronic records, what are the recommended steps or procedures for industry players to follow to proactively address and prevent data integrity problems as outlined in the \"FDA Data Integrity and Compliance With Drug CGMP (Q&A) Guidance for Industry\" document?", "prev_section_summary": "The section focuses on ensuring data integrity and compliance in CGMP records within the pharmaceutical industry. Key topics include definitions of \"data integrity\" and \"metadata,\" guidance on managing audit trails and using electronic versus paper records, handling potential data falsification issues, and training personnel to prevent and detect data integrity problems. Entities mentioned include the FDA, CGMP records, audit trails, electronic signatures, shared login accounts, and training programs for personnel.", "excerpt_keywords": "FDA, electronic records, data integrity, Drug CGMP, compliance"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[4] FDA Data Integrity and Compliance With Drug CGMP (Q&A) Guidance for Industry.pdf\n|is fda allowed to look at electronic records?|12|\n|---|---|\n|how does fda recommend data integrity problems be addressed?|12|", "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"}, "1b8b4091-ff78-4676-9207-c1de173f5541": {"__data__": {"id_": "1b8b4091-ff78-4676-9207-c1de173f5541", "embedding": null, "metadata": {"page_label": "5", "file_name": "[4] FDA Data Integrity and Compliance With Drug CGMP (Q&A) Guidance for Industry.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[4] FDA Data Integrity and Compliance With Drug CGMP (Q&A) Guidance for Industry.pdf", "file_type": "application/pdf", "file_size": 212227, "creation_date": "2024-04-07", "last_modified_date": "2024-04-04", "document_title": "Ensuring Data Integrity and Compliance with Drug CGMP Guidance for Industry", "questions_this_excerpt_can_answer": "1. What specific parts of the 21 CFR are clarified in the FDA's guidance on data integrity and compliance with drug CGMP for the pharmaceutical industry, and how do they relate to the manufacturing and handling of drugs, including biologics?\n   \n2. How does the FDA's guidance document suggest firms should approach the creation and handling of data to ensure compliance with CGMP requirements, particularly in terms of risk-based strategies for preventing and detecting data integrity issues?\n\n3. What resources or references does the FDA's guidance on data integrity and compliance with drug CGMP recommend for firms seeking to implement meaningful and effective strategies for managing data integrity risks, including any specific international guidelines or FDA web pages for the most recent guidance versions?", "prev_section_summary": "The section discusses the FDA's guidance for the pharmaceutical industry on managing and inspecting electronic records to ensure compliance with Drug CGMP. It also addresses how pharmaceutical companies should rectify data integrity issues in their electronic record-keeping practices to maintain regulatory standards. The recommended steps and procedures for industry players to proactively address and prevent data integrity problems are outlined in the \"FDA Data Integrity and Compliance With Drug CGMP (Q&A) Guidance for Industry\" document. Key entities include the FDA, pharmaceutical companies, and regulatory standards.", "excerpt_keywords": "FDA, data integrity, compliance, drug CGMP, pharmaceutical industry"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[4] FDA Data Integrity and Compliance With Drug CGMP (Q&A) Guidance for Industry.pdf\n## data integrity and compliance with drug cgmp questions and answers guidance for industry\n\nthis guidance represents the current thinking of the food and drug administration (fda or agency) on this topic. it does not establish any rights for any person and is not binding on fda or the public. you can use an alternative approach if it satisfies the requirements of the applicable statutes and regulations. to discuss an alternative approach, contact the fda office responsible for this guidance as listed on the title page.\n\n### i. introduction\n\nthe purpose of this guidance is to clarify the role of data integrity in current good manufacturing practice (cgmp) for drugs, as required in 21 cfr parts 210, 211, and 212. unless otherwise noted, the term cgmp in this guidance refers to cgmps for drugs (including biologics). fdas authority for cgmp comes from section 501(a)(2)(b) of the federal food, drug, and cosmetic act (fd&c act). part 210 covers current good manufacturing practice in manufacturing, processing, packing, or holding of drugs; general; part 211 covers current good manufacturing practice for finished pharmaceuticals; and part 212 covers current good manufacturing practice for positron emission tomography (pet) drugs. all citations to parts 211 and 212 in this document pertain to finished pharmaceuticals and pet drugs, but these requirements are also consistent with agency guidance on cgmp for active pharmaceutical ingredients with respect to data integrity.\n\nthis guidance provides the agencys current thinking on the creation and handling of data in accordance with cgmp requirements. fda expects that all data be reliable and accurate (see the \"background\" section). cgmp regulations and guidance allow for flexible and risk-based strategies to prevent and detect data integrity issues. firms should implement meaningful and effective strategies to manage their data integrity risks based on their process understanding and knowledge management of technologies and business models.\n\nmeaningful and effective strategies should consider the design, operation, and monitoring of systems and controls based on risk to patient, process, and product. managements involvement\n\n1this guidance has been prepared by the office of pharmaceutical quality and the office of compliance in the center for drug evaluation and research in cooperation with the center for biologics evaluation and research, the center for veterinary medicine, and the office of regulatory affairs at the food and drug administration.\n\n2see the international council for harmonisation (ich) guidance for industry q7 good manufacturing practice guide for active pharmaceutical ingredients. we update guidances periodically. to make sure you have the most recent version of a guidance, check the fda drugs guidance web page at https://www.fda.gov/drugs/guidancecomplianceregulatoryinformation/guidances/default.htm.\n\n3see ich guidance for industry q9 quality risk 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"}, "e6573f3a-a7f5-4bb9-80c4-8729ffea70b8": {"__data__": {"id_": "e6573f3a-a7f5-4bb9-80c4-8729ffea70b8", "embedding": null, "metadata": {"page_label": "6", "file_name": "[4] FDA Data Integrity and Compliance With Drug CGMP (Q&A) Guidance for Industry.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[4] FDA Data Integrity and Compliance With Drug CGMP (Q&A) Guidance for Industry.pdf", "file_type": "application/pdf", "file_size": 212227, "creation_date": "2024-04-07", "last_modified_date": "2024-04-04", "document_title": "Ensuring Data Integrity in Pharmaceutical Manufacturing: Importance, Regulations, and Consequences", "questions_this_excerpt_can_answer": "1. What specific responsibilities does management have in fostering a quality culture to prevent data integrity issues within pharmaceutical manufacturing, according to the FDA's guidance?\n   \n2. How does the FDA's guidance document differentiate between recommendations and legally enforceable responsibilities in the context of data integrity and compliance with drug CGMP?\n\n3. What are the specific CGMP requirements related to data integrity as outlined in sections 211 and 212, and how do they contribute to ensuring the safety, efficacy, and quality of drugs according to the FDA's observations?", "prev_section_summary": "This section provides guidance from the FDA on data integrity and compliance with drug CGMP for the pharmaceutical industry. Key topics covered include the role of data integrity in current good manufacturing practice (CGMP), the clarification of specific parts of the 21 CFR related to drug manufacturing and handling, and the importance of reliable and accurate data. The guidance emphasizes the need for firms to implement risk-based strategies to prevent and detect data integrity issues, and to consider the design, operation, and monitoring of systems and controls based on risk to patient, process, and product. The section also mentions the involvement of management in ensuring data integrity and references international guidelines such as the ICH guidance for industry Q7 on good manufacturing practice for active pharmaceutical ingredients and Q9 on quality risk management. Key entities involved in the creation of this guidance include the Office of Pharmaceutical Quality, the Office of Compliance, the Center for Drug Evaluation and Research, the Center for Biologics Evaluation and Research, the Center for Veterinary Medicine, and the Office of Regulatory Affairs at the FDA.", "excerpt_keywords": "FDA, data integrity, pharmaceutical manufacturing, CGMP, drug compliance"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[4] FDA Data Integrity and Compliance With Drug CGMP (Q&A) Guidance for Industry.pdf\nin and influence on these strategies is essential in preventing and correcting conditions that can lead to data integrity problems. it is the role of management with executive responsibility to create a quality culture where employees understand that data integrity is an organizational core value and employees are encouraged to identify and promptly report data integrity issues. in the absence of management support of a quality culture, quality systems can break down and lead to cgmp noncompliance.\n\nin general, fdas guidance documents 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 recent years, fda has increasingly observed cgmp violations involving data integrity during cgmp inspections. this is troubling because ensuring data integrity is an important component of industrys responsibility to ensure the safety, efficacy, and quality of drugs, and of fdas ability to protect the public health. these data integrity-related cgmp violations have led to numerous regulatory actions, including warning letters, import alerts, and consent decrees. the underlying premise in SSSS 210.1 and 212.2 is that cgmp sets forth minimum requirements to assure that drugs meet the standards of the fd&c act regarding safety, identity, strength, quality, and purity. requirements with respect to data integrity in parts 211 and 212 include, among other things:\n\n|SS 211.68|requiring that \"backup data are exact and complete\" and \"secure from alteration, inadvertent erasures, or loss\" and that \"output from the computer ... be checked for accuracy\"|\n|---|---|\n|SS 212.110(b)|requiring that data be \"stored to prevent deterioration or loss\"|\n|SSSS 211.100 and 211.160|requiring that certain activities be \"documented at the time of performance\" and that laboratory controls be \"scientifically sound\"|\n|SS 211.180|requiring that records be retained as \"original records,\" or \"true copies,\" or other \"accurate reproductions of the original records\"|\n|SSSS 211.188, 211.194, and 212.60(g)|requiring \"complete information,\" \"complete data derived from all tests,\" \"complete record of all data,\" and \"complete records of all tests performed\"|\n\naccording to section 501(a)(2)(b) of the fd&c act, a drug shall be deemed adulterated if \"the methods used in, or the facilities or controls used for, its manufacture, processing, packing, or holding do not conform to or are not operated or administered in conformity with current good manufacturing practice to assure that such drug meets the requirement of the act as to safety and has the identity and strength, and meets the quality and purity characteristics, which it purports or is represented to possess.\"", "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"}, "c5918774-ae9e-48fa-84d7-c0e781b492ef": {"__data__": {"id_": "c5918774-ae9e-48fa-84d7-c0e781b492ef", "embedding": null, "metadata": {"page_label": "7", "file_name": "[4] FDA Data Integrity and Compliance With Drug CGMP (Q&A) Guidance for Industry.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[4] FDA Data Integrity and Compliance With Drug CGMP (Q&A) Guidance for Industry.pdf", "file_type": "application/pdf", "file_size": 212227, "creation_date": "2024-04-07", "last_modified_date": "2024-04-04", "document_title": "\"Ensuring Data Integrity and Regulatory Compliance in Pharmaceutical Manufacturing\"", "questions_this_excerpt_can_answer": "1. What specific sections of the CGMP regulations emphasize the importance of reviewing production, control, and laboratory records for accuracy, completeness, and compliance with established standards in the pharmaceutical manufacturing industry?\n\n2. How does the FDA guidance document address the necessity of data integrity in terms of documentation practices, such as ensuring data completeness, attributability to specific individuals, and the security of records from creation through disposition?\n\n3. What are the electronic signature and record-keeping requirements as per 21 CFR Part 11, and how do they relate to the CGMP regulations parts 210, 211, and 212 in the context of ensuring data integrity and compliance in pharmaceutical manufacturing?", "prev_section_summary": "The key topics of the section include the importance of data integrity in pharmaceutical manufacturing, the role of management in fostering a quality culture to prevent data integrity issues, the FDA's guidance on recommendations versus legally enforceable responsibilities, and specific CGMP requirements related to data integrity outlined in sections 211 and 212. The entities involved are management with executive responsibility, employees, the FDA, and the pharmaceutical industry.", "excerpt_keywords": "Data Integrity, Compliance, Pharmaceutical Manufacturing, CGMP Regulations, Electronic Signatures"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[4] FDA Data Integrity and Compliance With Drug CGMP (Q&A) Guidance for Industry.pdf\nSSSS 211.22, 211.192, and 211.194(a) (requiring that production and control records be \"reviewed\" and that laboratory records be \"reviewed for accuracy, completeness, and compliance with established standards\").\n\nSSSS 211.182, 211.186(a), 211.188(b)(11), and 211.194(a)(8) (requiring that records be \"checked,\" \"verified,\" or \"reviewed\").\n\nwhen considering how to meet many of these regulatory requirements, it may be useful to ask the following questions:\n\n- are controls in place to ensure that data is complete?\n- are activities documented at the time of performance?\n- are activities attributable to a specific individual?\n- can only authorized individuals make changes to records?\n- is there a record of changes to data?\n- are records reviewed for accuracy, completeness, and compliance with established standards?\n- are data maintained securely from data creation through disposition after the records retention period?\n\nthis guidance helps answer these questions and enables an understanding of key concepts behind the regulatory requirements.\n\nwhile not in the scope of this guidance, data integrity-related cgmp violations can also impact or be directly linked to application filing, review, and regulatory actions.\n\nelectronic signature and record-keeping requirements are laid out in 21 cfr part 11 and apply to certain records subject to records requirements set forth in agency regulations, including parts 210, 211, and 212. for more information, see guidance for industry part 11, electronic records; electronic signatures--scope and application, which outlines fdas current thinking regarding the scope and application of part 11 pending fdas reexamination of part 11 as it applies to all fda-regulated products.", "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"}, "c4b4fd11-ed04-45a3-b305-f69ca6dabcb6": {"__data__": {"id_": "c4b4fd11-ed04-45a3-b305-f69ca6dabcb6", "embedding": null, "metadata": {"page_label": "8", "file_name": "[4] FDA Data Integrity and Compliance With Drug CGMP (Q&A) Guidance for Industry.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[4] FDA Data Integrity and Compliance With Drug CGMP (Q&A) Guidance for Industry.pdf", "file_type": "application/pdf", "file_size": 212227, "creation_date": "2024-04-07", "last_modified_date": "2024-04-04", "document_title": "Ensuring Data Integrity, Metadata Management, and Audit Trails for CGMP Compliance", "questions_this_excerpt_can_answer": "1. How does the FDA define \"data integrity\" in the context of CGMP compliance, and what are the key principles that underpin this definition?\n2. In the realm of pharmaceutical manufacturing and compliance, what constitutes \"metadata,\" and why is it considered crucial for understanding and managing data?\n3. What is the significance of an \"audit trail\" according to the FDA's guidance on data integrity and CGMP compliance, and what specific elements should it include to ensure the reconstruction of the course of events related to electronic records?", "prev_section_summary": "This section discusses the importance of data integrity and regulatory compliance in pharmaceutical manufacturing, focusing on specific sections of CGMP regulations that emphasize the review of production, control, and laboratory records. It addresses the necessity of data integrity in documentation practices, such as data completeness, attributability, and record security. The section also touches on electronic signature and record-keeping requirements outlined in 21 CFR Part 11, and their relation to CGMP regulations parts 210, 211, and 212 in ensuring data integrity and compliance. It highlights the importance of controls for data completeness, timely documentation, individual attribution, authorized changes to records, record of data changes, and secure data maintenance throughout the records retention period. Additionally, it mentions the potential impact of data integrity-related CGMP violations on application filing, review, and regulatory actions.", "excerpt_keywords": "Data integrity, Metadata, Audit trail, CGMP compliance, Pharmaceutical manufacturing"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[4] FDA Data Integrity and Compliance With Drug CGMP (Q&A) Guidance for Industry.pdf\n### iii. questions and answers\n\n|questions|answers|\n|---|---|\n|a. what is \"data integrity\"?|for the purposes of this guidance, data integrity refers to the completeness, consistency, and accuracy of data. complete, consistent, and accurate data should be attributable, legible, contemporaneously recorded, original or a true copy, and accurate (alcoa). data integrity is critical throughout the cgmp data life cycle, including in the creation, modification, processing, maintenance, archival, retrieval, transmission, and disposition of data after the records retention period ends. system design and controls should enable easy detection of errors, omissions, and aberrant results throughout the datas life cycle.|\n|b. what is \"metadata\"?|metadata is the contextual information required to understand data. a data value is by itself meaningless without additional information about the data. metadata is often described as data about data. metadata is structured information that describes, explains, or otherwise makes it easier to retrieve, use, or manage data. for example, the number \"23\" is meaningless without metadata, such as an indication of the unit \"mg.\" among other things, metadata for a particular piece of data could include a date/time stamp documenting when the data were acquired, a user id of the person who conducted the test or analysis that generated the data, the instrument id used to acquire the data, material status data, the material identification number, and audit trails. data should be maintained throughout the records retention period with all associated metadata required to reconstruct the cgmp activity (e.g., SSSS 211.188 and 211.194). the relationships between data and their metadata should be preserved in a secure and traceable manner.|\n|c. what is an \"audit trail\"?|for purposes of this guidance, audit trail means a secure, computer-generated, time-stamped electronic record that allows for reconstruction of the course of events relating to the creation, modification, or deletion of an electronic record. for example, the audit trail for a high performance liquid chromatography (hplc) run should include the user name, date/time of the run, the integration parameters used, and details of a reprocessing, if any. documentation should include change justification for the reprocessing.|", "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"}, "ed5ac6a4-56bb-480c-aa33-27f4941cfbfe": {"__data__": {"id_": "ed5ac6a4-56bb-480c-aa33-27f4941cfbfe", "embedding": null, "metadata": {"page_label": "9", "file_name": "[4] FDA Data Integrity and Compliance With Drug CGMP (Q&A) Guidance for Industry.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[4] FDA Data Integrity and Compliance With Drug CGMP (Q&A) Guidance for Industry.pdf", "file_type": "application/pdf", "file_size": 212227, "creation_date": "2024-04-07", "last_modified_date": "2024-04-04", "document_title": "FDA Guidelines on Audit Trails, Record-Keeping Practices, Record Formats, and Computer Systems in SS 211.68: Ensuring Compliance and Data Integrity in Pharmaceutical Manufacturing", "questions_this_excerpt_can_answer": "1. How does the FDA define the difference between \"static\" and \"dynamic\" record formats in the context of CGMP compliance, and can you provide examples of each?\n   \n2. According to the FDA's guidance, what constitutes a compliant backup of electronic records under SS 211.68(b), and how does it differentiate between a backup and a temporary backup in terms of data integrity requirements?\n\n3. What is the FDA's interpretation of \"systems\" in the phrase \"computer or related systems\" as per SS 211.68, and how does this definition encompass the various components involved in ensuring CGMP compliance?", "prev_section_summary": "This section discusses the importance of data integrity, metadata management, and audit trails for CGMP compliance in the pharmaceutical manufacturing industry. It defines data integrity as the completeness, consistency, and accuracy of data, emphasizing the need for data to be attributable, legible, contemporaneously recorded, original or a true copy, and accurate. Metadata is described as contextual information required to understand data, and it includes information such as date/time stamps, user IDs, instrument IDs, and audit trails. An audit trail is defined as a secure, computer-generated, time-stamped electronic record that allows for the reconstruction of events related to the creation, modification, or deletion of electronic records. The section highlights the critical role of these elements in ensuring compliance with CGMP regulations and emphasizes the importance of maintaining data integrity throughout the data life cycle.", "excerpt_keywords": "FDA, Data Integrity, Compliance, Drug CGMP, Audit Trails"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[4] FDA Data Integrity and Compliance With Drug CGMP (Q&A) Guidance for Industry.pdf\naudit trails include those that track creation, modification, or deletion of data (such as processing parameters and results) and those that track actions at the record or system level (such as attempts to access the system or rename or delete a file).\n\ncgmp-compliant record-keeping practices prevent data from being lost or obscured and ensure that activities are documented at the time of performance (see SSSS 211.68, 211.100, 211.160(a), 211.188, and 211.194). electronic record-keeping systems, which include audit trails, can support these cgmp requirements.\n\nhow does fda use the terms \"static\" and \"dynamic\" as they relate to record formats?\n\nfor the purposes of this guidance, static is used to indicate a fixed-data record such as a paper record or an electronic image, and dynamic means that the record format allows interaction between the user and the record content. for example, a dynamic chromatographic record may allow the user to change the baseline and reprocess chromatographic data so that the resulting peaks may appear smaller or larger. it also may allow the user to modify formulas or entries in a spreadsheet used to compute test results or other information such as calculated yield.\n\nhow does fda use the term \"backup\" in SS 211.68(b)?\n\nfda uses the term backup in SS 211.68(b) to refer to a true copy of the original record that is maintained securely throughout the record retention period (e.g., SS 211.180). backup data must be exact, complete, and secure from alteration, inadvertent erasures, or loss (SS 211.68(b)). the backup file should contain the data (which includes associated metadata) and should be in the original format or in a format compatible with the original format.\n\nfdas use of the term backup is consistent with the term archive as used in guidance for industry and fda staff general principles of software validation.\n\ntemporary backup copies (e.g., in case of a computer crash or other interruption) would not satisfy the requirement in SS 211.68(b) to maintain a backup file of data.\n\nwhat are the \"systems\" in \"computer or related systems\" in SS 211.68?\n\nthe american national standards institute (ansi) defines systems as people, machines, and methods organized to accomplish a set of specific functions. computer or related systems can refer to computer hardware, software, peripheral devices, networks, cloud infrastructure, personnel, and associated documents (e.g., user manuals and standard operating procedures).\n\namerican national standard for information systems, dictionary for information systems, american national standards institute, 1991.\n\nsee guidance for industry and fda staff general principles of software validation.", "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"}, "5c5334eb-ab6f-4e0c-9fcc-c7ad86014166": {"__data__": {"id_": "5c5334eb-ab6f-4e0c-9fcc-c7ad86014166", "embedding": null, "metadata": {"page_label": "10", "file_name": "[4] FDA Data Integrity and Compliance With Drug CGMP (Q&A) Guidance for Industry.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[4] FDA Data Integrity and Compliance With Drug CGMP (Q&A) Guidance for Industry.pdf", "file_type": "application/pdf", "file_size": 212227, "creation_date": "2024-04-07", "last_modified_date": "2024-04-04", "document_title": "Validation and Invalidation of CGMP Data and Workflows: A Comprehensive Guide", "questions_this_excerpt_can_answer": "1. What are the specific regulatory references that outline the requirements for invalidating CGMP test results and how should invalidated results be documented and retained within the quality unit's batch record?\n   \n2. How does the guidance differentiate between the validation of a computer system itself and the validation of CGMP workflows or processes executed within that system, particularly in relation to electronic master production and control records (MPCR)?\n\n3. According to the guidance, how does the concept of validation in computer science compare to the definition of process validation within the pharmaceutical industry, especially in terms of ensuring CGMP compliance and the consistent delivery of quality products?", "prev_section_summary": "This section discusses FDA guidelines on audit trails, record-keeping practices, record formats, and computer systems in SS 211.68 to ensure compliance and data integrity in pharmaceutical manufacturing. Key topics include the definition of \"static\" and \"dynamic\" record formats, compliant backups of electronic records, and the interpretation of \"systems\" in the context of computer or related systems. Entities mentioned include audit trails, record formats, backup data, computer hardware, software, peripheral devices, networks, cloud infrastructure, personnel, and associated documents.", "excerpt_keywords": "FDA, Data Integrity, Compliance, CGMP, Validation"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[4] FDA Data Integrity and Compliance With Drug CGMP (Q&A) Guidance for Industry.pdf\n## when is it permissible to invalidate a cgmp result and exclude it from the determination of batch conformance?\n\ndata created as part of a cgmp record must be evaluated by the quality unit as part of release criteria (see SSSS 211.22 and 212.70) and maintained for cgmp purposes (e.g., SS 211.180).\n\nelectronic data generated to fulfill cgmp requirements include relevant metadata required to reconstruct the cgmp activity captured in the record. invalidating test results to exclude them from quality unit decisions about conformance to a specification requires a valid, documented, scientifically sound justification. see, for example, SSSS 211.160(b), 211.188, 211.192, and 212.71(b) and the guidance for industry investigating out-of-specification (oos) test results for pharmaceutical production. even if test results are legitimately invalidated on the basis of a scientifically sound investigation, the full cgmp batch record provided to the quality unit would include the original (invalidated) data, along with the investigation report that justifies invalidating the result. the requirements for record retention and review do not differ depending on the data format; paper-based and electronic data record-keeping systems are subject to the same requirements.\n\n## does each cgmp workflow on a computer system need to be validated?\n\nyes, a cgmp workflow, such as creation of an electronic master production and control record (mpcr), is an intended use of a computer system to be checked through validation (see SSSS 211.63, 211.68(b), and 211.110(a)). the extent of validation studies should be commensurate with the risk posed by the automated system. when the same system is used to perform both cgmp and non-cgmp functions, the potential for non-cgmp functions to affect cgmp operations should be assessed and mitigated appropriately.\n\nif you validate the computer system but you do not validate it for its intended use, you cannot know if your workflow runs correctly. for example, qualifying the manufacturing execution system (mes) platform, a computer system, ensures that it meets its relevant requirements and specifications; however, it does not demonstrate that a given mpcr generated by the mes contains the correct calculations. in this example, validating the workflow ensures that the intended steps, requirements, and calculations in the mpcr are accurate and perform properly. this is similar to reviewing a paper mpcr and ensuring all supporting procedures are in place before the mpcr is implemented in production (see SSSS 211.100, 211.186, and 212.50(b) and the guidance for industry pet drugs--current good manufacturing practice (cgmp)).\n\nfor purposes of this guidance, the term \"quality unit\" is synonymous with the term \"quality control unit.\" for the definition of quality control unit, see SS 210.3(b)(15).\n\nsee note 8.\n\nin computer science, validation refers to ensuring that software meets its requirements. however, this may not meet the definition of process validation as found in guidance for industry process validation: general principles and practices: \"the collection and evaluation of data ... which establishes scientific evidence that a process is capable of consistently delivering quality products.\" see also ich guidance for industry q7 good manufacturing practice guide for active pharmaceutical ingredients, which defines validation as providing assurance that a specific process, method, or system will consistently produce a result meeting predetermined acceptance criteria. for purposes of this guidance, validation is being used in a manner consistent with the above guidance documents.", "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"}, "8965dcb1-22d8-482c-a756-cebceef46068": {"__data__": {"id_": "8965dcb1-22d8-482c-a756-cebceef46068", "embedding": null, "metadata": {"page_label": "11", "file_name": "[4] FDA Data Integrity and Compliance With Drug CGMP (Q&A) Guidance for Industry.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[4] FDA Data Integrity and Compliance With Drug CGMP (Q&A) Guidance for Industry.pdf", "file_type": "application/pdf", "file_size": 212227, "creation_date": "2024-04-07", "last_modified_date": "2024-04-04", "document_title": "FDA Recommendations for Controlling Access and Documenting Authorized Personnel in CGMP Computer Systems", "questions_this_excerpt_can_answer": "1. What specific measures does the FDA recommend for ensuring that changes to computerized CGMP records, such as mPCRs or laboratory data entries, are made exclusively by authorized personnel?\n\n2. How does the FDA view the use of shared login accounts in the context of CGMP computer systems, and what exceptions, if any, are considered acceptable for viewing data without violating CGMP requirements?\n\n3. In the context of controlling blank forms within CGMP environments, what examples of document control methods does the FDA consider effective for ensuring product quality and integrity, and how should these forms be managed post-issuance?", "prev_section_summary": "This section discusses the validation and invalidation of CGMP data and workflows in the pharmaceutical industry. Key topics include when it is permissible to invalidate a CGMP result, the documentation and retention requirements for invalidated results, the validation of computer systems and CGMP workflows, and the comparison between validation in computer science and process validation in the pharmaceutical industry. The section emphasizes the importance of scientifically sound justifications for invalidating test results, the need to validate each CGMP workflow on a computer system, and the distinction between validating a computer system itself and validating the workflows executed within it. It also highlights the requirements for record retention and review, the assessment of non-CGMP functions on CGMP operations, and the definition of validation in both computer science and the pharmaceutical industry.", "excerpt_keywords": "FDA, Data Integrity, Compliance, CGMP, Computer Systems"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[4] FDA Data Integrity and Compliance With Drug CGMP (Q&A) Guidance for Industry.pdf\nfda recommends you implement appropriate controls to manage risks associated with each element of the system. controls that are appropriately designed to validate a system for its intended use address software, hardware, personnel, and documentation.\n\n4. how should access to cgmp computer systems be restricted?\n\nyou must exercise appropriate controls to assure that changes to computerized mpcrs or other cgmp records or input of laboratory data into computerized records can be made only by authorized personnel (SS 211.68(b)). other examples of records for which control should be restricted to authorized personnel include automated visual inspection records, electronic materials management system records, and automated dispensing system weighing records. fda recommends that you restrict the ability to alter specifications, process parameters, data, or manufacturing or testing methods by technical means where possible (e.g., by limiting permissions to change settings or data).\n\nthe system administrator role, including any rights to alter files and settings, should be assigned to personnel independent from those responsible for the record content. to assist in controlling access, it is important that manufacturers establish and implement a method for documenting authorized personnels access privileges for each cgmp computer system in use (e.g., by maintaining a list of authorized individuals) (see SS 211.68(b)).\n\n5. why is fda concerned with the use of shared login accounts for computer systems?\n\nwhen login credentials are shared, a unique individual cannot be identified through the login and the system would not conform to the cgmp requirements in parts 211 and 212. fda requires that system controls, including documentation controls, be designed in accordance with cgmp to assure product quality (e.g., SSSS 211.100 and 212.50). for example, you must implement documentation controls that ensure that the actions as described in question 4 are attributable to a specific individual (see SSSS 211.68(b), 211.188(b)(11), 211.194(a)(7) and (8), and 212.50(c)(10)).\n\nshared, read-only user accounts that do not allow the user to modify data or settings are acceptable for viewing data, but they do not conform with the part 211 and 212 requirements for actions, such as second person review, to be attributable to a specific individual.\n\n6. how should blank forms be controlled?\n\nthere must be document controls in place to assure product quality (see SSSS 211.100, 211.160(a), 211.186, 212.20(d), and 212.60(g)). for example, bound paginated notebooks, stamped for official use by a document control group, provide good document control because they allow easy detection of unofficial notebooks as well as any gaps in notebook pages. if used, blank forms (e.g., electronic worksheets, laboratory notebooks, and mpcrs) should be controlled by the quality unit or by another document control method. as appropriate, numbered sets of blank forms may be issued and should be reconciled upon completion of all issued forms. incomplete or erroneous forms should be kept as part of the permanent record along with written justification for their replacement (see, e.g., SSSS 211.192, 211.194, 212.50(a), and", "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"}, "a01083d3-fa79-43d5-a137-ad68bd3a5e14": {"__data__": {"id_": "a01083d3-fa79-43d5-a137-ad68bd3a5e14", "embedding": null, "metadata": {"page_label": "12", "file_name": "[4] FDA Data Integrity and Compliance With Drug CGMP (Q&A) Guidance for Industry.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[4] FDA Data Integrity and Compliance With Drug CGMP (Q&A) Guidance for Industry.pdf", "file_type": "application/pdf", "file_size": 212227, "creation_date": "2024-04-07", "last_modified_date": "2024-04-04", "document_title": "Audit Trail Review and Compliance with CGMP Regulations: A Comprehensive Guide", "questions_this_excerpt_can_answer": "1. What specific sections of the CGMP regulations outline the responsibilities for reviewing audit trails and production and control records, and how does the FDA recommend implementing oversight and review of these records?\n   \n2. How does the FDA suggest determining the frequency of audit trail reviews when the CGMP regulations do not specify a review frequency, and what factors should be considered in this risk assessment?\n\n3. Can electronic copies be considered accurate reproductions of original records in the context of CGMP compliance, and what are the key considerations to ensure these copies preserve the content and meaning of the original records?", "prev_section_summary": "The key topics of this section include FDA recommendations for controlling access and documenting authorized personnel in CGMP computer systems. It covers measures for ensuring changes to computerized records are made only by authorized personnel, restrictions on access to CGMP computer systems, concerns with shared login accounts, and methods for controlling blank forms within CGMP environments. The section emphasizes the importance of appropriate controls, documentation controls, and document control methods to ensure product quality and integrity in pharmaceutical manufacturing processes. Key entities mentioned include authorized personnel, system administrators, shared login accounts, and the quality unit responsible for document control.", "excerpt_keywords": "Audit Trail Review, CGMP Regulations, FDA Recommendations, Electronic Copies, Data Integrity"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[4] FDA Data Integrity and Compliance With Drug CGMP (Q&A) Guidance for Industry.pdf\n212.70(f)(1)(vi)). all data required to recreate a cgmp activity should be maintained as part of the complete record.\n\nwho should review audit trails?\n\naudit trail review is similar to assessing cross-outs on paper when reviewing data. personnel responsible for record review under cgmp should review the audit trails that capture changes to data associated with the record as they review the rest of the record (e.g., SSSS 211.22(a), 211.101(c) and (d), 211.103, 211.182, 211.186(a), 211.192, 211.194(a)(8), and 212.20(d)). for example, all production and control records, which includes audit trails, must be reviewed and approved by the quality unit (SS 211.192). the regulations provide flexibility to have some activities reviewed by a person directly supervising or checking information (e.g., SS 211.188). fda recommends a quality system approach to implementing oversight and review of cgmp records.\n\nhow often should audit trails be reviewed?\n\nif the review frequency for the data is specified in cgmp regulations, adhere to that frequency for the audit trail review. for example, SS 211.188(b) requires review after each significant step in manufacture, processing, packing, or holding, and SS 211.22 requires data review before batch release. in these cases, you would apply the same review frequency for the audit trail. if the review frequency for the data is not specified in cgmp regulations, you should determine the review frequency for the audit trail using knowledge of your processes and risk assessment tools. the risk assessment should include evaluation of data criticality, control mechanisms, and impact on product quality.\n\nyour approach to audit trail review and the frequency with which you conduct it should ensure that cgmp requirements are met, appropriate controls are implemented, and the reliability of the review is proven. see the audit trail definition in 1.c. above for further information on audit trails.\n\ncan electronic copies be used as accurate reproductions of paper or electronic records?\n\nyes. electronic copies can be used as true copies of paper or electronic records, provided the copies preserve the content and meaning of the original record, which includes all metadata. see guidance for industry quality systems approach to pharmaceutical cgmp regulations. see also guidance for industry contract manufacturing arrangements for drugs: quality agreements for information about auditing as it relates to contract facilities. risks to data include, but are not limited to, the potential to be deleted, amended, or excluded without authorization or without detection. examples of audit trails that may be appropriate to review on a risk-based frequency include audit trails that capture instrument operational status, instrument communication logs, and alert 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"}, "87c27a7d-1bd1-47be-a3a9-27cada54d060": {"__data__": {"id_": "87c27a7d-1bd1-47be-a3a9-27cada54d060", "embedding": null, "metadata": {"page_label": "13", "file_name": "[4] FDA Data Integrity and Compliance With Drug CGMP (Q&A) Guidance for Industry.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[4] FDA Data Integrity and Compliance With Drug CGMP (Q&A) Guidance for Industry.pdf", "file_type": "application/pdf", "file_size": 212227, "creation_date": "2024-04-07", "last_modified_date": "2024-04-04", "document_title": "Regulatory Requirements for Retaining Laboratory Records and the Use of Electronic Signatures in CGMP Compliance: A Comprehensive Guide", "questions_this_excerpt_can_answer": "1. What are the FDA's guidelines on retaining true copies of dynamic electronic records in the pharmaceutical industry, and how does it relate to the preservation of the content and meaning of the original records?\n\n2. How does the FDA differentiate between the acceptability of paper printouts or static records and original electronic records for compliance with CGMP, specifically in the context of laboratory instruments like FT-IR?\n\n3. Under what conditions does the FDA consider electronic signatures to be equivalent to handwritten signatures for master production and control records in the pharmaceutical industry, according to CGMP requirements?", "prev_section_summary": "The section discusses the responsibilities for reviewing audit trails and production and control records outlined in CGMP regulations, the recommended implementation of oversight and review of these records by the FDA, determining the frequency of audit trail reviews, and the considerations for using electronic copies as accurate reproductions of original records in the context of CGMP compliance. Key entities mentioned include personnel responsible for record review, the quality unit, the FDA, and the importance of conducting risk assessments for determining audit trail review frequency.", "excerpt_keywords": "FDA, Data Integrity, Compliance, Drug CGMP, Electronic Signatures"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[4] FDA Data Integrity and Compliance With Drug CGMP (Q&A) Guidance for Industry.pdf\nrequired to reconstruct the cgmp activity and the static or dynamic nature of the original records. true copies of dynamic electronic records may be made and maintained in the format of the original records or in a format that allows for the content and meaning of the original records to be preserved if a suitable reader and copying equipment (e.g., software and hardware, including media readers) are readily available (SSSS 211.180(d) and 212.110).\n\n10. is it acceptable to retain paper printouts or static records instead of original electronic records from stand-alone computerized laboratory instruments, such as an ft-ir instrument? a paper printout or static record may satisfy retention requirements if it is the original record or a true copy of the original record (see SSSS 211.68(b), 211.188, 211.194, and 212.60). during data acquisition, for example, ph meters and balances may create a paper printout or static record as the original record. in this case, the paper printout or static record, or a true copy, must be retained (SS 211.180). however, electronic records from certain types of laboratory instruments--whether stand-alone or networked--are dynamic, and a printout or a static record does not preserve the dynamic record format that is part of the complete original record. for example, the spectral file created by ft-ir (fourier transform infrared spectroscopy) is dynamic and can be reprocessed. however, a static record or printout is fixed and would not satisfy cgmp requirements to retain original records or true copies (SS 211.180(d)). also, if the full spectrum is not displayed in the printout, contaminants may be excluded. you must ensure that original laboratory records, including paper and electronic records, are subject to second-person review (SS 211.194(a)(8)) to make certain that all test results and associated information are appropriately reported. similarly, in microbiology, a contemporaneous written record is maintained of the colony counts of a petri dish, and the record is then subject to second-person review. document control requirements in SS 211.180 pertain only to cgmp records. for more information on static and dynamic records, see 1.d. in this guidance. for pet drugs, see the guidance for industry pet drugs--current good manufacturing practice (cgmp) for discussion of equipment and laboratory controls, including regulatory requirements for records.\n\n11. can electronic signatures be used instead of handwritten signatures for master production and control records? yes, electronic signatures with the appropriate controls can be used instead of handwritten signatures or initials in any cgmp required record. although SS 211.186(a) specifies a \"full signature, handwritten,\" an electronic signature with the appropriate controls to securely link the signature with the associated record fulfills this requirement (21 cfr 11.2(a)). see part 11, which establishes criteria for when electronic signatures are considered the legally binding", "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"}, "f04a7f96-bf16-4e16-94dd-4098eede3c1f": {"__data__": {"id_": "f04a7f96-bf16-4e16-94dd-4098eede3c1f", "embedding": null, "metadata": {"page_label": "14", "file_name": "[4] FDA Data Integrity and Compliance With Drug CGMP (Q&A) Guidance for Industry.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[4] FDA Data Integrity and Compliance With Drug CGMP (Q&A) Guidance for Industry.pdf", "file_type": "application/pdf", "file_size": 212227, "creation_date": "2024-04-07", "last_modified_date": "2024-04-04", "document_title": "Electronic Signatures and CGMP Documentation Practices for Pet Drugs: A Comprehensive Guide", "questions_this_excerpt_can_answer": "1. What specific regulatory guidance does the FDA provide regarding the use of electronic signatures in the context of CGMP documentation practices for pet drugs, and how should firms document the controls for these electronic signatures?\n\n2. How does the FDA define a CGMP record in relation to electronic data, and what are the expectations for documenting or saving data to comply with CGMP requirements, especially concerning chromatographic data and the use of audit trails?\n\n3. What are the FDA's expectations for the design of computer systems, such as LIMS or EBR systems, in the context of CGMP documentation practices to ensure data integrity and compliance, particularly for pet drugs?", "prev_section_summary": "The section discusses the FDA guidelines on retaining true copies of dynamic electronic records in the pharmaceutical industry, the acceptability of paper printouts or static records versus original electronic records for compliance with CGMP, and the use of electronic signatures in place of handwritten signatures for master production and control records. Key topics include the preservation of original records, the differences between static and dynamic records, the requirements for retaining laboratory records, and the use of electronic signatures in CGMP compliance. Key entities mentioned include the FDA, laboratory instruments like FT-IR, electronic records, paper printouts, electronic signatures, and master production and control records.", "excerpt_keywords": "FDA, electronic signatures, CGMP documentation, pet drugs, data integrity"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[4] FDA Data Integrity and Compliance With Drug CGMP (Q&A) Guidance for Industry.pdf\nequivalent of handwritten signatures. firms using electronic signatures should document the controls used to ensure that they are able to identify the specific person who signed the records electronically.\n\nthere is no requirement for a handwritten signature for the mpcr in the pet cgmp regulations (21 cfr part 212).\n\nwhen does electronic data become a cgmp record?\n\nwhen generated to satisfy a cgmp requirement, all data become a cgmp record. you must document, or save, the data at the time of performance to create a record in compliance with cgmp requirements, including, but not limited to, SSSS 211.100(b) and 211.160(a).\n\nfda expects processes to be designed so that data required to be created and maintained cannot be modified without a record of the modification. for example, chromatographic data should be saved to durable media upon completion of each step or injection (e.g., peak integration or processing steps; finished, incomplete, or aborted injections) instead of at the end of an injection set, and changes to the chromatographic data or injection sequence should be documented in an audit trail. aborted or incomplete injections should be captured in audit trails and should be investigated and justified.\n\nit is not acceptable to record data on pieces of paper that will be discarded after the data are transcribed to a permanent laboratory notebook (see SSSS 211.100(b), 211.160(a), and 211.180(d)). similarly, it is not acceptable to store electronic records in a manner that allows for manipulation without creating a permanent record.\n\nyou may employ a combination of technical and procedural controls to meet cgmp documentation practices for electronic systems. for example, a computer system, such as a laboratory information management system (lims) or an electronic batch record (ebr) system, can be designed to automatically save after each entry. this would be similar to indelibly recording each entry contemporaneously on a paper batch record to satisfy cgmp requirements. the computer system described above could be combined with a procedure requiring data be keyed in or otherwise entered immediately when generated.\n\nfor pet drugs, see the \"laboratory controls\" section of the guidance for industry pet drugs--current good manufacturing practice (cgmp).\n\nunder section 704(a) of the fd&c act, fda inspections of manufacturing facilities \"shall extend to all things therein (including records, files, papers, processes, controls, and facilities) bearing on whether prescription drugs [and] nonprescription drugs intended for human use ... are adulterated or misbranded ... or otherwise bearing on violation of this chapter.\" accordingly, fda routinely requests and reviews records not intended to satisfy a cgmp requirement but which nonetheless contain cgmp information (e.g., shipping or other records that may be used to reconstruct an activity).", "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"}, "1aa5716d-7b67-4a47-8bea-ea85ea9b8827": {"__data__": {"id_": "1aa5716d-7b67-4a47-8bea-ea85ea9b8827", "embedding": null, "metadata": {"page_label": "15", "file_name": "[4] FDA Data Integrity and Compliance With Drug CGMP (Q&A) Guidance for Industry.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[4] FDA Data Integrity and Compliance With Drug CGMP (Q&A) Guidance for Industry.pdf", "file_type": "application/pdf", "file_size": 212227, "creation_date": "2024-04-07", "last_modified_date": "2024-04-04", "document_title": "FDA Regulations on System Suitability Testing and Data Integrity in Laboratory Chromatography: Ensuring Compliance and Accuracy in Analytical Testing", "questions_this_excerpt_can_answer": "1. What specific practices has the FDA identified as violative in the context of using actual samples during system suitability testing or test, prep, or equilibration runs in laboratory chromatography, and how does it relate to the concept of \"testing into compliance\"?\n\n2. According to the FDA guidance and USP general chapter <621>, what are the requirements for conducting system suitability tests in laboratory chromatography, and how should actual samples be handled if used for such testing?\n\n3. What are the FDA's requirements for retaining data from reprocessed laboratory chromatography analyses, and how does this relate to the principles of data integrity and compliance with CGMP as outlined in the provided document excerpt?", "prev_section_summary": "The key topics of this section include the use of electronic signatures in CGMP documentation practices for pet drugs, the definition of a CGMP record in relation to electronic data, expectations for documenting or saving data to comply with CGMP requirements, design of computer systems for data integrity and compliance, and FDA expectations for processes and controls. The entities mentioned include firms using electronic signatures, FDA regulations, CGMP requirements, chromatographic data, audit trails, computer systems like LIMS or EBR systems, and FDA inspections of manufacturing facilities.", "excerpt_keywords": "FDA, Data Integrity, Compliance, Drug CGMP, Laboratory Chromatography"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[4] FDA Data Integrity and Compliance With Drug CGMP (Q&A) Guidance for Industry.pdf\n## 13. why has fda cited use of actual samples during \"system suitability\" or test, prep, or equilibration runs in warning letters?\n\nfda prohibits sampling and testing with the goal of achieving a specific result or to overcome an unacceptable result (e.g., testing different samples until the desired passing result is obtained). this practice, also referred to as testing into compliance, is not consistent with cgmp (see the guidance for industry investigating out-of-specification (oos) test results for pharmaceutical production). in some situations, use of actual samples to perform system suitability testing has been used as a means of testing into compliance. fda considers it a violative practice to use an actual sample in test, prep, or equilibration runs as a means of disguising testing into compliance.\n\naccording to the united states pharmacopeia (usp), system suitability tests must include replicate injections of a standard preparation or other standard solutions to determine if requirements for precision are satisfied (see usp general chapter <621> chromatography). system suitability tests should be performed according to the firms established written procedures--which should include the identity of the preparation to be injected and the rationale for its selection--and the approved application or applicable compendial monograph (SSSS 211.160 and 212.60).\n\nif an actual sample is to be used for system suitability testing, it should be a properly characterized secondary standard, written procedures should be established and followed, and the sample should be from a different batch than the sample(s) being tested (SSSS 211.160, 211.165, and 212.60). cgmp original records must be complete (e.g., SSSS 211.68(b), 211.188, 211.194) and subjected to adequate review (SSSS 211.68(b), 211.186(a), 211.192, and 211.194(a)(8)). transparency is necessary. all data--including obvious errors and failing, passing, and suspect data--must be in the cgmp records that are retained and subject to review and oversight. an investigation with documented, scientifically sound justification is necessary for data to be invalidated and not used in determining conformance to specification for a batch (see SSSS 211.160, 211.165, 211.188, and 211.192).\n\nfor more information, see the ich guidance for industry q2(r1) validation of analytical procedures: text and methodology and vich guidances for industry gl1 validation of analytical procedures: definition and terminology and gl2 validation of analytical procedures: methodology.\n\n## 14. is it acceptable to only save the final results from reprocessed laboratory chromatography?\n\nno. analytical methods should be accurate and precise. for most lab analyses, reprocessing data should not be regularly needed. if chromatography is reprocessed, written procedures must be established and followed and each result retained for review (see SSSS 211.160, 211.165(c), 211.194(a)(4), and 212.60(a)). fda requires complete data in laboratory records, which includes\n\nvich=veterinary international conference on harmonisation. see ich guidance for industry q2(r1) validation of analytical procedures: text and methodology.", "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"}, "bf4f9b5e-e542-4b43-9615-05bf65688341": {"__data__": {"id_": "bf4f9b5e-e542-4b43-9615-05bf65688341", "embedding": null, "metadata": {"page_label": "16", "file_name": "[4] FDA Data Integrity and Compliance With Drug CGMP (Q&A) Guidance for Industry.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[4] FDA Data Integrity and Compliance With Drug CGMP (Q&A) Guidance for Industry.pdf", "file_type": "application/pdf", "file_size": 212227, "creation_date": "2024-04-07", "last_modified_date": "2024-04-04", "document_title": "Addressing Data Integrity Issues in CGMP Compliance: Strategies for Ensuring Regulatory Compliance and Quality Assurance", "questions_this_excerpt_can_answer": "1. What specific types of records and data are considered under the CGMP requirements for maintaining data integrity in the pharmaceutical industry, as outlined by the FDA?\n\n2. How does the FDA recommend handling internal tips or information regarding potential data falsification within the CGMP quality system, and what steps should be taken to investigate such allegations?\n\n3. What are the FDA's guidelines for training personnel on preventing and detecting data integrity issues as part of the CGMP training program, and what specific sections of the CGMP regulations support this requirement?", "prev_section_summary": "The section discusses FDA regulations on system suitability testing and data integrity in laboratory chromatography. Key topics include the FDA's prohibition of testing into compliance using actual samples, requirements for conducting system suitability tests, handling of actual samples in testing, and retaining data from reprocessed laboratory chromatography analyses. Entities mentioned include the FDA, USP, CGMP, system suitability tests, actual samples, chromatography, written procedures, data retention, and analytical methods.", "excerpt_keywords": "FDA, Data Integrity, Compliance, Drug CGMP, Quality Assurance"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[4] FDA Data Integrity and Compliance With Drug CGMP (Q&A) Guidance for Industry.pdf\nbut is not limited to notebooks, worksheets, graphs, charts, spectra, and other types of data from laboratory instruments (SSSS 211.194(a) and 212.60(g)(3)).\n\n15. can an internal tip or information regarding a quality issue, such as potential data falsification, be handled informally outside of the documented cgmp quality system?\n\nno. regardless of intent or how or from whom the information was received, suspected or known falsification or alteration of records required under parts 210, 211, and 212 must be fully investigated under the cgmp quality system to determine the effect of the event on patient safety, product quality, and data reliability; to determine the root cause; and to ensure the necessary corrective actions are taken (see SSSS 211.22(a), 211.125(c), 211.192, 211.198, 211.204, and 212.100).\n\nfda invites individuals to report suspected data integrity issues that may affect the safety, identity, strength, quality, or purity of drug products at druginfo@fda.hhs.gov. \"cgmp data integrity\" should be included in the subject line of the email. this reporting method is not intended to supersede other fda reports (e.g., field alert reports or biological product deviation reports that help identify drug products that pose potential safety threats).\n\n16. should personnel be trained in preventing and detecting data integrity issues as part of a routine cgmp training program?\n\nyes. training personnel to prevent and detect data integrity issues is consistent with the personnel requirements under SSSS 211.25 and 212.10, which state that personnel must have the education, training, and experience, or any combination thereof, to perform their assigned duties.\n\n17. is fda allowed to look at electronic records?\n\nyes. all records required under cgmp are subject to fda inspection. this applies to records generated and maintained on computerized systems, including electronic communications that support cgmp activities. for example, an email to authorize batch release is a cgmp record that fda may review.\n\nyou must allow authorized inspection, review, and copying of records, which includes copying of electronic data (SSSS 211.180(c) and 212.110(a) and (b)). see also the guidance for industry circumstances that constitute delaying, denying, limiting, or refusing a drug inspection and section 704 of the fd&c act. procedures governing the review of electronic records are described in chapter 5 of the investigations operations manual (iom) at https://www.fda.gov/iceci/inspections/iom/default.htm.\n\n18. how does fda recommend data integrity problems be addressed?\n\nfda encourages you to demonstrate that you have effectively remediated your problems by investigating to determine the problems scope and root causes, conducting a scientifically sound risk assessment of its potential effects (including impact on data used to support submissions to", "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"}, "38206b01-1640-4a5c-b31b-f402c13e2c04": {"__data__": {"id_": "38206b01-1640-4a5c-b31b-f402c13e2c04", "embedding": null, "metadata": {"page_label": "17", "file_name": "[4] FDA Data Integrity and Compliance With Drug CGMP (Q&A) Guidance for Industry.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[4] FDA Data Integrity and Compliance With Drug CGMP (Q&A) Guidance for Industry.pdf", "file_type": "application/pdf", "file_size": 212227, "creation_date": "2024-04-07", "last_modified_date": "2024-04-04", "document_title": "FDA Data Integrity Management Strategy and Corrective Action Plan", "questions_this_excerpt_can_answer": "1. What specific measures does the FDA recommend for a firm to address and correct data integrity lapses in compliance with drug CGMP guidelines?\n   \n2. How does the FDA suggest a firm should manage and prevent future data integrity breaches, including the types of systems or officials that should be put in place?\n\n3. Where can one find more detailed guidance on conducting internal reviews and developing corrective action operating plans as per the FDA's expectations related to the application integrity policy?", "prev_section_summary": "The key topics covered in this section include the types of records and data considered under CGMP requirements for data integrity in the pharmaceutical industry, handling internal tips or information regarding potential data falsification, guidelines for training personnel on preventing and detecting data integrity issues, FDA's authority to inspect electronic records, and recommendations for addressing data integrity problems. The entities mentioned include the FDA, pharmaceutical industry personnel, and the CGMP quality system.", "excerpt_keywords": "FDA, data integrity, compliance, corrective action plan, drug CGMP"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[4] FDA Data Integrity and Compliance With Drug CGMP (Q&A) Guidance for Industry.pdf\nfda), and implementing a management strategy, including a global corrective action plan that addresses the root causes. this may include retaining a third-party auditor and removing individuals responsible for data integrity lapses from positions where they can influence cgmp-related or drug application data at your firm. it also may include improvements in quality oversight, enhanced computer systems, and creation of mechanisms to prevent recurrences and address data integrity breaches (e.g., anonymous reporting system, data governance officials and guidelines).\n\nthese expectations mirror those developed for the application integrity policy. for more detailed information, see points to consider for internal reviews and corrective action operating plans at http://www.fda.gov/iceci/enforcementactions/applicationintegritypolicy/ucm134744.htm.", "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"}, "b0d6cfba-ac79-459f-8745-c48b3f5e78e5": {"__data__": {"id_": "b0d6cfba-ac79-459f-8745-c48b3f5e78e5", "embedding": null, "metadata": {"page_label": "1", "file_name": "[18] FDA General Principles of Software Validation -2002.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[18] FDA General Principles of Software Validation -2002.pdf", "file_type": "application/pdf", "file_size": 376042, "creation_date": "2024-04-07", "last_modified_date": "2024-03-28", "document_title": "FDA Guidance on Software Validation for Medical Devices", "questions_this_excerpt_can_answer": "1. What is the official release date of the final guidance document on the general principles of software validation provided by the FDA for industry and FDA staff, and how does it relate to its draft predecessor?\n   \n2. Can you detail the evolution of the FDA's guidance on software validation for medical devices from its initial draft version to the final guidance issued in 2002, including specific dates and version numbers?\n\n3. Which specific centers within the U.S. Department of Health and Human Services' Food and Drug Administration were involved in issuing the 2002 guidance document on software validation for medical devices?", "excerpt_keywords": "FDA, software validation, medical devices, guidance, industry"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[18] FDA General Principles of Software Validation -2002.pdf\n# general principles of software validation; final guidance for industry and fda staff\n\ndocument issued on: january 11, 2002\n\nthis document supersedes the draft document, \"general principles of software validation, version 1.1, dated june 9, 1997.\n\nu.s. department of health and human services\n\nfood and drug administration\n\ncenter for devices and radiological health\n\ncenter for biologics evaluation and research", "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"}, "e0a45702-238f-4326-8e7f-65f0488c639d": {"__data__": {"id_": "e0a45702-238f-4326-8e7f-65f0488c639d", "embedding": null, "metadata": {"page_label": "2", "file_name": "[18] FDA General Principles of Software Validation -2002.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[18] FDA General Principles of Software Validation -2002.pdf", "file_type": "application/pdf", "file_size": 376042, "creation_date": "2024-04-07", "last_modified_date": "2024-03-28", "document_title": "FDA Guidance for Industry on General Principles of Software Validation and Contact Information for Comments and Questions", "questions_this_excerpt_can_answer": "1. What is the process for submitting comments and suggestions regarding the FDA's guidance on the general principles of software validation, and where should these be directed?\n   \n2. Who should be contacted for questions regarding the use or interpretation of the FDA's guidance on software validation that involve the Center for Devices and Radiological Health (CDRH) or the Center for Biologics Evaluation and Research (CBER)?\n\n3. How can one obtain additional copies of the FDA's guidance document on the general principles of software validation, specifically for devices regulated by CDRH and biologics evaluated by CBER, including both electronic and hard copies?", "prev_section_summary": "The section provides information on the FDA's guidance on software validation for medical devices, specifically focusing on the final guidance document issued on January 11, 2002. It supersedes a previous draft document from 1997. The key entities involved in issuing this guidance include the U.S. Department of Health and Human Services, the Food and Drug Administration, the Center for Devices and Radiological Health, and the Center for Biologics Evaluation and Research. The section addresses the evolution of the FDA's guidance on software validation and provides details on the official release date and relationship to the draft predecessor.", "excerpt_keywords": "FDA, software validation, guidance, medical devices, CDRH, CBER, comments, suggestions, electronic copy, hard copy"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[18] FDA General Principles of Software Validation -2002.pdf\nguidance for industry and fda staff general principles of software validation\n\npublic comment preface comments and suggestions may be submitted at any time for agency consideration to dockets management branch, division of management systems and policy, office of human resources and management services, food and drug administration, 5630 fishers lane, room 1061, (hfa-305), rockville, md, 20852. when submitting comments, please refer to the exact title of this guidance document. comments may not be acted upon by the agency until the document is next revised or updated. for questions regarding the use or interpretation of this guidance which involve the center for devices and radiological health (cdrh), contact john f. murray at (301) 594-4659 or email jfm@cdrh.fda.gov for questions regarding the use or interpretation of this guidance which involve the center for biologics evaluation and research (cber) contact jerome davis at (301) 827-6220 or email davis@cber.fda.gov. additional copies cdrh additional copies are available from the internet at: www.fda.gov/medicaldevices/ deviceregulationandguidance/guidancedocuments/ucm085281.htm. you may also send an e-mail request to dsmica@fda.hhs.gov to receive an electronic copy of the guidance or send a fax request to 301-847-8149 to receive a hard copy. please use the document number (938) to identify the guidance you are requesting. cber additional copies are available from the internet at: http://www.fda.gov/cber/guidelines.htm, by writing to cber, office of communication, training, and manufacturers assistance (hfm- 40), 1401 rockville pike, rockville, maryland 20852-1448, or by telephone request at 1- 800-835-5709 or 301-827-1800. page ii", "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"}, "143215aa-4515-4f1a-be5e-f543825b425a": {"__data__": {"id_": "143215aa-4515-4f1a-be5e-f543825b425a", "embedding": null, "metadata": {"page_label": "3", "file_name": "[18] FDA General Principles of Software Validation -2002.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[18] FDA General Principles of Software Validation -2002.pdf", "file_type": "application/pdf", "file_size": 376042, "creation_date": "2024-04-07", "last_modified_date": "2024-03-28", "document_title": "Comprehensive Guide to Software Validation: Purpose, Scope, Regulatory Requirements, Definitions, Principles, and Benefits.", "questions_this_excerpt_can_answer": "1. What specific sections of the FDA's 2002 document on General Principles of Software Validation discuss the differences between software and hardware in terms of validation requirements, and what benefits are outlined for software validation?\n   \n2. How does the document detail the approach to software validation in terms of the software development lifecycle, including the stages of requirements gathering, defect prevention, and validation after changes to the software?\n\n3. In the context of regulatory requirements for software validation, how does the document differentiate between Quality System Regulation and pre-market submissions, and what guidance does it provide regarding the least burdensome approach for compliance?", "prev_section_summary": "This section provides guidance on the general principles of software validation from the FDA. It includes information on how to submit comments and suggestions for agency consideration, who to contact for questions regarding the guidance document, and how to obtain additional copies of the document. Key entities mentioned include the Center for Devices and Radiological Health (CDRH) and the Center for Biologics Evaluation and Research (CBER).", "excerpt_keywords": "FDA, software validation, regulatory requirements, software development lifecycle, quality system regulation"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[18] FDA General Principles of Software Validation -2002.pdf\n|content|page number|\n|---|---|\n|section 1. purpose|1|\n|section 2. scope|1|\n|2.1. applicability|2|\n|2.2. audience|2|\n|2.3. the least burdensome approach|2|\n|2.4. regulatory requirements for software validation|3|\n|2.4. quality system regulation vs pre-market submissions|4|\n|section 3. context for software validation|5|\n|3.1. definitions and terminology|5|\n|3.1.1 requirements and specifications|5|\n|3.1.2 verification and validation|6|\n|3.1.3 iq/oq/pq|7|\n|3.2. software development as part of system design|7|\n|3.3. software is different from hardware|8|\n|3.4. benefits of software validation|9|\n|3.5 design review|9|\n|section 4. principles of software validation|11|\n|4.1. requirements|11|\n|4.2. defect prevention|11|\n|4.3. time and effort|11|\n|4.4. software life cycle|11|\n|4.5. plans|12|\n|4.6. procedures|12|\n|4.7. software validation after a change|12|\n|4.8. validation coverage|12|\n|4.9. independence of review|12|", "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"}, "36a60b84-52be-4f38-8af0-672746521221": {"__data__": {"id_": "36a60b84-52be-4f38-8af0-672746521221", "embedding": null, "metadata": {"page_label": "4", "file_name": "[18] FDA General Principles of Software Validation -2002.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[18] FDA General Principles of Software Validation -2002.pdf", "file_type": "application/pdf", "file_size": 376042, "creation_date": "2024-04-07", "last_modified_date": "2024-03-28", "document_title": "Comprehensive Software Validation Guidelines and Best Practices", "questions_this_excerpt_can_answer": "1. What specific sections and page numbers detail the activities and tasks involved in software validation according to the FDA's general principles as outlined in the 2002 document?\n   \n2. How does the 2002 FDA document outline the validation process for automated process equipment and quality system software, including the necessary amount of validation evidence and considerations for off-the-shelf software?\n\n3. What resources or references does the 2002 FDA document on software validation provide regarding food and drug administration guidelines, other government references, international and national consensus standards, production process software, and general software quality?", "prev_section_summary": "The section provides an overview of the purpose, scope, regulatory requirements, definitions, principles, and benefits of software validation according to the FDA's 2002 document on General Principles of Software Validation. It discusses the differences between software and hardware in terms of validation requirements, the benefits of software validation, and the approach to software validation in the software development lifecycle. The document also differentiates between Quality System Regulation and pre-market submissions in terms of regulatory requirements and provides guidance on the least burdensome approach for compliance. Key topics include definitions and terminology, software development as part of system design, benefits of software validation, principles of software validation, and validation coverage. Key entities mentioned are requirements, defect prevention, time and effort, software life cycle, plans, procedures, and independence of review.", "excerpt_keywords": "Keywords: FDA, software validation, guidelines, automated process equipment, quality system software"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[18] FDA General Principles of Software Validation -2002.pdf\n## guidance for industry and fda staff - general principles of software validation\n\n4.10. flexibility and responsibility\n13\n\n## section 5. activities and tasks\n\n|5.1. software life cycle activities|14|\n|---|---|\n|5.2. typical tasks supporting validation|14|\n|5.2.1. quality planning|15|\n|5.2.2. requirements|16|\n|5.2.3. design|17|\n|5.2.4. construction or coding|20|\n|5.2.5. testing by the software developer|21|\n|5.2.6. user site testing|27|\n|5.2.7. maintenance and software changes|28|\n\n## section 6. validation of automated process equipment and quality system software\n\n|6.1. how much validation evidence is needed?|31|\n|---|---|\n|6.2. defined user requirements|32|\n|6.3. validation of off-the-shelf software and automated equipment|33|\n\n## appendix a - references\n\n|food and drug administration references|35|\n|---|---|\n|other government references|36|\n|international and national consensus standards|37|\n|production process software references|38|\n|general software quality references|39|\n\n## appendix b - development team\n\npage iv", "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"}, "92056097-8732-4b49-baf4-a9273a058164": {"__data__": {"id_": "92056097-8732-4b49-baf4-a9273a058164", "embedding": null, "metadata": {"page_label": "5", "file_name": "[18] FDA General Principles of Software Validation -2002.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[18] FDA General Principles of Software Validation -2002.pdf", "file_type": "application/pdf", "file_size": 376042, "creation_date": "2024-04-07", "last_modified_date": "2024-03-28", "document_title": "Guidance for FDA Staff and Industry on General Principles of Software Validation in Medical Devices", "questions_this_excerpt_can_answer": "1. What does the FDA's guidance document on the general principles of software validation specifically outline regarding the validation of medical device software or software used in the design, development, or manufacture of medical devices?\n\n2. How does the FDA's guidance document address the integration of software life cycle management and risk management activities in the context of medical device software validation?\n\n3. What is the FDA's stance on the responsibility for compliance with regulations when the software is developed by an entity other than the device manufacturer, such as in the case of off-the-shelf software?", "prev_section_summary": "The section provides guidance on software validation according to the FDA's general principles, outlining activities and tasks involved in the software life cycle. It details the validation process for automated process equipment and quality system software, including the necessary amount of validation evidence and considerations for off-the-shelf software. The document also references food and drug administration guidelines, other government references, international and national consensus standards, production process software, and general software quality. Key topics include flexibility and responsibility, software life cycle activities, validation tasks, user requirements, and references for further information.", "excerpt_keywords": "FDA, software validation, medical devices, risk management, compliance"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[18] FDA General Principles of Software Validation -2002.pdf\n## guidance for industry and fda staff\n\n## general principles of software validation\n\nthis document is intended to provide guidance. it represents the agencys current thinking on this topic. it does not create or confer any rights for or on any person and does not operate to bind food and drug administration (fda) or the public. an alternative approach may be used if such approach satisfies the requirements of the applicable statutes and regulations.\n\n### section 1. purpose\n\nthis guidance outlines general validation principles that the food and drug administration (fda) considers to be applicable to the validation of medical device software or the validation of software used to design, develop, or manufacture medical devices. this final guidance document, version 2.0, supersedes the draft document, general principles of software validation, version 1.1, dated june 9, 1997.\n\n### section 2. scope\n\nthis guidance describes how certain provisions of the medical device quality system regulation apply to software and the agencys current approach to evaluating a software validation system. for example, this document lists elements that are acceptable to the fda for the validation of software; however, it does not list all of the activities and tasks that must, in all instances, be used to comply with the law. the scope of this guidance is somewhat broader than the scope of validation in the strictest definition of that term. planning, verification, testing, traceability, configuration management, and many other aspects of good software engineering discussed in this guidance are important activities that together help to support a final conclusion that software is validated.\n\nthis guidance recommends an integration of software life cycle management and risk management activities. based on the intended use and the safety risk associated with the software to be developed, the software developer should determine the specific approach, the combination of techniques to be used, and the level of effort to be applied. while this guidance does not recommend any specific life cycle model or any specific technique or method, it does recommend that software validation and verification activities be conducted throughout the entire software life cycle.\n\nwhere the software is developed by someone other than the device manufacturer (e.g., off-the-shelf software) the software developer may not be directly responsible for compliance with fda regulations.\n\npage 1", "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"}, "6706c9fa-5ec9-46a2-9539-3d6b95fe9a64": {"__data__": {"id_": "6706c9fa-5ec9-46a2-9539-3d6b95fe9a64", "embedding": null, "metadata": {"page_label": "6", "file_name": "[18] FDA General Principles of Software Validation -2002.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[18] FDA General Principles of Software Validation -2002.pdf", "file_type": "application/pdf", "file_size": 376042, "creation_date": "2024-04-07", "last_modified_date": "2024-03-28", "document_title": "Comprehensive Guide to Software Validation in the Medical Device Industry", "questions_this_excerpt_can_answer": "1. What specific types of software does the FDA's guidance on software validation apply to within the medical device industry, as outlined in the 2002 document \"General Principles of Software Validation\"?\n\n2. Who are the intended audiences for the FDA's 2002 guidance on software validation in the medical device industry, and what roles do they play in relation to medical device software?\n\n3. How does the FDA's 2002 guidance document on software validation in the medical device industry address the concept of the \"least burdensome approach\" for compliance, and what does it suggest manufacturers do if they believe there is a less burdensome alternative?", "prev_section_summary": "The section provides guidance on general principles of software validation for medical devices, outlining the FDA's current thinking on the topic. It covers the purpose of the guidance, the scope of validation activities for medical device software, and the integration of software life cycle management and risk management. The document emphasizes the importance of various software engineering activities in ensuring validation, and addresses the responsibility for compliance with regulations when software is developed by entities other than the device manufacturer.", "excerpt_keywords": "FDA, software validation, medical device industry, guidance, least burdensome approach"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[18] FDA General Principles of Software Validation -2002.pdf\n## guidance for industry and fda staff\n\n### general principles of software validation\n\nin that case, the party with regulatory responsibility (i.e., the device manufacturer) needs to assess the adequacy of the off-the-shelf software developers activities and determine what additional efforts are needed to establish that the software is validated for the device manufacturers intended use.\n\n### 2.1. applicability\n\nthis guidance applies to:\n\n- software used as a component, part, or accessory of a medical device;\n- software that is itself a medical device (e.g., blood establishment software);\n- software used in the production of a device (e.g., programmable logic controllers in manufacturing equipment); and\n- software used in implementation of the device manufacturers quality system (e.g., software that records and maintains the device history record).\n\nthis document is based on generally recognized software validation principles and, therefore, can be applied to any software. for fda purposes, this guidance applies to any software related to a regulated medical device, as defined by section 201(h) of the federal food, drug, and cosmetic act (the act) and by current fda software and regulatory policy. this document does not specifically identify which software is or is not regulated.\n\n### 2.2. audience\n\nthis guidance provides useful information and recommendations to the following individuals:\n\n- persons subject to the medical device quality system regulation\n- persons responsible for the design, development, or production of medical device software\n- persons responsible for the design, development, production, or procurement of automated tools used for the design, development, or manufacture of medical devices or software tools used to implement the quality system itself\n- fda investigators\n- fda compliance officers\n- fda scientific reviewers\n\n### 2.3. the least burdensome approach\n\nwe believe we should consider the least burdensome approach in all areas of medical device regulation. this guidance reflects our careful review of the relevant scientific and legal requirements and what we believe is the least burdensome way for you to comply with those requirements. however, if you believe that an alternative approach would be less burdensome, please contact us so we can consider.", "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"}, "ec5eefec-84ef-4e89-bac6-abeeb4488142": {"__data__": {"id_": "ec5eefec-84ef-4e89-bac6-abeeb4488142", "embedding": null, "metadata": {"page_label": "7", "file_name": "[18] FDA General Principles of Software Validation -2002.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[18] FDA General Principles of Software Validation -2002.pdf", "file_type": "application/pdf", "file_size": 376042, "creation_date": "2024-04-07", "last_modified_date": "2024-03-28", "document_title": "FDA Requirements for Software Validation in Medical Devices: A Comprehensive Guide", "questions_this_excerpt_can_answer": "1. What percentage of medical device recalls between 1992 and 1998 were attributed to software failures, and what proportion of these failures were due to software defects introduced after initial production and distribution?\n\n2. As of what date did the Quality System Regulation, which includes requirements for software validation in medical devices, take effect, and where can these requirements be found in the Code of Federal Regulations?\n\n3. What specific aspects of the device production process or quality system are mentioned as requiring software validation according to 21 CFR \u00a7820.70(i), and how does this regulation extend to computer systems managing electronic records and signatures?", "prev_section_summary": "The section discusses the general principles of software validation in the medical device industry as outlined in the FDA's 2002 guidance document. It covers the applicability of the guidance to various types of software used in medical devices, the intended audiences including device manufacturers, software developers, and FDA staff, and the concept of the \"least burdensome approach\" for compliance. The section emphasizes the importance of assessing off-the-shelf software, the roles of different stakeholders in software validation, and the need for collaboration between industry and regulatory authorities to ensure compliance with regulations.", "excerpt_keywords": "FDA, Software Validation, Medical Devices, Quality System Regulation, Electronic Records"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[18] FDA General Principles of Software Validation -2002.pdf\n## guidance for industry and fda staff\n\ngeneral principles of software validation\n\nyour point of view. you may send your written comments to the contact person listed in the preface to this guidance or to the cdrh ombudsman. comprehensive information on cdrhs ombudsman, including ways to contact him, can be found on the internet at:\n\nhttp://www.fda.gov/cdrh/resolvingdisputes/ombudsman.html.\n\n## regulatory requirements for software validation\n\nthe fdas analysis of 3140 medical device recalls conducted between 1992 and 1998 reveals that 242 of them (7.7%) are attributable to software failures. of those software related recalls, 192 (or 79%) were caused by software defects that were introduced when changes were made to the software after its initial production and distribution. software validation and other related good software engineering practices discussed in this guidance are a principal means of avoiding such defects and resultant recalls.\n\nsoftware validation is a requirement of the quality system regulation, which was published in the federal register on october 7, 1996 and took effect on june 1, 1997. (see title 21 code of federal regulations (cfr) part 820, and 61 federal register (fr) 52602, respectively.) validation requirements apply to software used as components in medical devices, to software that is itself a medical device, and to software used in production of the device or in implementation of the device manufacturers quality system.\n\nunless specifically exempted in a classification regulation, any medical device software product developed after june 1, 1997, regardless of its device class, is subject to applicable design control provisions. (see of 21 cfr SS820.30.) this requirement includes the completion of current development projects, all new development projects, and all changes made to existing medical device software. specific requirements for validation of device software are found in 21 cfr SS820.30(g). other design controls, such as planning, input, verification, and reviews, are required for medical device software. (see 21 cfr SS820.30.) the corresponding documented results from these activities can provide additional support for a conclusion that medical device software is validated.\n\nany software used to automate any part of the device production process or any part of the quality system must be validated for its intended use, as required by 21 cfr SS820.70(i). this requirement applies to any software used to automate device design, testing, component acceptance, manufacturing, labeling, packaging, distribution, complaint handling, or to automate any other aspect of the quality system.\n\nin addition, computer systems used to create, modify, and maintain electronic records and to manage electronic signatures are also subject to the validation requirements. (see 21 cfr SS11.10(a).) such computer systems must be validated to ensure accuracy, reliability, consistent intended performance, and the ability to discern invalid or altered 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"}, "216054cf-0c54-41c9-a432-3886451feeab": {"__data__": {"id_": "216054cf-0c54-41c9-a432-3886451feeab", "embedding": null, "metadata": {"page_label": "8", "file_name": "[18] FDA General Principles of Software Validation -2002.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[18] FDA General Principles of Software Validation -2002.pdf", "file_type": "application/pdf", "file_size": 376042, "creation_date": "2024-04-07", "last_modified_date": "2024-03-28", "document_title": "Software Validation in Medical Device Manufacturing and Quality Systems: Ensuring Compliance and Efficacy", "questions_this_excerpt_can_answer": "1. What are the responsibilities of device manufacturers when they purchase off-the-shelf software for use in medical devices or in the manufacturing and quality systems of these devices, according to the FDA's 2002 guidance?\n   \n2. How does the FDA's 2002 guidance document differentiate between the management and control of the software validation process and other validation requirements, such as process validation for automated manufacturing processes?\n\n3. Where can device manufacturers find additional guidance on the use of off-the-shelf software in medical devices and in manufacturing or quality system operations, as per the FDA's 2002 guidance document?", "prev_section_summary": "The section discusses the FDA's requirements for software validation in medical devices, highlighting the importance of software validation in preventing recalls due to software failures. It mentions that software validation is a requirement of the Quality System Regulation, which took effect in 1997, and applies to software used in medical devices, as well as in the production process and quality system of device manufacturers. Specific requirements for validation of device software are outlined in the regulation, including design controls and validation of software used to automate various aspects of the device production process and quality system. The section also emphasizes the validation requirements for computer systems managing electronic records and signatures to ensure accuracy, reliability, and consistent performance.", "excerpt_keywords": "Software Validation, Medical Device Manufacturing, Quality Systems, FDA Guidance, Off-the-Shelf Software"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[18] FDA General Principles of Software Validation -2002.pdf\n## guidance for industry and fda staff\n\ngeneral principles of software validation\n\nsoftware for the above applications may be developed in-house or under contract. however, software is frequently purchased off-the-shelf for a particular intended use. all production and/or quality system software, even if purchased off-the-shelf, should have documented requirements that fully define its intended use, and information against which testing results and other evidence can be compared, to show that the software is validated for its intended use.\n\nthe use of off-the-shelf software in automated medical devices and in automated manufacturing and quality system operations is increasing. off-the-shelf software may have many capabilities, only a few of which are needed by the device manufacturer. device manufacturers are responsible for the adequacy of the software used in their devices, and used to produce devices. when device manufacturers purchase \"off-the-shelf software, they must ensure that it will perform as intended in their chosen application. for off-the-shelf software used in manufacturing or in the quality system, additional guidance is included in section 6.3 of this document. for device software, additional useful information may be found in fdas guidance for industry, fda reviewers, and compliance on off-the-shelf software use in medical devices.\n\n## 2.4. quality system regulation vs pre-market submissions\n\nthis document addresses quality system regulation issues that involve the implementation of software validation. it provides guidance for the management and control of the software validation process.\n\nthe management and control of the software validation process should not be confused with any other validation requirements, such as process validation for an automated manufacturing process. device manufacturers may use the same procedures and records for compliance with quality system and design control requirements, as well as for pre-market submissions to fda. this document does not cover any specific safety or efficacy issues related to software validation. design issues and documentation requirements for pre-market submissions of regulated software are not addressed by this document. specific issues related to safety and efficacy, and the documentation required in pre-market submissions, should be addressed to the office of device evaluation (ode), center for devices and radiological health (cdrh) or to the office of blood research and review, center for biologics evaluation and research (cber). see the references in appendix a for applicable fda guidance documents for pre-market submissions.\n\npage 4", "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"}, "27441a91-ffde-47f7-94fa-907485c2a9b3": {"__data__": {"id_": "27441a91-ffde-47f7-94fa-907485c2a9b3", "embedding": null, "metadata": {"page_label": "9", "file_name": "[18] FDA General Principles of Software Validation -2002.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[18] FDA General Principles of Software Validation -2002.pdf", "file_type": "application/pdf", "file_size": 376042, "creation_date": "2024-04-07", "last_modified_date": "2024-03-28", "document_title": "General Principles of Software Validation: Context, Definitions, and Best Practices", "questions_this_excerpt_can_answer": "1. What is the FDA's definition of \"establish\" as it pertains to software validation within the medical device quality system regulation, and how does it differ from common software industry terminology?\n   \n2. How does the FDA document differentiate between \"requirements\" and \"specifications\" in the context of software validation for medical devices, and what types of requirements are identified as crucial for successful software validation?\n\n3. Given the variety of medical devices and processes, what broad concepts does the FDA recommend for building a comprehensive approach to software validation, and where can additional specific information on these concepts be found according to the document?", "prev_section_summary": "This section discusses the general principles of software validation in the context of medical device manufacturing and quality systems, as outlined in the FDA's 2002 guidance document. Key topics include the responsibilities of device manufacturers when using off-the-shelf software, the management and control of the software validation process, and the differentiation between quality system regulation and pre-market submissions. The section emphasizes the importance of ensuring that software, whether developed in-house or purchased off-the-shelf, is validated for its intended use in medical devices and manufacturing operations. Device manufacturers are responsible for the adequacy of the software used in their devices and must ensure that off-the-shelf software performs as intended. Additional guidance on the use of off-the-shelf software in medical devices and quality system operations is provided in the document.", "excerpt_keywords": "FDA, software validation, medical devices, quality system regulation, requirements"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[18] FDA General Principles of Software Validation -2002.pdf\n## guidance for industry and fda staff\n\n## general principles of software validation\n\n### section 3. context for software validation\n\nmany people have asked for specific guidance on what fda expects them to do to ensure compliance with the quality system regulation with regard to software validation. information on software validation presented in this document is not new. validation of software, using the principles and tasks listed in sections 4 and 5, has been conducted in many segments of the software industry for well over 20 years.\n\ndue to the great variety of medical devices, processes, and manufacturing facilities, it is not possible to state in one document all of the specific validation elements that are applicable. however, a general application of several broad concepts can be used successfully as guidance for software validation. these broad concepts provide an acceptable framework for building a comprehensive approach to software validation. additional specific information is available from many of the references listed in appendix a.\n\n### 3.1. definitions and terminology\n\nunless defined in the quality system regulation, or otherwise specified below, all other terms used in this guidance are as defined in the current edition of the fda glossary of computerized system and software development terminology.\n\nthe medical device quality system regulation (21 cfr 820.3(k)) defines \"establish\" to mean \"define, document, and implement.\" where it appears in this guidance, the words \"establish\" and \"established\" should be interpreted to have this same meaning.\n\nsome definitions found in the medical device quality system regulation can be confusing when compared to commonly used terminology in the software industry. examples are requirements, specification, verification, and validation.\n\n#### 3.1.1 requirements and specifications\n\nwhile the quality system regulation states that design input requirements must be documented, and that specified requirements must be verified, the regulation does not further clarify the distinction between the terms \"requirement\" and \"specification.\" a requirement can be any need or expectation for a system or for its software. requirements reflect the stated or implied needs of the customer, and may be market-based, contractual, or statutory, as well as an organizations internal requirements. there can be many different kinds of requirements (e.g., design, functional, implementation, interface, performance, or physical requirements). software requirements are typically derived from the system requirements for those aspects of system functionality that have been allocated to software. software requirements are typically stated in functional terms and are defined, refined, and updated as a development project progresses. success in accurately and completely documenting software requirements is a crucial factor in successful validation of the resulting software.\n\npage 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"}, "2d4d1c9c-5b30-4b2b-b777-29186c395f39": {"__data__": {"id_": "2d4d1c9c-5b30-4b2b-b777-29186c395f39", "embedding": null, "metadata": {"page_label": "10", "file_name": "[18] FDA General Principles of Software Validation -2002.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[18] FDA General Principles of Software Validation -2002.pdf", "file_type": "application/pdf", "file_size": 376042, "creation_date": "2024-04-07", "last_modified_date": "2024-03-28", "document_title": "Software Verification and Validation in FDA Guidance: A Comprehensive Overview", "questions_this_excerpt_can_answer": "1. How does the FDA's guidance document define the term \"specification\" in the context of software validation, and what are some examples of different kinds of written specifications mentioned?\n   \n2. According to the FDA's guidance, how are the concepts of software verification and validation differentiated, and what specific activities are included under software verification to ensure the software development output meets its input requirements?\n\n3. What criteria does the FDA consider for software validation, and how does it suggest measuring the level of confidence that a software automated device meets all requirements and user expectations?", "prev_section_summary": "This section provides guidance on software validation within the medical device quality system regulation. It discusses the context for software validation, including the importance of validation in the software industry and the need for a comprehensive approach due to the variety of medical devices and processes. The section also clarifies definitions and terminology related to software validation, such as the distinction between requirements and specifications. It emphasizes the importance of accurately documenting software requirements for successful validation. Additional specific information on software validation can be found in the references listed in the document's appendix.", "excerpt_keywords": "FDA, software validation, verification, validation, software requirements"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[18] FDA General Principles of Software Validation -2002.pdf\n## guidance for industry and fda staff\n\n## general principles of software validation\n\na specification is defined as \"a document that states requirements.\" (see 21 cfr SS820.3(y).) it may refer to or include drawings, patterns, or other relevant documents and usually indicates the means and the criteria whereby conformity with the requirement can be checked. there are many different kinds of written specifications, e.g., system requirements specification, software requirements specification, software design specification, software test specification, software integration specification, etc. all of these documents establish \"specified requirements\" and are design outputs for which various forms of verification are necessary.\n\n### verification and validation\n\nthe quality system regulation is harmonized with iso 8402:1994, which treats \"verification\" and \"validation\" as separate and distinct terms. on the other hand, many software engineering journal articles and textbooks use the terms \"verification\" and \"validation\" interchangeably, or in some cases refer to software \"verification, validation, and testing (vv&t)\" as if it is a single concept, with no distinction among the three terms.\n\nsoftware verification provides objective evidence that the design outputs of a particular phase of the software development life cycle meet all of the specified requirements for that phase. software verification looks for consistency, completeness, and correctness of the software and its supporting documentation, as it is being developed, and provides support for a subsequent conclusion that software is validated. software testing is one of many verification activities intended to confirm that software development output meets its input requirements. other verification activities include various static and dynamic analyses, code and document inspections, walkthroughs, and other techniques.\n\nsoftware validation is a part of the design validation for a finished device, but is not separately defined in the quality system regulation. for purposes of this guidance, fda considers software validation to be \"confirmation by examination and provision of objective evidence that software specifications conform to user needs and intended uses, and that the particular requirements implemented through software can be consistently fulfilled.\" in practice, software validation activities may occur both during, as well as at the end of the software development life cycle to ensure that all requirements have been fulfilled. since software is usually part of a larger hardware system, the validation of software typically includes evidence that all software requirements have been implemented correctly and completely and are traceable to system requirements. a conclusion that software is validated is highly dependent upon comprehensive software testing, inspections, analyses, and other verification tasks performed at each stage of the software development life cycle. testing of device software functionality in a simulated use environment, and user site testing are typically included as components of an overall design validation program for a software automated device.\n\nsoftware verification and validation are difficult because a developer cannot test forever, and it is hard to know how much evidence is enough. in large measure, software validation is a matter of developing a \"level of confidence\" that the device meets all requirements and user expectations for the software automated functions and features of the device. measures such as defects found in specifications documents, estimates of defects remaining, testing coverage, and other techniques are all used to\n\npage 6", "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"}, "fc6b7973-6404-4d2a-9cdf-a2e9794447e1": {"__data__": {"id_": "fc6b7973-6404-4d2a-9cdf-a2e9794447e1", "embedding": null, "metadata": {"page_label": "11", "file_name": "[18] FDA General Principles of Software Validation -2002.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[18] FDA General Principles of Software Validation -2002.pdf", "file_type": "application/pdf", "file_size": 376042, "creation_date": "2024-04-07", "last_modified_date": "2024-03-28", "document_title": "Software Validation and System Design Integration: A Comprehensive Guide", "questions_this_excerpt_can_answer": "1. How does the FDA's guidance for industry and staff define the relationship between software validation and the safety risk posed by automated functions in medical devices, and what specific standards and sections does it reference for additional guidance on safety risk management?\n   \n2. What historical approach has the FDA and the regulated industry used to understand and define software validation in the context of process validation, and where can definitions and additional information regarding the Installation Qualification (IQ), Operational Qualification (OQ), and Performance Qualification (PQ) be found as per the FDA's guidance?\n\n3. In the context of system design and software development, how does the FDA's guidance suggest handling the integration of software requirements derived from overall system requirements, and what is the primary goal of software validation according to this guidance?", "prev_section_summary": "The section discusses the FDA's guidance on software validation, including the definition of specifications, the differentiation between verification and validation, and the criteria for software validation. It mentions various types of written specifications, verification activities such as testing and inspections, and the importance of developing a level of confidence that the software meets all requirements and user expectations. The section emphasizes the need for comprehensive testing and validation throughout the software development life cycle.", "excerpt_keywords": "FDA, software validation, system design integration, safety risk management, software requirements"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[18] FDA General Principles of Software Validation -2002.pdf\n## guidance for industry and fda staff\n\ngeneral principles of software validation\n\ndevelop an acceptable level of confidence before shipping the product. the level of confidence, and therefore the level of software validation, verification, and testing effort needed, will vary depending upon the safety risk (hazard) posed by the automated functions of the device. additional guidance regarding safety risk management for software may be found in section 4 of fdas guidance for the content of pre-market submissions for software contained in medical devices, and in the international standards iso/iec 14971-1 and iec 60601-1-4 referenced in appendix a.\n\n### 3.1.3 iq/oq/pq\n\nfor many years, both fda and regulated industry have attempted to understand and define software validation within the context of process validation terminology. for example, industry documents and other fda validation guidance sometimes describe user site software validation in terms of installation qualification (iq), operational qualification (oq) and performance qualification (pq). definitions of these terms and additional information regarding iq/oq/pq may be found in fdas guideline on general principles of process validation, dated may 11, 1987, and in fdas glossary of computerized system and software development terminology, dated august 1995.\n\nwhile iq/oq/pq terminology has served its purpose well and is one of many legitimate ways to organize software validation tasks at the user site, this terminology may not be well understood among many software professionals, and it is not used elsewhere in this document. however, both fda personnel and device manufacturers need to be aware of these differences in terminology as they ask for and provide information regarding software validation.\n\n### 3.2. software development as part of system design\n\nthe decision to implement system functionality using software is one that is typically made during system design. software requirements are typically derived from the overall system requirements and design for those aspects in the system that are to be implemented using software. there are user needs and intended uses for a finished device, but users typically do not specify whether those requirements are to be met by hardware, software, or some combination of both. therefore, software validation must be considered within the context of the overall design validation for the system.\n\na documented requirements specification represents the users needs and intended uses from which the product is developed. a primary goal of software validation is to then demonstrate that all completed software products comply with all documented software and system requirements. the correctness and completeness of both the system requirements and the software requirements should be addressed as part of the design validation process for the device. software validation includes confirmation of conformance to all software specifications and confirmation that all software requirements are traceable to the system specifications. confirmation is an important part of the overall design validation to ensure that all aspects of the medical device conform to user needs and intended uses.\n\npage 7", "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"}, "bb13186c-a1a4-419b-bc5a-d110fb318444": {"__data__": {"id_": "bb13186c-a1a4-419b-bc5a-d110fb318444", "embedding": null, "metadata": {"page_label": "12", "file_name": "[18] FDA General Principles of Software Validation -2002.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[18] FDA General Principles of Software Validation -2002.pdf", "file_type": "application/pdf", "file_size": 376042, "creation_date": "2024-04-07", "last_modified_date": "2024-03-28", "document_title": "Unique Characteristics of Software Development: A Comprehensive Overview", "questions_this_excerpt_can_answer": "1. How does the FDA document describe the primary factors that differentiate the quality assurance processes between software and hardware products?\n   \n2. What does the FDA document identify as the unique challenges posed by the branching feature of software, and how does it contribute to software complexity according to the 2002 guidelines?\n\n3. According to the FDA's 2002 guidelines, why is a tightly controlled engineering process deemed more crucial for software development compared to hardware, and what misconceptions about software changes does it address?", "prev_section_summary": "The section discusses the relationship between software validation and safety risk in medical devices, referencing FDA guidance and international standards. It also covers the historical approach to software validation using IQ/OQ/PQ terminology, as well as the integration of software requirements in system design. The primary goal of software validation is to ensure compliance with documented requirements and traceability to system specifications. Confirmation of conformance and completeness is crucial for overall design validation in medical devices.", "excerpt_keywords": "FDA, software validation, software development, quality assurance, branching feature"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[18] FDA General Principles of Software Validation -2002.pdf\n## guidance for industry and fda staff\n\n## general principles of software validation\n\n3.3. software is different from hardware\n\nwhile software shares many of the same engineering tasks as hardware, it has some very important differences. for example:\n\n- the vast majority of software problems are traceable to errors made during the design and development process. while the quality of a hardware product is highly dependent on design, development, and manufacture, the quality of a software product is dependent primarily on design and development with a minimum concern for software manufacture. software manufacturing consists of reproduction that can be easily verified. it is not difficult to manufacture thousands of program copies that function exactly the same as the original; the difficulty comes in getting the original program to meet all specifications.\n- one of the most significant features of software is branching, i.e., the ability to execute alternative series of commands, based on differing inputs. this feature is a major contributing factor for another characteristic of software - its complexity. even short programs can be very complex and difficult to fully understand.\n- typically, testing alone cannot fully verify that software is complete and correct. in addition to testing, other verification techniques and a structured and documented development process should be combined to ensure a comprehensive validation approach.\n- unlike hardware, software is not a physical entity and does not wear out. in fact, software may improve with age, as latent defects are discovered and removed. however, as software is constantly updated and changed, such improvements are sometimes countered by new defects introduced into the software during the change.\n- unlike some hardware failures, software failures occur without advanced warning. the softwares branching that allows it to follow differing paths during execution may hide some latent defects until long after a software product has been introduced into the marketplace.\n- another related characteristic of software is the speed and ease with which it can be changed. this factor can cause both software and non-software professionals to believe that software problems can be corrected easily. combined with a lack of understanding of software, it can lead managers to believe that tightly controlled engineering is not needed as much for software as it is for hardware. in fact, the opposite is true. because of its complexity, the development process for software should be even more tightly controlled than for hardware, in order to prevent problems that cannot be easily detected later in the development process.\n- seemingly insignificant changes in software code can create unexpected and very significant problems elsewhere in the software program. the software development process should be sufficiently well planned, controlled, and documented to detect and correct unexpected results from software changes.\n\npage 8", "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"}, "0e64c298-89dc-469f-a43c-3e587f22b6fe": {"__data__": {"id_": "0e64c298-89dc-469f-a43c-3e587f22b6fe", "embedding": null, "metadata": {"page_label": "13", "file_name": "[18] FDA General Principles of Software Validation -2002.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[18] FDA General Principles of Software Validation -2002.pdf", "file_type": "application/pdf", "file_size": 376042, "creation_date": "2024-04-07", "last_modified_date": "2024-03-28", "document_title": "Best Practices for Software Validation and Design Review", "questions_this_excerpt_can_answer": "1. How does the FDA document from 2002 address the challenge of software maintenance in the context of a highly mobile workforce and the importance of documentation in this scenario?\n\n2. What potential benefits does the FDA identify in the 2002 document regarding the practice of software validation for medical device manufacturers, particularly in terms of device reliability and long-term cost implications?\n\n3. How does the 2002 FDA document describe the role and structure of formal design reviews in the software validation process, especially in relation to managing and evaluating development projects within the medical device industry?", "prev_section_summary": "The section discusses the unique characteristics of software development compared to hardware, as outlined in the FDA's 2002 guidelines on software validation. Key points include the importance of design and development in software quality, the complexity introduced by branching features, the need for comprehensive validation approaches beyond testing, the continuous improvement and potential introduction of defects in software, the unpredictability of software failures, and the misconception that software changes can be easily corrected. The section emphasizes the necessity of tightly controlled engineering processes in software development to prevent hidden problems and unexpected consequences of code changes.", "excerpt_keywords": "FDA, software validation, design review, medical device, documentation"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[18] FDA General Principles of Software Validation -2002.pdf\n## guidance for industry and fda staff\n\n### general principles of software validation\n\ngiven the high demand for software professionals and the highly mobile workforce, the software personnel who make maintenance changes to software may not have been involved in the original software development. therefore, accurate and thorough documentation is essential.\n\nhistorically, software components have not been as frequently standardized and interchangeable as hardware components. however, medical device software developers are beginning to use component-based development tools and techniques. object-oriented methodologies and the use of off-the-shelf software components hold promise for faster and less expensive software development. however, component-based approaches require very careful attention during integration. prior to integration, time is needed to fully define and develop reusable software code and to fully understand the behavior of off-the-shelf components.\n\nfor these and other reasons, software engineering needs an even greater level of managerial scrutiny and control than does hardware engineering.\n\n### benefits of software validation\n\nsoftware validation is a critical tool used to assure the quality of device software and software automated operations. software validation can increase the usability and reliability of the device, resulting in decreased failure rates, fewer recalls and corrective actions, less risk to patients and users, and reduced liability to device manufacturers. software validation can also reduce long term costs by making it easier and less costly to reliably modify software and revalidate software changes. software maintenance can represent a very large percentage of the total cost of software over its entire life cycle. an established comprehensive software validation process helps to reduce the long-term cost of software by reducing the cost of validation for each subsequent release of the software.\n\n### design review\n\ndesign reviews are documented, comprehensive, and systematic examinations of a design to evaluate the adequacy of the design requirements, to evaluate the capability of the design to meet these requirements, and to identify problems. while there may be many informal technical reviews that occur within the development team during a software project, a formal design review is more structured and includes participation from others outside the development team. formal design reviews may reference or include results from other formal and informal reviews. design reviews may be conducted separately for the software, after the software is integrated with the hardware into the system, or both. design reviews should include examination of development plans, requirements specifications, design specifications, testing plans and procedures, all other documents and activities associated with the project, verification results from each stage of the defined life cycle, and validation results for the overall device.\n\ndesign review is a primary tool for managing and evaluating development projects. for example, formal design reviews allow management to confirm that all goals defined in the software validation plan have been met.", "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"}, "f0e71b7a-724b-4418-b314-4c0a1aa84d10": {"__data__": {"id_": "f0e71b7a-724b-4418-b314-4c0a1aa84d10", "embedding": null, "metadata": {"page_label": "14", "file_name": "[18] FDA General Principles of Software Validation -2002.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[18] FDA General Principles of Software Validation -2002.pdf", "file_type": "application/pdf", "file_size": 376042, "creation_date": "2024-04-07", "last_modified_date": "2024-03-28", "document_title": "Comprehensive Guide to Formal Design Reviews in Software Validation: Key Questions and Considerations", "questions_this_excerpt_can_answer": "1. What is the FDA's recommendation regarding the frequency and timing of formal design reviews during the device design process, particularly in relation to software validation?\n   \n2. Why is a formal design review considered especially important at or near the end of the requirements activity in the software validation process according to the FDA guidelines?\n\n3. What specific criteria should be documented and evaluated during formal design reviews to ensure the effectiveness and compliance of software life cycle activities as per the FDA's general principles of software validation?", "prev_section_summary": "The section discusses the general principles of software validation according to the FDA document from 2002. It highlights the importance of accurate documentation in software maintenance, the benefits of software validation for medical device manufacturers in terms of device reliability and cost implications, and the role of formal design reviews in managing and evaluating development projects within the medical device industry. Key topics include the challenges of software maintenance in a mobile workforce, the benefits of software validation, and the structure and importance of formal design reviews in the software validation process. Key entities mentioned are software personnel, software components, object-oriented methodologies, off-the-shelf software components, software engineering, hardware engineering, device software, design requirements, development plans, testing plans, verification results, and validation results.", "excerpt_keywords": "FDA, software validation, formal design reviews, medical device, documentation"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[18] FDA General Principles of Software Validation -2002.pdf\n# guidance for industry and fda staff\n\n## general principles of software validation\n\nbeen achieved. the quality system regulation requires that at least one formal design review be conducted during the device design process. however, it is recommended that multiple design reviews be conducted (e.g., at the end of each software life cycle activity, in preparation for proceeding to the next activity). formal design review is especially important at or near the end of the requirements activity, before major resources have been committed to specific design solutions. problems found at this point can be resolved more easily, save time and money, and reduce the likelihood of missing a critical issue.\n\nanswers to some key questions should be documented during formal design reviews. these include:\n\nhave pe appropriate tasks and expected results, outputs, or products been established for each software life cycle activity?\ndo pe tasks and expected results, outputs, or products of each software life cycle activity:\ncomply wip pe requirements of oper software life cycle activities in terms of correctness, completeness, consistency, and accuracy?\nsatisfy pe standards, practices, and conventions of pat activity?\nestablish a proper basis for initiating tasks for pe next software life cycle activity?\n\npage 10", "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"}, "7258d353-265a-4217-a25b-f202eca6563d": {"__data__": {"id_": "7258d353-265a-4217-a25b-f202eca6563d", "embedding": null, "metadata": {"page_label": "15", "file_name": "[18] FDA General Principles of Software Validation -2002.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[18] FDA General Principles of Software Validation -2002.pdf", "file_type": "application/pdf", "file_size": 376042, "creation_date": "2024-04-07", "last_modified_date": "2024-03-28", "document_title": "Principles of Software Validation: Ensuring Quality and Efficiency throughout the Software Development Life Cycle", "questions_this_excerpt_can_answer": "1. What specific regulatory references are cited in the document to underline the importance of having a documented software requirements specification for software validation?\n   \n2. How does the document describe the role of software quality assurance in the context of defect prevention during the software development process?\n\n3. According to the document, why is software testing alone considered insufficient for establishing confidence in software's fitness for its intended use, and what combination of methods is suggested to enhance confidence in software validation?", "prev_section_summary": "The section discusses the FDA's recommendations regarding formal design reviews in software validation, emphasizing the importance of conducting multiple design reviews throughout the device design process. It highlights the significance of a formal design review at or near the end of the requirements activity to identify and resolve issues early on, saving time and resources. The excerpt also outlines specific criteria that should be documented and evaluated during formal design reviews to ensure the effectiveness and compliance of software life cycle activities according to the FDA's general principles of software validation.", "excerpt_keywords": "FDA, software validation, requirements specification, defect prevention, software testing"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[18] FDA General Principles of Software Validation -2002.pdf\n## guidance for industry and fda staff\n\n## general principles of software validation\n\n### section 4. principles of software validation\n\nthis section lists the general principles that should be considered for the validation of software.\n\n#### 4.1. requirements\n\na documented software requirements specification provides a baseline for both validation and verification. the software validation process cannot be completed without an established software requirements specification (ref: 21 cfr 820.3(z) and (aa) and 820.30(f) and (g)).\n\n#### 4.2. defect prevention\n\nsoftware quality assurance needs to focus on preventing the introduction of defects into the software development process and not on trying to \"test quality into\" the software code after it is written. software testing is very limited in its ability to surface all latent defects in software code. for example, the complexity of most software prevents it from being exhaustively tested. software testing is a necessary activity. however, in most cases software testing by itself is not sufficient to establish confidence that the software is fit for its intended use. in order to establish that confidence, software developers should use a mixture of methods and techniques to prevent software errors and to detect software errors that do occur. the \"best mix\" of methods depends on many factors including the development environment, application, size of project, language, and risk.\n\n#### 4.3. time and effort\n\nto build a case that the software is validated requires time and effort. preparation for software validation should begin early, i.e., during design and development planning and design input. the final conclusion that the software is validated should be based on evidence collected from planned efforts conducted throughout the software lifecycle.\n\n#### 4.4. software life cycle\n\nsoftware validation takes place within the environment of an established software life cycle. the software life cycle contains software engineering tasks and documentation necessary to support the software validation effort. in addition, the software life cycle contains specific verification and validation tasks that are appropriate for the intended use of the software. this guidance does not recommend any particular life cycle models - only that they should be selected and used for a software development project.\n\npage 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"}, "5accc9dd-0d68-40c9-bd77-ff5165f7708a": {"__data__": {"id_": "5accc9dd-0d68-40c9-bd77-ff5165f7708a", "embedding": null, "metadata": {"page_label": "16", "file_name": "[18] FDA General Principles of Software Validation -2002.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[18] FDA General Principles of Software Validation -2002.pdf", "file_type": "application/pdf", "file_size": 376042, "creation_date": "2024-04-07", "last_modified_date": "2024-03-28", "document_title": "Software Validation Process and Principles: A Comprehensive Guide", "questions_this_excerpt_can_answer": "1. What are the key components that should be included in a software validation plan according to the FDA's general principles of software validation?\n   \n2. How does the FDA recommend handling the validation of software after it undergoes any changes, and what specific steps should be taken to ensure the software remains validated?\n\n3. According to the FDA's guidance, how should the level of validation activities be determined based on the software's complexity and associated safety risks?", "prev_section_summary": "The section discusses the general principles of software validation, emphasizing the importance of having a documented software requirements specification for validation and verification. It also highlights the role of software quality assurance in defect prevention during the software development process, stating that software testing alone is insufficient for establishing confidence in software's fitness for its intended use. The document suggests using a combination of methods and techniques to prevent and detect software errors. Additionally, it mentions that building a case for software validation requires time and effort, starting early in the design and development stages. The section also mentions the importance of software validation within an established software life cycle, containing specific tasks and documentation to support the validation effort.", "excerpt_keywords": "FDA, software validation, validation plan, software changes, validation coverage"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[18] FDA General Principles of Software Validation -2002.pdf\n## guidance for industry and fda staff\n\n## general principles of software validation\n\n|4.5. plans|the software validation process is defined and controlled through the use of a plan. the software validation plan defines \"what\" is to be accomplished through the software validation effort. software validation plans are a significant quality system tool. software validation plans specify areas such as scope, approach, resources, schedules and the types and extent of activities, tasks, and work items.|\n|---|---|\n|4.6. procedures|the software validation process is executed through the use of procedures. these procedures establish \"how\" to conduct the software validation effort. the procedures should identify the specific actions or sequence of actions that must be taken to complete individual validation activities, tasks, and work items.|\n|4.7. software validation after a change|due to the complexity of software, a seemingly small local change may have a significant global system impact. when any change (even a small change) is made to the software, the validation status of the software needs to be re-established. whenever software is changed, a validation analysis 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 software system. based on this analysis, the software developer should then conduct an appropriate level of software regression testing to show that unchanged but vulnerable portions of the system have not been adversely affected. design controls and appropriate regression testing provide the confidence that the software is validated after a software change.|\n|4.8. validation coverage|validation coverage should be based on the softwares complexity and safety risk - not on firm size or resource constraints. the selection of validation activities, tasks, and work items should be commensurate with the complexity of the software design and the risk associated with the use of the software for the specified intended use. for lower risk devices, only baseline validation activities may be conducted. as the risk increases additional validation activities should be added to cover the additional risk. validation documentation should be sufficient to demonstrate that all software validation plans and procedures have been completed successfully.|\n|4.9. independence of review|validation activities should be conducted using the basic quality assurance precept of \"independence of review.\" self-validation is extremely difficult. when possible, an independent evaluation is always better, especially for higher risk applications. some firms contract out for a third-party independent|", "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"}, "475f1a92-1111-43fb-8a0e-d1756ba4dc60": {"__data__": {"id_": "475f1a92-1111-43fb-8a0e-d1756ba4dc60", "embedding": null, "metadata": {"page_label": "17", "file_name": "[18] FDA General Principles of Software Validation -2002.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[18] FDA General Principles of Software Validation -2002.pdf", "file_type": "application/pdf", "file_size": 376042, "creation_date": "2024-04-07", "last_modified_date": "2024-03-28", "document_title": "Comprehensive Title: Software Validation in FDA-Regulated Medical Device Applications: Best Practices and Guidelines", "questions_this_excerpt_can_answer": "1. What strategies are suggested for smaller firms to maintain internal independence of review during the software validation process, according to the FDA's guidance on software validation in medical device applications?\n\n2. How does the FDA's guidance on software validation address the responsibility of device manufacturers in demonstrating software validation, especially when different forms of software components from various sources are involved?\n\n3. In the context of FDA-regulated medical device applications, how does the guidance suggest handling software validation activities that are dispersed across different locations and organizations, and who ultimately holds the responsibility for ensuring the software is validated?", "prev_section_summary": "The section discusses the key components of software validation according to the FDA's general principles. It emphasizes the importance of having a software validation plan that defines the scope, approach, resources, and activities involved in the validation process. Procedures are also highlighted as essential for executing the validation effort. The excerpt stresses the need for re-validating software after any changes, no matter how small, to ensure the software remains validated. It also mentions the importance of validation coverage based on software complexity and safety risks, rather than firm size or resource constraints. The concept of independence of review is emphasized, suggesting that validation activities should ideally be conducted independently for higher risk applications.", "excerpt_keywords": "FDA, software validation, medical device applications, best practices, guidelines"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[18] FDA General Principles of Software Validation -2002.pdf\n## guidance for industry and fda staff\n\n## general principles of software validation\n\nverification and validation are crucial steps in the software development process. while assigning internal staff members not involved in a particular design or implementation is one approach, smaller firms may need to get creative in task organization to maintain internal independence of review.\n\nflexibility and responsibility:\n\nthe specific implementation of software validation principles can vary between applications. the device manufacturer has the flexibility to choose how to apply these principles but ultimately holds the responsibility for demonstrating that the software has been validated.\n\nsoftware is utilized in various environments and for different devices with varying levels of risk. fda-regulated medical device applications involving software include components, standalone medical devices, and applications used in manufacturing, design, development, or quality system processes.\n\nin these environments, software components from different sources are used to create applications (e.g., in-house developed software, off-the-shelf software, contract software). the validation process can be complex due to the different forms of software components involved.\n\nsoftware validation activities may be dispersed across different locations and organizations. regardless of this distribution, the device manufacturer or specification developer holds the ultimate responsibility for ensuring the software is validated.", "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"}, "2fccae12-38f4-4d1a-8455-3112b5d645a1": {"__data__": {"id_": "2fccae12-38f4-4d1a-8455-3112b5d645a1", "embedding": null, "metadata": {"page_label": "18", "file_name": "[18] FDA General Principles of Software Validation -2002.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[18] FDA General Principles of Software Validation -2002.pdf", "file_type": "application/pdf", "file_size": 376042, "creation_date": "2024-04-07", "last_modified_date": "2024-03-28", "document_title": "Software Validation Activities and Tasks in the Software Development Life Cycle: A Comprehensive Guide", "questions_this_excerpt_can_answer": "1. What are the key activities included in a typical software life cycle model as outlined by the FDA's guidance for industry and FDA staff on general principles of software validation?\n\n2. How does the FDA's guidance suggest software developers should approach the selection of a software life cycle model for their product and organization?\n\n3. According to the FDA's guidance on software validation, how should the tasks supporting validation be adapted based on the safety risk associated with the software application?", "prev_section_summary": "The section discusses the general principles of software validation in FDA-regulated medical device applications. Key topics include the importance of verification and validation in the software development process, strategies for maintaining internal independence of review in smaller firms, flexibility and responsibility in implementing software validation principles, handling software validation activities involving software components from various sources, and the ultimate responsibility of the device manufacturer in ensuring software validation. Key entities mentioned include device manufacturers, software components, FDA-regulated medical device applications, and the responsibility for software validation.", "excerpt_keywords": "FDA, software validation, software development life cycle, guidance, tasks"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[18] FDA General Principles of Software Validation -2002.pdf\n## guidance for industry and fda staff\n\n## general principles of software validation\n\n### section 5. activities and tasks\n\nsoftware validation is accomplished through a series of activities and tasks that are planned and executed at various stages of the software development life cycle. these tasks may be one-time occurrences or may be iterated many times, depending on the life cycle model used and the scope of changes made as the software project progresses.\n\n#### 5.1. software life cycle activities\n\nthis guidance does not recommend the use of any specific software life cycle model. software developers should establish a software life cycle model that is appropriate for their product and organization. the software life cycle model that is selected should cover the software from its birth to its retirement. activities in a typical software life cycle model include the following:\n\n- quality planning\n- system requirements definition\n- detailed software requirements specification\n- software design specification\n- construction or coding\n- testing\n- installation\n- operation and support\n- maintenance\n- retirement\n\nverification, testing, and other tasks that support software validation occur during each of these activities. a life cycle model organizes these software development activities in various ways and provides a framework for monitoring and controlling the software development project. several software life cycle models (e.g., waterfall, spiral, rapid prototyping, incremental development, etc.) are defined in fdas glossary of computerized system and software development terminology, dated august 1995. these and many other life cycle models are described in various references listed in appendix a.\n\n#### 5.2. typical tasks supporting validation\n\nfor each of the software life cycle activities, there are certain \"typical\" tasks that support a conclusion that the software is validated. however, the specific tasks to be performed, their order of performance, and the iteration and timing of their performance will be dictated by the specific software life cycle model that is selected and the safety risk associated with the software application. for very low-risk applications, certain tasks may not be needed at all. however, the software developer should at least consider each of these tasks and should define and document which tasks are or are not appropriate for\n\npage 14", "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"}, "54f735e8-6fa1-4cdf-86e7-e87542a952cc": {"__data__": {"id_": "54f735e8-6fa1-4cdf-86e7-e87542a952cc", "embedding": null, "metadata": {"page_label": "19", "file_name": "[18] FDA General Principles of Software Validation -2002.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[18] FDA General Principles of Software Validation -2002.pdf", "file_type": "application/pdf", "file_size": 376042, "creation_date": "2024-04-07", "last_modified_date": "2024-03-28", "document_title": "Comprehensive Guide to Quality Planning and Management in Software Development", "questions_this_excerpt_can_answer": "1. What specific elements should a comprehensive quality planning process for software development in the pharmaceutical industry include, according to FDA guidelines?\n   \n2. How does the FDA recommend handling software anomalies found through validation or other activities in the context of pharmaceutical software development?\n\n3. What are the FDA's requirements for documentation and control in the configuration management plan for software development within the pharmaceutical industry?", "prev_section_summary": "This section discusses the activities and tasks involved in software validation as outlined by the FDA's guidance. It emphasizes the importance of selecting an appropriate software life cycle model for the product and organization, covering activities from quality planning to retirement. The section also highlights the typical tasks supporting validation for each software life cycle activity, emphasizing the need to adapt these tasks based on the safety risk associated with the software application. Various software life cycle models are mentioned, and the importance of verification, testing, and other tasks in supporting software validation is emphasized throughout the software development life cycle.", "excerpt_keywords": "FDA, software validation, quality planning, pharmaceutical industry, configuration management plan"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[18] FDA General Principles of Software Validation -2002.pdf\n## guidance for industry and fda staff\n\n## general principles of software validation\n\ntheir specific application. the following discussion is generic and is not intended to prescribe any particular software life cycle model or any particular order in which tasks are to be performed.\n\n### 5.2.1. quality planning\n\ndesign and development planning should culminate in a plan that identifies necessary tasks, procedures for anomaly reporting and resolution, necessary resources, and management review requirements, including formal design reviews. a software life cycle model and associated activities should be identified, as well as those tasks necessary for each software life cycle activity. the plan should include:\n\n- the specific tasks for each life cycle activity;\n- enumeration of important quality factors (e.g., reliability, maintainability, and usability);\n- methods and procedures for each task;\n- task acceptance criteria;\n- criteria for defining and documenting outputs in terms that will allow evaluation of their conformance to input requirements;\n- inputs for each task;\n- outputs from each task;\n- roles, resources, and responsibilities for each task;\n- risks and assumptions; and\n- documentation of user needs.\n\nmanagement must identify and provide the appropriate software development environment and resources. (see 21 cfr SS820.20(b)(1) and (2).) typically, each task requires personnel as well as physical resources. the plan should identify the personnel, the facility and equipment resources for each task, and the role that risk (hazard) management will play. a configuration management plan should be developed that will guide and control multiple parallel development activities and ensure proper communications and documentation. controls are necessary to ensure positive and correct correspondence among all approved versions of the specifications documents, source code, object code, and test suites that comprise a software system. the controls also should ensure accurate identification of, and access to, the currently approved versions.\n\nprocedures should be created for reporting and resolving software anomalies found through validation or other activities. management should identify the reports and specify the contents, format, and responsible organizational elements for each report. procedures also are necessary for the review and approval of software development results, including the responsible organizational elements for such reviews and approvals.\n\n### typical tasks - quality planning\n\nrisk (hazard) management plan\nconfiguration management plan\n\npage 15", "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"}, "ad6451d4-e564-4b4b-941a-581dec2d09d8": {"__data__": {"id_": "ad6451d4-e564-4b4b-941a-581dec2d09d8", "embedding": null, "metadata": {"page_label": "20", "file_name": "[18] FDA General Principles of Software Validation -2002.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[18] FDA General Principles of Software Validation -2002.pdf", "file_type": "application/pdf", "file_size": 376042, "creation_date": "2024-04-07", "last_modified_date": "2024-03-28", "document_title": "Comprehensive Guide to Software Validation and Requirements Development in Medical Device Software", "questions_this_excerpt_can_answer": "1. What are the key components that should be included in a software requirements specification document for medical device software, according to the FDA's 2002 guidelines?\n   \n2. How does the FDA's 2002 guidance for industry and staff suggest integrating technical risk management with the development of system requirements for medical device software?\n\n3. What specific strategies does the FDA's 2002 document recommend for mitigating the risks associated with software failures in medical devices?", "prev_section_summary": "The section discusses the general principles of software validation in the context of the pharmaceutical industry according to FDA guidelines. Key topics include quality planning, design and development planning, necessary tasks, procedures for anomaly reporting and resolution, necessary resources, management review requirements, software life cycle models, quality factors, methods and procedures for tasks, task acceptance criteria, inputs and outputs for tasks, roles and responsibilities, risks and assumptions, documentation of user needs, software development environment and resources, configuration management plan, controls for version management, procedures for reporting and resolving software anomalies, and review and approval of software development results. Key entities mentioned include management, personnel, facility and equipment resources, risk management, organizational elements, reports, and responsible elements for reviews and approvals.", "excerpt_keywords": "FDA, software validation, medical device software, requirements development, technical risk management"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[18] FDA General Principles of Software Validation -2002.pdf\n## guidance for industry and fda staff\n\n## general principles of software validation\n\n### software quality assurance plan\n\n|software verification and validation plan|verification and validation tasks, and acceptance criteria|\n|---|---|\n| |schedule and resource allocation (for software verification and validation activities)|\n| |reporting requirements|\n|formal design review requirements| |\n|other technical review requirements| |\n\n### problem reporting and resolution procedures\n\n### other support activities\n\n## 5.2.2. requirements\n\nrequirements development includes the identification, analysis, and documentation of information about the device and its intended use. areas of special importance include allocation of system functions to hardware/software, operating conditions, user characteristics, potential hazards, and anticipated tasks. in addition, the requirements should state clearly the intended use of the software.\n\nthe software requirements specification document should contain a written definition of the software functions. it is not possible to validate software without predetermined and documented software requirements. typical software requirements specify the following:\n\n- all software system inputs;\n- all software system outputs;\n- all functions that the software system will perform;\n- all performance requirements that the software will meet, (e.g., data throughput, reliability, and timing);\n- the definition of all external and user interfaces, as well as any internal software-to-system interfaces;\n- how users will interact with the system;\n- what constitutes an error and how errors should be handled;\n- required response times;\n- the intended operating environment for the software, if this is a design constraint (e.g., hardware platform, operating system);\n- all ranges, limits, defaults, and specific values that the software will accept; and\n- all safety related requirements, specifications, features, or functions that will be implemented in software.\n\nsoftware safety requirements are derived from a technical risk management process that is closely integrated with the system requirements development process. software requirement specifications should identify clearly the potential hazards that can result from a software failure in the system as well as any safety requirements to be implemented in software. the consequences of software failure should be evaluated, along with means of mitigating such failures (e.g., hardware mitigation, defensive programming, etc.). from this analysis, it should be possible to identify the most appropriate measures necessary to prevent harm.\n\npage 16", "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"}, "52a99632-f8e3-4741-805a-7280e4d1be1c": {"__data__": {"id_": "52a99632-f8e3-4741-805a-7280e4d1be1c", "embedding": null, "metadata": {"page_label": "21", "file_name": "[18] FDA General Principles of Software Validation -2002.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[18] FDA General Principles of Software Validation -2002.pdf", "file_type": "application/pdf", "file_size": 376042, "creation_date": "2024-04-07", "last_modified_date": "2024-03-28", "document_title": "Software Validation and Quality System Regulation Compliance Guidelines", "questions_this_excerpt_can_answer": "1. What specific criteria does the FDA's guidance for industry and staff outline for evaluating software requirements in the context of quality system regulation compliance, particularly regarding safety, fault tolerance, and security?\n   \n2. How does the FDA recommend conducting a software requirements traceability analysis in relation to system requirements and risk analysis results, as outlined in the 2002 General Principles of Software Validation document?\n\n3. What are the typical tasks involved in the requirements phase of software validation according to the FDA's 2002 guidelines, and how do these tasks contribute to ensuring software design meets regulatory standards for safety and effectiveness?", "prev_section_summary": "The section discusses the general principles of software validation for medical device software according to the FDA's 2002 guidelines. Key topics include software quality assurance plan, requirements development, problem reporting and resolution procedures, and other support activities. The section emphasizes the importance of documenting software requirements, specifying software functions, performance requirements, interfaces, error handling, response times, operating environment, safety requirements, and risk management. It also highlights the integration of technical risk management with system requirements development and strategies for mitigating risks associated with software failures in medical devices.", "excerpt_keywords": "FDA, software validation, quality system regulation, requirements traceability analysis, risk analysis"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[18] FDA General Principles of Software Validation -2002.pdf\n## guidance for industry and fda staff\n\n## general principles of software validation\n\nthe quality system regulation requires a mechanism for addressing incomplete, ambiguous, or conflicting requirements. (see 21 cfr 820.30(c).) each requirement (e.g., hardware, software, user, operator interface, and safety) identified in the software requirements specification should be evaluated for accuracy, completeness, consistency, testability, correctness, and clarity. for example, software requirements should be evaluated to verify that:\n\n- there are no internal inconsistencies among requirements;\n- all of the performance requirements for the system have been spelled out;\n- fault tolerance, safety, and security requirements are complete and correct;\n- allocation of software functions is accurate and complete;\n- software requirements are appropriate for the system hazards; and\n- all requirements are expressed in terms that are measurable or objectively verifiable.\n\na software requirements traceability analysis should be conducted to trace software requirements to (and from) system requirements and to risk analysis results. in addition to any other analyses and documentation used to verify software requirements, a formal design review is recommended to confirm that requirements are fully specified and appropriate before extensive software design efforts begin. requirements can be approved and released incrementally, but care should be taken that interactions and interfaces among software (and hardware) requirements are properly reviewed, analyzed, and controlled.\n\n### typical tasks - requirements\n\n- preliminary risk analysis\n- traceability analysis\n- software requirements to system requirements (and vice versa)\n- software requirements to risk analysis\n- description of user characteristics\n- listing of characteristics and limitations of primary and secondary memory\n- software requirements evaluation\n- software user interface requirements analysis\n- system test plan generation\n- acceptance test plan generation\n- ambiguity review or analysis\n\n### design\n\nin the design process, the software requirements specification is translated into a logical and physical representation of the software to be implemented. the software design specification is a description of what the software should do and how it should do it. due to complexity of the project or to enable", "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"}, "6c0aceb1-ffc0-4617-9b9e-e9b14525a7bb": {"__data__": {"id_": "6c0aceb1-ffc0-4617-9b9e-e9b14525a7bb", "embedding": null, "metadata": {"page_label": "22", "file_name": "[18] FDA General Principles of Software Validation -2002.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[18] FDA General Principles of Software Validation -2002.pdf", "file_type": "application/pdf", "file_size": 376042, "creation_date": "2024-04-07", "last_modified_date": "2024-03-28", "document_title": "Software Design Specification and Validation Principles Document", "questions_this_excerpt_can_answer": "1. What specific elements should be included in a comprehensive software design specification according to the FDA's general principles of software validation from 2002?\n   \n2. How does the FDA's 2002 guidance document suggest integrating human factors engineering into the software design and development process to mitigate use errors?\n\n3. What are the first four elements typically included by reference in the software design specification, as outlined in the FDA's 2002 general principles of software validation, and how do they contribute to the overall validation process?", "prev_section_summary": "The section discusses the FDA's guidance for industry and staff on software validation and quality system regulation compliance. Key topics include evaluating software requirements for accuracy, completeness, and consistency, conducting software requirements traceability analysis, and typical tasks in the requirements phase such as risk analysis, user characteristics description, and system test plan generation. The section emphasizes the importance of ensuring software design meets regulatory standards for safety and effectiveness through thorough evaluation and review processes.", "excerpt_keywords": "FDA, software validation, design specification, human factors engineering, risk analysis"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[18] FDA General Principles of Software Validation -2002.pdf\n## guidance for industry and fda staff\n\n## general principles of software validation\n\npersons with varying levels of technical responsibilities need to clearly understand design information. the design specification may contain both a high-level summary of the design and detailed design information. the completed software design specification constrains the programmer/coder to stay within the intent of the agreed-upon requirements and design. a complete software design specification will relieve the programmer from the need to make ad hoc design decisions.\n\nthe software design needs to address human factors. use error caused by designs that are either overly complex or contrary to users intuitive expectations for operation is one of the most persistent and critical problems encountered by fda. frequently, the design of the software is a factor in such use errors. human factors engineering should be woven into the entire design and development process, including the device design requirements, analyses, and tests. device safety and usability issues should be considered when developing flowcharts, state diagrams, prototyping tools, and test plans. also, task and function analyses, risk analyses, prototype tests and reviews, and full usability tests should be performed. participants from the user population should be included when applying these methodologies.\n\nthe software design specification should include:\n\n- software requirements specification, including predetermined criteria for acceptance of the software;\n- software risk analysis;\n- development procedures and coding guidelines (or other programming procedures);\n- systems documentation (e.g., a narrative or a context diagram) that describes the systems context in which the program is intended to function, including the relationship of hardware, software, and the physical environment;\n- hardware to be used;\n- parameters to be measured or recorded;\n- logical structure (including control logic) and logical processing steps (e.g., algorithms);\n- data structures and data flow diagrams;\n- definitions of variables (control and data) and description of where they are used;\n- error, alarm, and warning messages;\n- supporting software (e.g., operating systems, drivers, other application software);\n- communication links (links among internal modules of the software, links with the supporting software, links with the hardware, and links with the user);\n- security measures (both physical and logical security); and\n- any additional constraints not identified in the above elements.\n\nthe first four of the elements noted above usually are separate pre-existing documents that are included by reference in the software design specification. software requirements specification was discussed in the preceding section, as was software risk analysis. written development procedures serve as a guide to the organization, and written programming procedures serve as a guide to individual programmers. as software cannot be validated without knowledge of the context in which it is intended to function, systems documentation is referenced. if some of the above elements are not included in the 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"}, "bd54bc85-f2df-422f-a7f2-a89dd681ae9a": {"__data__": {"id_": "bd54bc85-f2df-422f-a7f2-a89dd681ae9a", "embedding": null, "metadata": {"page_label": "23", "file_name": "[18] FDA General Principles of Software Validation -2002.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[18] FDA General Principles of Software Validation -2002.pdf", "file_type": "application/pdf", "file_size": 376042, "creation_date": "2024-04-07", "last_modified_date": "2024-03-28", "document_title": "Best Practices for Software Design and Validation", "questions_this_excerpt_can_answer": "1. What specific evaluations and analyses are recommended during the software design phase to ensure the design is complete, correct, consistent, unambiguous, feasible, and maintainable according to the FDA's general principles of software validation from 2002?\n\n2. How does the FDA's 2002 guidance on software validation suggest handling the iterative nature of software development to ensure that all versions of software requirement specifications and software design specifications are properly archived and controlled?\n\n3. What are the typical tasks outlined in the FDA's 2002 document for ensuring software design is testable and aligns with software requirements, including the steps for updating risk analysis and generating various test plans?", "prev_section_summary": "The section discusses the importance of software design specification in software validation according to the FDA's general principles. It emphasizes the need for clear design information, integration of human factors engineering, and inclusion of specific elements in the software design specification. Key topics include software requirements specification, software risk analysis, development procedures, systems documentation, hardware, data structures, error messages, communication links, security measures, and additional constraints. The section also highlights the first four elements typically included in the software design specification and their importance in the validation process.", "excerpt_keywords": "FDA, software validation, software design, risk analysis, traceability"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[18] FDA General Principles of Software Validation -2002.pdf\nguidance for industry and fda staff general principles of software validation may be helpful to future reviewers and maintainers of the software if that is clearly stated (e.g., there are no error messages in this program). the activities that occur during software design have several purposes. software design evaluations are conducted to determine if the design is complete, correct, consistent, unambiguous, feasible, and maintainable. appropriate consideration of software architecture (e.g., modular structure) during design can reduce the magnitude of future validation efforts when software changes are needed. software design evaluations may include analyses of control flow, data flow, complexity, timing, sizing, memory allocation, criticality analysis, and many other aspects of the design. a traceability analysis should be conducted to verify that the software design implements all of the software requirements. as a technique for identifying where requirements are not sufficient, the traceability analysis should also verify that all aspects of the design are traceable to software requirements. an analysis of communication links should be conducted to evaluate the proposed design with respect to hardware, user, and related software requirements. the software risk analysis should be re-examined to determine whether any additional hazards have been identified and whether any new hazards have been introduced by the design.\n\nat the end of the software design activity, a formal design review should be conducted to verify that the design is correct, consistent, complete, accurate, and testable, before moving to implement the design. portions of the design can be approved and released incrementally for implementation; but care should be taken that interactions and communication links among various elements are properly reviewed, analyzed, and controlled. most software development models will be iterative. this is likely to result in several versions of both the software requirement specification and the software design specification. all approved versions should be archived and controlled in accordance with established configuration management procedures.\n\ntypical tasks - design\n\n- updated software risk analysis\n- traceability analysis - design specification to software requirements (and vice versa)\n- software design evaluation\n- design communication link analysis\n- module test plan generation\n- integration test plan generation\n- test design generation (module, integration, system, and acceptance)\n\npage 19", "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"}, "57b56fac-a13f-4b81-b281-84f5b9cb1b6c": {"__data__": {"id_": "57b56fac-a13f-4b81-b281-84f5b9cb1b6c", "embedding": null, "metadata": {"page_label": "24", "file_name": "[18] FDA General Principles of Software Validation -2002.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[18] FDA General Principles of Software Validation -2002.pdf", "file_type": "application/pdf", "file_size": 376042, "creation_date": "2024-04-07", "last_modified_date": "2024-03-28", "document_title": "Software Construction and Coding Guidelines and Procedures", "questions_this_excerpt_can_answer": "1. What are the two primary methods mentioned for constructing software, and how does the document define coding in the context of software development?\n   \n2. How does the document suggest handling the selection of programming languages and software build tools in relation to their impact on quality evaluation tasks during the coding process?\n\n3. What specific practices does the document recommend for documenting the final compilation process of software code, including handling compiler warnings and error messages?", "prev_section_summary": "The section discusses the importance of software design evaluations in ensuring completeness, correctness, consistency, feasibility, and maintainability of software. It emphasizes the need for traceability analysis, communication link analysis, and re-examination of software risk analysis during the design phase. The section also highlights the iterative nature of software development and the importance of properly archiving and controlling all versions of software requirement specifications and design specifications. Typical tasks outlined include updating software risk analysis, traceability analysis, design evaluation, communication link analysis, and generating module, integration, and system test plans.", "excerpt_keywords": "Software validation, Coding guidelines, Programming languages, Quality evaluation, Source code evaluation"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[18] FDA General Principles of Software Validation -2002.pdf\n## guidance for industry and fda staff\n\n## general principles of software validation\n\n5.2.4. construction or coding\n\nsoftware may be constructed either by coding (i.e., programming) or by assembling together previously coded software components (e.g., from code libraries, off-the-shelf software, etc.) for use in a new application. coding is the software activity where the detailed design specification is implemented as source code. coding is the lowest level of abstraction for the software development process. it is the last stage in decomposition of the software requirements where module specifications are translated into a programming language.\n\ncoding usually involves the use of a high-level programming language, but may also entail the use of assembly language (or microcode) for time-critical operations. the source code may be either compiled or interpreted for use on a target hardware platform. decisions on the selection of programming languages and software build tools (assemblers, linkers, and compilers) should include consideration of the impact on subsequent quality evaluation tasks (e.g., availability of debugging and testing tools for the chosen language). some compilers offer optional levels and commands for error checking to assist in debugging the code. different levels of error checking may be used throughout the coding process, and warnings or other messages from the compiler may or may not be recorded. however, at the end of the coding and debugging process, the most rigorous level of error checking is normally used to document what compilation errors still remain in the software. if the most rigorous level of error checking is not used for final translation of the source code, then justification for use of the less rigorous translation error checking should be documented. also, for the final compilation, there should be documentation of the compilation process and its outcome, including any warnings or other messages from the compiler and their resolution, or justification for the decision to leave issues unresolved.\n\nfirms frequently adopt specific coding guidelines that establish quality policies and procedures related to the software coding process. source code should be evaluated to verify its compliance with specified coding guidelines. such guidelines should include coding conventions regarding clarity, style, complexity management, and commenting. code comments should provide useful and descriptive information for a module, including expected inputs and outputs, variables referenced, expected data types, and operations to be performed. source code should also be evaluated to verify its compliance with the corresponding detailed design specification. modules ready for integration and test should have documentation of compliance with coding guidelines and any other applicable quality policies and procedures.\n\nsource code evaluations are often implemented as code inspections and code walkthroughs. such static analyses provide a very effective means to detect errors before execution of the code. they allow for examination of each error in isolation and can also help in focusing later dynamic testing of the software. firms may use manual (desk) checking with appropriate controls to ensure consistency and independence. source code evaluations should be extended to verification of internal linkages between modules and layers (horizontal and vertical interfaces), and compliance with their design specifications. documentation of the procedures used and the results of source code evaluations should be maintained as part of design verification.\n\npage 20", "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"}, "16695ee2-d6d1-48d0-8221-168082beaa5b": {"__data__": {"id_": "16695ee2-d6d1-48d0-8221-168082beaa5b", "embedding": null, "metadata": {"page_label": "25", "file_name": "[18] FDA General Principles of Software Validation -2002.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[18] FDA General Principles of Software Validation -2002.pdf", "file_type": "application/pdf", "file_size": 376042, "creation_date": "2024-04-07", "last_modified_date": "2024-03-28", "document_title": "Software Validation and Testing Best Practices", "questions_this_excerpt_can_answer": "1. How does the FDA recommend ensuring that every element of the software design specification is accurately implemented in code during the software validation process?\n   \n2. What specific methodologies and resources does the FDA suggest should be included in the early planning stages of software testing to ensure it is effective and efficient?\n\n3. Can you detail the types of literature the FDA references for best practices in software testing, particularly regarding methodologies that utilize specific metrics like cyclomatic complexity or guidelines for high integrity systems validation?", "prev_section_summary": "The section discusses software construction and coding guidelines and procedures in the context of software validation. It covers the methods of constructing software through coding or assembling previously coded components, the selection of programming languages and software build tools, documentation of the compilation process, coding guidelines, code evaluations, and verification of compliance with design specifications. The section emphasizes the importance of clarity, style, complexity management, commenting, and compliance with quality policies and procedures in the coding process. It also mentions the use of code inspections and walkthroughs for error detection before execution of the code.", "excerpt_keywords": "FDA, software validation, testing, best practices, guidelines"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[18] FDA General Principles of Software Validation -2002.pdf\n## guidance for industry and fda staff\n\n## general principles of software validation\n\na source code traceability analysis is an important tool to verify that all code is linked to established specifications and established test procedures. a source code traceability analysis should be conducted and documented to verify that:\n\n- each element of the software design specification has been implemented in code;\n- modules and functions implemented in code can be traced back to an element in the software design specification and to the risk analysis;\n- tests for modules and functions can be traced back to an element in the software design specification and to the risk analysis; and\n- tests for modules and functions can be traced to source code for the same modules and functions.\n\n### typical tasks - construction or coding\n\n- traceability analyses\n- - source code to design specification (and vice versa)\n- test cases to source code and to design specification\n\nsource code and source code documentation evaluation\n- source code interface analysis\n- test procedure and test case generation (module, integration, system, and acceptance)\n\n### 5.2.5. testing by the software developer\n\nsoftware testing entails running software products under known conditions with defined inputs and documented outcomes that can be compared to their predefined expectations. it is a time-consuming, difficult, and imperfect activity. as such, it requires early planning in order to be effective and efficient. test plans and test cases should be created as early in the software development process as feasible. they should identify the schedules, environments, resources (personnel, tools, etc.), methodologies, cases (inputs, procedures, outputs, expected results), documentation, and reporting criteria. the magnitude of effort to be applied throughout the testing process can be linked to complexity, criticality, reliability, and/or safety issues (e.g., requiring functions or modules that produce critical outcomes to be challenged with intensive testing of their fault tolerance features). descriptions of categories of software and software testing effort appear in the literature, for example:\n\n- nist special publication 500-235, structured testing: a testing methodology using the cyclomatic complexity metric;\n- nureg/cr-6293, verification and validation guidelines for high integrity systems; and\n- ieee computer society press, handbook of software reliability engineering.\n\npage 21", "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"}, "a65ce79a-296d-43ac-b572-3d518299d5e5": {"__data__": {"id_": "a65ce79a-296d-43ac-b572-3d518299d5e5", "embedding": null, "metadata": {"page_label": "26", "file_name": "[18] FDA General Principles of Software Validation -2002.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[18] FDA General Principles of Software Validation -2002.pdf", "file_type": "application/pdf", "file_size": 376042, "creation_date": "2024-04-07", "last_modified_date": "2024-03-28", "document_title": "Principles and Practices of Software Testing and Validation: A Comprehensive Guide", "questions_this_excerpt_can_answer": "1. What are the key principles that should guide the software testing process according to the FDA's General Principles of Software Validation document from 2002?\n   \n2. How does the document describe the limitations of software testing, and what implications does this have for the exhaustive testing of software products?\n\n3. What specific types of testing does the document recommend for ensuring a software product's compliance with its functional, performance, and interface definitions and requirements?", "prev_section_summary": "The section discusses the importance of source code traceability analysis in software validation to ensure that all elements of the software design specification are accurately implemented in code. It also highlights the typical tasks involved in software construction or coding, such as traceability analyses and test case generation. The section emphasizes the need for early planning in software testing to be effective and efficient, outlining the key components of test plans and test cases. Additionally, it references literature that provides guidance on software testing methodologies, including the use of metrics like cyclomatic complexity and guidelines for high integrity systems validation.", "excerpt_keywords": "FDA, software validation, software testing, test plans, structural testing"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[18] FDA General Principles of Software Validation -2002.pdf\n## guidance for industry and fda staff\n\ngeneral principles of software validation\n\nsoftware test plans should identify the particular tasks to be conducted at each stage of development and include justification of the level of effort represented by their corresponding completion criteria. software testing has limitations that must be recognized and considered when planning the testing of a particular software product. except for the simplest of programs, software cannot be exhaustively tested. generally it is not feasible to test a software product with all possible inputs, nor is it possible to test all possible data processing paths that can occur during program execution. there is no one type of testing or testing methodology that can ensure a particular software product has been thoroughly tested. testing of all program functionality does not mean all of the program has been tested. testing of all of a programs code does not mean all necessary functionality is present in the program. testing of all program functionality and all program code does not mean the program is 100% correct! software testing that finds no errors should not be interpreted to mean that errors do not exist in the software product; it may mean the testing was superficial.\n\nan essential element of a software test case is the expected result. it is the key detail that permits objective evaluation of the actual test result. this necessary testing information is obtained from the corresponding, predefined definition or specification. a software specification document must identify what, when, how, why, etc., is to be achieved with an engineering (i.e., measurable or objectively verifiable) level of detail in order for it to be confirmed through testing. the real effort of effective software testing lies in the definition of what is to be tested rather than in the performance of the test.\n\na software testing process should be based on principles that foster effective examinations of a software product. applicable software testing tenets include:\n\n- the expected test outcome is predefined;\n- a good test case has a high probability of exposing an error;\n- a successful test is one that finds an error;\n- there is independence from coding;\n- both application (user) and software (programming) expertise are employed;\n- testers use different tools from coders;\n- examining only the usual case is insufficient;\n- test documentation permits its reuse and an independent confirmation of the pass/fail status of a test outcome during subsequent review.\n\nonce the prerequisite tasks (e.g., code inspection) have been successfully completed, software testing begins. it starts with unit level testing and concludes with system level testing. there may be a distinct integration level of testing. a software product should be challenged with test cases based on its internal structure and with test cases based on its external specification. these tests should provide a thorough and rigorous examination of the software products compliance with its functional, performance, and interface definitions and requirements.\n\ncode-based testing is also known as structural testing or \"white-box\" testing. it identifies test cases based on knowledge obtained from the source code, detailed design specification, and other development documents. these test cases challenge the control decisions made by the program; and the programs data structures including configuration tables. structural testing can identify \"dead\" code\n\npage 22", "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"}, "a34a1998-f2da-440e-9ffc-e3c29ad1f836": {"__data__": {"id_": "a34a1998-f2da-440e-9ffc-e3c29ad1f836", "embedding": null, "metadata": {"page_label": "27", "file_name": "[18] FDA General Principles of Software Validation -2002.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[18] FDA General Principles of Software Validation -2002.pdf", "file_type": "application/pdf", "file_size": 376042, "creation_date": "2024-04-07", "last_modified_date": "2024-03-28", "document_title": "Comparing Structural and Functional Testing Approaches and Coverage Metrics in Software Testing", "questions_this_excerpt_can_answer": "1. How does structural testing differ from functional testing in the context of software validation as outlined by the FDA's general principles?\n   \n2. What are the specific coverage criteria used to evaluate the level of structural testing in software validation, according to the FDA's guidance for industry and staff?\n\n3. Can you detail the various types of structural coverage metrics and their descriptions as defined in the FDA's general principles of software validation document from 2002?", "prev_section_summary": "The section discusses the general principles of software validation according to the FDA's guidelines. It highlights the limitations of software testing, emphasizing that exhaustive testing is not feasible. The document recommends specific types of testing to ensure compliance with functional, performance, and interface requirements. Key topics include the importance of defining expected results in test cases, principles for effective software testing, and the different levels of testing from unit to system level. It also mentions code-based testing or structural testing to identify errors in the program's control decisions and data structures.", "excerpt_keywords": "FDA, software validation, structural testing, functional testing, coverage metrics"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[18] FDA General Principles of Software Validation -2002.pdf\n## guidance for industry and fda staff\n\n## general principles of software validation\n\nstructural testing is a type of software testing that focuses on the internal structure of the software. it involves testing the code itself to ensure that it functions as intended. structural testing is different from functional testing, which tests the software based on its specifications and requirements.\n\nstructural testing is typically done at the unit (module) level, but it can also be extended to other levels of software testing. the level of structural testing can be evaluated using metrics known as \"coverage,\" which measure the completeness of the testing process.\n\ncommon structural coverage metrics include:\n\n|coverage criteria|description|\n|---|---|\n|statement coverage|requires test cases for each program statement to be executed at least once.|\n|decision (branch) coverage|requires test cases for each program decision or branch to be executed so that each possible outcome occurs at least once.|\n|condition coverage|requires test cases for each condition in a program decision to take on all possible outcomes at least once.|\n|multi-condition coverage|requires test cases to exercise all possible combinations of conditions in a program decision.|\n|loop coverage|requires test cases for all program loops to be executed for zero, one, two, and many iterations covering initialization, typical running, and termination conditions.|\n|path coverage|requires test cases for each feasible path from start to exit of a program segment to be executed at least once.|\n|data flow coverage|requires test cases for each feasible data flow to be executed at least once.|\n\ndefinition-based or specification-based testing, also known as functional testing or \"black-box\" testing, focuses on testing the software based on its intended functionality. it challenges the programs internal and external interfaces and can be applied at all levels of software testing.", "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"}, "817d98b8-a745-470e-993b-2383573bddc4": {"__data__": {"id_": "817d98b8-a745-470e-993b-2383573bddc4", "embedding": null, "metadata": {"page_label": "28", "file_name": "[18] FDA General Principles of Software Validation -2002.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[18] FDA General Principles of Software Validation -2002.pdf", "file_type": "application/pdf", "file_size": 376042, "creation_date": "2024-04-07", "last_modified_date": "2024-03-28", "document_title": "Principles and Methods of Software Testing and Validation: A Comprehensive Guide", "questions_this_excerpt_can_answer": "1. What are the specific functional software testing methods mentioned in the document for ensuring a software product can handle unexpected or invalid inputs, and how do they contribute to the robustness of the software?\n   \n2. How does the document describe the use of statistical testing in software validation, and what are its prerequisites according to the 2002 FDA General Principles of Software Validation guide?\n\n3. What process does the document recommend for testing software changes post-baselining to ensure that new modifications do not adversely affect the existing functionalities of the software product?", "prev_section_summary": "The section discusses the differences between structural testing and functional testing in software validation according to the FDA's general principles. Structural testing focuses on the internal structure of the software and involves testing the code itself, while functional testing tests the software based on its specifications and requirements. The level of structural testing can be evaluated using coverage metrics such as statement coverage, decision coverage, condition coverage, multi-condition coverage, loop coverage, path coverage, and data flow coverage. Functional testing, also known as specification-based testing or black-box testing, focuses on testing the software based on its intended functionality and challenges the program's internal and external interfaces.", "excerpt_keywords": "Software validation, Functional testing, Structural testing, Statistical testing, Regression analysis"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[18] FDA General Principles of Software Validation -2002.pdf\n## guidance for industry and fda staff\n\n## general principles of software validation\n\nthe following types of functional software testing involve generally increasing levels of effort:\n\n|normal case|testing with usual inputs is necessary. however, testing a software product only with expected, valid inputs does not thoroughly test that software product. by itself, normal case testing cannot provide sufficient confidence in the dependability of the software product.|\n|---|---|\n|output forcing|choosing test inputs to ensure that selected (or all) software outputs are generated by testing.|\n|robustness|software testing should demonstrate that a software product behaves correctly when given unexpected, invalid inputs. methods for identifying a sufficient set of such test cases include equivalence class partitioning, boundary value analysis, and special case identification (error guessing). while important and necessary, these techniques do not ensure that all of the most appropriate challenges to a software product have been identified for testing.|\n|combinations of inputs|the functional testing methods identified above all emphasize individual or single test inputs. most software products operate with multiple inputs under their conditions of use. thorough software product testing should consider the combinations of inputs a software unit or system may encounter during operation. error guessing can be extended to identify combinations of inputs, but it is an ad hoc technique. cause-effect graphing is one functional software testing technique that systematically identifies combinations of inputs to a software product for inclusion in test cases.|\n\nfunctional and structural software test case identification techniques provide specific inputs for testing, rather than random test inputs. one weakness of these techniques is the difficulty in linking structural and functional test completion criteria to a software products reliability. advanced software testing methods, such as statistical testing, can be employed to provide further assurance that a software product is dependable. statistical testing uses randomly generated test data from defined distributions based on an operational profile (e.g., expected use, hazardous use, or malicious use of the software product). large amounts of test data are generated and can be targeted to cover particular areas or concerns, providing an increased possibility of identifying individual and multiple rare operating conditions that were not anticipated by either the software products designers or its testers. statistical testing also provides high structural coverage. it does require a stable software product. thus, structural and functional testing are prerequisites for statistical testing of a software product.\n\nanother aspect of software testing is the testing of software changes. changes occur frequently during software development. these changes are the result of 1) debugging that finds an error and it is corrected, 2) new or changed requirements (\"requirements creep\"), and 3) modified designs as more effective or efficient implementations are found. once a software product has been baselined (approved), any change to that product should have its own \"mini life cycle,\" including testing. testing of a changed software product requires additional effort. not only should it demonstrate that the change was implemented correctly, testing should also demonstrate that the change did not adversely impact other parts of the software product. regression analysis and testing are employed to provide", "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"}, "a57cbb84-dc50-4eea-9929-c2e6202db197": {"__data__": {"id_": "a57cbb84-dc50-4eea-9929-c2e6202db197", "embedding": null, "metadata": {"page_label": "29", "file_name": "[18] FDA General Principles of Software Validation -2002.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[18] FDA General Principles of Software Validation -2002.pdf", "file_type": "application/pdf", "file_size": 376042, "creation_date": "2024-04-07", "last_modified_date": "2024-03-28", "document_title": "Software Validation Levels and Regression Testing: A Comprehensive Guide", "questions_this_excerpt_can_answer": "1. What specific methodologies does the FDA recommend for assessing the impact of changes in software through documentation review in the context of software validation?\n   \n2. How does the FDA document categorize and describe the different levels of development testing for software products in the pharmaceutical industry, and what are the primary focuses of each testing level?\n\n3. What are the specific elements and performance issues that system level testing should address according to the FDA's guidelines on software validation, especially in relation to ensuring the software product's reliability and compatibility within the intended use environment?", "prev_section_summary": "The section discusses the general principles of software validation, focusing on functional software testing methods to ensure software reliability. Key topics include normal case testing, output forcing, robustness testing with unexpected inputs, combinations of inputs testing, and the use of statistical testing for software validation. The document emphasizes the importance of thorough testing post-baselining to ensure software changes do not adversely affect existing functionalities. Key entities mentioned include equivalence class partitioning, boundary value analysis, error guessing, cause-effect graphing, statistical testing, and regression analysis.", "excerpt_keywords": "FDA, software validation, regression testing, development testing, system level testing"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[18] FDA General Principles of Software Validation -2002.pdf\n## guidance for industry and fda staff\n\n## general principles of software validation\n\nassurance that a change has not created problems elsewhere in the software product. regression analysis is the determination of the impact of a change based on review of the relevant documentation (e.g., software requirements specification, software design specification, source code, test plans, test cases, test scripts, etc.) in order to identify the necessary regression tests to be run. regression testing is the rerunning of test cases that a program has previously executed correctly and comparing the current result to the previous result in order to detect unintended effects of a software change. regression analysis and regression testing should also be employed when using integration methods to build a software product to ensure that newly integrated modules do not adversely impact the operation of previously integrated modules.\n\nin order to provide a thorough and rigorous examination of a software product, development testing is typically organized into levels. as an example, a software products testing can be organized into unit, integration, and system levels of testing.\n\n|unit (module or component) level testing|focuses on the early examination of sub-program functionality and ensures that functionality not visible at the system level is examined by testing. unit testing ensures that quality software units are furnished for integration into the finished software product.|\n|---|---|\n|integration level testing|focuses on the transfer of data and control across a programs internal and external interfaces. external interfaces are those with other software (including operating system software), system hardware, and the users and can be described as communications links.|\n|system level testing|demonstrates that all specified functionality exists and that the software product is trustworthy. this testing verifies the as-built programs functionality and performance with respect to the requirements for the software product as exhibited on the specified operating platform(s). system level software testing addresses functional concerns and the following elements of a devices software that are related to the intended use(s):|\n\n- performance issues (e.g., response times, reliability measurements);\n- responses to stress conditions, e.g., behavior under maximum load, continuous use;\n- operation of internal and external security features;\n- effectiveness of recovery procedures, including disaster recovery;\n- usability;\n- compatibility with other software products;\n- behavior in each of the defined hardware configurations; and\n- accuracy of documentation.\n\ncontrol measures (e.g., a traceability analysis) should be used to ensure that the intended coverage is achieved. system level testing also exhibits the software products behavior in the intended operating environment. the location of such testing is dependent upon the software developers ability to produce the target operating environment(s). depending upon the circumstances, simulation and/or testing at (potential) customer locations may be utilized. test plans should identify the controls needed to ensure that 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"}, "9a203c2e-caa9-49f5-9738-0c5f4e0b4910": {"__data__": {"id_": "9a203c2e-caa9-49f5-9738-0c5f4e0b4910", "embedding": null, "metadata": {"page_label": "30", "file_name": "[18] FDA General Principles of Software Validation -2002.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[18] FDA General Principles of Software Validation -2002.pdf", "file_type": "application/pdf", "file_size": 376042, "creation_date": "2024-04-07", "last_modified_date": "2024-03-28", "document_title": "Software Validation and Testing in the Medical Device Industry: A Comprehensive Guide", "questions_this_excerpt_can_answer": "1. What specific steps should be taken by software developers to ensure that a software product intended for use in medical devices or their production meets FDA guidelines for software validation and testing?\n   \n2. How does the FDA recommend handling errors detected during the testing phase of software development for medical devices, and what subsequent actions are required before the software can be released for commercial distribution?\n\n3. What documentation and validation requirements does the FDA set forth for the use of software testing tools in the development and testing of software products for medical devices, and how should these tools' quality be assessed relative to the software product they are used to develop?", "prev_section_summary": "The section discusses the importance of regression analysis and testing in software validation to ensure that changes do not create problems elsewhere in the software product. It also outlines the different levels of development testing for software products in the pharmaceutical industry, including unit, integration, and system level testing. The focus of each testing level is described, with system level testing addressing performance issues, stress conditions, security features, recovery procedures, usability, compatibility, hardware configurations, and documentation accuracy. Control measures and traceability analysis are emphasized to ensure coverage, and testing in the intended operating environment is recommended.", "excerpt_keywords": "Software Validation, FDA Guidelines, Medical Device Industry, Testing, Software Development"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[18] FDA General Principles of Software Validation -2002.pdf\n## guidance for industry and fda staff\n\n## general principles of software validation\n\nthe intended coverage is achieved and that proper documentation is prepared when planned system level testing is conducted at sites not directly controlled by the software developer. also, for a software product that is a medical device or a component of a medical device that is to be used on humans prior to fda clearance, testing involving human subjects may require an investigational device exemption (ide) or institutional review board (irb) approval.\n\ntest procedures, test data, and test results should be documented in a manner permitting objective pass/fail decisions to be reached. they should also be suitable for review and objective decision making subsequent to running the test, and they should be suitable for use in any subsequent regression testing. errors detected during testing should be logged, classified, reviewed, and resolved prior to release of the software. software error data that is collected and analyzed during a development life cycle may be used to determine the suitability of the software product for release for commercial distribution. test reports should comply with the requirements of the corresponding test plans.\n\nsoftware products that perform useful functions in medical devices or their production are often complex. software testing tools are frequently used to ensure consistency, thoroughness, and efficiency in the testing of such software products and to fulfill the requirements of the planned testing activities. these tools may include supporting software built in-house to facilitate unit (module) testing and subsequent integration testing (e.g., drivers and stubs) as well as commercial software testing tools. such tools should have a degree of quality no less than the software product they are used to develop. appropriate documentation providing evidence of the validation of these software tools for their intended use should be maintained (see section 6 of this guidance).\n\ntypical tasks - testing by the software developer\n\n- test planning\n- structural test case identification\n- functional test case identification\n- traceability analysis - testing\n- unit (module) tests to detailed design\n- integration tests to high level design\n- system tests to software requirements\n- unit (module) test execution\n- integration test execution\n- functional test execution\n- system test execution\n- acceptance test execution\n- test results evaluation\n- error evaluation/resolution\n- final test report\n\npage 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"}, "e68fb6bd-1ea7-4d63-a2fe-d7929b2b47b7": {"__data__": {"id_": "e68fb6bd-1ea7-4d63-a2fe-d7929b2b47b7", "embedding": null, "metadata": {"page_label": "31", "file_name": "[18] FDA General Principles of Software Validation -2002.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[18] FDA General Principles of Software Validation -2002.pdf", "file_type": "application/pdf", "file_size": 376042, "creation_date": "2024-04-07", "last_modified_date": "2024-03-28", "document_title": "Comprehensive Guide to User Site Testing in Software Validation", "questions_this_excerpt_can_answer": "1. What specific regulatory references are cited in the document to emphasize the necessity of installation and inspection procedures, including testing, for software validation within the pharmaceutical industry?\n\n2. How does the document define \"user site testing\" in the context of software validation, and what types of testing does it encompass according to the FDA's guidance?\n\n3. What are the key components and considerations outlined in the document for conducting effective user site testing, including the handling of hardware and software configurations and the evaluation of system performance under various conditions?", "prev_section_summary": "This section discusses the general principles of software validation in the medical device industry according to FDA guidelines. It covers the importance of proper documentation, testing procedures, and error handling during software development. The excerpt also emphasizes the need for validation of software testing tools used in the development process. Key topics include test planning, test case identification, traceability analysis, and various testing tasks performed by software developers. The section highlights the complexity of software products in medical devices and the importance of maintaining quality in testing tools.", "excerpt_keywords": "Software Validation, User Site Testing, FDA Guidelines, Installation Verification, Testing Procedures"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[18] FDA General Principles of Software Validation -2002.pdf\n## guidance for industry and fda staff\n\n## general principles of software validation\n\n5.2.6. user site testing\n\ntesting at the user site is an essential part of software validation. the quality system regulation requires installation and inspection procedures (including testing where appropriate) as well as documentation of inspection and testing to demonstrate proper installation. (see 21 cfr SS820.170.) likewise, manufacturing equipment must meet specified requirements, and automated systems must be validated for their intended use. (see 21 cfr SS820.70(g) and 21 cfr SS820.70(i) respectively.)\n\nterminology regarding user site testing can be confusing. terms such as beta test, site validation, user acceptance test, installation verification, and installation testing have all been used to describe user site testing. for purposes of this guidance, the term \"user site testing\" encompasses all of these and any other testing that takes place outside of the developers controlled environment. this testing should take place at a users site with the actual hardware and software that will be part of the installed system configuration. the testing is accomplished through either actual or simulated use of the software being tested within the context in which it is intended to function.\n\nguidance contained here is general in nature and is applicable to any user site testing. however, in some areas (e.g., blood establishment systems) there may be specific site validation issues that need to be considered in the planning of user site testing. test planners should check with the fda center(s) with the corresponding product jurisdiction to determine whether there are any additional regulatory requirements for user site testing.\n\nuser site testing should follow a pre-defined written plan with a formal summary of testing and a record of formal acceptance. documented evidence of all testing procedures, test input data, and test results should be retained.\n\nthere should be evidence that hardware and software are installed and configured as specified. measures should ensure that all system components are exercised during the testing and that the versions of these components are those specified. the testing plan should specify testing throughout the full range of operating conditions and should specify continuation for a sufficient time to allow the system to encounter a wide spectrum of conditions and events in an effort to detect any latent faults that are not apparent during more normal activities.\n\nsome of the evaluations that have been performed earlier by the software developer at the developers site should be repeated at the site of actual use. these may include tests for a high volume of data, heavy loads or stresses, security, fault testing (avoidance, detection, tolerance, and recovery), error messages, and implementation of safety requirements. the developer may be able to furnish the user with some of the test data sets to be used for this purpose.\n\nin addition to an evaluation of the systems ability to properly perform its intended functions, there should be an evaluation of the ability of the users of the system to understand and correctly interface with it. operators should be able to perform the intended functions and respond in an appropriate and timely manner to all alarms, warnings, and error messages.\n\npage 27", "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"}, "3587448a-3ee6-4661-aa4e-2ccc8babac1d": {"__data__": {"id_": "3587448a-3ee6-4661-aa4e-2ccc8babac1d", "embedding": null, "metadata": {"page_label": "32", "file_name": "[18] FDA General Principles of Software Validation -2002.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[18] FDA General Principles of Software Validation -2002.pdf", "file_type": "application/pdf", "file_size": 376042, "creation_date": "2024-04-07", "last_modified_date": "2024-03-28", "document_title": "Software Validation, Maintenance, and User Site Testing with Software Changes", "questions_this_excerpt_can_answer": "1. What are the key differences between hardware maintenance and software maintenance as outlined in the FDA's General Principles of Software Validation document from 2002?\n   \n2. According to the 2002 FDA guidance for industry and FDA staff on software validation, what types of maintenance are identified for software, and how do they differ from preventive maintenance actions or software component replacement?\n\n3. In the context of the 2002 FDA guidelines on software validation, how should changes made to a software system during post-release maintenance be validated to ensure that unaffected parts of the software remain unimpacted?", "prev_section_summary": "This section focuses on user site testing as an essential part of software validation in the pharmaceutical industry. It outlines the regulatory requirements for installation and inspection procedures, including testing, as well as the documentation needed to demonstrate proper installation. The document defines \"user site testing\" as encompassing various types of testing outside of the developer's controlled environment, conducted at the user's site with the actual hardware and software configurations. Key components of effective user site testing include testing under various conditions, ensuring proper hardware and software installation, and evaluating system performance and user interaction. The section emphasizes the need for a pre-defined testing plan, formal summary of testing, and retention of documented evidence. It also highlights the importance of testing for high data volume, security, error handling, and user interface usability.", "excerpt_keywords": "Software Validation, Maintenance, User Site Testing, FDA Guidance, Software Changes"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[18] FDA General Principles of Software Validation -2002.pdf\n## guidance for industry and fda staff\n\ngeneral principles of software validation\n\nduring user site testing, records should be maintained of both proper system performance and any system failures that are encountered. the revision of the system to compensate for faults detected during this user site testing should follow the same procedures and controls as for any other software change.\n\nthe developers of the software may or may not be involved in the user site testing. if the developers are involved, they may seamlessly carry over to the users site the last portions of design-level systems testing. if the developers are not involved, it is all the more important that the user have persons who understand the importance of careful test planning, the definition of expected test results, and the recording of all test outputs.\n\ntypical tasks - user site testing\n\n- acceptance test execution\n- test results evaluation\n- error evaluation/resolution\n- final test report\n\n5.2.7. maintenance and software changes\n\nas applied to software, the term maintenance does not mean the same as when applied to hardware. the operational maintenance of hardware and software are different because their failure/error mechanisms are different. hardware maintenance typically includes preventive hardware maintenance actions, component replacement, and corrective changes. software maintenance includes corrective, perfective, and adaptive maintenance but does not include preventive maintenance actions or software component replacement.\n\nchanges made to correct errors and faults in the software are corrective maintenance. changes made to the software to improve the performance, maintainability, or other attributes of the software system are perfective maintenance. software changes to make the software system usable in a changed environment are adaptive maintenance.\n\nwhen changes are made to a software system, either during initial development or during post-release maintenance, sufficient regression analysis and testing should be conducted to demonstrate that portions of the software not involved in the change were not adversely impacted. this is in addition to testing that evaluates the correctness of the implemented change(s).\n\nthe specific validation effort necessary for each software change is determined by the type of change, the development products affected, and the impact of those products on the operation of the software. careful and complete documentation of the design structure and interrelationships of various modules, interfaces, etc., can limit the validation effort needed when a change is made. the level of effort needed\n\npage 28", "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"}, "0829f2be-55aa-431e-b77a-ed9e5b9a39de": {"__data__": {"id_": "0829f2be-55aa-431e-b77a-ed9e5b9a39de", "embedding": null, "metadata": {"page_label": "33", "file_name": "[18] FDA General Principles of Software Validation -2002.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[18] FDA General Principles of Software Validation -2002.pdf", "file_type": "application/pdf", "file_size": 376042, "creation_date": "2024-04-07", "last_modified_date": "2024-03-28", "document_title": "Software Validation and Maintenance Best Practices: A Comprehensive Guide", "questions_this_excerpt_can_answer": "1. What specific steps should be taken to revise a software validation plan when validating revised software, according to the FDA's general principles of software validation outlined in 2002?\n   \n2. How does the FDA recommend handling software anomalies to prevent the recurrence of similar quality problems, as detailed in the 2002 guidance for industry and FDA staff on software validation?\n\n3. What are the recommended procedures for updating documentation affected by software changes, based on the FDA's 2002 guidelines on software validation and maintenance best practices?", "prev_section_summary": "This section discusses the maintenance and software changes outlined in the FDA's General Principles of Software Validation document from 2002. It highlights the differences between hardware and software maintenance, the types of software maintenance (corrective, perfective, adaptive), and the importance of validating changes made to a software system to ensure unaffected parts remain unimpacted. The section also emphasizes the need for regression analysis and testing when implementing software changes, as well as the documentation of design structure and interrelationships to limit validation efforts.", "excerpt_keywords": "Software Validation, FDA, Maintenance, Documentation, Anomaly Evaluation"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[18] FDA General Principles of Software Validation -2002.pdf\n# guidance for industry and fda staff\n\n## general principles of software validation\n\nto fully validate a change is also dependent upon the degree to which validation of the original software was documented and archived. for example, test documentation, test cases, and results of previous verification and validation testing need to be archived if they are to be available for performing subsequent regression testing. failure to archive this information for later use can significantly increase the level of effort and expense of revalidating the software after a change is made.\n\nin addition to software verification and validation tasks that are part of the standard software development process, the following additional maintenance tasks should be addressed:\n\n|software validation plan revision|- for software that was previously validated, the existing software validation plan should be revised to support the validation of the revised software. if no previous software validation plan exists, such a plan should be established to support the validation of the revised software.|\n|---|---|\n|anomaly evaluation|- software organizations frequently maintain documentation, such as software problem reports that describe software anomalies discovered and the specific corrective action taken to fix each anomaly. too often, however, mistakes are repeated because software developers do not take the next step to determine the root causes of problems and make the process and procedural changes needed to avoid recurrence of the problem. software anomalies should be evaluated in terms of their severity and their effects on system operation and safety, but they should also be treated as symptoms of process deficiencies in the quality system. a root cause analysis of anomalies can identify specific quality system deficiencies. where trends are identified (e.g., recurrence of similar software anomalies), appropriate corrective and preventive actions must be implemented and documented to avoid further recurrence of similar quality problems. (see 21 cfr 820.100.)|\n|problem identification and resolution tracking|- all problems discovered during maintenance of the software should be documented. the resolution of each problem should be tracked to ensure it is fixed, for historical reference, and for trending.|\n|proposed change assessment|- all proposed modifications, enhancements, or additions should be assessed to determine the effect each change would have on the system. this information should determine the extent to which verification and/or validation tasks need to be iterated.|\n|task iteration|- for approved software changes, all necessary verification and validation tasks should be performed to ensure that planned changes are implemented correctly, all documentation is complete and up to date, and no unacceptable changes have occurred in software performance.|\n|documentation updating|- documentation should be carefully reviewed to determine which documents have been impacted by a change. all approved documents (e.g., specifications, test procedures, user manuals, etc.) that have been affected should be updated in accordance with configuration management procedures. specifications should be updated before any maintenance and software changes are made.|\n\npage 29", "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"}, "2d53bcff-2fdc-4cc7-a9ca-e27d18629012": {"__data__": {"id_": "2d53bcff-2fdc-4cc7-a9ca-e27d18629012", "embedding": null, "metadata": {"page_label": "34", "file_name": "[18] FDA General Principles of Software Validation -2002.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[18] FDA General Principles of Software Validation -2002.pdf", "file_type": "application/pdf", "file_size": 376042, "creation_date": "2024-04-07", "last_modified_date": "2024-03-28", "document_title": "Validation of Automated Process Equipment and Quality System Software in Medical Device Manufacturing: Ensuring Compliance and Quality Assurance", "questions_this_excerpt_can_answer": "1. What specific regulatory requirement has been in place since 1978 regarding the use of computers or automated data processing systems in the production or quality system of medical device manufacturing, according to the FDA's General Principles of Software Validation document from 2002?\n\n2. How does the FDA's 2002 General Principles of Software Validation document outline the integration of 21 CFR Part 11 requirements into the validation process of computer systems used in medical device manufacturing?\n\n3. What types of automated equipment and software tools are identified in the FDA's 2002 General Principles of Software Validation document as being extensively used in various aspects of medical device design and quality system, and how does it suggest these tools should be validated?", "prev_section_summary": "The section discusses the general principles of software validation outlined by the FDA in 2002, focusing on the importance of revising software validation plans, handling software anomalies, updating documentation, and tracking problem resolution during software maintenance. Key topics include the need for thorough documentation of validation activities, evaluating software anomalies for root causes, tracking problem resolution, assessing proposed changes, performing verification and validation tasks for approved changes, and updating documentation affected by software changes. The section emphasizes the importance of addressing process deficiencies to prevent the recurrence of similar quality problems in software systems.", "excerpt_keywords": "FDA, Software Validation, Medical Device Manufacturing, Quality System, Automated Equipment"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[18] FDA General Principles of Software Validation -2002.pdf\n## guidance for industry and fda staff\n\n## general principles of software validation\n\n### section 6. validation of automated process equipment and quality system software\n\nthe quality system regulation requires that \"when computers or automated data processing systems are used as part of production or the quality system, the [device] manufacturer shall validate computer software for its intended use according to an established protocol.\" (see 21 cfr SS820.70(i)). this has been a regulatory requirement of fdas medical device good manufacturing practice (gmp) regulations since 1978.\n\nin addition to the above validation requirement, computer systems that implement part of a device manufacturers production processes or quality system (or that are used to create and maintain records required by any other fda regulation) are subject to the electronic records; electronic signatures regulation. (see 21 cfr part 11.) this regulation establishes additional security, data integrity, and validation requirements when records are created or maintained electronically. these additional part 11 requirements should be carefully considered and included in system requirements and software requirements for any automated record keeping systems. system validation and software validation should demonstrate that all part 11 requirements have been met.\n\ncomputers and automated equipment are used extensively throughout all aspects of medical device design, laboratory testing and analysis, product inspection and acceptance, production and process control, environmental controls, packaging, labeling, traceability, document control, complaint management, and many other aspects of the quality system. increasingly, automated plant floor operations can involve extensive use of embedded systems in:\n\n- programmable logic controllers;\n- digital function controllers;\n- statistical process control;\n- supervisory control and data acquisition;\n- robotics;\n- human-machine interfaces;\n- input/output devices; and\n- computer operating systems.\n\nsoftware tools are frequently used to design, build, and test the software that goes into an automated medical device. many other commercial software applications, such as word processors, spreadsheets, databases, and flowcharting software are used to implement the quality system. all of these applications are subject to the requirement for software validation, but the validation approach used for each application can vary widely.\n\nwhether production or quality system software is developed in-house by the device manufacturer, developed by a contractor, or purchased off-the-shelf, it should be developed using the basic principles.", "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"}, "f82db916-78dd-4e24-9d39-7e0576ccd748": {"__data__": {"id_": "f82db916-78dd-4e24-9d39-7e0576ccd748", "embedding": null, "metadata": {"page_label": "35", "file_name": "[18] FDA General Principles of Software Validation -2002.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[18] FDA General Principles of Software Validation -2002.pdf", "file_type": "application/pdf", "file_size": 376042, "creation_date": "2024-04-07", "last_modified_date": "2024-03-28", "document_title": "Comprehensive Software Validation Guidelines and Requirements for Medical Device Manufacturers", "questions_this_excerpt_can_answer": "1. What factors determine the level of validation effort required for software used in medical device manufacturing according to the FDA's 2002 guidelines?\n   \n2. How does the FDA's 2002 guidance suggest device manufacturers manage the validation of commercial software applications that are part of the quality system but are not fully utilized for their capabilities?\n\n3. According to the FDA's 2002 guidelines, what steps should a device manufacturer take when software is upgraded or changes are made to ensure continued compliance with validation requirements?", "prev_section_summary": "The section discusses the validation of automated process equipment and quality system software in medical device manufacturing according to FDA regulations. Key topics include the regulatory requirement for validating computer software since 1978, integration of 21 CFR Part 11 requirements into validation processes, types of automated equipment and software tools used in medical device design and quality systems, and the importance of software validation for various applications. Entities mentioned include programmable logic controllers, digital function controllers, statistical process control, supervisory control and data acquisition, robotics, human-machine interfaces, input/output devices, and computer operating systems.", "excerpt_keywords": "FDA, software validation, medical device, quality system, risk analysis"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[18] FDA General Principles of Software Validation -2002.pdf\n## guidance for industry and fda staff\n\n## general principles of software validation\n\noutlined elsewhere in this guidance. the device manufacturer has latitude and flexibility in defining how\nvalidation of that software will be accomplished, but validation should be a key consideration in deciding\nhow and by whom the software will be developed or from whom it will be purchased. the software\ndeveloper defines a life cycle model. validation is typically supported by:\n\n- verifications of the outputs from each stage of that software development life cycle; and\n- checking for proper operation of the finished software in the device manufacturers intended use\nenvironment.\n\n## 6.1. how much validation evidence is needed?\n\nthe level of validation effort should be commensurate with the risk posed by the automated operation.\nin addition to risk other factors, such as the complexity of the process software and the degree to which\nthe device manufacturer is dependent upon that automated process to produce a safe and effective\ndevice, determine the nature and extent of testing needed as part of the validation effort. documented\nrequirements and risk analysis of the automated process help to define the scope of the evidence\nneeded to show that the software is validated for its intended use. for example, an automated milling\nmachine may require very little testing if the device manufacturer can show that the output of the\noperation is subsequently fully verified against the specification before release. on the other hand,\nextensive testing may be needed for:\n\n- a plant-wide electronic record and electronic signature system;\n- an automated controller for a sterilization cycle; or\n- automated test equipment used for inspection and acceptance of finished circuit boards in a life-\nsustaining / life-supporting device.\n\nnumerous commercial software applications may be used as part of the quality system (e.g., a\nspreadsheet or statistical package used for quality system calculations, a graphics package used for\ntrend analysis, or a commercial database used for recording device history records or for complaint\nmanagement). the extent of validation evidence needed for such software depends on the device\nmanufacturers documented intended use of that software. for example, a device manufacturer who\nchooses not to use all the vendor-supplied capabilities of the software only needs to validate those\nfunctions that will be used and for which the device manufacturer is dependent upon the software results\nas part of production or the quality system. however, high risk applications should not be running in the\nsame operating environment with non-validated software functions, even if those software functions are\nnot used. risk mitigation techniques such as memory partitioning or other approaches to resource\nprotection may need to be considered when high risk applications and lower risk applications are to be\nused in the same operating environment. when software is upgraded or any changes are made to the\nsoftware, the device manufacturer should consider how those changes may impact the \"used portions\"\nof the software and must reconfirm the validation of those portions of the software that are used. (see\n21 cfr SS820.70(i).)\n\npage 31", "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"}, "5dafd197-8a28-44e5-bcc8-b8c915456f29": {"__data__": {"id_": "5dafd197-8a28-44e5-bcc8-b8c915456f29", "embedding": null, "metadata": {"page_label": "36", "file_name": "[18] FDA General Principles of Software Validation -2002.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[18] FDA General Principles of Software Validation -2002.pdf", "file_type": "application/pdf", "file_size": 376042, "creation_date": "2024-04-07", "last_modified_date": "2024-03-28", "document_title": "Guidelines for Software Validation, User Requirements, and Compliance in Medical Device Manufacturing", "questions_this_excerpt_can_answer": "1. What specific elements must be included in a documented user requirements specification for software validation in medical device manufacturing according to the FDA's 2002 guidelines?\n   \n2. How does the FDA's 2002 guidance for software validation in medical device manufacturing address the handling of error and alarm conditions, including the documentation and execution of test cases?\n\n3. What responsibilities does a device manufacturer have in ensuring the validation of production and quality system software, as outlined in the FDA's 2002 guidelines for software validation in medical device manufacturing?", "prev_section_summary": "The section discusses the general principles of software validation for medical device manufacturers according to the FDA's 2002 guidelines. Key topics include the level of validation effort needed based on risk and complexity, the validation of commercial software applications within the quality system, and the steps to take when software is upgraded or changes are made to ensure continued compliance with validation requirements. Entities mentioned include device manufacturers, software developers, automated processes, risk analysis, commercial software applications, and validation evidence.", "excerpt_keywords": "FDA, software validation, user requirements, medical device manufacturing, compliance"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[18] FDA General Principles of Software Validation -2002.pdf\n## guidance for industry and fda staff\n\n## general principles of software validation\n\n6.2. defined user requirements\n\na very important key to software validation is a documented user requirements specification that defines:\n\n- the \"intended use\" of the software or automated equipment; and\n- the extent to which the device manufacturer is dependent upon that software or equipment for production of a quality medical device.\n\nthe device manufacturer (user) needs to define the expected operating environment including any required hardware and software configurations, software versions, utilities, etc. the user also needs to:\n\n- document requirements for system performance, quality, error handling, startup, shutdown, security, etc.;\n- identify any safety related functions or features, such as sensors, alarms, interlocks, logical processing steps, or command sequences; and\n- define objective criteria for determining acceptable performance.\n\nthe validation must be conducted in accordance with a documented protocol, and the validation results must also be documented. (see 21 cfr SS820.70(i).) test cases should be documented that will exercise the system to challenge its performance against the pre-determined criteria, especially for its most critical parameters. test cases should address error and alarm conditions, startup, shutdown, all applicable user functions and operator controls, potential operator errors, maximum and minimum ranges of allowed values, and stress conditions applicable to the intended use of the equipment. the test cases should be executed and the results should be recorded and evaluated to determine whether the results support a conclusion that the software is validated for its intended use.\n\na device manufacturer may conduct a validation using their own personnel or may depend on a third party such as the equipment/software vendor or a consultant. in any case, the device manufacturer retains the ultimate responsibility for ensuring that the production and quality system software:\n\n- is validated according to a written procedure for the particular intended use; and\n- will perform as intended in the chosen application.\n\nthe device manufacturer should have documentation including:\n\n- defined user requirements;\n- validation protocol used;\n- acceptance criteria;\n- test cases and results; and\n- a validation summary\n\nthat objectively confirms that the software is validated for its intended use.\n\npage 32", "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"}, "10f6091f-ce63-40ce-ac17-01376b534461": {"__data__": {"id_": "10f6091f-ce63-40ce-ac17-01376b534461", "embedding": null, "metadata": {"page_label": "37", "file_name": "[18] FDA General Principles of Software Validation -2002.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[18] FDA General Principles of Software Validation -2002.pdf", "file_type": "application/pdf", "file_size": 376042, "creation_date": "2024-04-07", "last_modified_date": "2024-03-28", "document_title": "Validation of Off-the-Shelf Software and Automated Equipment in Medical Device Manufacturing: A Comprehensive Guide", "questions_this_excerpt_can_answer": "1. What responsibilities do medical device manufacturers have when using off-the-shelf (OTS) software and automated equipment in their products, according to the FDA's guidance?\n   \n2. How should medical device manufacturers proceed if the vendor of an OTS software or automated equipment does not provide sufficient validation documentation or refuses to share proprietary information?\n\n3. What are the recommended steps for medical device manufacturers when dealing with OTS software development tools like compilers, linkers, editors, and operating systems, in terms of validation, according to the FDA's 2002 guidance?", "prev_section_summary": "The section discusses the importance of having a documented user requirements specification for software validation in medical device manufacturing according to the FDA's 2002 guidelines. It outlines the elements that must be included in the user requirements specification, such as the intended use of the software, system performance requirements, safety features, and criteria for acceptable performance. The section also addresses the handling of error and alarm conditions, the execution of test cases, and the responsibilities of device manufacturers in ensuring the validation of production and quality system software. Key entities mentioned include the device manufacturer, users, software vendors, consultants, and the FDA.", "excerpt_keywords": "FDA, software validation, medical device manufacturing, off-the-shelf software, automated equipment"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[18] FDA General Principles of Software Validation -2002.pdf\n## guidance for industry and fda staff\n\n## general principles of software validation\n\n6.3. validation of off-the-shelf software and automated equipment\n\nmost of the automated equipment and systems used by device manufacturers are supplied by third-party vendors and are purchased off-the-shelf (ots). the device manufacturer is responsible for ensuring that the product development methodologies used by the ots software developer are appropriate and sufficient for the device manufacturers intended use of that ots software. for ots software and equipment, the device manufacturer may or may not have access to the vendors software validation documentation. if the vendor can provide information about their system requirements, software requirements, validation process, and the results of their validation, the medical device manufacturer can use that information as a beginning point for their required validation documentation. the vendors life cycle documentation, such as testing protocols and results, source code, design specification, and requirements specification, can be useful in establishing that the software has been validated. however, such documentation is frequently not available from commercial equipment vendors, or the vendor may refuse to share their proprietary information.\n\nwhere possible and depending upon the device risk involved, the device manufacturer should consider auditing the vendors design and development methodologies used in the construction of the ots software and should assess the development and validation documentation generated for the ots software. such audits can be conducted by the device manufacturer or by a qualified third party. the audit should demonstrate that the vendors procedures for and results of the verification and validation activities performed the ots software are appropriate and sufficient for the safety and effectiveness requirements of the medical device to be produced using that software.\n\nsome vendors who are not accustomed to operating in a regulated environment may not have a documented life cycle process that can support the device manufacturers validation requirement. other vendors may not permit an audit. where necessary validation information is not available from the vendor, the device manufacturer will need to perform sufficient system level \"black box\" testing to establish that the software meets their \"user needs and intended uses.\" for many applications black box testing alone is not sufficient. depending upon the risk of the device produced, the role of the ots software in the process, the ability to audit the vendor, and the sufficiency of vendor-supplied information, the use of ots software or equipment may or may not be appropriate, especially if there are suitable alternatives available. the device manufacturer should also consider the implications (if any) for continued maintenance and support of the ots software should the vendor terminate their support.\n\nfor some off-the-shelf software development tools, such as software compilers, linkers, editors, and operating systems, exhaustive black-box testing by the device manufacturer may be impractical. without such testing - a key element of the validation effort - it may not be possible to validate these software tools. however, their proper operation may be satisfactorily inferred by other means. for example, compilers are frequently certified by independent third-party testing, and commercial software products may have \"bug lists\", system requirements and other operational information available from the vendor that can be compared to the device manufacturers intended use to help focus the \"black-box\" testing effort. off-the-shelf operating systems need not be validated as a separate program. however, system-level validation testing of the application software should address all the operating system services used, including maximum loading conditions, file operations, handling of system error\n\npage 33", "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"}, "0834d867-db17-4a6d-9807-abb7ae229972": {"__data__": {"id_": "0834d867-db17-4a6d-9807-abb7ae229972", "embedding": null, "metadata": {"page_label": "38", "file_name": "[18] FDA General Principles of Software Validation -2002.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[18] FDA General Principles of Software Validation -2002.pdf", "file_type": "application/pdf", "file_size": 376042, "creation_date": "2024-04-07", "last_modified_date": "2024-03-28", "document_title": "Software Validation Guidelines for Industry and FDA Staff: A Comprehensive Guide", "questions_this_excerpt_can_answer": "1. What are the general principles of software validation as outlined by the FDA for industry and FDA staff within the context of conditions and memory constraints?\n   \n2. Where can one find more detailed information on production and process software as referenced in the FDA's Software Validation Guidelines for Industry and FDA Staff document from 2002?\n\n3. How does the FDA's 2002 document on Software Validation Guidelines address the specific considerations necessary for the intended use of application programs in the pharmaceutical industry, particularly in relation to conditions and memory constraints?", "prev_section_summary": "This section discusses the validation of off-the-shelf software and automated equipment in medical device manufacturing according to FDA guidance. Key topics include the responsibilities of medical device manufacturers when using OTS software, the steps to take if vendors do not provide validation documentation, and the validation of OTS software development tools. Entities mentioned include device manufacturers, vendors, validation documentation, audits, black box testing, and software development tools like compilers and operating systems.", "excerpt_keywords": "FDA, software validation, industry, memory constraints, production software"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[18] FDA General Principles of Software Validation -2002.pdf\n# guidance for industry and fda staff\n\ngeneral principles of software validation\n\nconditions, and memory constraints that may be applicable to the intended use of the application program.\n\nfor more detailed information, see the production and process software references in appendix a.\n\npage 34", "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"}, "972e7772-faee-4a68-a593-b5965ed6dbb9": {"__data__": {"id_": "972e7772-faee-4a68-a593-b5965ed6dbb9", "embedding": null, "metadata": {"page_label": "39", "file_name": "[18] FDA General Principles of Software Validation -2002.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[18] FDA General Principles of Software Validation -2002.pdf", "file_type": "application/pdf", "file_size": 376042, "creation_date": "2024-04-07", "last_modified_date": "2024-03-28", "document_title": "FDA Guidance on Software Validation and Development for Medical Devices", "questions_this_excerpt_can_answer": "1. What specific FDA guidance documents are available for medical device manufacturers regarding design control and human factors as of 1997?\n2. As of the late 1990s, what resources did the FDA provide to assist in understanding the regulatory requirements for software contained within medical devices, including off-the-shelf software?\n3. What historical documents or guidelines has the FDA issued related to electronic records and signatures, software development terminology, and process validation principles relevant to the medical device industry up to the year 1999?", "prev_section_summary": "The section provides guidance on the general principles of software validation as outlined by the FDA for industry and FDA staff, specifically addressing conditions and memory constraints relevant to the intended use of application programs. It references appendix A for more detailed information on production and process software. The document focuses on addressing specific considerations necessary for the intended use of application programs in the pharmaceutical industry, particularly in relation to conditions and memory constraints.", "excerpt_keywords": "FDA, software validation, medical devices, guidance, electronic records"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[18] FDA General Principles of Software Validation -2002.pdf\n## guidance for industry and fda staff\n\n## general principles of software validation\n\n### appendix a - references\n\n|design control guidance for medical device manufacturers|center for devices and radiological health, food and drug administration, march 1997|\n|---|---|\n|do it by design, an introduction to human factors in medical devices|center for devices and radiological health, food and drug administration, march 1997|\n|electronic records; electronic signatures final rule|62 federal register 13430 (march 20, 1997)|\n|glossary of computerized system and software development terminology|division of field investigations, office of regional operations, office of regulatory affairs, food and drug administration, august 1995|\n|guidance for the content of pre-market submissions for software contained in medical devices|office of device evaluation, center for devices and radiological health, food and drug administration, may 1998|\n|guidance for industry, fda reviewers and compliance on off-the-shelf software use in medical devices|office of device evaluation, center for devices and radiological health, food and drug administration, september 1999|\n|guideline on general principles of process validation|center for drugs and biologics, & center for devices and radiological health, food and drug administration, may 1987|\n|medical devices; current good manufacturing practice (cgmp) final rule; quality system regulation|61 federal register 52602 (october 7, 1996)|\n|reviewer guidance for a pre-market notification submission for blood establishment computer software|center for biologics evaluation and research, food and drug administration, january 1997|\n|student manual 1, course inv545, computer system validation|division of human resource development, office of regulatory affairs, food and drug administration, 1997|\n|technical report, software development activities|division of field investigations, office of regional operations, office of regulatory affairs, food and drug administration, july 1987|", "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"}, "dee9c516-2ad1-4d81-bcb6-469bdc8ab876": {"__data__": {"id_": "dee9c516-2ad1-4d81-bcb6-469bdc8ab876", "embedding": null, "metadata": {"page_label": "40", "file_name": "[18] FDA General Principles of Software Validation -2002.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[18] FDA General Principles of Software Validation -2002.pdf", "file_type": "application/pdf", "file_size": 376042, "creation_date": "2024-04-07", "last_modified_date": "2024-03-28", "document_title": "Government Publications on Software Validation, Verification, and Testing in the Nuclear Industry: A Comprehensive Guide", "questions_this_excerpt_can_answer": "1. What are the titles and publication years of the documents produced by the National Bureau of Standards (now NIST) that focus on the validation, verification, and testing of computer software specifically for individual programmers and the broader programming community in the early 1980s?\n\n2. Can you list the publications prepared for the U.S. Nuclear Regulatory Commission between 1987 and 1996 that provide guidelines on software quality assurance, verification and validation for high integrity systems, and review guidelines on software languages for use in nuclear power plant safety systems?\n\n3. What are the specific NIST special publications released in September 1995 that address the role of software verification and validation in computer assurance and its relationship with software project management standards, as well as standards and guidelines for high integrity software?", "prev_section_summary": "The section provides a list of references and guidance documents related to software validation for medical devices issued by the FDA. Key topics include design control, human factors, electronic records and signatures, software development terminology, pre-market submissions for software in medical devices, off-the-shelf software use, process validation principles, and good manufacturing practices. Entities mentioned include the Center for Devices and Radiological Health, Office of Device Evaluation, Division of Field Investigations, Center for Drugs and Biologics, Center for Biologics Evaluation and Research, and Office of Regulatory Affairs within the FDA.", "excerpt_keywords": "Software Validation, Verification, Testing, NIST, Nuclear Regulatory Commission"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[18] FDA General Principles of Software Validation -2002.pdf\n|other government references|\n|---|\n|w. richards adrion, martha a. branstad, john c. cherniavsky.|nbs special publication 500-75, validation, verification, and testing of computer software, center for programming science and technology, institute for computer sciences and technology, national bureau of standards, u.s. department of commerce, february 1981.|\n|martha a. branstad, john c cherniavsky, w. richards adrion.|nbs special publication 500-56, validation, verification, and testing for the individual programmer, center for programming science and technology, institute for computer sciences and technology, national bureau of standards, u.s. department of commerce, february 1980.|\n|j.l. bryant, n.p. wilburn.|handbook of software quality assurance techniques applicable to the nuclear industry, nureg/cr-4640, u.s. nuclear regulatory commission, 1987.|\n|h. hecht, et.al.|verification and validation guidelines for high integrity systems. nureg/cr-6293. prepared for u.s. nuclear regulatory commission, 1995.|\n|h. hecht, et.al.|review guidelines on software languages for use in nuclear power plant safety systems, final report. nureg/cr-6463. prepared for u.s. nuclear regulatory commission, 1996.|\n|j.d. lawrence, w.l. persons.|survey of industry methods for producing highly reliable software, nureg/cr-6278, u.s. nuclear regulatory commission, 1994.|\n|j.d. lawrence, g.g. preckshot.|design factors for safety-critical software, nureg/cr-6294, u.s. nuclear regulatory commission, 1994.|\n|patricia b. powell, editor.|nbs special publication 500-98, planning for software validation, verification, and testing, center for programming science and technology, institute for computer sciences and technology, national bureau of standards, u.s. department of commerce, november 1982.|\n|patricia b. powell, editor.|nbs special publication 500-93, software validation, verification, and testing technique and tool reference guide, center for programming science and technology, institute for computer sciences and technology, national bureau of standards, u.s. department of commerce, september 1982.|\n|delores r. wallace, roger u. fujii.|nist special publication 500-165, software verification and validation: its role in computer assurance and its relationship with software project management standards, national computer systems laboratory, national institute of standards and technology, u.s. department of commerce, september 1995.|\n|delores r. wallace, laura m. ippolito, d. richard kuhn.|nist special publication 500-204, high integrity software, standards and guidelines, computer systems laboratory, national institute of standards of technology, u.s. department of commerce, september 1995.|", "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"}, "9deaacec-7d1a-4546-b716-79bf6d306172": {"__data__": {"id_": "9deaacec-7d1a-4546-b716-79bf6d306172", "embedding": null, "metadata": {"page_label": "41", "file_name": "[18] FDA General Principles of Software Validation -2002.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[18] FDA General Principles of Software Validation -2002.pdf", "file_type": "application/pdf", "file_size": 376042, "creation_date": "2024-04-07", "last_modified_date": "2024-03-28", "document_title": "Software Validation Standards and Guidelines: A Comprehensive Guide", "questions_this_excerpt_can_answer": "1. What specific NIST publications are referenced in the FDA's General Principles of Software Validation document for guidance on software verification and validation processes, and what are their publication dates?\n   \n2. Can you list the international and national consensus standards for software validation and safety that are recognized by the FDA in their 2002 guidance document, including the specific standards related to the nuclear industry, quality control, and medical electrical equipment?\n\n3. What are the publication years and the organizations responsible for the development of the ANSI, AS, IEC, and IEEE standards mentioned in the FDA's 2002 guidance document on software validation, particularly those standards that focus on the safety of programmable components and electrical/electronic/programmable electronic safety-related systems?", "prev_section_summary": "The section provides a list of government publications related to software validation, verification, and testing in the nuclear industry. Key topics include validation, verification, and testing of computer software, software quality assurance techniques, guidelines for high integrity systems, software languages for nuclear power plant safety systems, and industry methods for producing reliable software. Key entities mentioned in the publications include the National Bureau of Standards (now NIST), the U.S. Department of Commerce, the U.S. Nuclear Regulatory Commission, and various authors and editors involved in producing the publications.", "excerpt_keywords": "FDA, Software Validation, NIST, Standards, Guidelines"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[18] FDA General Principles of Software Validation -2002.pdf\n## guidance for industry and fda staff\n\ngeneral principles of software validation\n\nstandards and technology, u.s. department of commerce, september 1992.\n\ndelores r. wallace, et.al. nist special publication 500-234, reference information for the software verification and validation process. computer systems laboratory, national institute of standards and technology, u.s. department of commerce, march 1996.\n\ndelores r. wallace, editor. nist special publication 500-235, structured testing: a testing methodology using the cyclomatic complexity metric. computer systems laboratory, national institute of standards and technology, u.s. department of commerce, august 1996.\n\n### international and national consensus standards\n\n|ansi / ans-10.4-1987,|guidelines for the verification and validation of scientific and engineering computer programs for the nuclear industry, american national standards institute, 1987.|\n|---|---|\n|ansi / asqc standard d1160-1995,|formal design reviews, american society for quality control, 1995.|\n|ansi / ul 1998:1998,|standard for safety for software in programmable components, underwriters laboratories, inc., 1998.|\n|as 3563.1-1991,|software quality management system, part 1: requirements. published by standards australia [standards association of australia], 1 the crescent, homebush, nsw 2140.|\n|as 3563.2-1991,|software quality management system, part 2: implementation guide. published by standards australia [standards association of australia], 1 the crescent, homebush, nsw 2140.|\n|iec 60601-1-4:1996,|medical electrical equipment, part 1: general requirements for safety, 4. collateral standard: programmable electrical medical systems. international electrotechnical commission, 1996.|\n|iec 61506:1997,|industrial process measurement and control - documentation of application software. international electrotechnical commission, 1997.|\n|iec 61508:1998,|functional safety of electrical/electronic/programmable electronic safety-related systems. international electrotechnical commission, 1998.|\n|ieee std 1012-1986,|software verification and validation plans, institute for electrical and electronics engineers, 1986.|", "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"}, "f1a86b2f-7f7f-4140-b8ee-bf98a902d71d": {"__data__": {"id_": "f1a86b2f-7f7f-4140-b8ee-bf98a902d71d", "embedding": null, "metadata": {"page_label": "42", "file_name": "[18] FDA General Principles of Software Validation -2002.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[18] FDA General Principles of Software Validation -2002.pdf", "file_type": "application/pdf", "file_size": 376042, "creation_date": "2024-04-07", "last_modified_date": "2024-03-28", "document_title": "Software Validation Standards and Guidelines in Regulated Industries: A Comprehensive Guide", "questions_this_excerpt_can_answer": "1. What are the specific ISO standards referenced in the FDA's General Principles of Software Validation document for ensuring quality management and assurance in software development and maintenance within regulated industries as of 2002?\n\n2. How does the FDA document from 2002 incorporate international standards for software life cycle processes and software product evaluation, and which organizations are responsible for these standards?\n\n3. What guidance or standards are provided for the application of risk management in medical device software, according to the FDA's 2002 document on software validation principles?", "prev_section_summary": "The section provides guidance on software validation standards and guidelines, referencing specific NIST publications for software verification and validation processes. It lists international and national consensus standards recognized by the FDA in their 2002 guidance document, including standards related to the nuclear industry, quality control, and medical electrical equipment. The publication years and organizations responsible for the development of ANSI, AS, IEC, and IEEE standards are also mentioned, particularly focusing on safety standards for programmable components and electrical/electronic/programmable electronic safety-related systems. Key entities mentioned include the U.S. Department of Commerce, National Institute of Standards and Technology, American National Standards Institute, American Society for Quality Control, Underwriters Laboratories, Inc., Standards Australia, and the International Electrotechnical Commission.", "excerpt_keywords": "FDA, Software Validation, ISO Standards, Quality Management, Risk Management"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[18] FDA General Principles of Software Validation -2002.pdf\n|guidance for industry and fda staff|general principles of software validation|\n|---|---|\n|ieee standards collection, software engineering, institute of electrical and electronics engineers, inc., 1994. isbn 1-55937-442-x.| |\n|iso 8402:1994|quality management and quality assurance - vocabulary. international organization for standardization, 1994.|\n|iso 9000-3:1997|quality management and quality assurance standards - part 3: guidelines for the application of iso 9001:1994 to the development, supply, installation and maintenance of computer software. international organization for standardization, 1997.|\n|iso 9001:1994|quality systems - model for quality assurance in design, development, production, installation, and servicing. international organization for standardization, 1994.|\n|iso 13485:1996|quality systems - medical devices - particular requirements for the application of iso 9001. international organization for standardization, 1996.|\n|iso/iec 12119:1994|information technology - software packages - quality requirements and testing, joint technical committee iso/iec jtc 1, international organization for standardization and international electrotechnical commission, 1994.|\n|iso/iec 12207:1995|information technology - software life cycle processes, joint technical committee iso/iec jtc 1, subcommittee sc 7, international organization for standardization and international electrotechnical commission, 1995.|\n|iso/iec 14598:1999|information technology - software product evaluation, joint technical committee iso/iec jtc 1, subcommittee sc 7, international organization for standardization and international electrotechnical commission, 1999.|\n|iso 14971-1:1998|medical devices - risk management - part 1: application of risk analysis. international organization for standardization, 1998.|\n|software considerations in airborne systems and equipment certification. special committee 167 of rtca. rtca inc., washington, d.c. tel: 202-833-9339. document no. rtca/do-178b, december 1992.| |\n|production process software references| |\n|the application of the principles of glp to computerized systems, environmental monograph #116, organization for economic cooperation and development (oecd), 1995.| |\n|george j. grigonis, jr., edward j. subak, jr., and michael wyrick, \"validation key practices for computer systems used in regulated operations,\" pharmaceutical technology, june 1997.| |\n|guide to inspection of computerized systems in drug processing, reference materials|page 38|", "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"}, "7ea144e1-68c4-4f87-bee9-486e3852533b": {"__data__": {"id_": "7ea144e1-68c4-4f87-bee9-486e3852533b", "embedding": null, "metadata": {"page_label": "43", "file_name": "[18] FDA General Principles of Software Validation -2002.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[18] FDA General Principles of Software Validation -2002.pdf", "file_type": "application/pdf", "file_size": 376042, "creation_date": "2024-04-07", "last_modified_date": "2024-03-28", "document_title": "Software Validation and Quality Assurance in the Pharmaceutical Industry: Ensuring Compliance and Safety", "questions_this_excerpt_can_answer": "1. What specific FDA training aids and resources were available in the early 1980s for investigators focusing on software validation within the pharmaceutical industry, and who were the key FDA offices and personnel involved in their development?\n\n2. Can you list the editions and parts of the GAMP guide that were relevant for the validation of automated systems in pharmaceutical manufacture as of March 1998, and describe the structure of its guidance?\n\n3. What are some key references and authors that were considered foundational for understanding general software quality and testing techniques in the pharmaceutical industry as of the mid-1990s, including specific books and their publication details?", "prev_section_summary": "The section provides a list of specific ISO standards referenced in the FDA's General Principles of Software Validation document from 2002 for ensuring quality management and assurance in software development and maintenance within regulated industries. It includes standards such as ISO 9000-3, ISO 13485, ISO/IEC 12119, and ISO 14971-1 related to quality management, software life cycle processes, medical devices, and risk management. The section also mentions guidance for industry and FDA staff, as well as references to software considerations in airborne systems and equipment certification. Additionally, it includes references to publications on the application of Good Laboratory Practices (GLP) to computerized systems and validation key practices for computer systems used in regulated operations.", "excerpt_keywords": "FDA, Software Validation, Pharmaceutical Industry, GAMP Guide, Quality Assurance"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[18] FDA General Principles of Software Validation -2002.pdf\n## guidance for industry and fda staff\n\ngeneral principles of software validation\n\ntraining aids for investigators, division of drug quality compliance, associate director for compliance, office of drugs, national center for drugs and biologics, & division of field investigations, associate director for field support, executive director of regional operations, food and drug administration, february 1983.\n\ndaniel p. olivier, \"validating process software\", fda investigator course: medical device process validation, food and drug administration.\n\ngamp guide for validation of automated systems in pharmaceutical manufacture, version v3.0, good automated manufacturing practice (gamp) forum, march 1998:\n\nvolume 1, part 1: user guide\npart 2: supplier guide\nvolume 2: best practice for user and suppliers\n\ntechnical report no. 18, validation of computer-related systems. pda committee on validation of computer-related systems. pda journal of pharmaceutical science and technology, volume 49, number 1, january-february 1995 supplement.\n\nvalidation compliance annual 1995, international validation forum, inc.\n\ngeneral software quality references\n\n- boris beizer, black box testing, techniques for functional testing of software and systems, john wiley & sons, 1995. isbn 0-471-12094-4.\n- boris beizer, software system testing and quality assurance, international thomson computer press, 1996. isbn 1-85032-821-8.\n- boris beizer, software testing techniques, second edition, van nostrand reinhold, 1990. isbn 0-442-20672-0.\n- richard bender, writing testable requirements, version 1.0, bender & associates, inc., larkspur, ca 94777, 1996.\n- frederick p. brooks, jr., the mythical man-month, essays on software engineering, addison-wesley longman, anniversary edition, 1995. isbn 0-201-83595-9.\n- silvana castano, et.al., database security, acm press, addison-wesley publishing company, 1995. isbn 0-201-59375-0.\n\ncomputerized data systems for nonclinical safety assessment, current concepts and quality assurance, drug information association, maple glen, pa, september 1988.\n\npage 39", "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"}, "a05ae93a-8328-40ea-9b12-302c33690e9f": {"__data__": {"id_": "a05ae93a-8328-40ea-9b12-302c33690e9f", "embedding": null, "metadata": {"page_label": "44", "file_name": "[18] FDA General Principles of Software Validation -2002.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[18] FDA General Principles of Software Validation -2002.pdf", "file_type": "application/pdf", "file_size": 376042, "creation_date": "2024-04-07", "last_modified_date": "2024-03-28", "document_title": "Software Validation and Quality Assurance: A Comprehensive Guide", "questions_this_excerpt_can_answer": "1. What are some key reference materials on software validation and quality assurance principles as recommended by the FDA in 2002?\n2. Can you list any publications that specifically address the integration of Total Quality Management (TQM) principles within computer software development, as recognized by the FDA's guidance on software validation?\n3. What resources does the FDA suggest for understanding the process of software inspection and its role in software validation and quality assurance, according to their 2002 guidelines?", "prev_section_summary": "This section provides information on the specific FDA training aids and resources available in the early 1980s for investigators focusing on software validation in the pharmaceutical industry. It also mentions key FDA offices and personnel involved in their development. Additionally, it lists the editions and parts of the GAMP guide relevant for the validation of automated systems in pharmaceutical manufacture as of March 1998, along with the structure of its guidance. The section also includes references and authors considered foundational for understanding general software quality and testing techniques in the pharmaceutical industry as of the mid-1990s, including specific books and their publication details.", "excerpt_keywords": "FDA, software validation, quality assurance, Total Quality Management, software inspection"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[18] FDA General Principles of Software Validation -2002.pdf\n|guidance for industry and fda staff|general principles of software validation|\n|---|---|\n|m. s. deutsch, software verification and validation, realistic project approaches, prentice hall, 1982.| |\n|robert h. dunn and richard s. ullman, tqm for computer software, second edition, mcgraw-hill, inc., 1994. isbn 0-07-018314-7.| |\n|elfriede dustin, jeff rashka, and john paul, automated software testing - introduction, management and performance, addison wesley longman, inc., 1999. isbn 0-201-43287-0.| |\n|robert g. ebenau and susan h. strauss, software inspection process, mcgraw-hill, 1994. isbn 0-07-062166-7.| |\n|richard e. fairley, software engineering concepts, mcgraw-hill publishing company, 1985. isbn 0-07-019902-7.| |\n|michael a. friedman and jeffrey m. voas, software assessment - reliability, safety, testability, wiley-interscience, john wiley & sons inc., 1995. isbn 0-471-01009-x.| |\n|tom gilb, dorothy graham, software inspection, addison-wesley publishing company, 1993. isbn 0-201-63181-4.| |\n|robert b. grady, practical software metrics for project management and process improvement, ptr prentice-hall inc., 1992. isbn 0-13-720384-5.| |\n|les hatton, safer c: developing software for high-integrity and safety-critical systems, mcgraw-hill book company, 1994. isbn 0-07-707640-0.| |\n|janis v. halvorsen, a software requirements specification document model for the medical device industry, proceedings ieee southeastcon 93, banking on technology, april 4th -7th, 1993, charlotte, north carolina.| |\n|debra s. herrmann, software safety and reliability: techniques, approaches and standards of key industrial sectors, ieee computer society, 1999. isbn 0-7695-0299-7.| |\n|bill hetzel, the complete guide to software testing, second edition, a wiley-qed publication, john wiley & sons, inc., 1988. isbn 0-471-56567-9.| |\n|watts s. humphrey, a discipline for software engineering. addison-wesley longman, 1995. isbn 0-201-54610-8.| |\n|watts s. humphrey, managing the software process, addison-wesley publishing company, 1989. isbn 0-201-18095-2.| |\n|capers jones, software quality, analysis and guidelines for success, international thomson computer press, 1997. isbn 1-85032-867-6.| |", "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"}, "87562596-0d7f-4b08-9274-66d18f98d156": {"__data__": {"id_": "87562596-0d7f-4b08-9274-66d18f98d156", "embedding": null, "metadata": {"page_label": "45", "file_name": "[18] FDA General Principles of Software Validation -2002.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[18] FDA General Principles of Software Validation -2002.pdf", "file_type": "application/pdf", "file_size": 376042, "creation_date": "2024-04-07", "last_modified_date": "2024-03-28", "document_title": "A Comprehensive Overview of Software Quality and Testing", "questions_this_excerpt_can_answer": "1. What are some key reference materials on software quality and testing that were published in the 1990s, as recognized by the FDA's General Principles of Software Validation document from 2002?\n\n2. Can you identify a resource that specifically addresses the topic of software validation within the context of medical device quality systems, as cited in a 2002 FDA document on software validation principles?\n\n3. What literature is available that combines the expertise of software quality engineering with the specific challenges faced by the healthcare manufacturing industries, according to a comprehensive overview provided by the FDA in 2002?", "prev_section_summary": "The section provides a list of key reference materials on software validation and quality assurance principles recommended by the FDA in 2002. It includes publications on software verification and validation, Total Quality Management (TQM) for computer software, automated software testing, software inspection process, software engineering concepts, software assessment, software metrics, software safety and reliability, software testing, and software engineering discipline and process management. These resources cover various aspects of software development, testing, quality assurance, and process improvement in the context of regulatory guidelines.", "excerpt_keywords": "Software Quality, Software Validation, FDA, Medical Device, Healthcare Manufacturing"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[18] FDA General Principles of Software Validation -2002.pdf\n|j.m. juran, frank m. gryna|quality planning and analysis, third edition, , mcgraw-hill, 1993. isbn 0-07-033183-9|\n|---|---|\n|stephen h. kan|metrics and models in software quality engineering, addison-wesley publishing company, 1995. isbn 0-201-63339-6|\n|cem kaner, jack falk, hung quoc nguyen|testing computer software, second edition, vsn nostrand reinhold, 1993. isbn 0-442-01361-2|\n|craig kaplan, ralph clark, victor tang|secrets of software quality, 40 innovations from ibm, mcgraw-hill, 1995. isbn 0-07-911795-3|\n|edward kit|software testing in the real world, addison-wesley longman, 1995. isbn 0-201-87756-2|\n|alan kusinitz|\"software validation\", current issues in medical device quality systems, association for the advancement of medical instrumentation, 1997. isbn 1-57020-075-0|\n|nancy g. leveson|safeware, system safety and computers, addison-wesley publishing company, 1995. isbn 0-201-11972-2|\n|michael r. lyu, editor|handbook of software reliability engineering, ieee computer society press, mcgraw-hill, 1996. isbn 0-07-039400-8|\n|steven r. mallory|software development and quality assurance for the healthcare manufacturing industries, interpharm press,inc., 1994. isbn 0-935184-58-9|\n|brian marick|the craft of software testing, prentice hall ptr, 1995. isbn 0-13-177411-5|\n|steve mcconnell|rapid development, microsoft press, 1996. isbn 1-55615-900-5|\n|glenford j. myers|the art of software testing, john wiley & sons, 1979. isbn 0-471-04328-1|\n|peter g. neumann|computer related risks, acm press/addison-wesley publishing co., 1995. isbn 0-201-55805-x|\n|daniel olivier|conducting software audits, auditing software for conformance to fda requirements, computer application specialists, san diego, ca, 1994|\n|william perry|effective methods for software testing, john wiley & sons, inc. 1995. isbn 0-471-06097-6|\n|william e. perry, randall w. rice|surviving the top ten challenges of software testing, dorset|", "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"}, "232b32e5-e840-4e1b-8747-6ab8c5a0fdb3": {"__data__": {"id_": "232b32e5-e840-4e1b-8747-6ab8c5a0fdb3", "embedding": null, "metadata": {"page_label": "46", "file_name": "[18] FDA General Principles of Software Validation -2002.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[18] FDA General Principles of Software Validation -2002.pdf", "file_type": "application/pdf", "file_size": 376042, "creation_date": "2024-04-07", "last_modified_date": "2024-03-28", "document_title": "Software Engineering and Validation: A Comprehensive Guide", "questions_this_excerpt_can_answer": "1. What are some recommended readings on software engineering and validation principles as per the FDA's guidance document from 2002?\n   \n2. Can you provide a list of publications that were considered authoritative in the field of software engineering and validation according to a comprehensive guide published by the FDA in 2002?\n\n3. What specific literature did the FDA recommend in 2002 for industry and staff to understand the general principles of software validation, including works on software engineering culture and software requirements?", "prev_section_summary": "The section provides a list of key reference materials on software quality and testing published in the 1990s, as recognized by the FDA's General Principles of Software Validation document from 2002. The list includes books on quality planning, metrics, testing, software reliability engineering, system safety, software development for healthcare manufacturing industries, software audits, and challenges of software testing. Authors such as J.M. Juran, Stephen H. Kan, Cem Kaner, and Nancy G. Leveson are mentioned, along with their respective publications. The section highlights the importance of software validation within the context of medical device quality systems and the expertise required to address the specific challenges faced by the healthcare manufacturing industries.", "excerpt_keywords": "FDA, software validation, software engineering, quality planning, software requirements"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[18] FDA General Principles of Software Validation -2002.pdf\n|guidance for industry and fda staff|general principles of software validation|\n|---|---|\n|house publishing, 1997. isbn 0-932633-38-2.| |\n|roger s. pressman|software engineering, a practitioners approach, third edition, mcgraw-hill inc., 1992. isbn 0-07-050814-3.|\n|roger s. pressman|a managers guide to software engineering, mcgraw-hill inc., 1993 isbn 0-07-050820-8.|\n|a. p. sage, j. d. palmer|software systems engineering, john wiley & sons, 1990.|\n|joc sanders, eugene curran|software quality, addison-wesley publishing co., 1994. isbn 0-201-63198-9.|\n|ken shumate, marilyn keller|software specification and design, a disciplined approach for real-time systems, john wiley & sons, 1992. isbn 0-471-53296-7.|\n|dennis d. smith|designing maintainable software, springer-verlag, 1999. isbn 0-387-98783-5.|\n|ian sommerville|software engineering, third edition, addison wesley publishing co., 1989. isbn 0-201-17568-1.|\n|karl e. wiegers|creating a software engineering culture, dorset house publishing, 1996. isbn 0-932633-33-1.|\n|karl e. wiegers|software inspection, improving quality with software inspections, software development, april 1995, pages 55-64.|\n|karl e. wiegers|software requirements, microsoft press, 1999. isbn 0-7356-0631-5.|\n\npage 42", "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"}, "13fc55a5-3203-44b3-b34a-b0ea0fb90908": {"__data__": {"id_": "13fc55a5-3203-44b3-b34a-b0ea0fb90908", "embedding": null, "metadata": {"page_label": "47", "file_name": "[18] FDA General Principles of Software Validation -2002.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[18] FDA General Principles of Software Validation -2002.pdf", "file_type": "application/pdf", "file_size": 376042, "creation_date": "2024-04-07", "last_modified_date": "2024-03-28", "document_title": "FDA Software Validation Guidance: Collaborative Efforts Across Various Offices and Teams", "questions_this_excerpt_can_answer": "1. Who were the key individuals from the Office of Device Evaluation involved in the development of the FDA's General Principles of Software Validation guidance document in 2002?\n   \n2. Which offices within the Center for Devices and Radiological Health contributed to the FDA Software Validation Guidance, and can you name at least one team member from each of those offices?\n\n3. How did the collaboration between the Center for Drug Evaluation and Research and the Center for Biologics Evaluation and Research manifest in the creation of the FDA Software Validation Guidance, specifically in terms of personnel contributions?", "prev_section_summary": "The section provides a list of recommended readings on software engineering and validation principles as per the FDA's guidance document from 2002. The list includes authoritative publications by authors such as Roger S. Pressman, A. P. Sage, Joc Sanders, Ken Shumate, Dennis D. Smith, Ian Sommerville, and Karl E. Wiegers. These works cover topics such as software engineering culture, software requirements, software quality, software systems engineering, and designing maintainable software. The section aims to guide industry and staff in understanding the general principles of software validation.", "excerpt_keywords": "FDA, software validation, guidance, Center for Devices and Radiological Health, collaboration"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[18] FDA General Principles of Software Validation -2002.pdf\n## guidance for industry and fda staff\n\n## general principles of software validation\n\n|center for devices and radiological health|development team|\n|---|---|\n|office of compliance|stewart crumpler|\n|office of device evaluation|james cheng, donna-bea tillman|\n|office of health and industry programs|bryan benesch, dick sawyer|\n|office of science and technology|john murray|\n|office of surveillance and biometrics|howard press|\n|center for drug evaluation and research|office of medical policy|charles snipes|\n|center for biologics evaluation and research|office of compliance and biologics quality|alice godziemski|\n|office of regulatory affairs|office of regional operations|david bergeson, joan loreng|", "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"}, "ff9b73b2-7320-4496-b74a-6a9cf8bf4004": {"__data__": {"id_": "ff9b73b2-7320-4496-b74a-6a9cf8bf4004", "embedding": null, "metadata": {"page_label": "1", "file_name": "[20] FDA Guidance-Computer-Software-Assurance - 2022.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[20] FDA Guidance-Computer-Software-Assurance - 2022.pdf", "file_type": "application/pdf", "file_size": 1042506, "creation_date": "2024-04-07", "last_modified_date": "2024-04-05", "document_title": "Guidance for Ensuring Computer Software Assurance in Production and Quality Systems", "questions_this_excerpt_can_answer": "1. What is the specific process for submitting comments and suggestions regarding the draft guidance on computer software assurance for production and quality system software issued by the FDA in 2022?\n   \n2. Who should industry members and FDA staff contact for questions related to the draft guidance on computer software assurance for CDRH-regulated devices and CBER-regulated devices?\n\n3. By when must comments and suggestions regarding the draft guidance on computer software assurance be submitted to the FDA, following its publication in the Federal Register?", "excerpt_keywords": "FDA, computer software assurance, production, quality system, draft guidance"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[20] FDA Guidance-Computer-Software-Assurance - 2022.pdf\n## draft - not for implementation\n\ncomputer software assurance for production and quality system software\n\ndraft guidance for industry and food and drug administration staff\n\ndraft guidance\n\nthis draft guidance document is being distributed for comment purposes only.\n\ndocument issued on september 13, 2022.\n\nyou should submit comments and suggestions regarding this draft document within 60 days of publication in the federal register of the notice announcing the availability of the draft guidance. submit electronic comments to https://www.regulations.gov. submit written comments to the dockets management staff, food and drug administration, 5630 fishers lane, room 1061, (hfa-305), rockville, md 20852. identify all comments with the docket number listed in the notice of availability that publishes in the federal register.\n\nfor questions about this document regarding cdrh-regulated devices, contact the compliance and quality staff at 301-796-5577 or by email at caseforquality@fda.hhs.gov. for questions about this document regarding cber-regulated devices, contact the office of communication, outreach, and development (ocod) at 1-800-835-4709 or 240-402-8010, or by email at ocod@fda.hhs.gov.\n\nfda\nu.s. department of health and human services\nfood and drug administration\ncenter for devices and radiological health\ncenter for biologics evaluation and research", "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"}, "746634bb-71f7-4ee9-b6dd-2f42f960a829": {"__data__": {"id_": "746634bb-71f7-4ee9-b6dd-2f42f960a829", "embedding": null, "metadata": {"page_label": "2", "file_name": "[20] FDA Guidance-Computer-Software-Assurance - 2022.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[20] FDA Guidance-Computer-Software-Assurance - 2022.pdf", "file_type": "application/pdf", "file_size": 1042506, "creation_date": "2024-04-07", "last_modified_date": "2024-04-05", "document_title": "Obtaining Additional Copies of FDA Guidance Documents: A Comprehensive Guide", "questions_this_excerpt_can_answer": "1. How can one obtain additional copies of FDA guidance documents related to computer software assurance as mentioned in the 2022 guidance document?\n   \n2. What specific contact information is provided for obtaining additional copies of guidance documents from the Center for Devices and Radiological Health (CDRH) and the Center for Biologics Evaluation and Research (CBER) as outlined in the 2022 FDA guidance document on computer software assurance?\n\n3. What is the document number required when requesting a copy of the FDA guidance on computer software assurance via email from CDRH, as specified in the 2022 guidance document?", "prev_section_summary": "The section provides information on the draft guidance for ensuring computer software assurance in production and quality systems issued by the FDA in 2022. It outlines the process for submitting comments and suggestions on the draft guidance, including the deadline for submission and contact information for industry members and FDA staff. The key entities mentioned in the section include the FDA, Center for Devices and Radiological Health (CDRH), and Center for Biologics Evaluation and Research (CBER).", "excerpt_keywords": "FDA, guidance documents, computer software assurance, CDRH, CBER"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[20] FDA Guidance-Computer-Software-Assurance - 2022.pdf\n|content|page number|\n|---|---|\n|additional copies|preface|\n|cdrh| |\n|additional copies are available from the internet. you may also send an email request to cdrh-guidance@fda.hhs.gov to receive a copy of the guidance. please include the document number 17045 and complete title of the guidance in the request.| |\n|cber| |\n|additional copies are available from the center for biologics evaluation and research (cber), office of communication, outreach, and development (ocod), 10903 new hampshire ave., bldg. 71, room 3128, silver spring, md 20993-0002, or by calling 1-800-835-4709 or 240-402-8010, by email, ocod@fda.hhs.gov or from the internet at https://www.fda.gov/vaccines-blood-biologics/guidance-compliance-regulatory-information-biologics/biologics-guidances.| |", "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"}, "4dc6054f-2844-4145-825f-65e24c27eb5f": {"__data__": {"id_": "4dc6054f-2844-4145-825f-65e24c27eb5f", "embedding": null, "metadata": {"page_label": "3", "file_name": "[20] FDA Guidance-Computer-Software-Assurance - 2022.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[20] FDA Guidance-Computer-Software-Assurance - 2022.pdf", "file_type": "application/pdf", "file_size": 1042506, "creation_date": "2024-04-07", "last_modified_date": "2024-04-05", "document_title": "\"Comprehensive Guide to Computer Software Assurance Risk Framework and Examples\"", "questions_this_excerpt_can_answer": "1. What specific steps does the FDA recommend for determining the appropriate computer software assurance activities based on a risk-based approach, as outlined in their 2022 guidance document?\n\n2. How does the FDA's 2022 guidance document on Computer Software Assurance suggest establishing records for assurance activities, and what examples are provided to illustrate this process?\n\n3. In the 2022 FDA guidance on Computer Software Assurance, how are different types of software systems like nonconformance management systems, learning management systems (LMS), and business intelligence applications treated in terms of risk framework and assurance activities?", "prev_section_summary": "The key topics of the section include obtaining additional copies of FDA guidance documents related to computer software assurance, specific contact information for obtaining copies from the Center for Devices and Radiological Health (CDRH) and the Center for Biologics Evaluation and Research (CBER), and the document number required when requesting a copy of the FDA guidance on computer software assurance via email from CDRH. The entities mentioned are CDRH, CBER, and the contact information provided for obtaining additional copies of guidance documents.", "excerpt_keywords": "FDA, Computer Software Assurance, Risk Framework, Guidance Document, Assurance Activities"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[20] FDA Guidance-Computer-Software-Assurance - 2022.pdf\n|content|page number|\n|---|---|\n|i. introduction|4|\n|ii. background|5|\n|iii. scope|6|\n|iv. computer software assurance|6|\n|v. computer software assurance risk framework|7|\n|identifying the intended use|7|\n|determining the risk-based approach|9|\n|determining the appropriate assurance activities|13|\n|establishing the appropriate record|16|\n|appendix a. examples|20|\n|example 1: nonconformance management system|20|\n|example 2: learning management system (lms)|23|\n|example 3: business intelligence applications|24|", "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"}, "aff89b04-d232-48e1-90ec-51830748192b": {"__data__": {"id_": "aff89b04-d232-48e1-90ec-51830748192b", "embedding": null, "metadata": {"page_label": "4", "file_name": "[20] FDA Guidance-Computer-Software-Assurance - 2022.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[20] FDA Guidance-Computer-Software-Assurance - 2022.pdf", "file_type": "application/pdf", "file_size": 1042506, "creation_date": "2024-04-07", "last_modified_date": "2024-04-05", "document_title": "Guidance on Computer Software Assurance for Production and Quality System Software in the Medical Device Industry", "questions_this_excerpt_can_answer": "1. What is the FDA's proposed approach for establishing confidence in the automation used for production or quality systems within the medical device industry, as outlined in the 2022 draft guidance document?\n\n2. How does the 2022 draft guidance on Computer Software Assurance for Production and Quality System Software intend to supplement or supersede existing FDA guidance on software validation, specifically regarding the validation of automated process equipment and quality system software?\n\n3. Which FDA centers and offices collaborated in the preparation of the 2022 draft guidance on Computer Software Assurance for Production and Quality System Software, and what are the recommended methods and testing activities to establish computer software assurance according to this document?", "prev_section_summary": "The section provides an overview of the FDA's 2022 guidance on Computer Software Assurance, focusing on the risk framework and examples provided. Key topics include determining appropriate assurance activities based on a risk-based approach, establishing records for assurance activities, and treating different types of software systems in terms of risk framework and assurance activities. The section also includes examples such as nonconformance management systems, learning management systems (LMS), and business intelligence applications to illustrate the concepts discussed.", "excerpt_keywords": "FDA, Computer Software Assurance, Medical Device Industry, Automation, Quality System Software"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[20] FDA Guidance-Computer-Software-Assurance - 2022.pdf\n# computer software assurance for production and quality system software\n\ndraft guidance for industry and food and drug administration staff\n\nthis draft guidance, when finalized, will represent the current thinking of the food and drug administration (fda or agency) on this topic. it does not establish any rights for any person and is not binding on fda or the public. you can use an alternative approach if it satisfies the requirements of the applicable statutes and regulations. to discuss an alternative approach, contact the fda staff or office responsible for this guidance as listed on the title page.\n\n## i. introduction\n\nfda is issuing this draft guidance to provide recommendations on computer software assurance for computers and automated data processing systems used as part of medical device production or the quality system. this draft guidance is intended to:\n\n- describe \"computer software assurance\" as a risk-based approach to establish confidence in the automation used for production or quality systems, and identify where additional rigor may be appropriate; and\n- describe various methods and testing activities that may be applied to establish computer software assurance and provide objective evidence to fulfill regulatory requirements, such as computer software validation requirements in 21 cfr part 820 (part 820).\n\nwhen final, this guidance will supplement fdas guidance, \"general principles of software validation\" (\"software validation guidance\") except this guidance will supersede section 6 (\"validation of automated process equipment and quality system software\") of the software validation guidance.\n\nthis guidance has been prepared by the center for devices and radiological health (cdrh) and the center for biologics evaluation and research (cber) in consultation with the center for drug evaluation and research (cder), office of combination products (ocp), and office of regulatory affairs (ora).\n\navailable at https://www.fda.gov/regulatory-information/search-fda-guidance-documents/general-principles-software-validation", "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"}, "aa3381d9-30f8-4edc-8757-035395aa746c": {"__data__": {"id_": "aa3381d9-30f8-4edc-8757-035395aa746c", "embedding": null, "metadata": {"page_label": "5", "file_name": "[20] FDA Guidance-Computer-Software-Assurance - 2022.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[20] FDA Guidance-Computer-Software-Assurance - 2022.pdf", "file_type": "application/pdf", "file_size": 1042506, "creation_date": "2024-04-07", "last_modified_date": "2024-04-05", "document_title": "FDA Guidance on Software Validation for Medical Device Manufacturing and Quality Control: Ensuring Compliance and Safety", "questions_this_excerpt_can_answer": "1. How does the FDA envision the future state of the medical device ecosystem in terms of product quality and patient safety, and what role does compliance with the Quality System Regulation, Part 820, play in achieving this vision?\n\n2. What specific requirements does the FDA's Quality System Regulation include for medical device manufacturers regarding the validation of computer software used as part of production or the quality system, as outlined in 21 CFR 820.70(i)?\n\n3. How has the FDA engaged with stakeholders and other industries to foster the adoption and use of advanced manufacturing technologies, such as automation and robotics, in the medical device manufacturing sector, and what are the expected benefits of these technologies for medical device quality, availability, and safety?", "prev_section_summary": "The section discusses the draft guidance on Computer Software Assurance for Production and Quality System Software in the Medical Device Industry issued by the FDA. Key topics covered include the definition of \"computer software assurance,\" methods and testing activities to establish confidence in automation used for production or quality systems, and the supplementing and superseding of existing FDA guidance on software validation. The section also mentions the collaboration of FDA centers and offices such as the Center for Devices and Radiological Health (CDRH), Center for Biologics Evaluation and Research (CBER), Center for Drug Evaluation and Research (CDER), Office of Combination Products (OCP), and Office of Regulatory Affairs (ORA) in preparing the draft guidance.", "excerpt_keywords": "FDA, Software Validation, Medical Device Manufacturing, Quality System Regulation, Automation"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[20] FDA Guidance-Computer-Software-Assurance - 2022.pdf\n## background\n\nfda envisions a future state where the medical device ecosystem is inherently focused on device features and manufacturing practices that promote product quality and patient safety. fda has sought to identify and promote successful manufacturing practices and help device manufacturers raise their manufacturing quality level. in doing so, one goal is to help manufacturers produce high-quality medical devices that align with the laws and regulations implemented by fda. compliance with the quality system regulation, part 820, is required for manufacturers of finished medical devices to the extent they engage in operations to which part 820 applies. the quality system regulation includes requirements for medical device manufacturers to develop, conduct, control, and monitor production processes to ensure that a device conforms to its specifications (21 cfr 820.70, production and process controls), including requirements for manufacturers to validate computer software used as part of production or the quality system for its intended use (see 21 cfr 820.70(i)). recommending best practices should promote product quality and patient safety, and correlate to higher-quality outcomes. this draft guidance addresses practices relating to computers and automated data processing systems used as part of production or the quality system.\n\nin recent years, advances in manufacturing technologies, including the adoption of automation, robotics, simulation, and other digital capabilities, have allowed manufacturers to reduce sources of error, optimize resources, and reduce patient risk. fda recognizes the potential for these technologies to provide significant benefits for enhancing the quality, availability, and safety of medical devices, and has undertaken several efforts to help foster the adoption and use of such technologies.\n\nspecifically, fda has engaged with stakeholders via the medical device innovation consortium (mdic), site visits to medical device manufacturers, and benchmarking efforts with other industries (e.g., automotive, consumer electronics) to keep abreast of the latest technologies and to better understand stakeholders challenges and opportunities for further advancement. as part of these ongoing efforts, medical device manufacturers have expressed a desire for greater clarity regarding the agencys expectations for software validation for computers and automated data processing systems used as part of production or the quality system. given the rapidly changing\n\navailable at https://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfstandards/search.cfm.\n\nthis guidance discusses the \"intended use\" of computer software used as part of production or the quality system (see 21 cfr 820.70(i)), which is different from the intended use of the device itself (see 21 cfr 801.4).", "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"}, "d9e3757c-c8cf-4602-b2fd-987d62a0b074": {"__data__": {"id_": "d9e3757c-c8cf-4602-b2fd-987d62a0b074", "embedding": null, "metadata": {"page_label": "6", "file_name": "[20] FDA Guidance-Computer-Software-Assurance - 2022.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[20] FDA Guidance-Computer-Software-Assurance - 2022.pdf", "file_type": "application/pdf", "file_size": 1042506, "creation_date": "2024-04-07", "last_modified_date": "2024-04-05", "document_title": "FDA Guidance on Risk-Based Computer Software Assurance for Medical Device Production and Quality Systems", "questions_this_excerpt_can_answer": "1. What approach does the FDA recommend for validating computer software used in medical device production or quality systems, according to the 2022 guidance document?\n   \n2. How does the FDA's 2022 guidance document differentiate between the validation requirements for computer software used in production or quality systems and the design verification or validation requirements for software in a medical device (SIMD) or software as a medical device (SAMD)?\n\n3. What specific aspects does the FDA's 2022 guidance on computer software assurance for medical device production and quality systems emphasize for manufacturers to focus on, in order to ensure product quality while complying with 21 CFR 820.70(i)?", "prev_section_summary": "The key topics of the section include the FDA's vision for the future state of the medical device ecosystem focusing on product quality and patient safety, compliance with the Quality System Regulation, requirements for validation of computer software in medical device manufacturing, and the adoption of advanced manufacturing technologies such as automation and robotics. Entities mentioned include the FDA, medical device manufacturers, stakeholders, the Medical Device Innovation Consortium (MDIC), and other industries like automotive and consumer electronics.", "excerpt_keywords": "FDA, Guidance, Computer Software Assurance, Medical Device, Quality Systems"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[20] FDA Guidance-Computer-Software-Assurance - 2022.pdf\n### draft - not for implementation\n\nnature of software, manufacturers have also expressed a desire for a more iterative, agile\n\napproach for validation of computer software used as part of production or the quality system.\n\ntraditionally, software validation has often been accomplished via software testing and other\n\nverification activities conducted at each stage of the software development lifecycle. however,\n\nas explained in fdas software validation guidance, software testing alone is often insufficient\n\nto establish confidence that the software is fit for its intended use. instead, the software\n\nvalidation guidance recommends that \"software quality assurance\" focus on preventing the\n\nintroduction of defects into the software development process, and it encourages use of a risk-\n\nbased approach for establishing confidence that software is fit for its intended use.\n\nfda believes that applying a risk-based approach to computer software used as part of\n\nproduction or the quality system would better focus manufacturers assurance activities to help\n\nensure product quality while helping to fulfill the validation requirements of 21 cfr 820.70(i).\n\nfor these reasons, fda is now providing recommendations on computer software assurance for\n\ncomputers and automated data processing systems used as part of medical device production or\n\nthe quality system. fda believes that these recommendations will help foster the adoption and\n\nuse of innovative technologies that promote patient access to high-quality medical devices\n\nand help manufacturers to keep pace with the dynamic, rapidly changing technology landscape, while\n\npromoting compliance with laws and regulations implemented by fda.\n\n### scope\n\nwhen final, this guidance is intended to provide recommendations regarding computer software\n\nassurance for computers or automated data processing systems used as part of production or the\n\nquality system.\n\nthis guidance is not intended to provide a complete description of all software validation\n\nprinciples. fda has previously outlined principles for software validation, including managing\n\nchanges as part of the software lifecycle, in fdas software validation guidance. this guidance\n\napplies the risk-based approach to software validation discussed in the software validation\n\nguidance to production or quality system software. this guidance additionally discusses specific\n\nrisk considerations, acceptable testing methods, and efficient generation of objective evidence\n\nfor production or quality system software.\n\nthis guidance does not provide recommendations for the design verification or validation\n\nrequirements specified in 21 cfr 820.30 when applied to software in a medical device (simd)\n\nor software as a medical device (samd). for more information regarding fdas\n\nrecommendations for design verification or validation of simd or samd, see the software\n\nvalidation guidance.\n\n### computer software assurance\n\ncomputer software assurance is a risk-based approach for establishing and maintaining\n\nconfidence that software is fit for its intended use. this approach considers the 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"}, "ac16f18b-5952-4285-bf29-33d054a8746b": {"__data__": {"id_": "ac16f18b-5952-4285-bf29-33d054a8746b", "embedding": null, "metadata": {"page_label": "7", "file_name": "[20] FDA Guidance-Computer-Software-Assurance - 2022.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[20] FDA Guidance-Computer-Software-Assurance - 2022.pdf", "file_type": "application/pdf", "file_size": 1042506, "creation_date": "2024-04-07", "last_modified_date": "2024-04-05", "document_title": "Comprehensive Software Assurance Risk Framework for Medical Device Manufacturers", "questions_this_excerpt_can_answer": "1. What is the FDA's approach to computer software assurance for medical device manufacturers, and how does it prioritize the validation efforts based on risk?\n   \n2. How does the FDA define the intended use of software within the context of production or the quality system for medical device manufacturers, and what are the two categories under which such software can fall?\n\n3. What specific examples of software uses are considered to be directly part of production or the quality system according to the FDA's guidance on computer software assurance for medical device manufacturers?", "prev_section_summary": "The section discusses the FDA's guidance on Risk-Based Computer Software Assurance for Medical Device Production and Quality Systems. Key topics include the need for a more iterative and agile approach for validating computer software, the importance of software quality assurance to prevent defects, the recommendation of a risk-based approach for establishing software fitness for use, and the focus on product quality while complying with regulations. The section also outlines the scope of the guidance, emphasizing recommendations for computer software assurance in production or quality systems, and differentiating from design verification or validation requirements for software in medical devices. Key entities mentioned include manufacturers, FDA, computer software, automated data processing systems, software validation principles, risk considerations, testing methods, and objective evidence generation.", "excerpt_keywords": "FDA, Computer Software Assurance, Medical Device Manufacturers, Risk-Based Approach, Software Validation"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[20] FDA Guidance-Computer-Software-Assurance - 2022.pdf\n## draft - not for implementation\n\n116 compromised safety and/or quality of the device (should the software fail to perform as intended)\n\nto determine the level of assurance effort and activities appropriate to establish confidence in the software. because the computer software assurance effort is risk-based, it follows a least-burdensome approach, where the burden of validation is no more than necessary to address the risk. such an approach supports the efficient use of resources, in turn promoting product quality.\n\nin addition, computer software assurance establishes and maintains that the software used in production or the quality system is in a state of control throughout its lifecycle (\"validated state\"). this is important because manufacturers increasingly rely on computers and automated processing systems to monitor and operate production, alert responsible personnel, and transfer and analyze production data, among other uses. by allowing manufacturers to leverage principles such as risk-based testing, unscripted testing, continuous performance monitoring, and data monitoring, as well as validation activities performed by other entities (e.g., developers, suppliers), the computer software assurance approach provides flexibility and agility in helping to assure that the software maintains a validated state consistent with 21 cfr 820.70(i).\n\nsoftware that is fit for its intended use and that maintains a validated state should perform as intended, helping to ensure that finished devices will be safe and effective and in compliance with regulatory requirements (see 21 cfr 820.1(a)(1)). section v below outlines a risk-based framework for computer software assurance.\n\n## v. computer software assurance risk framework\n\nthe following approach is intended to help manufacturers establish a risk-based framework for computer software assurance throughout the softwares lifecycle. examples of applying this risk framework to various computer software assurance situations are provided in appendix a.\n\n### identifying the intended use\n\nthe regulation requires manufacturers to validate software that is used as part of production or the quality system for its intended use (see 21 cfr 820.70(i)). to determine whether the requirement for validation applies, manufacturers must first determine whether the software is intended for use as part of production or the quality system.\n\nin general, software used as part of production or the quality system falls into one of two categories: software that is used directly as part of production or the quality system, and software that supports production or the quality system.\n\nsoftware with the following intended uses are considered to be used directly as part of production or the quality system:\n\n- software intended for automating production processes, inspection, testing, or the collection and processing of production data; and\n- software intended for automating quality system processes, collection and processing of quality system data, or maintaining a quality record established under the quality system regulation.", "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"}, "5a838fe5-99f9-4486-9ec4-e56c612cb705": {"__data__": {"id_": "5a838fe5-99f9-4486-9ec4-e56c612cb705", "embedding": null, "metadata": {"page_label": "8", "file_name": "[20] FDA Guidance-Computer-Software-Assurance - 2022.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[20] FDA Guidance-Computer-Software-Assurance - 2022.pdf", "file_type": "application/pdf", "file_size": 1042506, "creation_date": "2024-04-07", "last_modified_date": "2024-04-05", "document_title": "Software Intended Uses and Validation Requirements in Production and Quality Systems: A Comprehensive Guide", "questions_this_excerpt_can_answer": "1. What specific types of software does the FDA consider as part of production or the quality system, requiring validation under 21 CFR 820.70(i)?\n   \n2. How does the FDA suggest manufacturers approach validation for software with multiple features, functions, and operations that have different roles within production or the quality system?\n\n3. Can you provide an example of how a commercial off-the-shelf (COTS) spreadsheet software's basic input functions might be used within a manufacturing process, and explain why additional assurance activities might not be necessary beyond initial installation and configuration according to the FDA guidance?", "prev_section_summary": "This section discusses the FDA's approach to computer software assurance for medical device manufacturers, emphasizing a risk-based framework for validation efforts. It outlines the importance of ensuring software is fit for its intended use and maintains a validated state throughout its lifecycle. The section also defines the intended use of software within production or the quality system, categorizing software as either directly part of production/quality system or supporting it. Examples of software uses considered to be directly part of production/quality system are provided. The section highlights the need for manufacturers to validate software used in production or the quality system and outlines a risk-based framework for computer software assurance. Key entities mentioned include manufacturers, software developers, suppliers, and regulatory requirements under 21 CFR 820.70(i).", "excerpt_keywords": "FDA, software assurance, validation requirements, production systems, quality systems"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[20] FDA Guidance-Computer-Software-Assurance - 2022.pdf\n## software with intended uses\n\nsoftware with the following intended uses are considered to be used to support production or the quality system:\n\n- software intended for use as development tools that test or monitor software systems or that automate testing activities for the software used as part of production or the quality system, such as those used for developing and running scripts; and\n- software intended for automating general record-keeping that is not part of the quality record.\n\nboth kinds of software are used as \"part of\" production or the quality system and must be validated under 21 cfr 820.70(i). however, as further discussed below, supporting software often carries lower risk, such that under a risk-based computer software assurance approach, the effort of validation may be reduced accordingly without compromising safety.\n\non the other hand, software with the following intended uses generally are not considered to be used as part of production or the quality system, such that the requirement for validation in 21 cfr 820.70(i) would not apply:\n\n- software intended for management of general business processes or operations, such as email or accounting applications; and\n- software intended for establishing or supporting infrastructure not specific to production or the quality system, such as networking or continuity of operations.\n\nfda recognizes that software used in production or the quality system is often complex and comprised of several features, functions, and operations; software may have one or more intended uses depending on the individual features, functions, and operations of that software. in cases where the individual features, functions, and operations have different roles within production or the quality system, they may present different risks with different levels of validation effort. fda recommends that manufacturers examine the intended uses of the individual features, functions, and operations to facilitate development of a risk-based assurance strategy. manufacturers may decide to conduct different assurance activities for individual features, functions, or operations.\n\nfor example, a commercial off-the-shelf (cots) spreadsheet software may be comprised of various functions with different intended uses. when utilizing the basic input functions of the cots spreadsheet software for an intended use of documenting the time and temperature readings for a curing process, a manufacturer may not need to perform additional assurance activities beyond those conducted by the cots software developer and initial installation and configuration. the intended use of the software, \"documenting readings,\" only supports maintaining the quality system record and poses a low process risk. as such, initial 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"}, "4e17ff76-4641-4b99-bb41-dfe0e7c4f123": {"__data__": {"id_": "4e17ff76-4641-4b99-bb41-dfe0e7c4f123", "embedding": null, "metadata": {"page_label": "9", "file_name": "[20] FDA Guidance-Computer-Software-Assurance - 2022.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[20] FDA Guidance-Computer-Software-Assurance - 2022.pdf", "file_type": "application/pdf", "file_size": 1042506, "creation_date": "2024-04-07", "last_modified_date": "2024-04-05", "document_title": "\"Implementing a Risk-Based Approach for Computer Software Assurance in Production and Quality Systems\"", "questions_this_excerpt_can_answer": "1. How does the FDA's 2022 guidance differentiate between the risk analysis for computer software assurance in production or quality systems and the risk analysis for medical devices as described in ISO 14971:2019?\n   \n2. According to the FDA's 2022 guidance on computer software assurance, what factors should manufacturers consider when determining if additional validation is necessary for custom formulas created using COTS spreadsheet functions directly used in production or the quality system?\n\n3. What does the FDA's 2022 guidance recommend manufacturers document in their standard operating procedures (SOPs) regarding the use of software features, functions, or operations as part of production or the quality system?", "prev_section_summary": "The section discusses the types of software considered part of production or the quality system, the validation requirements under 21 CFR 820.70(i), and the approach recommended by the FDA for validating software with multiple features. It also provides examples of software intended uses that may or may not require additional assurance activities. Key topics include software intended uses, validation requirements, risk-based assurance approach, and examples of software applications in manufacturing processes. Key entities mentioned are software developers, manufacturers, and the FDA.", "excerpt_keywords": "FDA, guidance, computer software assurance, risk-based approach, validation"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[20] FDA Guidance-Computer-Software-Assurance - 2022.pdf\n## draft - not for implementation\n\n200 such as the vendor assessment and software installation and configuration may be sufficient to establish that the software is fit for its intended use and maintains a validated state. however, if a manufacturer utilizes built-in functions of the cots spreadsheet to create custom formulas that are directly used in production or the quality system, then additional risks may be present. for example, if a custom formula automatically calculates time and temperature statistics to monitor the performance and suitability of the curing process, then additional validation by the manufacturer might be necessary.\n\nfor the purposes of this guidance, we describe and recommend a computer software assurance framework by examining the intended uses of the individual features, functions, or operations of the software. however, in simple cases where software only has one intended use (e.g., if all of the features, functions, and operations within the software share the same intended use), manufacturers may not find it helpful to examine each feature, function, and operation individually. in such cases, manufacturers may develop a risk-based approach and consider assurance activities based on the intended use of the software overall.\n\nfda recommends that manufacturers document their decision-making process for determining whether a software feature, function, or operation is intended for use as part of production or the quality system in their standard operating procedures (sops).\n\n## determining the risk based approach\n\nonce a manufacturer has determined that a software feature, function, or operation is intended for use as part of production or the quality system, fda recommends using a risk-based analysis to determine appropriate assurance activities. broadly, this risk-based approach entails systematically identifying reasonably foreseeable software failures, determining whether such a failure poses a high process risk, and systematically selecting and performing assurance activities commensurate with the medical device or process risk, as applicable.\n\nnote that conducting a risk-based analysis for computer software assurance for production or quality system software is distinct from performing a risk analysis for a medical device as described in iso 14971:2019 - medical devices - application of risk management to medical devices. unlike the risks contemplated in iso 14971:2019 for analysis (medical device risks), failures of the production or the quality system software to perform as intended do not occur in a probabilistic manner where an assessment for the likelihood of occurrence for a particular risk could be estimated based on historical data or modeling.\n\ninstead, the risk-based analysis for production or quality system software considers those factors that may impact or prevent the software from performing as intended, such as proper system configuration and management, security of the system, data storage, data transfer, or operation error. thus, a risk-based analysis for production or quality system software should consider which failures are reasonably foreseeable (as opposed to likely) and the risks resulting from each such failure. this guidance discusses both process risks and medical device risks. a process risk refers to the potential to compromise production or the quality system. a medical device risk refers to the potential for a device to harm the patient or user. when discussing medical device", "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"}, "e3db4e10-b56e-4704-a81f-6f1daa19914b": {"__data__": {"id_": "e3db4e10-b56e-4704-a81f-6f1daa19914b", "embedding": null, "metadata": {"page_label": "10", "file_name": "[20] FDA Guidance-Computer-Software-Assurance - 2022.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[20] FDA Guidance-Computer-Software-Assurance - 2022.pdf", "file_type": "application/pdf", "file_size": 1042506, "creation_date": "2024-04-07", "last_modified_date": "2024-04-05", "document_title": "FDA Guidance on Identifying High Process Risk Software Features in Medical Devices", "questions_this_excerpt_can_answer": "1. What criteria does the FDA use to determine if a software feature, function, or operation in medical devices poses a high process risk in terms of compromising safety and quality?\n   \n2. Can you provide examples of software functionalities in medical devices that the FDA does not consider to pose a high process risk, particularly in relation to their impact on safety and quality?\n\n3. How does the FDA differentiate between software features that are critical for the safety and quality of medical devices and those that are less critical, according to the guidance on identifying high process risk software features?", "prev_section_summary": "The section discusses the FDA's 2022 guidance on implementing a risk-based approach for computer software assurance in production and quality systems. Key topics include differentiating risk analysis for software assurance from that for medical devices, factors for determining additional validation for custom formulas created using COTS spreadsheet functions, and documenting software features in standard operating procedures. The section also covers the risk-based approach recommended by the FDA, which involves identifying software failures, assessing process risks, and selecting assurance activities. It emphasizes that the risk analysis for production or quality system software is distinct from that for medical devices, focusing on factors that may impact software performance rather than probabilistic risks. The guidance addresses process risks and medical device risks, highlighting the importance of considering foreseeable failures and their potential impacts.", "excerpt_keywords": "FDA, Guidance, Computer Software Assurance, Medical Devices, Process Risk"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[20] FDA Guidance-Computer-Software-Assurance - 2022.pdf\n## draft - not for implementation\n\n244 risks, this guidance focuses on the medical device risk resulting from a quality problem that compromises safety.\n\nspecifically, fda considers a software feature, function, or operation to pose a high process risk when its failure to perform as intended may result in a quality problem that foreseeably compromises safety, meaning an increased medical device risk. this process risk identification step focuses only on the process, as opposed to the medical device risk posed to the patient or user. examples of software features, functions, or operations that are generally high process risk are those that:\n\n- maintain process parameters (e.g., temperature, pressure, or humidity) that affect the physical properties of product or manufacturing processes that are identified as essential to device safety or quality;\n- measure, inspect, analyze and/or determine acceptability of product or process with limited or no additional human awareness or review;\n- perform process corrections or adjustments of process parameters based on data monitoring or automated feedback from other process steps without additional human awareness or review;\n- produce directions for use or other labeling provided to patients and users that are necessary for safe operation of the medical device; and/or\n- automate surveillance, trending, or tracking of data that the manufacturer identifies as essential to device safety and quality.\n\nin contrast, fda considers a software feature, function, or operation not to pose a high process risk when its failure to perform as intended would not result in a quality problem that foreseeably compromises safety. this includes situations where failure to perform as intended would not result in a quality problem, as well as situations where failure to perform as intended may result in a quality problem that does not foreseeably lead to compromised safety. examples of software features, functions, or operations that generally are not high process risk include those that:\n\n- collect and record data from the process for monitoring and review purposes that do not have a direct impact on production or process performance;\n- are used as part of the quality system for corrective and preventive actions (capa) routing, automated logging/tracking of complaints, automated change control management, or automated procedure management;\n- are intended to manage data (process, store, and/or organize data), automate an existing calculation, increase process monitoring, or provide alerts when an exception occurs in an established process; and/or", "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"}, "a712a261-3dd2-40aa-a191-0fd341708228": {"__data__": {"id_": "a712a261-3dd2-40aa-a191-0fd341708228", "embedding": null, "metadata": {"page_label": "11", "file_name": "[20] FDA Guidance-Computer-Software-Assurance - 2022.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[20] FDA Guidance-Computer-Software-Assurance - 2022.pdf", "file_type": "application/pdf", "file_size": 1042506, "creation_date": "2024-04-07", "last_modified_date": "2024-04-05", "document_title": "Risk Assessment and Assurance Activities for Software in Production and Quality Systems: A Comprehensive Guide", "questions_this_excerpt_can_answer": "1. How does the FDA categorize the process risks associated with software used in production or quality systems, and what criteria determine the level of assurance activities required for each category?\n   \n2. What specific example does the FDA provide to illustrate a scenario where a software feature in an ERP management system is identified as having an intermediate (not high) process risk, and what factors contribute to this classification?\n\n3. In the context of automating material checks before their use in production within an ERP management system, how does the FDA differentiate between high process risk and not high process risk scenarios, and what implications does this differentiation have for the manufacturer's assurance activities?", "prev_section_summary": "The section discusses the criteria used by the FDA to determine high process risk software features in medical devices. It outlines examples of software functionalities that pose high process risk, such as maintaining process parameters, performing corrections based on data monitoring, and producing essential labeling for safe device operation. It also highlights software features that are not considered high process risk, including data collection for monitoring, quality system functions, and data management. The section emphasizes the importance of identifying software features critical for device safety and quality to mitigate risks.", "excerpt_keywords": "FDA, Software Assurance, Risk Assessment, Quality Systems, Process Risks"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[20] FDA Guidance-Computer-Software-Assurance - 2022.pdf\n## draft  - not for implementation\n\n* are used to support production or the quality system, as explained in section v.a. above.\n\nfda acknowledges that process risks associated with software used as part of production or the quality system are on a spectrum, ranging from high risk to low risk. manufacturers should determine the risk of each software feature, function, or operation as the risk falls on that spectrum, depending on the intended use of the software. however, fda is primarily concerned with the review and assurance for those software features, functions, and operations that are high process risk because a failure also poses a medical device risk. therefore, for the purposes of this guidance, fda is presenting the process risks in a binary manner, \"high process risk\" and \"not high process risk.\" a manufacturer may still determine that a process risk is, for example, \"moderate,\" \"intermediate,\" or even \"low\" for purposes of determining assurance activities; in such a case, the portions of this guidance concerning \"not high process risk\" would apply. as discussed in section v.c. below, assurance activities should be conducted for software that is \"high process risk\" and \"not high process risk\" commensurate with the risk.\n\nexample 1: an enterprise resource planning (erp) management system contains a feature that automates manufacturing material restocking. this feature ensures that the right materials are ordered and delivered to appropriate production operations. however, a qualified person checks the materials before their use in production. the failure of this feature to perform as intended may result in a mix-up in restocking and delivery, which would be a quality problem because the wrong materials would be restocked and delivered. however, the delivery of the wrong materials to the qualified person should result in the rejection of those materials before use in production; as such, the quality problem should not foreseeably lead to compromised safety. the manufacturer identifies this as an intermediate (not high) process risk and determines assurance activities commensurate with the process risk. the manufacturer already undertakes some of those identified assurance activities so implements only the remaining identified assurance activities.\n\nexample 2: a similar feature in another erp management system performs the same tasks as in the previous example except that it also automates checking the materials before their use in production. a qualified person does not check the material first. the manufacturer identifies this as a high process risk because the failure of the feature to perform as intended may result in a quality problem that foreseeably compromises safety. as such, the manufacturer will determine assurance activities that are commensurate with the related medical device risk. the manufacturer already undertakes some of those identified assurance activities so implements only the remaining identified assurance activities.\n\nexample 3: an erp management system contains a feature to automate product delivery. the medical device risk depends upon, among other factors, the correct product being delivered to the device user. a failure of this feature to perform as intended may result in a delivery mix-up, which would be a quality problem that foreseeably compromises safety; as such, the manufacturer identifies this as a high process risk. since the failure would compromise safety, the manufacturer will next determine the related increase in device risk and identify the assurance activities that are commensurate with the device risk. in this case, the manufacturer", "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"}, "a1cae6e8-8113-4f82-9098-be6a435dc3da": {"__data__": {"id_": "a1cae6e8-8113-4f82-9098-be6a435dc3da", "embedding": null, "metadata": {"page_label": "12", "file_name": "[20] FDA Guidance-Computer-Software-Assurance - 2022.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[20] FDA Guidance-Computer-Software-Assurance - 2022.pdf", "file_type": "application/pdf", "file_size": 1042506, "creation_date": "2024-04-07", "last_modified_date": "2024-04-05", "document_title": "FDA Guidance on Manufacturing Changes for Medical Devices", "questions_this_excerpt_can_answer": "1. What specific criteria does the FDA guidance outline for determining whether changes to manufacturing procedures or methods, including software changes, for medical devices subject to a PMA or HDE, should be submitted in a 30-day notice versus an annual report?\n   \n2. How does the FDA guidance classify the risk and required assurance activities for an automated graphical user interface (GUI) function used in production software for developing test scripts, in terms of its potential impact on the safety and effectiveness of a medical device?\n\n3. According to the FDA guidance, under what circumstances would changes to a Manufacturing Execution System (MES) that manages workflow, tracks progress, and records data in the production of medical devices be considered annually reportable, and when would such changes necessitate a 30-day notice due to their impact on the safety or effectiveness of the device?", "prev_section_summary": "The section discusses the categorization of process risks associated with software used in production or quality systems by the FDA, ranging from high risk to low risk. It emphasizes the need for assurance activities for software features, functions, and operations that pose high process risks, as they also pose a medical device risk. The FDA presents process risks as \"high process risk\" and \"not high process risk\" for the purpose of guidance. Examples are provided to illustrate scenarios where software features in ERP management systems are classified as intermediate or high process risk, highlighting the implications for assurance activities based on the level of risk. The differentiation between high process risk and not high process risk scenarios in automating material checks before production is also discussed, emphasizing the need for assurance activities commensurate with the level of risk.", "excerpt_keywords": "FDA, Guidance, Manufacturing Changes, Medical Devices, Software Assurance"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[20] FDA Guidance-Computer-Software-Assurance - 2022.pdf\n334 has not already implemented any of the identified assurance activities so implements all of the assurance activities identified in the analysis.\n\nexample 4: an automated graphical user interface (gui) function in the production software is used for developing test scripts based on user interactions and to automate future testing of modifications to the user interface of a system used in production. a failure of this gui function to perform as intended may result in implementation disruptions and delay updates to the production system, but in this case, these errors should not foreseeably lead to compromised safety because the gui function operates in a separate test environment. the manufacturer identifies this as a low (not high) process risk and determines assurance activities that are commensurate with the process risk. the manufacturer already undertakes some of those identified assurance activities so implements only the remaining identified assurance activities.\n\nas noted in fdas guidance, \"30-day notices, 135 day premarket approval (pma) supplements and 75-day humanitarian device exemption (hde) supplements for manufacturing method or process changes,\" for devices subject to a pma or hde, changes to the manufacturing procedure or method of manufacturing that do not affect the safety or effectiveness of the device must be submitted in a periodic report (usually referred to as an annual report). in contrast, modifications to manufacturing procedures or methods of manufacture that affect the safety and effectiveness of the device must be submitted in a 30-day notice. changes to the manufacturing procedure or method of manufacturing may include changes to software used in production or the quality system. for an addition or change to software used in production or the quality system of devices subject to a pma or hde, fda recommends that manufacturers apply the principles outlined above in determining whether the change may affect the safety or effectiveness of the device. in general, if a change may result in a quality problem that foreseeably compromises safety, then it should be submitted in a 30-day notice. if a change would not result in a quality problem that foreseeably compromises safety, an annual report may be appropriate.\n\nfor example, a manufacturing execution system (mes) may be used to manage workflow, track progress, record data, and establish alerts or thresholds based on validated parameters, which are part of maintaining the quality system. failure of such an mes to perform as intended may disrupt operations but not affect the process parameters established to produce a safe and effective device. changes affecting these mes operations are generally considered annually reportable. in contrast, an mes used to automatically control and adjust established critical production parameters (e.g., temperature, pressure, process time) may be a change to a manufacturing procedure that affects the safety or effectiveness of the device. if so, changes affecting this specific operation would require a 30-day notice.\n\navailable at https://www.fda.gov/regulatory-information/search-fda-guidance-documents/30-day-notices-135-day-premarket-approval-pma-supplements-and-75-day-humanitarian-device-exemption.\n\n1 cfr 814.39(b), 814.126(b)(1), and https://www.fda.gov/regulatory-information/search-fda-guidance-documents/annual-reports-approved-premarket-approval-applications-pma.\n\n2 cfr 814.39(b), 814.126(b)(1). changes in manufacturing/sterilization site or to design or performance specifications do not qualify for a 30-day notice.", "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"}, "745b610b-42be-4e16-88f7-6deb10a2931e": {"__data__": {"id_": "745b610b-42be-4e16-88f7-6deb10a2931e", "embedding": null, "metadata": {"page_label": "13", "file_name": "[20] FDA Guidance-Computer-Software-Assurance - 2022.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[20] FDA Guidance-Computer-Software-Assurance - 2022.pdf", "file_type": "application/pdf", "file_size": 1042506, "creation_date": "2024-04-07", "last_modified_date": "2024-04-05", "document_title": "Assurance Activities for Software Features in Medical Devices: A Comprehensive Guide", "questions_this_excerpt_can_answer": "1. How does the FDA Guidance document from 2022 define the relationship between the level of process risk associated with a software feature in medical devices and the required rigor of assurance activities?\n   \n2. What specific types of unscripted testing methods are recommended by the 2022 FDA Guidance document for manufacturers to use when conducting assurance activities for software features in medical devices, and how are these methods characterized?\n\n3. In the context of the 2022 FDA Guidance on Computer Software Assurance for medical devices, how should manufacturers differentiate between software features that pose a high process risk versus those that do not, and what implications does this differentiation have for the approach to assurance activities?", "prev_section_summary": "The section discusses the FDA guidance on manufacturing changes for medical devices, specifically focusing on determining when changes to manufacturing procedures or methods, including software changes, should be submitted in a 30-day notice versus an annual report for devices subject to a PMA or HDE. It also classifies the risk and required assurance activities for automated graphical user interface (GUI) functions used in production software and Manufacturing Execution Systems (MES) that manage workflow, track progress, and record data in the production of medical devices. The guidance provides criteria for determining the impact of changes on the safety and effectiveness of the device, outlining when changes necessitate a 30-day notice versus an annual report. The section emphasizes the importance of assessing potential risks and implementing appropriate assurance activities based on the impact of the changes on device safety and effectiveness.", "excerpt_keywords": "FDA Guidance, Computer Software Assurance, Medical Devices, Assurance Activities, Unscripted Testing"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[20] FDA Guidance-Computer-Software-Assurance - 2022.pdf\n## determining the appropriate assurance activities\n\nonce the manufacturer has determined whether a software feature, function, or operation poses a high process risk (a quality problem that may foreseeably compromise safety), the manufacturer should identify the assurance activities commensurate with the medical device risk or the process risk. in cases where the quality problem may foreseeably compromise safety (high process risk), the level of assurance should be commensurate with the medical device risk. in cases where the quality problem may not foreseeably compromise safety (not high process risk), the level of assurance rigor should be commensurate with the process risk. in either case, heightened risks of software features, functions, or operations generally entail greater rigor, i.e., a greater amount of objective evidence. conversely, relatively less risk (i.e., not high process risk) of compromised safety and/or quality generally entails less collection of objective evidence for the computer software assurance effort.\n\na feature, function, or operation that could lead to severe harm to a patient or user would generally be high device risk. in contrast, a feature, function, or operation that would not foreseeably lead to severe harm would likely not be high device risk. in either case, the risk of the softwares failure to perform as intended is commensurate with the resulting medical device risk.\n\nif the manufacturer instead determined that the software feature, function, or operation does not pose a high process risk (i.e., it would not lead to a quality problem that foreseeably compromises safety), the manufacturer should consider the risk relative to the process, i.e., production or the quality system. this is because the failure would not compromise safety, so the failure would not introduce additional medical device risk. for example, a function that collects and records process data for review would pose a lower process risk than a function that determines acceptability of product prior to human review.\n\ntypes of assurance activities commonly performed by manufacturers include, but are not limited to, the following:\n\n|unscripted testing|dynamic testing in which the testers actions are not prescribed by written instructions in a test case. it includes:|\n|---|---|\n|ad-hoc testing|a concept derived from unscripted practice that focuses primarily on performing testing that does not rely on large amounts of documentation (e.g., test procedures) to execute.|\n|error-guessing|a test design technique in which test cases are derived on the basis of the testers knowledge of past failures or general knowledge of failure modes.|", "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"}, "5a1ef3dc-6dd3-4508-8817-a271522530fd": {"__data__": {"id_": "5a1ef3dc-6dd3-4508-8817-a271522530fd", "embedding": null, "metadata": {"page_label": "14", "file_name": "[20] FDA Guidance-Computer-Software-Assurance - 2022.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[20] FDA Guidance-Computer-Software-Assurance - 2022.pdf", "file_type": "application/pdf", "file_size": 1042506, "creation_date": "2024-04-07", "last_modified_date": "2024-04-05", "document_title": "Risk-Based Testing and Assurance Activities in Software Development: A Comprehensive Guide", "questions_this_excerpt_can_answer": "1. What distinguishes exploratory testing from scripted testing in the context of FDA's guidance on computer software assurance for pharmaceutical software development?\n   \n2. How does the FDA guidance document define the approach for \"limited scripted testing\" and in what scenarios is it recommended for use in software assurance activities?\n\n3. According to the FDA guidance on computer software assurance, what factors should manufacturers consider when deciding on the appropriate assurance activities for software features, functions, and operations, especially in terms of risk management and quality system controls?", "prev_section_summary": "The section discusses the determination of appropriate assurance activities for software features in medical devices based on the level of process risk associated with them. It explains that assurance activities should be commensurate with the medical device risk or process risk, with higher risks requiring greater rigor in assurance. The differentiation between high process risk and not high process risk software features is highlighted, with implications for the approach to assurance activities. The section also mentions types of unscripted testing methods recommended by the FDA Guidance document for manufacturers to use, such as ad-hoc testing and error-guessing. Overall, the key topics include risk assessment, assurance activities, and unscripted testing methods in the context of software features in medical devices.", "excerpt_keywords": "exploratory testing, scripted testing, risk-based testing, assurance activities, software development"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[20] FDA Guidance-Computer-Software-Assurance - 2022.pdf\n## exploratory testing\n\nexperience-based testing in which the tester spontaneously designs and executes tests based on the testers existing relevant knowledge, prior exploration of the test item (including results from previous tests), and heuristic \"rules of thumb\" regarding common software behaviors and types of failure. exploratory testing looks for hidden properties, including hidden, unanticipated user behaviors, or accidental use situations that could interfere with other software properties being tested and could pose a risk of software failure.\n\n## scripted testing\n\ndynamic testing in which the testers actions are prescribed by written instructions in a test case. scripted testing includes both robust and limited scripted testing.\n\n### robust scripted testing\n\nscripted testing efforts in which the risk of the computer system or automation includes evidence of repeatability, traceability to requirements, and auditability.\n\n### limited scripted testing\n\na hybrid approach of scripted and unscripted testing that is appropriately scaled according to the risk of the computer system or automation. this approach may apply scripted testing for high-risk features or operations and unscripted testing for low- to medium-risk items as part of the same assurance effort.\n\nin general, fda recommends that manufacturers apply principles of risk-based testing in which the management, selection, prioritization, and use of testing activities and resources are consciously based on corresponding types and levels of analyzed risk to determine the appropriate activities. for high-risk software features, functions, and operations, manufacturers may choose to consider more rigor such as the use of scripted testing or limited scripted testing, as appropriate, when determining their assurance activities. in contrast, for software features, functions, and operations that are not high-risk, manufacturers may consider using unscripted testing methods such as ad-hoc testing, error-guessing, exploratory testing, or a combination of methods that is suitable for the risk of the intended use.\n\nwhen deciding on the appropriate assurance activities, manufacturers should consider whether there are any additional controls or mechanisms in place throughout the quality system that may decrease the impact of compromised safety and/or quality if failure of the software feature, function, or operation were to occur. for example, as part of a comprehensive assurance approach, manufacturers can leverage the following to reduce the effort of additional assurance activities:\n\n- activities, people, and established processes that provide control in production. such activities may include procedures to ensure integrity in the data supporting production or software quality assurance processes performed by other organizational units.", "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"}, "bfa6a3df-ceee-4812-8f90-721c58cff6f7": {"__data__": {"id_": "bfa6a3df-ceee-4812-8f90-721c58cff6f7", "embedding": null, "metadata": {"page_label": "15", "file_name": "[20] FDA Guidance-Computer-Software-Assurance - 2022.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[20] FDA Guidance-Computer-Software-Assurance - 2022.pdf", "file_type": "application/pdf", "file_size": 1042506, "creation_date": "2024-04-07", "last_modified_date": "2024-04-05", "document_title": "Enhancing Software Assurance through Established Processes and Controls: A Comprehensive Guide", "questions_this_excerpt_can_answer": "1. How does the FDA Guidance document suggest manufacturers can leverage existing validation work and electronic information performed by developers in the context of computer software assurance?\n   \n2. What role do process controls play in detecting and correcting quality problems related to software features, functions, or operations, according to the 2022 FDA Guidance on Computer Software Assurance?\n\n3. In what ways does the FDA Guidance document recommend collecting data and information for the purpose of monitoring software performance issues or deviations after implementation, and how can this influence the decision on assurance activities?", "prev_section_summary": "The section discusses the concepts of exploratory testing and scripted testing in the context of FDA's guidance on computer software assurance for pharmaceutical software development. It explains the differences between robust scripted testing and limited scripted testing, with a focus on risk-based testing principles. The section emphasizes the importance of considering risk levels when determining appropriate assurance activities for software features, functions, and operations, and suggests using a combination of testing methods based on the level of risk. Manufacturers are advised to assess additional controls and mechanisms within the quality system to mitigate the impact of software failures. Key entities include exploratory testing, scripted testing, risk-based testing, robust scripted testing, limited scripted testing, and quality system controls.", "excerpt_keywords": "FDA Guidance, Computer Software Assurance, Software Assurance, Process Controls, Quality System Controls"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[20] FDA Guidance-Computer-Software-Assurance - 2022.pdf\n## established purchasing control processes for selecting and monitoring software\n\nfor example, the manufacturer could incorporate the practices, validation work, and electronic information already performed by developers of the software as the starting point and determine what additional activities may be needed. for some lower-risk software features, functions, and operations, this may be all the assurance that is needed by the manufacturer.\n\n## additional process controls throughout production\n\nfor example, if a process is fully understood, all critical process parameters are monitored, and/or all outputs of a process undergo verification testing, these controls can serve as additional mechanisms to detect and correct the occurrence of quality problems that may occur if a software feature, function, or operation were to fail to perform as intended. in this example, the presence of these controls can be leveraged to reduce the effort of assurance activities appropriate for the software.\n\n## data and information collection for monitoring software\n\nthe data and information periodically or continuously collected by the software for the purposes of monitoring or detecting issues and anomalies in the software after implementation of the software. the capability to monitor and detect performance issues or deviations and system errors may reduce the risk associated with a failure of the software to perform as intended and may be considered when deciding on assurance activities.\n\n## use of computer system validation tools\n\nthe use of computer system validation tools (e.g., bug tracker, automated testing) for the assurance of software used in production or as part of the quality system whenever possible.\n\n## testing in iterative cycles throughout the software lifecycle\n\nthe use of testing done in iterative cycles and continuously throughout the lifecycle of the software used in production or as part of the quality system.\n\nfor example, supporting software, as referenced in section v.a., often carries lower risk, such that the assurance effort may generally be reduced accordingly. because assurance activities used \"directly\" in production or the quality system often inherently cover the performance of supporting software, assurance that this supporting software performs as intended may be sufficiently established by leveraging vendor validation records, software installation, or software configuration, such that additional assurance activities (e.g., scripted or unscripted testing) may be unnecessary.\n\nmanufacturers are responsible for determining the appropriate assurance activities for ensuring the software features, functions, or operations maintain a validated state. the assurance activities and considerations noted above are some possible ways of providing assurance and are not intended to be prescriptive or exhaustive. manufacturers may leverage any of the activities or a combination of activities that are most appropriate for risk associated with the 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"}, "5fabf202-e8f9-4d31-85bd-f1da6a652e06": {"__data__": {"id_": "5fabf202-e8f9-4d31-85bd-f1da6a652e06", "embedding": null, "metadata": {"page_label": "16", "file_name": "[20] FDA Guidance-Computer-Software-Assurance - 2022.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[20] FDA Guidance-Computer-Software-Assurance - 2022.pdf", "file_type": "application/pdf", "file_size": 1042506, "creation_date": "2024-04-07", "last_modified_date": "2024-04-05", "document_title": "Software Assurance Activities Record Keeping and Documentation Plan", "questions_this_excerpt_can_answer": "1. What specific elements should be included in the record to demonstrate that a software feature, function, or operation has been adequately assessed according to the FDA's guidance on computer software assurance provided in 2022?\n   \n2. How does the FDA's 2022 guidance on computer software assurance recommend handling the documentation of assurance activities, particularly in terms of the level of detail required and the approach to documenting risk determination and testing outcomes?\n\n3. According to the FDA's 2022 guidance document on computer software assurance, what are the recommended practices for establishing review and approval processes for software testing and assessment records, including the requirements for signatory authority?", "prev_section_summary": "The section discusses the importance of established processes and controls in enhancing software assurance, particularly in the context of computer software used in production or as part of the quality system. Key topics include leveraging existing validation work and electronic information, utilizing process controls for detecting and correcting quality problems, collecting data for monitoring software performance issues, using computer system validation tools, and testing in iterative cycles throughout the software lifecycle. The section emphasizes the need for manufacturers to determine appropriate assurance activities based on the risk associated with the software's intended use.", "excerpt_keywords": "Software Assurance, Record Keeping, Documentation Plan, FDA Guidance, Computer Software"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[20] FDA Guidance-Computer-Software-Assurance - 2022.pdf\n## establishing the appropriate record\n\nwhen establishing the record, the manufacturer should capture sufficient objective evidence to demonstrate that the software feature, function, or operation was assessed and performs as intended. in general, the record should include the following:\n\n- the intended use of the software feature, function, or operation;\n- the determination of risk of the software feature, function, or operation;\n- documentation of the assurance activities conducted, including:\n- description of the testing conducted based on the assurance activity;\n- issues found (e.g., deviations, failures) and the disposition;\n- conclusion statement declaring acceptability of the results;\n- the date of testing/assessment and the name of the person who conducted the testing/assessment;\n- established review and approval when appropriate (e.g., when necessary, a signature and date of an individual with signatory authority)\n\ndocumentation of assurance activities need not include more evidence than necessary to show that the software feature, function, or operation performs as intended for the risk identified. fda recommends the record retain sufficient details of the assurance activity to serve as a baseline for improvements or as a reference point if issues occur.\n\ntable 1 provides some examples of ways to implement and develop the record when using the risk-based testing approaches identified in section v.c. above. manufacturers may use alternative approaches and provide different documentation so long as their approach satisfies applicable legal documentation requirements.\n\n|assurance activity|test plan|test results|record (including digital)|\n|---|---|---|---|\n|scripted testing:|test objectives test cases (step-by-step procedure) expected results independent review and approval of test cases|pass/fail for test case details regarding any failures/deviations found|intended use risk determination detailed report of testing performed pass/fail result for each test case issues found and disposition conclusion statement record of who performed testing and date established review and approval when appropriate|\n|robust testing:|test objectives test cases (step-by-step procedure) expected results independent review and approval of test cases|pass/fail for test case details regarding any failures/deviations found|intended use risk determination detailed report of testing performed pass/fail result for each test case issues found and disposition conclusion statement record of who performed testing and date established review and approval when appropriate|\n\nfor the quality system regulations general requirements for records, including record retention period, see 21 cfr 820.180.", "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"}, "3457606a-d4e2-421d-8309-d34efcc86449": {"__data__": {"id_": "3457606a-d4e2-421d-8309-d34efcc86449", "embedding": null, "metadata": {"page_label": "17", "file_name": "[20] FDA Guidance-Computer-Software-Assurance - 2022.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[20] FDA Guidance-Computer-Software-Assurance - 2022.pdf", "file_type": "application/pdf", "file_size": 1042506, "creation_date": "2024-04-07", "last_modified_date": "2024-04-05", "document_title": "Assurance Activity Test Plan and Results Record for Scripted and Unscripted Testing", "questions_this_excerpt_can_answer": "1. What are the key differences between scripted and unscripted testing as outlined in the FDA Guidance-Computer-Software-Assurance document from 2022?\n   \n2. How does the FDA Guidance-Computer-Software-Assurance document from 2022 recommend documenting the results and review process for both scripted and unscripted testing of software in the pharmaceutical industry?\n\n3. What specific information does the FDA Guidance-Computer-Software-Assurance document from 2022 require to be included in the test results record for unscripted testing of failure-modes, and how does this differ from the documentation requirements for testing of features and functions?", "prev_section_summary": "This section discusses the importance of establishing appropriate records for software assurance activities in accordance with the FDA's guidance on computer software assurance provided in 2022. Key topics include capturing objective evidence to demonstrate software assessment, documenting risk determination, conducting assurance activities, and establishing review and approval processes. The section emphasizes the need for sufficient detail in documentation to show that software features perform as intended and meet identified risks. Examples of implementing and developing records using risk-based testing approaches are provided, along with recommendations for record retention in compliance with quality system regulations. Key entities mentioned include manufacturers, individuals conducting testing/assessment, and those with signatory authority for review and approval.", "excerpt_keywords": "FDA, Guidance, Computer Software Assurance, Test Plan, Unscripted Testing"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[20] FDA Guidance-Computer-Software-Assurance - 2022.pdf\n|assurance activity|test plan|test results|record|\n|---|---|---|---|\n|scripted testing:|- limited test cases (step-by-step procedure) identified\n- expected results for the test cases\n- identify unscripted testing applied\n- independent review and approval of test plan\n|- pass/fail for test case identified\n- details regarding any failures/deviations found\n- pass/fail test result for each test case\n- issues found and disposition\n- conclusion statement\n|- intended use\n- risk determination\n- summary description of testing performed\n- record of who performed testing and date\n- established review and approval when appropriate\n|\n|unscripted testing:|- testing of features and functions with no test plan\n|- details regarding any failures/deviations found\n- intended use\n- risk determination\n- summary description of features and functions tested and testing performed\n- issues found and disposition\n- conclusion statement\n- record of who performed testing and date of testing\n- established review and approval when appropriate\n| |\n|unscripted testing:|- testing of failure-modes with no test plan\n|- details regarding any failures/deviations found\n- intended use\n- risk determination\n- summary description of failure-modes tested and testing performed\n- issues found and disposition\n- conclusion statement\n- record of who performed testing and date of testing\n- established review and approval when appropriate\n| |\n|unscripted testing:|- establish high level test plan objectives (no step-by-step procedure is necessary)\n|- pass/fail for each test plan objective\n- details regarding any failures/deviations found\n- pass/fail test result for each objective\n- issues found and disposition\n- conclusion statement\n- record of who performed testing and date of testing\n- established review and approval when appropriate\n| |", "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"}, "8782c439-78a6-4b4f-a3de-f52478789633": {"__data__": {"id_": "8782c439-78a6-4b4f-a3de-f52478789633", "embedding": null, "metadata": {"page_label": "18", "file_name": "[20] FDA Guidance-Computer-Software-Assurance - 2022.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[20] FDA Guidance-Computer-Software-Assurance - 2022.pdf", "file_type": "application/pdf", "file_size": 1042506, "creation_date": "2024-04-07", "last_modified_date": "2024-04-05", "document_title": "Record of Assurance for Nonconformance Data Spreadsheet Testing", "questions_this_excerpt_can_answer": "1. What specific testing methodology was employed to assess the functionality of the spreadsheet designed for collecting and graphing nonconformance data in a controlled system, and what was the primary goal of this testing?\n   \n2. How did the manufacturer address the deviation encountered during the update testing of the spreadsheet, and what measures were taken to prevent similar issues from affecting the spreadsheet's intended use for monitoring purposes?\n\n3. In the context of the FDA Guidance on Computer Software Assurance for 2022, how is the risk associated with the spreadsheet's failure to perform as intended evaluated, and what criteria determine whether the software poses a high process risk in terms of compromising safety or quality?", "prev_section_summary": "The section discusses the differences between scripted and unscripted testing in the FDA Guidance-Computer-Software-Assurance document from 2022. It outlines the key elements of a test plan and test results record for both types of testing, including the identification of test cases, expected results, independent review and approval, pass/fail criteria, details of failures/deviations, intended use, risk determination, summary description of testing performed, issues found and disposition, conclusion statement, and record of testing personnel and dates. The document also specifies the documentation requirements for testing failure-modes in unscripted testing compared to testing features and functions. Key entities mentioned include assurance activities, test plans, test results records, scripted testing, unscripted testing, failure-modes, test objectives, and review and approval processes.", "excerpt_keywords": "FDA Guidance, Computer Software Assurance, Spreadsheet Testing, Nonconformance Data, Risk Evaluation"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[20] FDA Guidance-Computer-Software-Assurance - 2022.pdf\n## draft  -  not for implementation\n\n529  the following       is an  example     of a  record of assurance in a scenario where a manufacturer has\n\n530  developed a spreadsheet with the intended use of                 collecting    and graphing nonconformance data\n\n531  stored in a controlled system          for monitoring purposes.          in this example, the manufacturer has\n\n532  established     additional process controls and inspections that ensure non-conforming product is                            not\n\n533  released.    in this case,   failure of the spreadsheet to perform as intended                would    not result in a\n\n534  quality problem that        foreseeably     leads  to compromised safety,          so  the spreadsheet would not          pose\n\n535  a high   process    risk. the manufacturer conducted rapid exploratory testing of specific functions\n\n536  used in the spreadsheet to ensure that analyses can be created, read, updated, and/or deleted.\n\n537  during    exploratory     testing,   all calculated fields updated correctly           except for    one   deviation that\n\n538  occurred during       update testing.     in this scenario, the record would be documented as follows:\n\n- intended use:        the spreadsheet is intended for use in            collecting    and graphing nonconformance data stored in a controlled system                   for monitoring purposes; as such, it is used as part of production or the quality system.                because of this use, the spreadsheet is different from similar software used for business operations such                      as  for  accounting.\n- risk-based       analysis:     in this case, the software is only used to collect and display data for monitoring nonconformances,              and   the manufacturer has established additional process controls and inspections to ensure that nonconforming product is                       not released. therefore, failure of the spreadsheet to perform as intended                should   not  result in a quality problem that foreseeably leads to        compromised safety. as such, the software                does   not  pose a    high process    risk, and the assurance activities should be             commensurate with the process risk.\n- tested:    spreadsheet x, version 1.2\n- test type:     unscripted testing       - exploratory testing\n- goal:     ensure that analyses can be          correctly   created,   read,   updated, and     deleted\n- testing objectives and activities:\n- create new analysis        -  passed\n- read data from the required source             -  passed\n- update data in the analysis         -  failed due to input error, then passed\n- delete data     - passed\n- verify through observation that all calculated fields correctly update with changes\n-  passed with noted deviation\n- deviation:      during update      testing,   when the    user   inadvertently     input text into    an updatable     field  requiring   numeric data,      the associated row showed           an  immediate error.\n- conclusion:       no errors    were observed       in the  spreadsheet functions beyond the             deviation. incorrectly    inputting    text into the field     is immediately visible and         does not impact the risk of the intended use. in addition, a validation rule was placed on the field to permit                        only numeric data inputs.", "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"}, "a18a19fb-d9d4-475e-b932-6b991968ee29": {"__data__": {"id_": "a18a19fb-d9d4-475e-b932-6b991968ee29", "embedding": null, "metadata": {"page_label": "19", "file_name": "[20] FDA Guidance-Computer-Software-Assurance - 2022.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[20] FDA Guidance-Computer-Software-Assurance - 2022.pdf", "file_type": "application/pdf", "file_size": 1042506, "creation_date": "2024-04-07", "last_modified_date": "2024-04-05", "document_title": "FDA Recommendations for Electronic Records Management in Manufacturing and Quality Systems", "questions_this_excerpt_can_answer": "1. How does the FDA recommend manufacturers document their assurance activities in the context of advances in digital technology, and what specific types of electronic records are suggested as preferable to paper documentation?\n   \n2. What is the FDA's stance on the application of Part 11, electronic records; electronic signatures, in relation to computers or automated data processing systems used within production or quality systems, and under what conditions does the agency intend to exercise enforcement discretion regarding Part 11 requirements?\n\n3. In the scenario where a document required under Part 820 is maintained in electronic form as part of production or the quality system, under what circumstances would it be considered an \"electronic record\" as per Part 11, and can you provide an example of when Part 11 would apply to such a document?", "prev_section_summary": "The section discusses a scenario where a manufacturer developed a spreadsheet for collecting and graphing nonconformance data in a controlled system for monitoring purposes. The manufacturer conducted exploratory testing to ensure the spreadsheet's functionality, with a focus on creating, reading, updating, and deleting analyses. A deviation was encountered during update testing, but measures were taken to address it, such as placing validation rules on input fields. The risk associated with the spreadsheet's failure to perform as intended was evaluated, and it was determined that the software does not pose a high process risk as it does not compromise safety or quality. The manufacturer established additional process controls to prevent the release of nonconforming products. The section emphasizes the importance of assurance activities being commensurate with the process risk.", "excerpt_keywords": "FDA, electronic records, Part 11, computer software, quality systems"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[20] FDA Guidance-Computer-Software-Assurance - 2022.pdf\n## advances in digital technology\n\nmay allow for manufacturers to leverage automated traceability, testing, and the electronic capture of work performed to document the results, reducing the need for manual or paper-based documentation. as a least burdensome method, fda recommends the use of electronic records, such as system logs, audit trails, and other data generated by the software, as opposed to paper documentation and screenshots, in establishing the record associated with the assurance activities.\n\nmanufacturers have expressed confusion and concern regarding the application of part 11, electronic records; electronic signatures, to computers or automated data processing systems used as part of production or the quality system. as described in the \"part 11, electronic records; electronic signatures - scope and application\" guidance, the agency intends to exercise enforcement discretion regarding part 11 requirements for validation of computerized systems used to create, modify, maintain, or transmit electronic records (see 21 cfr 11.10(a) and 11.30). in general, 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 (see 21 cfr 11.1(b)). part 11 also applies to electronic records submitted to the agency under requirements of the federal food, drug, and cosmetic act (fd&c act) and the public health service act (phs act), even if such records are not specifically identified in agency regulations (see 21 cfr 11.1(b)).\n\nin the context of computer or automated data processing systems, for computer software used as part of production or the quality system, a document required under part 820 and maintained in electronic form would generally be an \"electronic record\" within the meaning of part 11 (see 21 cfr 11.3(b)(6)). for example, if a document requires a signature under part 820 and is maintained in electronic form, then part 11 applies (see, e.g., 21 cfr 820.40 (requiring signatures for control of required documents)).", "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"}, "328fd0aa-21fe-4b29-a3f8-2a152162517e": {"__data__": {"id_": "328fd0aa-21fe-4b29-a3f8-2a152162517e", "embedding": null, "metadata": {"page_label": "20", "file_name": "[20] FDA Guidance-Computer-Software-Assurance - 2022.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[20] FDA Guidance-Computer-Software-Assurance - 2022.pdf", "file_type": "application/pdf", "file_size": 1042506, "creation_date": "2024-04-07", "last_modified_date": "2024-04-05", "document_title": "Risk-Based Assurance Strategy for Nonconformance Management System: A Comprehensive Approach to Quality Assurance and Risk Management.", "questions_this_excerpt_can_answer": "1. What specific risk-based analysis approach does the manufacturer use for the nonconformance (NC) initiation operations in the context of implementing COTS software for automating their nonconformance process?\n   \n2. How does the manufacturer ensure the intended use of the nonconformance initiation operations is met, and what specific assurance activities are conducted to validate the performance of these operations according to the FDA Guidance-Computer-Software-Assurance - 2022?\n\n3. Can you detail the criteria and process used by the manufacturer to document the assessment and testing outcomes of the nonconformance initiation operations as outlined in the Risk-Based Assurance Strategy for Nonconformance Management System section of the FDA guidance document?", "prev_section_summary": "The key topics of this section include the FDA's recommendations for electronic records management in manufacturing and quality systems, the use of electronic records over paper documentation, the application of Part 11 (electronic records; electronic signatures) to computer software used in production or quality systems, and the circumstances under which Part 11 requirements apply to electronic records. The entities mentioned in the section are manufacturers, FDA, computer or automated data processing systems, electronic records, and Part 11 regulations.", "excerpt_keywords": "FDA, Guidance, Computer Software Assurance, Risk-Based, Nonconformance Management System"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[20] FDA Guidance-Computer-Software-Assurance - 2022.pdf\n## appendix a. examples\n\nthe examples in this section outline possible application of the principles in this draft guidance to various software assurance situations cases.\n\nexample 1: nonconformance management system\n\na manufacturer has purchased cots software for automating their nonconformance process and is applying a risk-based approach for computer software assurance in its implementation. the software is intended to manage the nonconformance process electronically. the following features, functions, or operations were considered by the manufacturer in developing a risk-based assurance strategy:\n\n|features, functions, or operations|intended use of the features, functions or operations|risk-based analysis|assurance activities|\n|---|---|---|---|\n|nonconformance (nc) initiation operations:|the intended uses of the operations are to manage the workflow of the nonconformance and to error-proof the workflow to facilitate the work and a complete quality record.|failure of the nc initiation operation to perform as intended may delay the initiation workflow, but would not result in a quality problem that foreseeably compromises safety as the manufacturer has additional processes in place for containment of non-conforming product. as such, the manufacturer determined the nc initiation operations did not pose a high process risk.|the manufacturer has performed an assessment of the system capability, supplier evaluation, and installation activities. in addition, the manufacturer supplements these activities with exploratory testing of the operations. high-level objectives for testing are established to meet the intended use and no unanticipated failures occur. the manufacturer documents: - the intended use\n- risk determination, summary description of the features, functions, operations tested\n- the testing objectives and if they passed or failed\n- any issues found and their disposition\n- a concluding statement noting that the performance of the operation is acceptable\n- the date testing was performed, and who performed the testing.\n|", "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"}, "2f851409-7b3c-4340-8804-1357dedd4206": {"__data__": {"id_": "2f851409-7b3c-4340-8804-1357dedd4206", "embedding": null, "metadata": {"page_label": "21", "file_name": "[20] FDA Guidance-Computer-Software-Assurance - 2022.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[20] FDA Guidance-Computer-Software-Assurance - 2022.pdf", "file_type": "application/pdf", "file_size": 1042506, "creation_date": "2024-04-07", "last_modified_date": "2024-04-05", "document_title": "Assurance Activities and Risk Analysis for Electronic Signature Function", "questions_this_excerpt_can_answer": "1. What specific elements are included in the execution record of an electronic signature according to the 2022 FDA Guidance on Computer Software Assurance?\n   \n2. How does the 2022 FDA Guidance document describe the risk associated with the failure of the electronic signature function in pharmaceutical manufacturing or quality system records?\n\n3. What assurance activities are recommended by the 2022 FDA Guidance for ensuring that the electronic signature function meets regulatory requirements and its intended use within pharmaceutical environments?", "prev_section_summary": "The section discusses the risk-based assurance strategy for a nonconformance management system, specifically focusing on the implementation of COTS software for automating nonconformance processes. It outlines the manufacturer's approach to analyzing and ensuring the intended use of nonconformance initiation operations, as well as the assurance activities conducted to validate their performance. The criteria and process used by the manufacturer to document assessment and testing outcomes are also detailed. The section includes an example of applying these principles in a nonconformance management system scenario, highlighting the features, functions, and operations considered, along with the risk-based analysis and assurance activities undertaken. Key entities include nonconformance initiation operations, intended use, risk determination, testing objectives, issues found, and performance acceptance criteria.", "excerpt_keywords": "FDA, Guidance, Computer Software Assurance, Electronic Signature, Risk Analysis"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[20] FDA Guidance-Computer-Software-Assurance - 2022.pdf\n## features, functions, or operations\n\n|intended use of the features, functions or operations|risk-based analysis|assurance activities|\n|---|---|---|\n|electronic signature function:| | |\n|- the electronic signature execution record is stored as part of the audit trail.\n- the electronic signature employs two distinct identification components of a login and password.\n- when an electronic signature is executed, the following information is part of the execution record: - the name of the person who signs the record\n- the date (dd-mm-yyyy) and time (hh:mm) the signature was executed.\n- the meaning associated with the signature (such as review, approval, responsibility, or authorship).\n|if the electronic signature function were to fail to perform as intended, then production or quality system records may not reflect appropriate approval or be sufficiently auditable, or may fail to meet other regulatory requirements. however, such a failure would not foreseeably lead to compromised safety. as such, the manufacturer determined that this function does not pose high process risk.|the manufacturer has performed an assessment of the system capability, supplier evaluation, and installation activities. to provide assurance that the function complies with applicable requirements, the manufacturer performs ad-hoc testing of this function with users to demonstrate the function meets the intended use. - the manufacturer documents: - the intended use\n- risk determination\n- testing performed\n- any issues found and their disposition\n- a concluding statement noting that the performance of the function is acceptable\n- the date testing was performed and who performed the testing.\n|", "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"}, "57cf529f-1768-4e1e-a83e-890e35a21279": {"__data__": {"id_": "57cf529f-1768-4e1e-a83e-890e35a21279", "embedding": null, "metadata": {"page_label": "22", "file_name": "[20] FDA Guidance-Computer-Software-Assurance - 2022.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[20] FDA Guidance-Computer-Software-Assurance - 2022.pdf", "file_type": "application/pdf", "file_size": 1042506, "creation_date": "2024-04-07", "last_modified_date": "2024-04-05", "document_title": "Risk-Based Analysis Assurance Activities for Product Containment Function: A Comprehensive Guide", "questions_this_excerpt_can_answer": "1. What specific steps does the manufacturer take to ensure the reliability of a product containment function that has been identified as posing a high process risk?\n   \n2. How does the manufacturer document the assurance activities related to the product containment function, and what specific elements are included in this documentation according to the 2022 FDA Guidance on Computer Software Assurance?\n\n3. What criteria does the manufacturer use to determine the necessity of a product correction or removal in the event of a nonconformance occurring in a distributed product, as outlined in the 2022 FDA Guidance document?", "prev_section_summary": "The section discusses the electronic signature function in pharmaceutical manufacturing or quality system records, focusing on its intended use, risk analysis, and assurance activities. Key topics include the elements of the electronic signature execution record, the risk associated with the failure of the electronic signature function, and the assurance activities recommended by the 2022 FDA Guidance for ensuring compliance with regulatory requirements. Entities mentioned include the manufacturer, system capability, supplier evaluation, installation activities, ad-hoc testing, intended use documentation, risk determination, testing results, issue disposition, and performance acceptance statement.", "excerpt_keywords": "FDA, Guidance, Computer Software Assurance, Risk-Based Analysis, Product Containment Function"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[20] FDA Guidance-Computer-Software-Assurance - 2022.pdf\n## features, functions, or operations intended use of the risk-based analysis assurance activities\n\n|product containment function:|this function is intended to trigger the necessary evaluation and decision-making on whether a product correction or removal is needed when the nonconformance occurred in product that has been distributed.|\n|---|---|\n| |failure of the function to perform as intended would result in a necessary correction or removal not being initiated, resulting in a quality problem that foreseeably compromises safety. the manufacturer therefore determined that this function poses high process risk.|\n| |the manufacturer has performed an assessment of the system capability, supplier evaluation, and installation activities. since the manufacturer determined the function to pose high process risk, the manufacturer determined assurance activities commensurate with the medical device risk: established a detailed scripted test protocol that exercises the possible interactions and potential ways the function could fail. the testing also included appropriate repeatability testing in various scenarios to provide assurance that the function works reliably.|\n| |the manufacturer documents:|\n| |- the intended use|\n| |- risk determination|\n| |- detailed test protocol developed|\n| |- detailed report of the testing performed|\n| |- pass/fail results for each test case|\n| |- any issues found and their disposition|\n| |- a concluding statement noting that the performance of the operation is acceptable|\n| |- the date testing was performed and who performed the testing|\n| |- the signature and date of the appropriate signatory authority.|", "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"}, "6e5b9df9-e712-4209-92c8-0813a68d29f8": {"__data__": {"id_": "6e5b9df9-e712-4209-92c8-0813a68d29f8", "embedding": null, "metadata": {"page_label": "23", "file_name": "[20] FDA Guidance-Computer-Software-Assurance - 2022.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[20] FDA Guidance-Computer-Software-Assurance - 2022.pdf", "file_type": "application/pdf", "file_size": 1042506, "creation_date": "2024-04-07", "last_modified_date": "2024-04-05", "document_title": "Risk-Based Assurance Strategy for Learning Management System (LMS) Implementation: A Comprehensive Guide", "questions_this_excerpt_can_answer": "1. How does the manufacturer approach the risk-based assurance strategy for the user log-on features of the Learning Management System (LMS) to comply with 21 CFR 820.25, and what specific assurance activities are conducted to ensure its integrity?\n   \n2. What specific documentation does the manufacturer create as part of their risk-based assurance strategy when assessing the user log-on features of the LMS, and how do they document the outcome of their testing activities?\n\n3. In the context of implementing a COTS LMS with a risk-based assurance strategy, how does the manufacturer evaluate the potential impact of the failure of the system's user log-on features on the integrity of the quality system record, and what criteria do they use to determine the process risk associated with these features?", "prev_section_summary": "The section discusses risk-based analysis assurance activities for product containment functions, focusing on ensuring the reliability of functions that pose high process risk. Key topics include the intended use of the risk-based analysis assurance activities, the importance of product containment functions in triggering necessary evaluations and decision-making, and the manufacturer's assurance activities such as system capability assessment, supplier evaluation, and detailed testing protocols. Entities mentioned include the manufacturer, the product containment function, detailed test protocols, testing reports, pass/fail results, issues found and their disposition, and signatory authorities.", "excerpt_keywords": "Learning Management System, LMS, Risk-Based Assurance Strategy, Computer Software Assurance, Quality System Record"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[20] FDA Guidance-Computer-Software-Assurance - 2022.pdf\n## example 2: learning management system (lms)\n\na manufacturer is implementing a cots lms and is applying a risk-based approach for computer software assurance in its implementation. the software is intended to manage, record, track, and report on training. the following features, functions, or operations were considered by the manufacturer in developing a risk-based assurance strategy:\n\n|features, functions, or operations|intended use of the features, functions, or operations|risk-based analysis|assurance activities|establishing the appropriate record|\n|---|---|---|---|---|\n|the system provides user log-on features (e.g., username and password)|all of the features, functions, and operations have the same intended use, that is, to manage, record, track and report on training. they are intended to automate processes to comply with 21 cfr 820.25 (personnel), and to establish the necessary records.|failure of these features, functions, or operations to perform as intended would impact the integrity of the quality system record but would not foreseeably compromise safety. as such, the manufacturer determined that the features, functions, and operations do not pose high process risk.|the manufacturer has performed an assessment of the system capability, supplier evaluation, and installation activities. in addition, the manufacturer supplements these activities with unscripted testing, applying error-guessing to attempt to circumvent process flow and \"break\" the system (e.g. try to delete the audit trail).|the manufacturer documents: - the intended use\n- risk determination\n- a summary description of the failure modes tested\n- any issues found and their disposition\n- a concluding statement noting that the performance of the operation is acceptable\n- the date testing was performed, and who performed the testing\n|\n|the system assigns trainings to users per the curriculum assigned by management| | | | |\n|the system captures evidence of users training completion| | | | |\n|the system notifies users of training curriculum assignments, completion of trainings, and outstanding trainings| | | | |\n|the system notifies users management of outstanding trainings| | | | |\n|the system generates reports on training curriculum assignments, completion of training, and outstanding trainings| | | | |", "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"}, "8ec23436-1627-4de7-bd20-c8ae2d87f3c7": {"__data__": {"id_": "8ec23436-1627-4de7-bd20-c8ae2d87f3c7", "embedding": null, "metadata": {"page_label": "24", "file_name": "[20] FDA Guidance-Computer-Software-Assurance - 2022.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[20] FDA Guidance-Computer-Software-Assurance - 2022.pdf", "file_type": "application/pdf", "file_size": 1042506, "creation_date": "2024-04-07", "last_modified_date": "2024-04-05", "document_title": "Risk-Based Assurance Strategy for Business Intelligence Implementation in a Medical Device Manufacturer: A Comprehensive Guide", "questions_this_excerpt_can_answer": "1. What specific steps does a medical device manufacturer take to ensure the secure and robust connectivity of their business intelligence solution, according to the 2022 FDA Guidance on Computer Software Assurance?\n   \n2. How does the 2022 FDA Guidance document suggest a medical device manufacturer should document and validate the performance of connectivity functions in their business intelligence applications to mitigate high process risks?\n\n3. What criteria does the 2022 FDA Guidance recommend for determining the level of assurance activities required for the connectivity functions of a business intelligence solution implemented by a medical device manufacturer?", "prev_section_summary": "The section discusses the implementation of a Learning Management System (LMS) with a risk-based assurance strategy for computer software assurance. It focuses on the user log-on features of the LMS and the assurance activities conducted to ensure its integrity. The manufacturer evaluates the potential impact of the failure of the system's user log-on features on the integrity of the quality system record and documents their risk-based assurance strategy. Key topics include risk analysis, assurance activities, documentation, system capabilities, supplier evaluation, installation activities, and testing. Key entities mentioned are the manufacturer, system features, functions, operations, and users.", "excerpt_keywords": "Keywords: FDA Guidance, Computer Software Assurance, Business Intelligence, Medical Device Manufacturer, Risk-Based Assurance Strategy"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[20] FDA Guidance-Computer-Software-Assurance - 2022.pdf\n## example 3: business intelligence applications\n\ndraft - not for implementation\n\na medical device manufacturer has decided to implement a commercial business intelligence solution for data mining, trending, and reporting. the software is intended to better understand product and process performance over time, in order to provide identification of improvement opportunities. the following features, functions, or operations were considered by the manufacturer in developing a risk-based assurance strategy:\n\n|features, functions, or operations|intended use of the features, functions or operations|risk-based analysis|assurance activities|\n|---|---|---|---|\n|connectivity functions:|these functions are intended to ensure a secure and robust capability for the system to connect to the appropriate data sources, ensure integrity of the data, prevent data corruption, modify, and store the data appropriately.|failure of these functions to perform as intended would result in inaccurate or inconsistent trending or analysis. this would result in failure to identify potential quality trends, issues or opportunities for improvement, which in some cases, may result in a quality problem that foreseeably compromises safety. as such, the manufacturer determined that these functions posed high process risk, necessitating more-rigorous assurance activities, commensurate with the related medical device risk.|the manufacturer documents: - the intended use\n- risk determination\n- detailed test protocol\n- a detailed report of the testing performed\n- pass/fail results for each test case\n- any issues found and their disposition\n- a concluding statement noting that the performance of the operation is acceptable\n- the date testing was performed, and who performed the testing\n- the signature and date of the appropriate signatory authority.\n|", "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"}, "c2b38479-e821-4314-bc97-a9328a93fca9": {"__data__": {"id_": "c2b38479-e821-4314-bc97-a9328a93fca9", "embedding": null, "metadata": {"page_label": "25", "file_name": "[20] FDA Guidance-Computer-Software-Assurance - 2022.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[20] FDA Guidance-Computer-Software-Assurance - 2022.pdf", "file_type": "application/pdf", "file_size": 1042506, "creation_date": "2024-04-07", "last_modified_date": "2024-04-05", "document_title": "Risk-Based Analysis Assurance Activities for Usability Features and Reporting Functions", "questions_this_excerpt_can_answer": "1. What criteria does the manufacturer use to determine the risk level associated with the usability feature and reporting functions in the context of FDA's guidance on computer software assurance?\n   \n2. How does the manufacturer document the assessment process for both the usability feature and reporting functions to ensure they meet the FDA's requirements for computer software assurance in 2022?\n\n3. What specific steps are included in the manufacturer's documentation process for evaluating the risk and performance acceptability of both usability features and reporting functions, as outlined in the 2022 FDA guidance document on computer software assurance?", "prev_section_summary": "The section discusses the implementation of a commercial business intelligence solution by a medical device manufacturer, focusing on connectivity functions and assurance activities to ensure secure and robust data connectivity. Key topics include risk-based analysis, documentation and validation of connectivity functions, and criteria for determining assurance activities. Entities mentioned include the manufacturer, data sources, integrity of data, quality trends, assurance activities, test protocols, test results, issues found, signatory authority, and performance acceptance.", "excerpt_keywords": "FDA, guidance, computer software assurance, risk-based analysis, usability features, reporting functions"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[20] FDA Guidance-Computer-Software-Assurance - 2022.pdf\n## features, functions, or operations intended use of the risk-based analysis assurance activities\n\n|usability feature:|this feature is intended to facilitate the interaction of the user with the system and provide assistance on use of all the system features. the failure of the feature to perform as intended is unlikely to result in a quality problem that would lead to compromised safety. therefore, the manufacturer determined that the feature does not pose high process risk. the feature does not necessitate any additional assurance effort beyond what the manufacturer has already performed in assessing the system capability, supplier evaluation, and installation activities. the manufacturer documents:|\n|---|---|\n| |- the intended use\n- risk determination\n- the date of assessment and who performed the assessment\n- a concluding statement noting that the performance is acceptable given the intended use and risk.\n|\n|reporting functions:|these functions are intended to allow the user to query the data sources, join data from various sources, perform analysis, and generate visuals and summaries. these functions are intended for collection and recording data for monitoring and review purposes that do not have a direct impact on production or process performance. failure of these functions to perform as intended may result in a quality problem (e.g., incomplete or inadequate reports) but, in this example, would not foreseeably lead to compromised safety because these functions are intended for collection and recording data for monitoring and review purposes that do not have a direct impact on production or process performance. therefore, the manufacturer determined that these functions do not pose high process risk. the manufacturer documents:|\n| |- the intended use\n- risk determination\n- the date of assessment and who performed the assessment\n- a concluding statement noting that the performance is acceptable given the intended use and risk.\n|", "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"}, "d772ae64-8d6c-46da-ae4f-d6911eb229b0": {"__data__": {"id_": "d772ae64-8d6c-46da-ae4f-d6911eb229b0", "embedding": null, "metadata": {"page_label": "1", "file_name": "[21] FDA 21 CFR Part 11 Electronic Records Electronic-Signatures - 2003.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[21] FDA 21 CFR Part 11 Electronic Records Electronic-Signatures - 2003.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 the application of Part 11, concerning electronic records and electronic signatures, within the pharmaceutical industry as of August 2003?\n\n2. As of August 2003, what document provides the FDA's guidance on electronic records and electronic signatures in the context of Pharmaceutical Current Good Manufacturing Practices (CGMPs)?\n\n3. What is the official title of the FDA guidance document that outlines the scope and application of Part 11, which pertains to electronic records and electronic signatures, as it relates to various FDA centers including CDER, CBER, CDRH, CFSAN, CVM, and ORA?", "excerpt_keywords": "FDA, Part 11, Electronic Records, Electronic Signatures, Pharmaceutical Industry"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[21] FDA 21 CFR Part 11 Electronic Records Electronic-Signatures - 2003.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"}, "2e7dfb26-9abf-42c6-a901-f5e5fe1adccc": {"__data__": {"id_": "2e7dfb26-9abf-42c6-a901-f5e5fe1adccc", "embedding": null, "metadata": {"page_label": "2", "file_name": "[21] FDA 21 CFR Part 11 Electronic Records Electronic-Signatures - 2003.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[21] FDA 21 CFR Part 11 Electronic Records Electronic-Signatures - 2003.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 as of August 2003, and which FDA centers and offices provide resources and assistance regarding this guidance?\n   \n2. How can industry professionals contact the Division of Drug Information within the Center for Drug Evaluation and Research (CDER) or the Office of Communication, Training, and Manufacturers Assistance within the Center for Biologics Evaluation and Research (CBER) for guidance on electronic records and electronic signatures as outlined in the document from August 2003?\n\n3. What are the contact details for obtaining guidance on electronic records and electronic signatures from the Center for Veterinary Medicine (CVM), the Division of Small Manufacturers Assistance, and the Center for Food Safety and Applied Nutrition (CFSAN) as per the FDA document from August 2003?", "prev_section_summary": "The section provides guidance from the FDA on the scope and application of Part 11, concerning electronic records and electronic signatures in the pharmaceutical industry. It outlines the involvement of various FDA centers including CDER, CBER, CDRH, CFSAN, CVM, and ORA in providing guidance on electronic records and signatures in the context of Pharmaceutical Current Good Manufacturing Practices (CGMPs). The document was published in August 2003.", "excerpt_keywords": "FDA, electronic records, electronic signatures, guidance, pharmaceutical industry"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[21] FDA 21 CFR Part 11 Electronic Records Electronic-Signatures - 2003.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"}, "1a657fd7-45e7-4654-8c29-4077203b0f42": {"__data__": {"id_": "1a657fd7-45e7-4654-8c29-4077203b0f42", "embedding": null, "metadata": {"page_label": "3", "file_name": "[21] FDA 21 CFR Part 11 Electronic Records Electronic-Signatures - 2003.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[21] FDA 21 CFR Part 11 Electronic Records Electronic-Signatures - 2003.pdf", "file_type": "application/pdf", "file_size": 44957, "creation_date": "2024-04-07", "last_modified_date": "2024-03-28", "document_title": "Comprehensive Guide to Achieving Part 11 Compliance in the Pharmaceutical Industry", "questions_this_excerpt_can_answer": "1. What specific strategies does the \"Comprehensive Guide to Achieving Part 11 Compliance in the Pharmaceutical Industry\" recommend for interpreting the scope of FDA 21 CFR Part 11 requirements, particularly in relation to electronic records and electronic signatures within the pharmaceutical sector?\n\n2. How does the document detail the approach to ensuring compliance with specific FDA 21 CFR Part 11 requirements such as validation, audit trails, and legacy systems, and what unique insights does it offer for pharmaceutical companies looking to navigate these regulations effectively?\n\n3. In the context of FDA 21 CFR Part 11 compliance, what are the recommended practices for record retention and managing copies of records as outlined in the \"Comprehensive Guide to Achieving Part 11 Compliance in the Pharmaceutical Industry,\" and how do these practices specifically cater to the needs of the pharmaceutical industry?", "prev_section_summary": "The section provides guidance for industry professionals on the scope and application of electronic records and electronic signatures as outlined in the FDA document from August 2003. It includes contact information for various FDA centers and offices that can provide assistance and resources regarding electronic records and signatures, such as the Division of Drug Information within the Center for Drug Evaluation and Research (CDER), the Office of Communication, Training, and Manufacturers Assistance within the Center for Biologics Evaluation and Research (CBER), the Center for Veterinary Medicine (CVM), the Division of Small Manufacturers Assistance, and the Center for Food Safety and Applied Nutrition (CFSAN). The section emphasizes the importance of compliance and security in electronic recordkeeping within the pharmaceutical industry.", "excerpt_keywords": "FDA, 21 CFR Part 11, Electronic Records, Electronic Signatures, Pharmaceutical Industry"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[21] FDA 21 CFR Part 11 Electronic Records Electronic-Signatures - 2003.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"}, "6a06c3e1-39b0-41ac-80d7-ddb98b29006b": {"__data__": {"id_": "6a06c3e1-39b0-41ac-80d7-ddb98b29006b", "embedding": null, "metadata": {"page_label": "4", "file_name": "[21] FDA 21 CFR Part 11 Electronic Records Electronic-Signatures - 2003.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[21] FDA 21 CFR Part 11 Electronic Records Electronic-Signatures - 2003.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 purpose of the FDA's guidance on 21 CFR Part 11 regarding electronic records and electronic signatures, and how does it impact the rights and obligations of individuals or entities under FDA regulations?\n   \n2. How does the FDA's guidance document on 21 CFR Part 11 define its scope in relation to electronic records and signatures, especially concerning records requirements set forth in agency regulations and submissions under the Federal Food, Drug, and Cosmetic Act and the Public Health Service Act?\n\n3. Can entities choose alternative approaches to maintaining or submitting electronic records and signatures under 21 CFR Part 11, and what is the process for discussing these alternatives with the FDA, according to the guidance document?", "prev_section_summary": "The section provides a comprehensive guide to achieving Part 11 compliance in the pharmaceutical industry, focusing on strategies for interpreting the scope of FDA 21 CFR Part 11 requirements related to electronic records and electronic signatures. It details approaches to ensuring compliance with specific requirements such as validation, audit trails, legacy systems, record retention, and managing copies of records. The document offers unique insights and recommended practices tailored to the needs of pharmaceutical companies navigating these regulations effectively.", "excerpt_keywords": "FDA, guidance, electronic records, electronic signatures, compliance"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[21] FDA 21 CFR Part 11 Electronic Records Electronic-Signatures - 2003.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"}, "06d37c01-5432-40fd-85c0-d25430f63712": {"__data__": {"id_": "06d37c01-5432-40fd-85c0-d25430f63712", "embedding": null, "metadata": {"page_label": "5", "file_name": "[21] FDA 21 CFR Part 11 Electronic Records Electronic-Signatures - 2003.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[21] FDA 21 CFR Part 11 Electronic Records Electronic-Signatures - 2003.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 announced it will exercise enforcement discretion on during the re-examination of Part 11 as it applies to all FDA-regulated products?\n   \n2. How does the FDA's guidance document issued in 2003 define its stance on legacy systems operational before August 20, 1997, in relation to Part 11 requirements?\n\n3. Can you detail the FDA's efforts to engage with industry and other stakeholders regarding the interpretation and implementation of Part 11 regulations after they became effective in August 1997?", "prev_section_summary": "The section provides guidance on FDA's 21 CFR Part 11 regarding electronic records and electronic signatures. It outlines the purpose of the guidance, defines the scope of Part 11 in relation to electronic records and signatures, and discusses alternative approaches for maintaining or submitting electronic records. Key topics include the applicability of Part 11 to electronic records created under agency regulations, submissions under the Federal Food, Drug, and Cosmetic Act, and the Public Health Service Act. Entities affected by this guidance include those required to maintain electronic records or submit information to the FDA electronically.", "excerpt_keywords": "FDA, Part 11, Electronic Records, Electronic Signatures, Enforcement Discretion"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[21] FDA 21 CFR Part 11 Electronic Records Electronic-Signatures - 2003.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"}, "300decee-eeb0-4f23-8665-bf03cb6aca29": {"__data__": {"id_": "300decee-eeb0-4f23-8665-bf03cb6aca29", "embedding": null, "metadata": {"page_label": "6", "file_name": "[21] FDA 21 CFR Part 11 Electronic Records Electronic-Signatures - 2003.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[21] FDA 21 CFR Part 11 Electronic Records Electronic-Signatures - 2003.pdf", "file_type": "application/pdf", "file_size": 44957, "creation_date": "2024-04-07", "last_modified_date": "2024-03-28", "document_title": "Re-examination and Enforcement Discretion of 21 CFR Part 11 Requirements: A Comprehensive Overview", "questions_this_excerpt_can_answer": "1. What were the main concerns raised by stakeholders regarding the interpretations of the 21 CFR Part 11 requirements that led to the FDA's decision to re-examine these regulations?\n   \n2. Can you detail the specific Part 11 draft guidance documents that the FDA withdrew in early 2003, as part of its re-examination of the 21 CFR Part 11 requirements?\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 requirements for recording the signer's local time, according to the context provided?", "prev_section_summary": "The section discusses the FDA's exercise of enforcement discretion for Part 11 requirements, specifically focusing on validation, audit trail, record retention, and record copying requirements. It mentions the FDA's intention to narrowly interpret the scope of Part 11 and its stance on legacy systems operational before August 20, 1997. The section also highlights the background of Part 11 regulations, industry discussions, and FDA's efforts to engage with stakeholders for the interpretation and implementation of the regulations. Key entities mentioned include the FDA, industry coalition, and other interested parties.", "excerpt_keywords": "FDA, 21 CFR Part 11, Electronic Records, Electronic Signatures, Enforcement Discretion"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[21] FDA 21 CFR Part 11 Electronic Records Electronic-Signatures - 2003.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"}, "fba2704b-2d2c-456a-976c-822f0cffe36b": {"__data__": {"id_": "fba2704b-2d2c-456a-976c-822f0cffe36b", "embedding": null, "metadata": {"page_label": "7", "file_name": "[21] FDA 21 CFR Part 11 Electronic Records Electronic-Signatures - 2003.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[21] FDA 21 CFR Part 11 Electronic Records Electronic-Signatures - 2003.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 Enforcement and Compliance: 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 2003 guidance document clarify its approach to the scope of Part 11, especially in terms of narrowing the interpretation of which records are subject to Part 11 requirements?\n\n3. What are the specific controls and requirements for electronic systems and electronic signatures that the FDA explicitly states it will continue to enforce under Part 11, despite the exercise of enforcement discretion in other areas?", "prev_section_summary": "The section discusses the re-examination and enforcement discretion of 21 CFR Part 11 requirements by the FDA. Key topics include concerns raised by stakeholders regarding interpretations of the requirements, withdrawal of draft guidance documents in 2003, the impact on industry compliance and innovation, and the FDA's current stance on time stamps in systems spanning different time zones. 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": "[21] FDA 21 CFR Part 11 Electronic Records Electronic-Signatures - 2003.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"}, "2327f7dd-bcd4-40d3-8df8-24763afa18a3": {"__data__": {"id_": "2327f7dd-bcd4-40d3-8df8-24763afa18a3", "embedding": null, "metadata": {"page_label": "8", "file_name": "[21] FDA 21 CFR Part 11 Electronic Records Electronic-Signatures - 2003.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[21] FDA 21 CFR Part 11 Electronic Records Electronic-Signatures - 2003.pdf", "file_type": "application/pdf", "file_size": 44957, "creation_date": "2024-04-07", "last_modified_date": "2024-03-28", "document_title": "Requirements for Electronic Records Management in Compliance with Part 11", "questions_this_excerpt_can_answer": "1. How does the FDA define the scope of Part 11 regarding the use of electronic records and signatures in lieu of paper records, and what criteria determine whether electronic records fall under Part 11 regulations?\n   \n2. What specific recommendations does the FDA provide for organizations to determine whether their electronic records are subject to Part 11 regulations, especially in cases where records are maintained in both electronic and paper formats?\n\n3. In what instances does the FDA consider electronic records and signatures not to be subject to Part 11, and what documentation practices does the FDA recommend for organizations to justify their reliance on paper records over electronic records for regulated activities?", "prev_section_summary": "This section discusses the FDA's approach to enforcing and complying with Part 11 requirements for electronic records and signatures. Key topics include the FDA's exercise of enforcement discretion for legacy systems, clarification of the scope of Part 11, specific controls and requirements for electronic systems and signatures, and the enforcement of predicate rule requirements. Entities involved include the FDA, individuals developing, maintaining, or using electronic systems, and those responsible for ensuring compliance with Part 11 provisions.", "excerpt_keywords": "FDA, Part 11, Electronic Records, Electronic Signatures, Compliance"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[21] FDA 21 CFR Part 11 Electronic Records Electronic-Signatures - 2003.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"}, "2fdbd961-7896-476e-9c20-589a9421d446": {"__data__": {"id_": "2fdbd961-7896-476e-9c20-589a9421d446", "embedding": null, "metadata": {"page_label": "9", "file_name": "[21] FDA 21 CFR Part 11 Electronic Records Electronic-Signatures - 2003.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[21] FDA 21 CFR Part 11 Electronic Records Electronic-Signatures - 2003.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 Guide", "questions_this_excerpt_can_answer": "1. What is the FDA's stance on enforcing specific Part 11 requirements related to the validation of computerized systems, and how does it suggest organizations should approach the validation process?\n   \n2. How does the FDA recommend organizations determine the extent of validation needed for their computerized systems under Part 11, especially in cases where there is no explicit predicate rule requirement for system validation?\n\n3. Regarding Part 11 requirements, what is the FDA's approach to enforcing rules related to computer-generated, time-stamped audit trails, and what considerations should organizations make to ensure compliance in the absence of specific predicate rule requirements?", "prev_section_summary": "The section discusses the FDA's narrow interpretation of the scope of Part 11 regarding electronic records and signatures. It outlines when Part 11 regulations apply to electronic records maintained in lieu of paper records, and when they do not. The key topics include the definition of Part 11 records, criteria for determining if electronic records are subject to Part 11 regulations, and recommendations for documenting decisions regarding the use of electronic versus paper records for regulated activities. The section emphasizes the importance of considering business practices and predicate rule requirements in determining the applicability of Part 11.", "excerpt_keywords": "FDA, Part 11, Electronic Records, Electronic Signatures, Validation"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[21] FDA 21 CFR Part 11 Electronic Records Electronic-Signatures - 2003.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"}, "6775443f-7316-49c0-a3e7-54f501d1cd71": {"__data__": {"id_": "6775443f-7316-49c0-a3e7-54f501d1cd71", "embedding": null, "metadata": {"page_label": "10", "file_name": "[21] FDA 21 CFR Part 11 Electronic Records Electronic-Signatures - 2003.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[21] FDA 21 CFR Part 11 Electronic Records Electronic-Signatures - 2003.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 2003 guidance document?\n   \n2. How does the FDA recommend providing copies of electronic records to an investigator during an inspection, according to the 2003 guidance document on Part 11 requirements?\n\n3. What is the FDA's stance on applying Part 11 controls to systems that have been changed since August 20, 1997, as per the 2003 guidance document on Electronic Records and Electronic Signatures?", "prev_section_summary": "The section discusses the FDA's approach to enforcing specific Part 11 requirements related to validation of computerized systems and audit trail compliance. Key topics include validation of computerized systems, enforcement discretion for specific Part 11 requirements, the importance of considering system impact on meeting predicate rule requirements, and the need for audit trails to ensure trustworthiness and integrity of records. Entities mentioned include the FDA, organizations, electronic signatures, and computer-generated audit trails.", "excerpt_keywords": "FDA, Part 11, Electronic Records, Electronic Signatures, Legacy Systems"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[21] FDA 21 CFR Part 11 Electronic Records Electronic-Signatures - 2003.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"}, "09c31b39-4806-4e74-a1b5-aa294c933b06": {"__data__": {"id_": "09c31b39-4806-4e74-a1b5-aa294c933b06", "embedding": null, "metadata": {"page_label": "11", "file_name": "[21] FDA 21 CFR Part 11 Electronic Records Electronic-Signatures - 2003.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[21] FDA 21 CFR Part 11 Electronic Records Electronic-Signatures - 2003.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 recommendations does the FDA provide regarding the process of copying Part 11 records to ensure they preserve the content and meaning of the original records?\n   \n2. How does the FDA suggest organizations should decide on the method for maintaining records in compliance with Part 11, and what factors should influence this decision?\n\n3. In what scenarios does the FDA not intend to object to the archiving of required records in non-electronic formats, and what conditions must still be met regarding the preservation of these records' content and meaning?", "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 the criteria for legacy systems to qualify for enforcement discretion, recommendations for providing copies of electronic records to investigators during inspections, and the application of Part 11 controls to systems that have been changed since August 20, 1997. The section also emphasizes the importance of record security and integrity, as well as providing access to records in common portable formats.", "excerpt_keywords": "FDA, Part 11, Electronic Records, Electronic Signatures, Compliance"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[21] FDA 21 CFR Part 11 Electronic Records Electronic-Signatures - 2003.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"}, "05b5f527-6641-4480-ae3f-a128dca42f42": {"__data__": {"id_": "05b5f527-6641-4480-ae3f-a128dca42f42", "embedding": null, "metadata": {"page_label": "12", "file_name": "[21] FDA 21 CFR Part 11 Electronic Records Electronic-Signatures - 2003.pdf", "file_path": "/content/drive/MyDrive/Desarrollo Pharma.IA/PharmaWise Engineer/PharmaWise CSV & Data Integrity/raw_data/[21] FDA 21 CFR Part 11 Electronic Records Electronic-Signatures - 2003.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 the Medical Device Industry: A Comprehensive Guide", "questions_this_excerpt_can_answer": "1. What specific FDA guidance document, published in 2002, provides the general principles of software validation for industry and FDA staff, and where can it be found online?\n   \n2. As of 2001, which document serves as the guide for validation of automated systems in the pharmaceutical industry according to the Good Automated Manufacturing Practice (GAMP) forum, and what is its online source?\n\n3. What is the title and publication year of the FDA guidance that addresses the use of off-the-shelf software in medical devices, and what is the URL for accessing this document?", "prev_section_summary": "The section discusses best practices for record retention and preservation in compliance with Part 11 of FDA regulations. Key topics include recommendations for copying Part 11 records to preserve their content and meaning, the exercise of enforcement discretion for record protection and retrieval, decision-making on record maintenance based on risk assessment and value determination, and the FDA's acceptance of archiving required records in non-electronic formats under certain conditions. The section also mentions the co-existence of paper and electronic record components in a hybrid situation as long as predicate rule requirements are met and the content and meaning of the records are preserved.", "excerpt_keywords": "FDA, software validation, medical device industry, GAMP, electronic records"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {}, "text": "[21] FDA 21 CFR Part 11 Electronic Records Electronic-Signatures - 2003.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"}}, "docstore/metadata": {"29af9f8b-7367-4f59-95c9-f139d7370eb4": {"doc_hash": "2abbcaf4b068426f091e7b29eb64d8df823163e4c4deb4fcba1a397c54c7b3b8"}, "d1d8ba6b-32c9-42c4-95ee-587a31f57fed": {"doc_hash": "0c1567b5afef8800262fe41888c1bbe68d4342e24c8a79253674674ab203de5f"}, "e15a963c-4c4a-4901-8a5d-4750cd2a5cb7": {"doc_hash": "77e5580594ac97fb76bc3d0bb7d35c55fca55d53ce6a603c2a2b81c5ff87630c"}, "a8a3185f-a90a-4235-b764-951b2f5ea2bd": {"doc_hash": "a6262128a9a71d694b2252ba99fbe7c1ec0085a70e23767e01c6cfaba23667a3"}, "1b8b4091-ff78-4676-9207-c1de173f5541": {"doc_hash": "41c6afddc229ec274d00cdfdced6127aa582d6325e2967d3427ac8d8ca0c06d3"}, "e6573f3a-a7f5-4bb9-80c4-8729ffea70b8": {"doc_hash": "e0094c6167eaeba48d6c82a977fdf1d83bb3fb5888d2048875319b737ee970e8"}, "c5918774-ae9e-48fa-84d7-c0e781b492ef": {"doc_hash": "039308c994247b30efc64e2ae7d6df70607d24dbc03fee099911114757a5827a"}, "c4b4fd11-ed04-45a3-b305-f69ca6dabcb6": {"doc_hash": "7150750d07b82899776fd2cf4e36b6170c5e459d4e5ba85fc7c919b1f6f97d25"}, "ed5ac6a4-56bb-480c-aa33-27f4941cfbfe": {"doc_hash": "bd88bfe6949172058357aed37aa9f2a6ffaad3b3a170a564aae8ba3c13ede95c"}, "5c5334eb-ab6f-4e0c-9fcc-c7ad86014166": {"doc_hash": "4846c89a694c355c59e121234b67dbc16e798ad1003c26066e709f97bb57e105"}, "8965dcb1-22d8-482c-a756-cebceef46068": {"doc_hash": "5ee43b1e2d8004bdb4860aa7dc449a24e76d805436221e2a542a1aa952ecafbd"}, "a01083d3-fa79-43d5-a137-ad68bd3a5e14": {"doc_hash": "93ee2d2cf865af7a1613d4e7dfae7a4592e63618de9f787971397719a52c0bc1"}, "87c27a7d-1bd1-47be-a3a9-27cada54d060": {"doc_hash": "4ba8c8fb58bcc84eb58e7bc7fd072a44d76a4756e69b5b4949da4b2c30baad28"}, "f04a7f96-bf16-4e16-94dd-4098eede3c1f": {"doc_hash": "cb1562df23654758d7374e86bbcc982f3b181f8829fe69da6272dadad5455960"}, "1aa5716d-7b67-4a47-8bea-ea85ea9b8827": {"doc_hash": "34e655ce13b94af980a536bdde5d1902f434254087a08d57cf3f71e29bc29988"}, "bf4f9b5e-e542-4b43-9615-05bf65688341": {"doc_hash": "4a949a9dceb90b916ae020ac7ba235ad43eba5c2aab6c91a07e85918e884fcf7"}, "38206b01-1640-4a5c-b31b-f402c13e2c04": {"doc_hash": "993fe3948caee76f8dd68b2ce997d8aaea3b80cbe339624c60fb0bb024053941"}, "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"}, "b0d6cfba-ac79-459f-8745-c48b3f5e78e5": {"doc_hash": "02058c7c7b93880c8d65fbe76f0fd92c185a8376a2f35443471989a63d232c7f"}, "e0a45702-238f-4326-8e7f-65f0488c639d": {"doc_hash": "2a654afe8f1064d071e80f1fe590add9ab33a507ce4c6458696ebf7269722517"}, "143215aa-4515-4f1a-be5e-f543825b425a": {"doc_hash": "e24324bdb99723bd4456cf35c64d9d97f5699d2c8dc8a6995bb7951a2fb4d846"}, "36a60b84-52be-4f38-8af0-672746521221": {"doc_hash": "6adef6e827b47e36260c94704def566ad5b34c28214873fac4e73efcfb2a93d0"}, "92056097-8732-4b49-baf4-a9273a058164": {"doc_hash": "f8c18ea275539a531bf7a89614eafcd7a7197726988f926bc5aa0a8084a4b271"}, "6706c9fa-5ec9-46a2-9539-3d6b95fe9a64": {"doc_hash": "38cd94e8116faefe0a41d5b28f11660edb2b1fb2242aeb77daa2ff793e17dd2f"}, "ec5eefec-84ef-4e89-bac6-abeeb4488142": {"doc_hash": "057345d69e718818e3e94f6cb6e58938c9d2e1e5e9e3b60d794b19488b040ba1"}, "216054cf-0c54-41c9-a432-3886451feeab": {"doc_hash": "142bff5dfb001954a1cc7e1d0c7c65ae5bde56f82075261dcc77315414b6e723"}, "27441a91-ffde-47f7-94fa-907485c2a9b3": {"doc_hash": "1615f363660927b02faeba0eaf416385c1f35d6eaae61d0e286aa4efd945f9ec"}, "2d4d1c9c-5b30-4b2b-b777-29186c395f39": {"doc_hash": "208377be3ad50fe9be01d2ea289091090dbae34653a337d7c7025aed3d90604d"}, "fc6b7973-6404-4d2a-9cdf-a2e9794447e1": {"doc_hash": "c264f435c0d74cc043b5a82e61fa0dc50c3427f895ceafd6cb0c631783494f9e"}, "bb13186c-a1a4-419b-bc5a-d110fb318444": {"doc_hash": "4e7373e6b6e71f62d0d6152563a803eea21e152fc7022e15d06a35dbffddf37d"}, "0e64c298-89dc-469f-a43c-3e587f22b6fe": {"doc_hash": "12262c001c498d457251d8f857328de5b135776639102be3a7b9055a649a514b"}, "f0e71b7a-724b-4418-b314-4c0a1aa84d10": {"doc_hash": "c6795b7b600a19e0de89b82b83d193a7ee03a8ba39f899ced3d9e1fe054abd09"}, "7258d353-265a-4217-a25b-f202eca6563d": {"doc_hash": "6dca19ed4d2df7af0ab997cc36e5cf768faa8799b1d01301d232b7472a16bfb3"}, "5accc9dd-0d68-40c9-bd77-ff5165f7708a": {"doc_hash": "3f5d79af1d552a41ae45edd26757de06d0afe4f872aee77a5ed27d88ee9cb2c6"}, "475f1a92-1111-43fb-8a0e-d1756ba4dc60": {"doc_hash": "1ea5db1dd893cbc2d80c2008762d26541c3ff828660fa56a93d096a66b5b3dc3"}, "2fccae12-38f4-4d1a-8455-3112b5d645a1": {"doc_hash": "207381329286e78588c04b7b9a3b7f9f56abac1de4032f9321291e5c9e742bba"}, "54f735e8-6fa1-4cdf-86e7-e87542a952cc": {"doc_hash": "0a61a74ed1a6bf94bb3602ffe0f9f98900e00ca122b13d91f499957e79cfd93e"}, "ad6451d4-e564-4b4b-941a-581dec2d09d8": {"doc_hash": "64b8c7b118ef2f5e72bb8d0bb0a75e11aba7ad8aa789474bf920dbc48dd0f29d"}, "52a99632-f8e3-4741-805a-7280e4d1be1c": {"doc_hash": "0a94444d2a8f4cfbca8212360f525fddac21b2b300a3e83f3e5b58de6e4bd538"}, "6c0aceb1-ffc0-4617-9b9e-e9b14525a7bb": {"doc_hash": "3e2c1b43e74f3ea49a8192470a22daecd0e054a407decb04aaedad4e6c7bac38"}, "bd54bc85-f2df-422f-a7f2-a89dd681ae9a": {"doc_hash": "12df5fa0938d6ffa54a27892f82cb5af75b682db643d1afdc725521b55ab3a87"}, "57b56fac-a13f-4b81-b281-84f5b9cb1b6c": {"doc_hash": "90f3258ef41b00d48184fc9955fec3bde9e8d264a4c4c9241b190e0b81a81994"}, "16695ee2-d6d1-48d0-8221-168082beaa5b": {"doc_hash": "11060675e77227a4496a57da535486708e1e028542c587ae0a3f601a2bf37482"}, "a65ce79a-296d-43ac-b572-3d518299d5e5": {"doc_hash": "1d6acbf5a4994f44fac77796e09c718a85a516bcd24a828fcfedacdca919e67e"}, "a34a1998-f2da-440e-9ffc-e3c29ad1f836": {"doc_hash": "84108fcd717f52d019f14fc470ee5b9f0a98e3d204cd523cfc147c8619c5179c"}, "817d98b8-a745-470e-993b-2383573bddc4": {"doc_hash": "15c2008e12fb986c8a78570ef3768e6c16e3cfafeb398985608a35104441692c"}, "a57cbb84-dc50-4eea-9929-c2e6202db197": {"doc_hash": "e6652e9a5970bbe319e0643e799b212035e710166986da67b5426ab456f1c14d"}, "9a203c2e-caa9-49f5-9738-0c5f4e0b4910": {"doc_hash": "b914350f09c21da3d9e477103bdeab7156513f84084460402995dcf2e5ccef58"}, "e68fb6bd-1ea7-4d63-a2fe-d7929b2b47b7": {"doc_hash": "c11df56381fa6e4d40b22cee201f7c87843f4833ca6aef77e6531cf9777dc358"}, "3587448a-3ee6-4661-aa4e-2ccc8babac1d": {"doc_hash": "955bc9e04a7c3798388f562e6e619c94c825d3e7a53ef2b019658aa954d3ba84"}, "0829f2be-55aa-431e-b77a-ed9e5b9a39de": {"doc_hash": "38424fd9c31c275162c002ae329da3d5c26a503cb3eb9ef7bfe2ce87719dc2dc"}, "2d53bcff-2fdc-4cc7-a9ca-e27d18629012": {"doc_hash": "1884d6de452891881332287f284cad257eb2c67421cac2e5a5a507aef2cae23a"}, "f82db916-78dd-4e24-9d39-7e0576ccd748": {"doc_hash": "38650eddb2efb6b18a2f7e0269e5e51ea8380482dc32f6e7193f98360bc30110"}, "5dafd197-8a28-44e5-bcc8-b8c915456f29": {"doc_hash": "fab971e98531dcb61533dcd35ccf01b7ebaa50b5c418a3edc2740fbd65801a33"}, "10f6091f-ce63-40ce-ac17-01376b534461": {"doc_hash": "941714ab2346409e1d003dbbe18d45b67cf65b77ed816e3a3c6a5a2a7a0aefd8"}, "0834d867-db17-4a6d-9807-abb7ae229972": {"doc_hash": "039b89c33b8d05c0869144a91bc99f49b204dab007532937461d31f5ec0c00fb"}, "972e7772-faee-4a68-a593-b5965ed6dbb9": {"doc_hash": "98682b8f4e83e5936cfba7e18b1015d560068007c41c9e1552f97acd68d37ef2"}, "dee9c516-2ad1-4d81-bcb6-469bdc8ab876": {"doc_hash": "7126b02299aac361176154ffa78ebb36a7efc2761d47fe0581f04a35c62bce2d"}, "9deaacec-7d1a-4546-b716-79bf6d306172": {"doc_hash": "62d4f02eccf1010aa423ea2cb6fef32abdcda29dde1926e20a21c5a13a75d475"}, "f1a86b2f-7f7f-4140-b8ee-bf98a902d71d": {"doc_hash": "f9ce7c3f1cbde429e964f923a63dcf61c93a9553eaafcdfca95d4a0b3450da17"}, "7ea144e1-68c4-4f87-bee9-486e3852533b": {"doc_hash": "d5a85771e500b99c6c88ad88b10fd040d779e743fe84debf4692abff90487b40"}, "a05ae93a-8328-40ea-9b12-302c33690e9f": {"doc_hash": "16d76bbc425c609d5c1526756dfabd2a533a8eff9a6627e13053dff56addbb0a"}, "87562596-0d7f-4b08-9274-66d18f98d156": {"doc_hash": "1067fe239fa9c3a31cfec91ba540ed133cf3160e4bb45c921f3d7df9b50e4cb4"}, "232b32e5-e840-4e1b-8747-6ab8c5a0fdb3": {"doc_hash": "4d2771f34f86b707b4aa9bc843f43f3b273282d29e55b39b1a5896349df4a559"}, "13fc55a5-3203-44b3-b34a-b0ea0fb90908": {"doc_hash": "0cf4ae6202bbb949c366f9b806234ee2040adc72f7685225be123ba5f368d4b2"}, "ff9b73b2-7320-4496-b74a-6a9cf8bf4004": {"doc_hash": "0ee1767f50b499a4cade0f55fde43abc685426289426e838c3c80a8e734ff262"}, "746634bb-71f7-4ee9-b6dd-2f42f960a829": {"doc_hash": "04506e9126b389e9303e3df53d3e293f31778c8e38228ad1b6f59c31f1d58f98"}, "4dc6054f-2844-4145-825f-65e24c27eb5f": {"doc_hash": "a07660c97bbf7a511fdc0608ee9d46af0d787145ea878102fc682ff4dd2b697d"}, "aff89b04-d232-48e1-90ec-51830748192b": {"doc_hash": "7dec50c15294a589f1e2ac0436fd8bef8e3652888c24f516b2a7a0c5e214732d"}, "aa3381d9-30f8-4edc-8757-035395aa746c": {"doc_hash": "d1bd7d8d001e2bc3ecc5aff62fdf95e17baeac90f6c9ce2c3dbbdd1861268c6f"}, "d9e3757c-c8cf-4602-b2fd-987d62a0b074": {"doc_hash": "b5332c2b8c528d2c4049ffb42780e3d9aaa31674aa4efcf9f48cd5717b6f6858"}, "ac16f18b-5952-4285-bf29-33d054a8746b": {"doc_hash": "23591e76c019e85fa20feda2af75b3e89369305c3fccb890fc859d8d7caa073b"}, "5a838fe5-99f9-4486-9ec4-e56c612cb705": {"doc_hash": "d6b739a764c264ae1cf7e49e369349c7c80ed63e1e5dcfc308985f2fb6292dc1"}, "4e17ff76-4641-4b99-bb41-dfe0e7c4f123": {"doc_hash": "953b9bc7238fbdbfbd794c70a535983c72ba539eb1fda133991a0e0bea018479"}, "e3db4e10-b56e-4704-a81f-6f1daa19914b": {"doc_hash": "ff036212ba20c45b56c529f09689655d7e5936dfe285c65a6a4887ed26ee1a19"}, "a712a261-3dd2-40aa-a191-0fd341708228": {"doc_hash": "2ae54805afea2caa66f967369217ab8c5742c562c76566648e28f1761ab3fdb0"}, "a1cae6e8-8113-4f82-9098-be6a435dc3da": {"doc_hash": "778037ed9a94ce03d8abe2220a731044a941a6d7ac75ceea15502c3234297e62"}, "745b610b-42be-4e16-88f7-6deb10a2931e": {"doc_hash": "997c4906ccff0548b6e620c48e60972b06e0a811c12c61c1e45173d2325a4255"}, "5a1ef3dc-6dd3-4508-8817-a271522530fd": {"doc_hash": "7b11b63eb6bab47f55f14ecaca5c916b3179c4b3f0fc3cd13baf9855837129fe"}, "bfa6a3df-ceee-4812-8f90-721c58cff6f7": {"doc_hash": "82006f56d6d510a854ec79b2445fcb16565d5052070a0962bc0cba9ffb12fdef"}, "5fabf202-e8f9-4d31-85bd-f1da6a652e06": {"doc_hash": "6e84f51d8914436470a9936859cf5a794b6a784be403c010699ee24e4a966969"}, "3457606a-d4e2-421d-8309-d34efcc86449": {"doc_hash": "871ba1bd034400758c7787664bf915d68739e89d6645883e268fb97c58c1b077"}, "8782c439-78a6-4b4f-a3de-f52478789633": {"doc_hash": "a64ef7d87d404176b3f626114d13ad0c60d30794b778cf941612e718df412246"}, "a18a19fb-d9d4-475e-b932-6b991968ee29": {"doc_hash": "cae2e6c79bb2bf061dfeba865d3440efcf1a47db775a05de0531eb5cda75a2d9"}, "328fd0aa-21fe-4b29-a3f8-2a152162517e": {"doc_hash": "87ce5fd1e45d7f500ad47f5fc60c243f436f156bc106a7b1a2dd7f825c2532de"}, "2f851409-7b3c-4340-8804-1357dedd4206": {"doc_hash": "daed8357fbe76324eb471ecde04de13413a0e684c72503f24bbc0be3b32f02b1"}, "57cf529f-1768-4e1e-a83e-890e35a21279": {"doc_hash": "7b65ec1eb8bc51b5ee262656defc5c2a15ad6d4a88ba9a54a673b262889243e2"}, "6e5b9df9-e712-4209-92c8-0813a68d29f8": {"doc_hash": "880f503e83a4b02f9ab26bd78e0a6489d42c83dfa1f4cfef569c8970846f86e8"}, "8ec23436-1627-4de7-bd20-c8ae2d87f3c7": {"doc_hash": "e2c6dbfe77f279ea549489be0fa0a90cd561ecc8d78079467167d2e035963ae1"}, "c2b38479-e821-4314-bc97-a9328a93fca9": {"doc_hash": "6b2590729999044e637b59cdaba9e6557666eff31ea04e19851f66fd7699d2ca"}, "d772ae64-8d6c-46da-ae4f-d6911eb229b0": {"doc_hash": "a838684c979832d688377ec0f94cf049aa951ed6cd59cb83f2a16c1f36de3eed"}, "2e7dfb26-9abf-42c6-a901-f5e5fe1adccc": {"doc_hash": "b70d960aca1ead143231e44441adffcba2400718b9ed1b601ab7920f6780f1a4"}, "1a657fd7-45e7-4654-8c29-4077203b0f42": {"doc_hash": "013f7100b54bb2d32327a31c669654d37591f77c87fe7bf9e4d648e30d0754d1"}, "6a06c3e1-39b0-41ac-80d7-ddb98b29006b": {"doc_hash": "81f8636a9feae03b3edc0b67f9120540cc69d0c2676858516af6f5556daef589"}, "06d37c01-5432-40fd-85c0-d25430f63712": {"doc_hash": "b13e787df4644b812e5548b219d4515fc7c79b0e7fd68e41a3144c13f4dd97a7"}, "300decee-eeb0-4f23-8665-bf03cb6aca29": {"doc_hash": "01a0f7a458db752742aa97eb6a028470546940719475a6a69ecb584ad35e05ac"}, "fba2704b-2d2c-456a-976c-822f0cffe36b": {"doc_hash": "8d98cdcc8685dbe1d2d8f525b63fc0d9ab10834ec9fceb1649b9cde496e0aa2a"}, "2327f7dd-bcd4-40d3-8df8-24763afa18a3": {"doc_hash": "f49798c0fbda88886542ae19b3fe890149808378364820dc6fe9f50a810f9270"}, "2fdbd961-7896-476e-9c20-589a9421d446": {"doc_hash": "7ce8471269d3eb9fd446755b2a206b9e8b7be7aa51f7a3617e2c1041052be6e3"}, "6775443f-7316-49c0-a3e7-54f501d1cd71": {"doc_hash": "6012abf0f681f50854a8a7eb555637e27cd93f4cbc74074e5f580ad077bdbd6a"}, "09c31b39-4806-4e74-a1b5-aa294c933b06": {"doc_hash": "1131b4ce35990e14cab29b2a49f4209ee17518a96f9fd1a91154903a79a50fd2"}, "05b5f527-6641-4480-ae3f-a128dca42f42": {"doc_hash": "908c2bcae364869e3f12c15e41427fc216e510296f7c194690ed7d3004c62e50"}}}