diff --git "a/vec_33_di/storage_nodes/docstore.json" "b/vec_33_di/storage_nodes/docstore.json"
new file mode 100644--- /dev/null
+++ "b/vec_33_di/storage_nodes/docstore.json"
@@ -0,0 +1 @@
+{"docstore/data": {"cc53f633-1a8e-42df-93bc-982da454d32d": {"__data__": {"id_": "cc53f633-1a8e-42df-93bc-982da454d32d", "embedding": null, "metadata": {"page_label": "1", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# Guide for Computer Systems Validation\n\n*Guide n\u00b0 33/2020 - version 1*", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas que podr\u00edan proporcionar respuestas espec\u00edficas basadas en el contexto del documento \"ANVISA Guide for Computer Systems Validation 33/2020\":\n\n1. **\u00bfCu\u00e1les son los principales requisitos establecidos por la ANVISA para la validaci\u00f3n de sistemas inform\u00e1ticos en el sector de la salud?**\n   - Esta pregunta busca detalles espec\u00edficos sobre los requisitos que la ANVISA establece en su gu\u00eda, que pueden no estar disponibles en otros documentos o fuentes.\n\n2. **\u00bfQu\u00e9 metodolog\u00edas o enfoques recomienda la ANVISA para llevar a cabo la validaci\u00f3n de sistemas inform\u00e1ticos?**\n   - Esta pregunta se centra en las metodolog\u00edas espec\u00edficas que la gu\u00eda sugiere, lo cual puede ser crucial para las organizaciones que buscan cumplir con las normativas de la ANVISA.\n\n3. **\u00bfQu\u00e9 implicaciones tiene la falta de validaci\u00f3n de sistemas inform\u00e1ticos seg\u00fan la gu\u00eda de la ANVISA?**\n   - Esta pregunta busca entender las consecuencias o riesgos asociados con no seguir las pautas de validaci\u00f3n, lo que puede ser un aspecto cr\u00edtico para las empresas en el sector de la salud.\n\n### Resumen de nivel superior:\nEl documento \"ANVISA Guide for Computer Systems Validation 33/2020\" proporciona directrices sobre c\u00f3mo las organizaciones del sector salud deben validar sus sistemas inform\u00e1ticos para garantizar la calidad y la conformidad con las regulaciones. La gu\u00eda aborda aspectos como los requisitos de validaci\u00f3n, las metodolog\u00edas recomendadas y las implicaciones de no cumplir con estas normativas.", "excerpt_keywords": "Keywords: ANVISA, computer systems validation, health sector, regulatory compliance, validation methodologies"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "ec2746c9-df75-4485-88c9-b0ad698a0979", "node_type": "4", "metadata": {"page_label": "1", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# Guide for Computer Systems Validation\n\n*Guide n\u00b0 33/2020 - version 1*", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "a5e66c5350d795934c6efaadb2337c12a7e21136557c5207593d7b57e3742279", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "# Guide for Computer Systems Validation\n\n*Guide n\u00b0 33/2020 - version 1*", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 71, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "12d10f50-b772-4758-985f-10aa807d40e3": {"__data__": {"id_": "12d10f50-b772-4758-985f-10aa807d40e3", "embedding": null, "metadata": {"page_label": "2", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# Guide for Computer Systems Validation\n\n**EFFECTIVE FROM 4/14/2020**\n\n**Start of the contribution period: 4/14/2020**\n\n**End of the contribution period: 08/12/2020**\n\nThis Guide expresses Anvisa's understanding of best practices with respect to procedures, routines and methods considered adequate to meet technical requirements or administrative requirements required by the Agency's legislative and regulatory frameworks.\n\nIt is a non-normative regulatory instrument, of a recommendatory and non-binding nature, therefore, it is possible to use alternative approaches to the propositions provided here, since compatible with the requirements related to the specific case. Failure to comply with the content of this document does not characterize a health violation, nor does it constitute a reason for refusing petitions, provided the requirements of the legislation are met.\n\nThe recommendations contained in this Guide take effect from the date of its publication on the Portal Anvisa, are subject to receiving suggestions from society through a form electronic.\n\nContributions received will be evaluated and may support the revision of the Guide and the consequent publication of a new version of the document. Regardless of the area's decision, it will be published general analysis of contributions and rational that justifies the revision or not of the Guide.\n\nOrdinance No. 1,741, of December 12, 2018, which provides for guidelines and procedures for quality improvement regulatory agency at the National Health Surveillance Agency (Anvisa).\n\nIn order to ensure greater transparency in the process of preparing the regulatory instruments issued by Anvisa, clarify that the names of those responsible for contributions (individuals and legal entities) are considered information public and will be made available in an unrestricted manner in reports and other documents generated from the results of this Guide. The participants' e-mail and CPF, which are considered direct confidential information, will have their access restricted to agents legally authorized public bodies and the persons to whom such information refers, as recommended in article 31, paragraph 1, of Law No. 12,527, of November 18, 2011. Other information that may be considered confidential by the participants may be joined in a specific field on the electronic form.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior del contenido:\n\n### Resumen de Nivel Superior\nEl documento es una gu\u00eda emitida por la Agencia Nacional de Vigilancia Sanitaria (Anvisa) de Brasil, que establece las mejores pr\u00e1cticas para la validaci\u00f3n de sistemas inform\u00e1ticos en el \u00e1mbito de la salud. Es un instrumento no normativo y de car\u00e1cter recomendatorio, lo que significa que no es obligatorio seguir sus directrices, aunque se espera que se cumplan los requisitos legales pertinentes. La gu\u00eda tambi\u00e9n menciona un proceso de contribuci\u00f3n p\u00fablica para recibir sugerencias y mejorar el documento, asegurando la transparencia en la gesti\u00f3n de las contribuciones.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfQu\u00e9 implicaciones tiene el car\u00e1cter no normativo de la gu\u00eda para las organizaciones que buscan cumplir con los requisitos de Anvisa?**\n   - La gu\u00eda es de car\u00e1cter recomendatorio y no vinculante, lo que permite a las organizaciones utilizar enfoques alternativos siempre que sean compatibles con los requisitos legales espec\u00edficos. Esto significa que no seguir las recomendaciones de la gu\u00eda no se considera una violaci\u00f3n de salud, siempre que se cumplan las normativas vigentes.\n\n2. **\u00bfC\u00f3mo se manejar\u00e1n las contribuciones recibidas de la sociedad en relaci\u00f3n con la gu\u00eda?**\n   - Las contribuciones ser\u00e1n evaluadas y podr\u00edan llevar a la revisi\u00f3n de la gu\u00eda, resultando en la publicaci\u00f3n de una nueva versi\u00f3n. Anvisa publicar\u00e1 un an\u00e1lisis general de las contribuciones y la justificaci\u00f3n de cualquier decisi\u00f3n tomada respecto a la revisi\u00f3n del documento.\n\n3. **\u00bfQu\u00e9 tipo de informaci\u00f3n se considera p\u00fablica y cu\u00e1l es confidencial en el proceso de contribuci\u00f3n?**\n   - Los nombres de los responsables de las contribuciones (tanto individuos como entidades legales) se consideran informaci\u00f3n p\u00fablica y se har\u00e1n accesibles en informes y documentos relacionados. Sin embargo, la informaci\u00f3n confidencial, como correos electr\u00f3nicos y CPF de los participantes, estar\u00e1 restringida a agentes autorizados y a las personas a las que se refiere dicha informaci\u00f3n, de acuerdo con la legislaci\u00f3n vigente.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\nEl documento \"ANVISA Guide for Computer Systems Validation 33/2020\" se centra en la validaci\u00f3n de sistemas inform\u00e1ticos en el sector de la salud, estableciendo directrices esenciales para garantizar la calidad y el cumplimiento normativo. Los temas clave incluyen:\n\n1. **Requisitos de Validaci\u00f3n**: Detalla los principales requisitos que las organizaciones deben cumplir para validar sus sistemas inform\u00e1ticos, asegurando que estos operen de manera efectiva y segura.\n\n2. **Metodolog\u00edas y Enfoques**: Proporciona recomendaciones sobre las metodolog\u00edas y enfoques que las organizaciones pueden adoptar para llevar a cabo la validaci\u00f3n de sus sistemas, lo que es crucial para cumplir con las normativas de la ANVISA.\n\n3. **Implicaciones de la Falta de Validaci\u00f3n**: Aborda las consecuencias y riesgos asociados con la falta de validaci\u00f3n de sistemas inform\u00e1ticos, enfatizando la importancia de seguir las pautas establecidas para evitar problemas legales y de calidad.\n\n### Entidades Clave\n\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil, responsable de regular y supervisar el sector de la salud.\n- **Sistemas Inform\u00e1ticos**: Herramientas y plataformas tecnol\u00f3gicas utilizadas en el sector salud que requieren validaci\u00f3n para asegurar su correcto funcionamiento y cumplimiento normativo.\n\nEste resumen proporciona una visi\u00f3n general de los aspectos m\u00e1s relevantes del documento, destacando su importancia para las organizaciones del sector salud en Brasil.", "excerpt_keywords": "Keywords: ANVISA, Computer Systems Validation, regulatory framework, best practices, non-normative guidelines"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "a9bd1347-1d55-4117-ad94-1570a52c7caa", "node_type": "4", "metadata": {"page_label": "2", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# Guide for Computer Systems Validation\n\n**EFFECTIVE FROM 4/14/2020**\n\n**Start of the contribution period: 4/14/2020**\n\n**End of the contribution period: 08/12/2020**\n\nThis Guide expresses Anvisa's understanding of best practices with respect to procedures, routines and methods considered adequate to meet technical requirements or administrative requirements required by the Agency's legislative and regulatory frameworks.\n\nIt is a non-normative regulatory instrument, of a recommendatory and non-binding nature, therefore, it is possible to use alternative approaches to the propositions provided here, since compatible with the requirements related to the specific case. Failure to comply with the content of this document does not characterize a health violation, nor does it constitute a reason for refusing petitions, provided the requirements of the legislation are met.\n\nThe recommendations contained in this Guide take effect from the date of its publication on the Portal Anvisa, are subject to receiving suggestions from society through a form electronic.\n\nContributions received will be evaluated and may support the revision of the Guide and the consequent publication of a new version of the document. Regardless of the area's decision, it will be published general analysis of contributions and rational that justifies the revision or not of the Guide.\n\nOrdinance No. 1,741, of December 12, 2018, which provides for guidelines and procedures for quality improvement regulatory agency at the National Health Surveillance Agency (Anvisa).\n\nIn order to ensure greater transparency in the process of preparing the regulatory instruments issued by Anvisa, clarify that the names of those responsible for contributions (individuals and legal entities) are considered information public and will be made available in an unrestricted manner in reports and other documents generated from the results of this Guide. The participants' e-mail and CPF, which are considered direct confidential information, will have their access restricted to agents legally authorized public bodies and the persons to whom such information refers, as recommended in article 31, paragraph 1, of Law No. 12,527, of November 18, 2011. Other information that may be considered confidential by the participants may be joined in a specific field on the electronic form.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "1cb2107fc5c1635c0a96c02ec501b5e61211f3fd8a90ee9cbebb99b466250d6c", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "# Guide for Computer Systems Validation\n\n**EFFECTIVE FROM 4/14/2020**\n\n**Start of the contribution period: 4/14/2020**\n\n**End of the contribution period: 08/12/2020**\n\nThis Guide expresses Anvisa's understanding of best practices with respect to procedures, routines and methods considered adequate to meet technical requirements or administrative requirements required by the Agency's legislative and regulatory frameworks.\n\nIt is a non-normative regulatory instrument, of a recommendatory and non-binding nature, therefore, it is possible to use alternative approaches to the propositions provided here, since compatible with the requirements related to the specific case. Failure to comply with the content of this document does not characterize a health violation, nor does it constitute a reason for refusing petitions, provided the requirements of the legislation are met.\n\nThe recommendations contained in this Guide take effect from the date of its publication on the Portal Anvisa, are subject to receiving suggestions from society through a form electronic.\n\nContributions received will be evaluated and may support the revision of the Guide and the consequent publication of a new version of the document. Regardless of the area's decision, it will be published general analysis of contributions and rational that justifies the revision or not of the Guide.\n\nOrdinance No. 1,741, of December 12, 2018, which provides for guidelines and procedures for quality improvement regulatory agency at the National Health Surveillance Agency (Anvisa).\n\nIn order to ensure greater transparency in the process of preparing the regulatory instruments issued by Anvisa, clarify that the names of those responsible for contributions (individuals and legal entities) are considered information public and will be made available in an unrestricted manner in reports and other documents generated from the results of this Guide. The participants' e-mail and CPF, which are considered direct confidential information, will have their access restricted to agents legally authorized public bodies and the persons to whom such information refers, as recommended in article 31, paragraph 1, of Law No. 12,527, of November 18, 2011. Other information that may be considered confidential by the participants may be joined in a specific field on the electronic form.", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 2351, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "adba163d-3a2c-4ab6-b0d2-9fc1cdcd94bf": {"__data__": {"id_": "adba163d-3a2c-4ab6-b0d2-9fc1cdcd94bf", "embedding": null, "metadata": {"page_label": "3", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# SUMMARY\n\n1. **SCOPE**\n.................................................................................................................. 5\n\n2. **INTRODUCTION**\n.................................................................................................................. 5\n\n3. **LEGAL BASE**\n.................................................................................................................. 5\n\n4. **CONCEPTS, TERMS AND DEFINITIONS**\n.................................................................................................................. 5\n\n4.1 **KEY CONCEPTS**\n.................................................................................................................. 5\n\n4.2 **KEY TERMS**\n.................................................................................................................. 7\n\n5. **LIFE CYCLE APPROACH**\n.................................................................................................................. 9\n\n5.1 **INTRODUCTION**\n.................................................................................................................. 9\n\n5.2 **LIFE CYCLE OF COMPUTERIZED SYSTEMS**\n.................................................................................................................. 10\n\n5.3 **COMPUTERIZED SYSTEM VALIDATION STRUCTURE**\n.................................................................................................................. 11\n\n6. **QUALITY RISK MANAGEMENT**\n.................................................................................................................. 13\n\n6.1 **INTRODUCTION**\n.................................................................................................................. 13\n\n6.2 **QUALITY RISK MANAGEMENT WITH SCIENTIFIC BASIS**\n.................................................................................................................. 14\n\n6.3 **QUALITY RISK MANAGEMENT PROCESS**\n.................................................................................................................. 14\n\n7. **SOFTWARE AND HARDWARE CATEGORIZATION**\n.................................................................................................................. 17\n\n7.1 **INTRODUCTION**\n.................................................................................................................. 17\n\n7.2 **USE OF GAMP CATEGORIES**\n.................................................................................................................. 17\n\n7.3 **SOFTWARE CATEGORIES**\n.................................................................................................................. 18\n\n7.4 **HARDWARE CATEGORIES**\n.................................................................................................................. 21\n\n8. **INVENTORY LIST**\n.................................................................................................................. 22\n\n9. **VALIDATION OF COMPUTERIZED SYSTEMS**\n.................................................................................................................. 22\n\n9.1 **INTRODUCTION**\n.................................................................................................................. 22\n\n9.2 **VALIDATION PLAN**\n.................................................................................................................. 24\n\n9.3 **DOCUMENT CONTAINING USER REQUIREMENTS SPECIFICATIONS (ERU/URS)**\n.................................................................................................................. 27", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas que pueden proporcionar respuestas espec\u00edficas basadas en el contexto del documento \"ANVISA - Guide for Computer Systems Validation 33/2020\":\n\n1. **\u00bfCu\u00e1les son los principales conceptos y t\u00e9rminos definidos en la secci\u00f3n 4 del documento, y por qu\u00e9 son importantes para la validaci\u00f3n de sistemas computarizados?**\n   - Esta pregunta busca profundizar en la secci\u00f3n de conceptos y t\u00e9rminos, que es fundamental para entender el marco de referencia del documento.\n\n2. **\u00bfQu\u00e9 pasos se describen en el proceso de gesti\u00f3n de riesgos de calidad en la secci\u00f3n 6, y c\u00f3mo se aplican a la validaci\u00f3n de sistemas computarizados?**\n   - Esta pregunta se centra en el proceso de gesti\u00f3n de riesgos, que es crucial para garantizar la calidad y la seguridad en la validaci\u00f3n de sistemas.\n\n3. **\u00bfC\u00f3mo se categoriza el software y hardware en la secci\u00f3n 7, y qu\u00e9 criterios se utilizan para determinar estas categor\u00edas?**\n   - Esta pregunta busca explorar la categorizaci\u00f3n de software y hardware, lo cual es esencial para aplicar un enfoque adecuado en la validaci\u00f3n de sistemas.\n\n### Res\u00famenes de nivel superior del contexto circundante:\n\n- **Alcance y Objetivo del Documento:** El documento establece directrices para la validaci\u00f3n de sistemas computarizados en el contexto de la regulaci\u00f3n de la ANVISA, asegurando que estos sistemas cumplan con los est\u00e1ndares de calidad y seguridad requeridos en la industria.\n\n- **Enfoque del Ciclo de Vida:** Se presenta un enfoque basado en el ciclo de vida para la validaci\u00f3n de sistemas, que incluye desde la planificaci\u00f3n hasta la ejecuci\u00f3n y el mantenimiento, asegurando que cada etapa del ciclo se gestione adecuadamente.\n\n- **Gesti\u00f3n de Riesgos de Calidad:** Se enfatiza la importancia de la gesti\u00f3n de riesgos de calidad, proporcionando un marco para identificar, evaluar y mitigar riesgos asociados con el uso de sistemas computarizados en entornos regulados.\n\nEstos res\u00famenes pueden ayudar a formular preguntas m\u00e1s espec\u00edficas y relevantes sobre el contenido del documento.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n**Temas Clave:**\n\n1. **Gu\u00eda de Validaci\u00f3n de Sistemas Inform\u00e1ticos:** El documento establece las mejores pr\u00e1cticas para la validaci\u00f3n de sistemas inform\u00e1ticos en el \u00e1mbito de la salud, seg\u00fan la Agencia Nacional de Vigilancia Sanitaria (Anvisa).\n\n2. **Car\u00e1cter No Normativo:** La gu\u00eda es un instrumento no vinculante y recomendatorio, lo que permite a las organizaciones adoptar enfoques alternativos siempre que cumplan con los requisitos legales pertinentes.\n\n3. **Proceso de Contribuci\u00f3n P\u00fablica:** Se establece un mecanismo para recibir sugerencias de la sociedad, que ser\u00e1n evaluadas y podr\u00edan llevar a la revisi\u00f3n de la gu\u00eda.\n\n4. **Transparencia en la Gesti\u00f3n de Contribuciones:** Se aclara que los nombres de los contribuyentes ser\u00e1n p\u00fablicos, mientras que la informaci\u00f3n confidencial, como correos electr\u00f3nicos y CPF, estar\u00e1 restringida a agentes autorizados.\n\n5. **Vigencia de la Gu\u00eda:** Las recomendaciones son efectivas desde la fecha de publicaci\u00f3n en el Portal Anvisa y est\u00e1n sujetas a revisi\u00f3n en funci\u00f3n de las contribuciones recibidas.\n\n**Entidades:**\n\n- **ANVISA (Agencia Nacional de Vigilancia Sanitaria):** La entidad responsable de emitir la gu\u00eda y regular las pr\u00e1cticas de validaci\u00f3n de sistemas inform\u00e1ticos en el sector salud en Brasil.\n\n- **Contribuyentes:** Individuos y entidades que aportan sugerencias para la mejora de la gu\u00eda.\n\n- **Legislaci\u00f3n:** Referencias a leyes y normativas que regulan la transparencia y el manejo de informaci\u00f3n confidencial, como la Ley No. 12,527 de 2011.\n\nEste resumen destaca los aspectos m\u00e1s relevantes del documento, as\u00ed como las entidades involucradas en su creaci\u00f3n y aplicaci\u00f3n.", "excerpt_keywords": "Keywords: validation, computerized systems, quality risk management, software categorization, ANVISA"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "3f08a92e-1331-4339-957a-a549ee49a71c", "node_type": "4", "metadata": {"page_label": "3", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# SUMMARY\n\n1. **SCOPE**\n.................................................................................................................. 5\n\n2. **INTRODUCTION**\n.................................................................................................................. 5\n\n3. **LEGAL BASE**\n.................................................................................................................. 5\n\n4. **CONCEPTS, TERMS AND DEFINITIONS**\n.................................................................................................................. 5\n\n4.1 **KEY CONCEPTS**\n.................................................................................................................. 5\n\n4.2 **KEY TERMS**\n.................................................................................................................. 7\n\n5. **LIFE CYCLE APPROACH**\n.................................................................................................................. 9\n\n5.1 **INTRODUCTION**\n.................................................................................................................. 9\n\n5.2 **LIFE CYCLE OF COMPUTERIZED SYSTEMS**\n.................................................................................................................. 10\n\n5.3 **COMPUTERIZED SYSTEM VALIDATION STRUCTURE**\n.................................................................................................................. 11\n\n6. **QUALITY RISK MANAGEMENT**\n.................................................................................................................. 13\n\n6.1 **INTRODUCTION**\n.................................................................................................................. 13\n\n6.2 **QUALITY RISK MANAGEMENT WITH SCIENTIFIC BASIS**\n.................................................................................................................. 14\n\n6.3 **QUALITY RISK MANAGEMENT PROCESS**\n.................................................................................................................. 14\n\n7. **SOFTWARE AND HARDWARE CATEGORIZATION**\n.................................................................................................................. 17\n\n7.1 **INTRODUCTION**\n.................................................................................................................. 17\n\n7.2 **USE OF GAMP CATEGORIES**\n.................................................................................................................. 17\n\n7.3 **SOFTWARE CATEGORIES**\n.................................................................................................................. 18\n\n7.4 **HARDWARE CATEGORIES**\n.................................................................................................................. 21\n\n8. **INVENTORY LIST**\n.................................................................................................................. 22\n\n9. **VALIDATION OF COMPUTERIZED SYSTEMS**\n.................................................................................................................. 22\n\n9.1 **INTRODUCTION**\n.................................................................................................................. 22\n\n9.2 **VALIDATION PLAN**\n.................................................................................................................. 24\n\n9.3 **DOCUMENT CONTAINING USER REQUIREMENTS SPECIFICATIONS (ERU/URS)**\n.................................................................................................................. 27", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "ae54e6e6c91080a2a7a2ad4d4f5240503332fad0430c4a9523d9e8a465fb19c1", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "# SUMMARY\n\n1. **SCOPE**\n.................................................................................................................. 5\n\n2. **INTRODUCTION**\n.................................................................................................................. 5\n\n3. **LEGAL BASE**\n.................................................................................................................. 5\n\n4. **CONCEPTS, TERMS AND DEFINITIONS**\n.................................................................................................................. 5\n\n4.1 **KEY CONCEPTS**\n.................................................................................................................. 5\n\n4.2 **KEY TERMS**\n.................................................................................................................. 7\n\n5. **LIFE CYCLE APPROACH**\n.................................................................................................................. 9\n\n5.1 **INTRODUCTION**\n.................................................................................................................. 9\n\n5.2 **LIFE CYCLE OF COMPUTERIZED SYSTEMS**\n.................................................................................................................. 10\n\n5.3 **COMPUTERIZED SYSTEM VALIDATION STRUCTURE**\n.................................................................................................................. 11\n\n6. **QUALITY RISK MANAGEMENT**\n.................................................................................................................. 13\n\n6.1 **INTRODUCTION**\n.................................................................................................................. 13\n\n6.2 **QUALITY RISK MANAGEMENT WITH SCIENTIFIC BASIS**\n.................................................................................................................. 14\n\n6.3 **QUALITY RISK MANAGEMENT PROCESS**\n.................................................................................................................. 14\n\n7. **SOFTWARE AND HARDWARE CATEGORIZATION**\n.................................................................................................................. 17\n\n7.1 **INTRODUCTION**\n.................................................................................................................. 17\n\n7.2 **USE OF GAMP CATEGORIES**\n.................................................................................................................. 17\n\n7.3 **SOFTWARE CATEGORIES**\n.................................................................................................................. 18\n\n7.4 **HARDWARE CATEGORIES**\n.................................................................................................................. 21\n\n8. **INVENTORY LIST**\n.................................................................................................................. 22\n\n9. **VALIDATION OF COMPUTERIZED SYSTEMS**\n.................................................................................................................. 22\n\n9.1 **INTRODUCTION**\n.................................................................................................................. 22\n\n9.2 **VALIDATION PLAN**\n.................................................................................................................. 24\n\n9.3 **DOCUMENT CONTAINING USER REQUIREMENTS SPECIFICATIONS (ERU/URS)**\n.................................................................................................................. 27", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 3604, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "d0fb92e5-8538-445f-9d90-f23ea47246ab": {"__data__": {"id_": "d0fb92e5-8538-445f-9d90-f23ea47246ab", "embedding": null, "metadata": {"page_label": "4", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# Guide for Computer Systems Validation\n\n## 9.4 SELECTION OF COMPUTER SYSTEMS SUPPLIER\n... 32\n\n## 9.5 DOCUMENT CONTAINING FUNCTIONAL SPECIFICATIONS (EF / FS)\n... 33\n\n## 9.6 DOCUMENT CONTAINING THE CONFIGURATION AND THE PROJECT\n... 36\n\n## 9.7 TESTING PLAN FOR COMPUTERIZED SYSTEMS\n... 41\n\n## 9.8 COMPLEMENTARY ACTIVITIES\n... 54\n\n## 9.9 VALIDATION REPORT\n... 57\n\n## 10. INVENTORY LIST\n... 59\n\n## 11. OPERATIONAL PHASE OF COMPUTERIZED SYSTEMS\n... 60\n\n### 11.1 INTRODUCTION\n... 60\n\n### 11.2 SYSTEM DELIVERY\n... 61\n\n### 11.3 SUPPORT SERVICE MANAGEMENT\n... 62\n\n## 11.4 MONITORING SYSTEM PERFORMANCE\n... 63\n\n## 11.5 INCIDENT MANAGEMENT\n... 66\n\n## 11.6 CORRECTIVE AND PREVENTIVE ACTIONS (COVER)\n... 67\n\n## 11.7 MANAGEMENT OF CHANGES AND SYSTEM CONFIGURATION\n... 68\n\n## 11.8 SYSTEM REPAIR ACTIVITIES\n... 71\n\n## 11.9 PERIODIC REVIEW\n... 73\n\n## 11.10 BACKUP AND RESTORATION\n... 75\n\n## 11.11 BUSINESS CONTINUITY PLANNING / DISASTER RECOVERY\n... 79\n\n## 11.12 SYSTEM SECURITY MANAGEMENT\n... 81\n\n## 11.13 SYSTEM ADMINISTRATION\n... 82\n\n## 11.14 RECORD MANAGEMENT (RETENTION, ARCHIVING AND RECOVERY)\n... 83\n\n## 12 DATA MIGRATION\n... 85\n\n### 12.1 INTRODUCTION\n... 85\n\n### 12.2 QUALITY MANAGEMENT\n... 86\n\n### 12.3 IMPORTANT POINTS\n... 87\n\n### 12.4 DATA MIGRATION PLAN\n... 89\n\n### 12.5 DATA MIGRATION REPORT\n... 90\n\n## 13 RETIREMENT OF COMPUTERIZED SYSTEMS\n... 90\n\n### 13.1 INTRODUCTION\n... 90\n\n### 13.2 SYSTEM RETIREMENT PLAN\n... 91\n\n### 13.3 SYSTEM RETIREMENT REPORT\n... 93\n\n## 14. VALIDATION OF SHEETS\n... 94", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento \"ANVISA - Guide for Computer Systems Validation 33/2020\" es una gu\u00eda que establece los lineamientos y procedimientos para la validaci\u00f3n de sistemas computacionales en el \u00e1mbito regulado por ANVISA (Ag\u00eancia Nacional de Vigil\u00e2ncia Sanit\u00e1ria) en Brasil. La gu\u00eda abarca desde la selecci\u00f3n de proveedores de sistemas hasta la gesti\u00f3n de cambios, la seguridad del sistema y la planificaci\u00f3n de la continuidad del negocio. Tambi\u00e9n incluye secciones sobre la migraci\u00f3n de datos y el retiro de sistemas, asegurando que todos los aspectos del ciclo de vida del sistema est\u00e9n debidamente documentados y validados.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfCu\u00e1les son los elementos clave que deben incluirse en un \"Plan de Migraci\u00f3n de Datos\" seg\u00fan la gu\u00eda?**\n   - Esta pregunta busca detalles espec\u00edficos sobre los requisitos y consideraciones que deben tenerse en cuenta al planificar la migraci\u00f3n de datos, que se menciona en la secci\u00f3n 12.\n\n2. **\u00bfQu\u00e9 aspectos se deben considerar en la \"Gesti\u00f3n de Cambios y Configuraci\u00f3n del Sistema\" seg\u00fan la gu\u00eda de ANVISA?**\n   - Esta pregunta se centra en los procedimientos y pr\u00e1cticas recomendadas para gestionar cambios en los sistemas computacionales, lo cual es crucial para mantener la integridad y la validaci\u00f3n del sistema.\n\n3. **\u00bfQu\u00e9 se debe incluir en un \"Informe de Validaci\u00f3n\" y cu\u00e1l es su prop\u00f3sito dentro del proceso de validaci\u00f3n de sistemas?**\n   - Esta pregunta busca informaci\u00f3n sobre el contenido y la importancia del informe de validaci\u00f3n, que es un documento clave en el proceso de validaci\u00f3n de sistemas computacionales seg\u00fan la gu\u00eda. \n\nEstas preguntas est\u00e1n dise\u00f1adas para extraer informaci\u00f3n espec\u00edfica que puede no estar disponible en otras fuentes, enfoc\u00e1ndose en los detalles y procedimientos que la gu\u00eda establece.", "prev_section_summary": "### Resumen de Temas Clave y Entidades de la Secci\u00f3n\n\n1. **Alcance (SCOPE)**: Define el \u00e1mbito de aplicaci\u00f3n del documento, estableciendo las directrices para la validaci\u00f3n de sistemas computarizados en el contexto regulatorio de ANVISA.\n\n2. **Introducci\u00f3n (INTRODUCTION)**: Presenta el prop\u00f3sito del documento y su relevancia en la industria, as\u00ed como una visi\u00f3n general de los temas que se abordar\u00e1n.\n\n3. **Base Legal (LEGAL BASE)**: Describe el marco legal que sustenta las directrices de validaci\u00f3n, asegurando que se alineen con las normativas vigentes.\n\n4. **Conceptos, T\u00e9rminos y Definiciones (CONCEPTS, TERMS AND DEFINITIONS)**:\n   - **Conceptos Clave (KEY CONCEPTS)**: Introduce los conceptos fundamentales que son esenciales para la comprensi\u00f3n de la validaci\u00f3n de sistemas.\n   - **T\u00e9rminos Clave (KEY TERMS)**: Define t\u00e9rminos espec\u00edficos utilizados en el documento, facilitando una comunicaci\u00f3n clara y precisa.\n\n5. **Enfoque del Ciclo de Vida (LIFE CYCLE APPROACH)**:\n   - **Ciclo de Vida de Sistemas Computarizados (LIFE CYCLE OF COMPUTERIZED SYSTEMS)**: Detalla las etapas del ciclo de vida que deben considerarse en la validaci\u00f3n.\n   - **Estructura de Validaci\u00f3n de Sistemas Computarizados (COMPUTERIZED SYSTEM VALIDATION STRUCTURE)**: Describe c\u00f3mo se organiza el proceso de validaci\u00f3n a lo largo del ciclo de vida.\n\n6. **Gesti\u00f3n de Riesgos de Calidad (QUALITY RISK MANAGEMENT)**:\n   - **Gesti\u00f3n de Riesgos con Base Cient\u00edfica (QUALITY RISK MANAGEMENT WITH SCIENTIFIC BASIS)**: Enfatiza la importancia de un enfoque basado en evidencia para la gesti\u00f3n de riesgos.\n   - **Proceso de Gesti\u00f3n de Riesgos (QUALITY RISK MANAGEMENT PROCESS)**: Especifica los pasos a seguir para identificar y mitigar riesgos en la validaci\u00f3n de sistemas.\n\n7. **Categorizaci\u00f3n de Software y Hardware (SOFTWARE AND HARDWARE CATEGORIZATION)**:\n   - **Uso de Categor\u00edas GAMP (USE OF GAMP CATEGORIES)**: Explica c\u00f3mo se aplican las categor\u00edas GAMP para clasificar software y hardware.\n   - **Categor\u00edas de Software (SOFTWARE CATEGORIES)** y **Categor\u00edas de Hardware (HARDWARE CATEGORIES)**: Proporciona criterios para clasificar diferentes tipos de software y hardware utilizados en sistemas computarizados.\n\n8. **Lista de Inventario (INVENTORY LIST)**: Presenta un listado de los sistemas y componentes que requieren validaci\u00f3n.\n\n9. **Validaci\u00f3n de Sistemas Computarizados (VALIDATION OF COMPUTERIZED SYSTEMS)**:\n   - **Plan de Validaci\u00f3n (VALIDATION PLAN)**: Describe c\u00f3mo se debe estructurar un plan de validaci\u00f3n efectivo.\n   - **Documento de Especificaciones de Requisitos del Usuario (ERU/URS)**: Detalla la importancia de documentar los requisitos del usuario para asegurar que el sistema cumpla con las expectativas y necesidades.\n\nEste resumen abarca los temas clave y entidades presentes en la secci\u00f3n, proporcionando una visi\u00f3n general de los aspectos fundamentales relacionados con la validaci\u00f3n de sistemas computarizados seg\u00fan las directrices de ANVISA.", "excerpt_keywords": "Keywords: validation, computerized systems, ANVISA, data migration, system retirement"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "a76cf395-5ffe-422f-8188-30d4bcb04aed", "node_type": "4", "metadata": {"page_label": "4", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# Guide for Computer Systems Validation\n\n## 9.4 SELECTION OF COMPUTER SYSTEMS SUPPLIER\n... 32\n\n## 9.5 DOCUMENT CONTAINING FUNCTIONAL SPECIFICATIONS (EF / FS)\n... 33\n\n## 9.6 DOCUMENT CONTAINING THE CONFIGURATION AND THE PROJECT\n... 36\n\n## 9.7 TESTING PLAN FOR COMPUTERIZED SYSTEMS\n... 41\n\n## 9.8 COMPLEMENTARY ACTIVITIES\n... 54\n\n## 9.9 VALIDATION REPORT\n... 57\n\n## 10. INVENTORY LIST\n... 59\n\n## 11. OPERATIONAL PHASE OF COMPUTERIZED SYSTEMS\n... 60\n\n### 11.1 INTRODUCTION\n... 60\n\n### 11.2 SYSTEM DELIVERY\n... 61\n\n### 11.3 SUPPORT SERVICE MANAGEMENT\n... 62\n\n## 11.4 MONITORING SYSTEM PERFORMANCE\n... 63\n\n## 11.5 INCIDENT MANAGEMENT\n... 66\n\n## 11.6 CORRECTIVE AND PREVENTIVE ACTIONS (COVER)\n... 67\n\n## 11.7 MANAGEMENT OF CHANGES AND SYSTEM CONFIGURATION\n... 68\n\n## 11.8 SYSTEM REPAIR ACTIVITIES\n... 71\n\n## 11.9 PERIODIC REVIEW\n... 73\n\n## 11.10 BACKUP AND RESTORATION\n... 75\n\n## 11.11 BUSINESS CONTINUITY PLANNING / DISASTER RECOVERY\n... 79\n\n## 11.12 SYSTEM SECURITY MANAGEMENT\n... 81\n\n## 11.13 SYSTEM ADMINISTRATION\n... 82\n\n## 11.14 RECORD MANAGEMENT (RETENTION, ARCHIVING AND RECOVERY)\n... 83\n\n## 12 DATA MIGRATION\n... 85\n\n### 12.1 INTRODUCTION\n... 85\n\n### 12.2 QUALITY MANAGEMENT\n... 86\n\n### 12.3 IMPORTANT POINTS\n... 87\n\n### 12.4 DATA MIGRATION PLAN\n... 89\n\n### 12.5 DATA MIGRATION REPORT\n... 90\n\n## 13 RETIREMENT OF COMPUTERIZED SYSTEMS\n... 90\n\n### 13.1 INTRODUCTION\n... 90\n\n### 13.2 SYSTEM RETIREMENT PLAN\n... 91\n\n### 13.3 SYSTEM RETIREMENT REPORT\n... 93\n\n## 14. VALIDATION OF SHEETS\n... 94", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "6eb1f923f3b8a7fbbeb4aa3116896fdf44a6e8e9e8ffea332531fc29957cf80c", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "# Guide for Computer Systems Validation\n\n## 9.4 SELECTION OF COMPUTER SYSTEMS SUPPLIER\n... 32\n\n## 9.5 DOCUMENT CONTAINING FUNCTIONAL SPECIFICATIONS (EF / FS)\n... 33\n\n## 9.6 DOCUMENT CONTAINING THE CONFIGURATION AND THE PROJECT\n... 36\n\n## 9.7 TESTING PLAN FOR COMPUTERIZED SYSTEMS\n... 41\n\n## 9.8 COMPLEMENTARY ACTIVITIES\n... 54\n\n## 9.9 VALIDATION REPORT\n... 57\n\n## 10. INVENTORY LIST\n... 59\n\n## 11. OPERATIONAL PHASE OF COMPUTERIZED SYSTEMS\n... 60\n\n### 11.1 INTRODUCTION\n... 60\n\n### 11.2 SYSTEM DELIVERY\n... 61\n\n### 11.3 SUPPORT SERVICE MANAGEMENT\n... 62\n\n## 11.4 MONITORING SYSTEM PERFORMANCE\n... 63\n\n## 11.5 INCIDENT MANAGEMENT\n... 66\n\n## 11.6 CORRECTIVE AND PREVENTIVE ACTIONS (COVER)\n... 67\n\n## 11.7 MANAGEMENT OF CHANGES AND SYSTEM CONFIGURATION\n... 68\n\n## 11.8 SYSTEM REPAIR ACTIVITIES\n... 71\n\n## 11.9 PERIODIC REVIEW\n... 73\n\n## 11.10 BACKUP AND RESTORATION\n... 75\n\n## 11.11 BUSINESS CONTINUITY PLANNING / DISASTER RECOVERY\n... 79\n\n## 11.12 SYSTEM SECURITY MANAGEMENT\n... 81\n\n## 11.13 SYSTEM ADMINISTRATION\n... 82\n\n## 11.14 RECORD MANAGEMENT (RETENTION, ARCHIVING AND RECOVERY)\n... 83\n\n## 12 DATA MIGRATION\n... 85\n\n### 12.1 INTRODUCTION\n... 85\n\n### 12.2 QUALITY MANAGEMENT\n... 86\n\n### 12.3 IMPORTANT POINTS\n... 87\n\n### 12.4 DATA MIGRATION PLAN\n... 89\n\n### 12.5 DATA MIGRATION REPORT\n... 90\n\n## 13 RETIREMENT OF COMPUTERIZED SYSTEMS\n... 90\n\n### 13.1 INTRODUCTION\n... 90\n\n### 13.2 SYSTEM RETIREMENT PLAN\n... 91\n\n### 13.3 SYSTEM RETIREMENT REPORT\n... 93\n\n## 14. VALIDATION OF SHEETS\n... 94", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 1491, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "60edc40c-35bd-4e67-81b5-91322b4abecc": {"__data__": {"id_": "60edc40c-35bd-4e67-81b5-91322b4abecc", "embedding": null, "metadata": {"page_label": "5", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# Guide for Computer Systems Validation\n\n## Table of Contents\n\n- **14.1 INTRODUCTION** ........................................................................................................... 94\n- **14.2 TYPES OF APPLICATIONS FOR END USER** .......................................................... 94\n- **14.3 RISK-BASED APPROACH** ......................................................................................... 96\n- **14.4 USE OF GAMP CATEGORIES** .................................................................................. 97\n- **14.5 RISK-BASED CONTROLS** ......................................................................................... 97\n- **14.6 APPROACHES FOR VALIDATION** .......................................................................... 99\n- **15 FINAL CONSIDERATIONS** .......................................................................................... 101\n- **16 GLOSSARY AND ACRONYMS** ................................................................................... 101\n- **17 BIBLIOGRAPHICAL REFERENCES** .......................................................................... 103\n- **17.1 REGULATORY** ....................................................................................................... 103\n- **17.2 TECHNIQUES** ......................................................................................................... 103\n\n----\n\n## 1. SCOPE\n\nThe purpose of this guide is to propose guidelines to help obtain, by the regulated sector, computer systems correctly installed and validated and that meet regulatory requirements.\n\nThis Guide is applicable to the computerized systems used in the areas, equipment and other activities relevant to Good Manufacturing Practices for Inputs and Medicines. The proposal is to internalize the document GAMP 5 in order to facilitate the reader's understanding of the guidelines proposed by that international guide.\n\nThe scope of this Guide includes computerized systems categories 3, 4 and 5, the interfaces between systems and spreadsheets.\n\nThe above mentioned systems are included, installed in stand-alone or network architecture, this network to be installed locally, nationally or globally.\n\nThis guide replaces the eponymous guide published by this Agency in April 2010.\n\n## 2. INTRODUCTION\n\nIf the regulated company decides to use this Guide, it is recommended that its implementation be carried out in its entirety (where applicable) and not partially, since all the activities described in this document are necessary jointly for the achievement of an adequate sequence of acquisition, validation, operationalization and finally retirement of the computerized system, especially for more complex systems.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento es una gu\u00eda de ANVISA (Ag\u00eancia Nacional de Vigil\u00e2ncia Sanit\u00e1ria) sobre la validaci\u00f3n de sistemas inform\u00e1ticos, aplicable a la industria regulada de medicamentos y productos de salud. La gu\u00eda propone directrices para asegurar que los sistemas inform\u00e1ticos est\u00e9n correctamente instalados y validados, cumpliendo con los requisitos regulatorios. Se enfoca en sistemas de categor\u00edas 3, 4 y 5, y enfatiza la importancia de implementar todas las actividades descritas en el documento de manera conjunta para lograr una validaci\u00f3n adecuada.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfCu\u00e1les son las categor\u00edas de sistemas inform\u00e1ticos que abarca la gu\u00eda de ANVISA y qu\u00e9 tipos de sistemas se incluyen en cada categor\u00eda?**\n   - La gu\u00eda se aplica a los sistemas inform\u00e1ticos de categor\u00edas 3, 4 y 5, as\u00ed como a las interfaces entre sistemas y hojas de c\u00e1lculo.\n\n2. **\u00bfPor qu\u00e9 es importante implementar la gu\u00eda de ANVISA en su totalidad y no de manera parcial?**\n   - La implementaci\u00f3n completa es crucial porque todas las actividades descritas en el documento son necesarias de manera conjunta para asegurar una secuencia adecuada de adquisici\u00f3n, validaci\u00f3n, operaci\u00f3n y eventual retiro del sistema inform\u00e1tico, especialmente en sistemas m\u00e1s complejos.\n\n3. **\u00bfQu\u00e9 documento internacional se busca internalizar en la gu\u00eda de ANVISA y cu\u00e1l es su prop\u00f3sito?**\n   - La gu\u00eda busca internalizar el documento GAMP 5, con el prop\u00f3sito de facilitar la comprensi\u00f3n de las directrices propuestas por esa gu\u00eda internacional en el contexto de la validaci\u00f3n de sistemas inform\u00e1ticos en el sector regulado.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\nEl documento \"ANVISA - Guide for Computer Systems Validation 33/2020\" aborda diversos aspectos relacionados con la validaci\u00f3n de sistemas computacionales en el contexto regulado por ANVISA. A continuaci\u00f3n se presentan los temas clave y entidades mencionadas en la secci\u00f3n:\n\n1. **Selecci\u00f3n de Proveedores de Sistemas Computacionales**:\n   - Importancia de elegir proveedores adecuados para garantizar la calidad y conformidad de los sistemas.\n\n2. **Documentaci\u00f3n de Especificaciones Funcionales (EF / FS)**:\n   - Necesidad de tener documentos claros que definan las funcionalidades requeridas del sistema.\n\n3. **Configuraci\u00f3n y Proyecto del Sistema**:\n   - Documentaci\u00f3n que detalla la configuraci\u00f3n del sistema y su dise\u00f1o.\n\n4. **Plan de Pruebas para Sistemas Computacionales**:\n   - Estrategias y procedimientos para validar que el sistema funcione como se espera.\n\n5. **Informe de Validaci\u00f3n**:\n   - Documento que resume los resultados de la validaci\u00f3n y su importancia en el proceso.\n\n6. **Fase Operativa de Sistemas Computacionales**:\n   - Incluye la entrega del sistema, gesti\u00f3n del soporte, y monitoreo del rendimiento.\n\n7. **Gesti\u00f3n de Cambios y Configuraci\u00f3n del Sistema**:\n   - Procedimientos para manejar cambios en el sistema y asegurar su integridad.\n\n8. **Migraci\u00f3n de Datos**:\n   - Proceso de trasladar datos de un sistema a otro, incluyendo la planificaci\u00f3n y gesti\u00f3n de calidad.\n\n9. **Retiro de Sistemas Computacionales**:\n   - Proceso y documentaci\u00f3n necesaria para la desactivaci\u00f3n de sistemas obsoletos.\n\n10. **Validaci\u00f3n de Hojas**:\n    - Proceso de validaci\u00f3n espec\u00edfico para documentos y hojas de c\u00e1lculo utilizadas en el sistema.\n\n### Entidades Clave\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria en Brasil.\n- **Sistemas Computacionales**: Software y hardware utilizados en el \u00e1mbito regulado.\n- **Proveedores de Sistemas**: Empresas o individuos que ofrecen soluciones de software.\n- **Documentaci\u00f3n**: Informes y planes que detallan los procesos de validaci\u00f3n y operaci\u00f3n.\n\nEste resumen proporciona una visi\u00f3n general de los temas y entidades clave que se abordan en la gu\u00eda, destacando la importancia de la validaci\u00f3n y gesti\u00f3n de sistemas computacionales en el contexto regulado.", "excerpt_keywords": "Keywords: ANVISA, computer systems validation, GAMP 5, regulatory compliance, Good Manufacturing Practices"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "4c4570df-4b29-448d-9673-43faf57b3599", "node_type": "4", "metadata": {"page_label": "5", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# Guide for Computer Systems Validation\n\n## Table of Contents\n\n- **14.1 INTRODUCTION** ........................................................................................................... 94\n- **14.2 TYPES OF APPLICATIONS FOR END USER** .......................................................... 94\n- **14.3 RISK-BASED APPROACH** ......................................................................................... 96\n- **14.4 USE OF GAMP CATEGORIES** .................................................................................. 97\n- **14.5 RISK-BASED CONTROLS** ......................................................................................... 97\n- **14.6 APPROACHES FOR VALIDATION** .......................................................................... 99\n- **15 FINAL CONSIDERATIONS** .......................................................................................... 101\n- **16 GLOSSARY AND ACRONYMS** ................................................................................... 101\n- **17 BIBLIOGRAPHICAL REFERENCES** .......................................................................... 103\n- **17.1 REGULATORY** ....................................................................................................... 103\n- **17.2 TECHNIQUES** ......................................................................................................... 103\n\n----\n\n## 1. SCOPE\n\nThe purpose of this guide is to propose guidelines to help obtain, by the regulated sector, computer systems correctly installed and validated and that meet regulatory requirements.\n\nThis Guide is applicable to the computerized systems used in the areas, equipment and other activities relevant to Good Manufacturing Practices for Inputs and Medicines. The proposal is to internalize the document GAMP 5 in order to facilitate the reader's understanding of the guidelines proposed by that international guide.\n\nThe scope of this Guide includes computerized systems categories 3, 4 and 5, the interfaces between systems and spreadsheets.\n\nThe above mentioned systems are included, installed in stand-alone or network architecture, this network to be installed locally, nationally or globally.\n\nThis guide replaces the eponymous guide published by this Agency in April 2010.\n\n## 2. INTRODUCTION\n\nIf the regulated company decides to use this Guide, it is recommended that its implementation be carried out in its entirety (where applicable) and not partially, since all the activities described in this document are necessary jointly for the achievement of an adequate sequence of acquisition, validation, operationalization and finally retirement of the computerized system, especially for more complex systems.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "5ec1e6ea3d2f4abf3be4a6275b6bc075a5175462d5569100dfc574a2e07478ca", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "# Guide for Computer Systems Validation\n\n## Table of Contents\n\n- **14.1 INTRODUCTION** ........................................................................................................... 94\n- **14.2 TYPES OF APPLICATIONS FOR END USER** .......................................................... 94\n- **14.3 RISK-BASED APPROACH** ......................................................................................... 96\n- **14.4 USE OF GAMP CATEGORIES** .................................................................................. 97\n- **14.5 RISK-BASED CONTROLS** ......................................................................................... 97\n- **14.6 APPROACHES FOR VALIDATION** .......................................................................... 99\n- **15 FINAL CONSIDERATIONS** .......................................................................................... 101\n- **16 GLOSSARY AND ACRONYMS** ................................................................................... 101\n- **17 BIBLIOGRAPHICAL REFERENCES** .......................................................................... 103\n- **17.1 REGULATORY** ....................................................................................................... 103\n- **17.2 TECHNIQUES** ......................................................................................................... 103\n\n----\n\n## 1. SCOPE\n\nThe purpose of this guide is to propose guidelines to help obtain, by the regulated sector, computer systems correctly installed and validated and that meet regulatory requirements.\n\nThis Guide is applicable to the computerized systems used in the areas, equipment and other activities relevant to Good Manufacturing Practices for Inputs and Medicines. The proposal is to internalize the document GAMP 5 in order to facilitate the reader's understanding of the guidelines proposed by that international guide.\n\nThe scope of this Guide includes computerized systems categories 3, 4 and 5, the interfaces between systems and spreadsheets.\n\nThe above mentioned systems are included, installed in stand-alone or network architecture, this network to be installed locally, nationally or globally.\n\nThis guide replaces the eponymous guide published by this Agency in April 2010.\n\n## 2. INTRODUCTION\n\nIf the regulated company decides to use this Guide, it is recommended that its implementation be carried out in its entirety (where applicable) and not partially, since all the activities described in this document are necessary jointly for the achievement of an adequate sequence of acquisition, validation, operationalization and finally retirement of the computerized system, especially for more complex systems.", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 2739, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "743311df-d416-4c46-8dff-cd20882b4af8": {"__data__": {"id_": "743311df-d416-4c46-8dff-cd20882b4af8", "embedding": null, "metadata": {"page_label": "6", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 3. LEGAL BASE\n\n- Resolution - RDC No. 69 of December 8, 2014 - which provides for Good Manufacturing Practices of Active Pharmaceutical Inputs;\n- Resolution - RDC n\u00ba 301, of August 21, 2019 - which provides for the General Good Guidelines Drug Manufacturing Practices;\n- Normative Instruction - IN n\u00ba 43, of August 21, 2019 - which provides for the Good Practices of Manufacturing complementary to the computerized systems used in the manufacture of Medicines;\n- Normative Instruction - IN n\u00ba 47, of August 21, 2019 - which provides for the Good Practices of Manufacturing complementary to qualification and validation activities\n\n# 4. CONCEPTS, TERMS AND DEFINITIONS\n\n## 4.1 KEY CONCEPTS\n\n### 4.1.1 Understanding the Process and the Product\n\nThe understanding of the process to be automated / computerized (eg: materials management; document management; management of analytical records, etc.) is fundamental in defining the system requirements. Understanding the process and the product is the basis for making decisions based on science and risk to ensure that the system is suitable for its intended use.\n\nEfforts to ensure suitability for the intended use should focus on those aspects that are critical to patient safety, product quality and data integrity. These critical aspects must be identified, specified and verified.\n\nFor some systems used in manufacturing, the process requirements depend on a complete understanding of product characteristics. For these systems, the identification of Critical Attributes of Quality Control (ACQ) and the associated Critical Process Parameters allow the control requirements of processes are defined.\n\nThe requirements specification should focus on the critical aspects. The extent and details of the specification of the requirement must be commensurate with the associated risk, complexity and innovation of the system.\n\nIncomplete understanding of the process makes effective and efficient service of the system's benefit difficult computerized to the business.\n\n### 4.1.2 Life Cycle Approach within the Quality Management System (QMS)\n\nIt implies carrying out activities in a systematic way from conception to retirement of the system, allowing for consistent management and approach for all systems.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento \"ANVISA - Guide for Computer Systems Validation 33/2020\" establece un marco legal y conceptual para la validaci\u00f3n de sistemas inform\u00e1ticos en la industria farmac\u00e9utica en Brasil. Se mencionan resoluciones y normativas que regulan las Buenas Pr\u00e1cticas de Manufactura (BPM) y se enfatiza la importancia de comprender los procesos y productos para definir requisitos del sistema. Adem\u00e1s, se introduce un enfoque de ciclo de vida dentro del Sistema de Gesti\u00f3n de Calidad (QMS) para asegurar una gesti\u00f3n coherente de los sistemas desde su concepci\u00f3n hasta su retiro.\n\n### Preguntas\n\n1. **\u00bfCu\u00e1les son las resoluciones y normativas espec\u00edficas mencionadas en el documento que regulan las Buenas Pr\u00e1cticas de Manufactura en Brasil?**\n   - Respuesta: El documento menciona la Resoluci\u00f3n RDC No. 69 de diciembre de 2014, la Resoluci\u00f3n RDC n\u00ba 301 de agosto de 2019, la Instrucci\u00f3n Normativa IN n\u00ba 43 de agosto de 2019 y la Instrucci\u00f3n Normativa IN n\u00ba 47 de agosto de 2019.\n\n2. **\u00bfPor qu\u00e9 es fundamental entender el proceso y el producto al definir los requisitos del sistema en la industria farmac\u00e9utica?**\n   - Respuesta: Entender el proceso y el producto es esencial para tomar decisiones basadas en ciencia y riesgo, asegurando que el sistema sea adecuado para su uso previsto. Esto permite identificar y verificar aspectos cr\u00edticos para la seguridad del paciente, la calidad del producto y la integridad de los datos.\n\n3. **\u00bfQu\u00e9 implica el enfoque de ciclo de vida dentro del Sistema de Gesti\u00f3n de Calidad (QMS) seg\u00fan el documento?**\n   - Respuesta: Implica realizar actividades de manera sistem\u00e1tica desde la concepci\u00f3n hasta el retiro del sistema, lo que permite una gesti\u00f3n y un enfoque coherentes para todos los sistemas involucrados en el proceso de manufactura.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n**Temas Clave:**\n\n1. **Objetivo de la Gu\u00eda:** Proporcionar directrices para la correcta instalaci\u00f3n y validaci\u00f3n de sistemas inform\u00e1ticos en el sector regulado, asegurando el cumplimiento de los requisitos regulatorios.\n\n2. **\u00c1mbito de Aplicaci\u00f3n:** La gu\u00eda se aplica a sistemas inform\u00e1ticos en las \u00e1reas relevantes para las Buenas Pr\u00e1cticas de Manufactura de Insumos y Medicamentos, incluyendo sistemas de categor\u00edas 3, 4 y 5, as\u00ed como interfaces entre sistemas y hojas de c\u00e1lculo.\n\n3. **Internalizaci\u00f3n de GAMP 5:** Se busca facilitar la comprensi\u00f3n de las directrices del documento internacional GAMP 5 en el contexto de la validaci\u00f3n de sistemas inform\u00e1ticos.\n\n4. **Importancia de la Implementaci\u00f3n Completa:** Se enfatiza que la implementaci\u00f3n de la gu\u00eda debe ser total y no parcial, ya que todas las actividades descritas son necesarias para asegurar una secuencia adecuada en la adquisici\u00f3n, validaci\u00f3n, operaci\u00f3n y retiro de los sistemas inform\u00e1ticos.\n\n**Entidades:**\n\n- **ANVISA:** Ag\u00eancia Nacional de Vigil\u00e2ncia Sanit\u00e1ria, responsable de la regulaci\u00f3n en el sector de medicamentos y productos de salud en Brasil.\n- **GAMP 5:** Buenas Pr\u00e1cticas de Manufactura (Good Automated Manufacturing Practice), un documento internacional que proporciona directrices sobre la validaci\u00f3n de sistemas inform\u00e1ticos.\n- **Categor\u00edas de Sistemas:** Se mencionan las categor\u00edas 3, 4 y 5, que se refieren a diferentes tipos de sistemas inform\u00e1ticos en el contexto de la validaci\u00f3n.\n\nEste resumen destaca los aspectos fundamentales de la gu\u00eda y su relevancia en la validaci\u00f3n de sistemas inform\u00e1ticos en el sector regulado.", "excerpt_keywords": "Keywords: validation, pharmaceutical, Good Manufacturing Practices, quality management, system requirements"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "246485af-178d-4954-9b40-2e6dc0edcb69", "node_type": "4", "metadata": {"page_label": "6", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 3. LEGAL BASE\n\n- Resolution - RDC No. 69 of December 8, 2014 - which provides for Good Manufacturing Practices of Active Pharmaceutical Inputs;\n- Resolution - RDC n\u00ba 301, of August 21, 2019 - which provides for the General Good Guidelines Drug Manufacturing Practices;\n- Normative Instruction - IN n\u00ba 43, of August 21, 2019 - which provides for the Good Practices of Manufacturing complementary to the computerized systems used in the manufacture of Medicines;\n- Normative Instruction - IN n\u00ba 47, of August 21, 2019 - which provides for the Good Practices of Manufacturing complementary to qualification and validation activities\n\n# 4. CONCEPTS, TERMS AND DEFINITIONS\n\n## 4.1 KEY CONCEPTS\n\n### 4.1.1 Understanding the Process and the Product\n\nThe understanding of the process to be automated / computerized (eg: materials management; document management; management of analytical records, etc.) is fundamental in defining the system requirements. Understanding the process and the product is the basis for making decisions based on science and risk to ensure that the system is suitable for its intended use.\n\nEfforts to ensure suitability for the intended use should focus on those aspects that are critical to patient safety, product quality and data integrity. These critical aspects must be identified, specified and verified.\n\nFor some systems used in manufacturing, the process requirements depend on a complete understanding of product characteristics. For these systems, the identification of Critical Attributes of Quality Control (ACQ) and the associated Critical Process Parameters allow the control requirements of processes are defined.\n\nThe requirements specification should focus on the critical aspects. The extent and details of the specification of the requirement must be commensurate with the associated risk, complexity and innovation of the system.\n\nIncomplete understanding of the process makes effective and efficient service of the system's benefit difficult computerized to the business.\n\n### 4.1.2 Life Cycle Approach within the Quality Management System (QMS)\n\nIt implies carrying out activities in a systematic way from conception to retirement of the system, allowing for consistent management and approach for all systems.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "ec585de7be1a4dad313541066308fb8d9ea27e390bd8758f8ce928198fb304c6", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "# 3. LEGAL BASE\n\n- Resolution - RDC No. 69 of December 8, 2014 - which provides for Good Manufacturing Practices of Active Pharmaceutical Inputs;\n- Resolution - RDC n\u00ba 301, of August 21, 2019 - which provides for the General Good Guidelines Drug Manufacturing Practices;\n- Normative Instruction - IN n\u00ba 43, of August 21, 2019 - which provides for the Good Practices of Manufacturing complementary to the computerized systems used in the manufacture of Medicines;\n- Normative Instruction - IN n\u00ba 47, of August 21, 2019 - which provides for the Good Practices of Manufacturing complementary to qualification and validation activities\n\n# 4. CONCEPTS, TERMS AND DEFINITIONS\n\n## 4.1 KEY CONCEPTS\n\n### 4.1.1 Understanding the Process and the Product\n\nThe understanding of the process to be automated / computerized (eg: materials management; document management; management of analytical records, etc.) is fundamental in defining the system requirements. Understanding the process and the product is the basis for making decisions based on science and risk to ensure that the system is suitable for its intended use.\n\nEfforts to ensure suitability for the intended use should focus on those aspects that are critical to patient safety, product quality and data integrity. These critical aspects must be identified, specified and verified.\n\nFor some systems used in manufacturing, the process requirements depend on a complete understanding of product characteristics. For these systems, the identification of Critical Attributes of Quality Control (ACQ) and the associated Critical Process Parameters allow the control requirements of processes are defined.\n\nThe requirements specification should focus on the critical aspects. The extent and details of the specification of the requirement must be commensurate with the associated risk, complexity and innovation of the system.\n\nIncomplete understanding of the process makes effective and efficient service of the system's benefit difficult computerized to the business.\n\n### 4.1.2 Life Cycle Approach within the Quality Management System (QMS)\n\nIt implies carrying out activities in a systematic way from conception to retirement of the system, allowing for consistent management and approach for all systems.", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 2255, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "528151a7-bf41-4bf6-8b4f-3f78a5f03d6b": {"__data__": {"id_": "528151a7-bf41-4bf6-8b4f-3f78a5f03d6b", "embedding": null, "metadata": {"page_label": "7", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "As more knowledge of the system is acquired during use, the Quality Management (QMS) should allow continuous improvement of the process and the system, based on periodic reviews and evaluations of operational and performance data and analysis of the root causes of failures occurred. Improvements identified and corrective actions taken should follow change management.\n\nAn appropriate life-cycle approach allows for quality assurance and suitability for the intended use system, in addition to obtaining and maintaining compliance with regulatory requirements.\n\n## 4.1.3 Scalable Life Cycle Activities\n\nLife cycle activities should be staggered according to:\n\n- The impact of the system on patient safety, product quality and data integrity (risk assessment);\n- The complexity of the system and its innovation (architecture and categorization of system components);\n- The result of the supplier's assessment (capability);\n- The impact of the system on business (can also motivate escalation).\n\nThe scheduling strategy must be clearly defined in a plan and follow policies and procedures established and approved.\n\n## 4.1.4 Science-Based Quality Risk Management\n\nQuality risk management is a systematic process for assessing, controlling, communicating and risk review. Its application allows efforts to be concentrated on the critical aspects of a system computerized in a controlled and justified manner.\n\nGuide for Computer Systems Validation\nGuide n\u00b0 33/2020 - version 1, of 03/26/2020\n\nQuality risk management should be based on a clear understanding of the process and the impact potential for patient safety, product quality and data integrity. For systems that control or monitor Critical Process Parameters, they must be traceable to Critical Attributes of Quality and to the regulatory submissions of the manufacturing systems.\n\nQuantitative and qualitative techniques can be used to identify and manage risks. Controls and measures mitigation measures are developed to reduce risks to an acceptable level. The implemented controls must be monitored during day-to-day operation to ensure continuous effectiveness.\n\n## 4.1.5 Leveraging Supplier Involvement\n\nCompanies in the regulated sector should seek to maximize supplier engagement throughout the life cycle of the system, if it has a satisfactory evaluation, with the purpose of using its knowledge, experience and documentation.\n\nThe supplier can assist in determining user requirements, in risk assessments, in creating functional and other specifications, system configuration, testing, support and system maintenance.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la Validaci\u00f3n de Sistemas Inform\u00e1ticos enfatiza la importancia de un enfoque de ciclo de vida escalable y la gesti\u00f3n de riesgos de calidad en sistemas regulados. Se destaca la necesidad de mejorar continuamente los procesos y sistemas mediante revisiones peri\u00f3dicas y la identificaci\u00f3n de causas ra\u00edz de fallos. Adem\u00e1s, se sugiere que la gesti\u00f3n de riesgos debe centrarse en aspectos cr\u00edticos que afectan la seguridad del paciente, la calidad del producto y la integridad de los datos. Tambi\u00e9n se menciona la importancia de involucrar a los proveedores a lo largo del ciclo de vida del sistema para aprovechar su experiencia y conocimientos.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfCu\u00e1les son los criterios que determinan c\u00f3mo se deben escalar las actividades del ciclo de vida de un sistema inform\u00e1tico seg\u00fan el documento de ANVISA?**\n   - El documento menciona que las actividades del ciclo de vida deben escalarse seg\u00fan el impacto del sistema en la seguridad del paciente, la calidad del producto y la integridad de los datos, la complejidad e innovaci\u00f3n del sistema, los resultados de la evaluaci\u00f3n del proveedor y el impacto del sistema en el negocio.\n\n2. **\u00bfQu\u00e9 t\u00e9cnicas se pueden utilizar para identificar y gestionar riesgos en sistemas inform\u00e1ticos, seg\u00fan la gu\u00eda de ANVISA?**\n   - Se pueden utilizar t\u00e9cnicas cuantitativas y cualitativas para identificar y gestionar riesgos. Adem\u00e1s, se deben desarrollar controles y medidas de mitigaci\u00f3n para reducir los riesgos a un nivel aceptable, y estos controles deben ser monitoreados durante la operaci\u00f3n diaria para asegurar su efectividad continua.\n\n3. **\u00bfC\u00f3mo se sugiere que las empresas del sector regulado involucren a los proveedores en el ciclo de vida del sistema?**\n   - Las empresas deben maximizar la participaci\u00f3n de los proveedores a lo largo del ciclo de vida del sistema, siempre que estos tengan una evaluaci\u00f3n satisfactoria. Los proveedores pueden ayudar en la determinaci\u00f3n de requisitos del usuario, en evaluaciones de riesgo, en la creaci\u00f3n de especificaciones funcionales, en la configuraci\u00f3n del sistema, en pruebas, y en el soporte y mantenimiento del sistema.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n#### 1. **Marco Legal**\n   - **Resoluciones y Normativas:**\n     - **RDC No. 69 (2014):** Buenas Pr\u00e1cticas de Manufactura de Insumos Farmac\u00e9uticos Activos.\n     - **RDC n\u00ba 301 (2019):** Directrices Generales de Buenas Pr\u00e1cticas de Manufactura de Medicamentos.\n     - **IN n\u00ba 43 (2019):** Buenas Pr\u00e1cticas de Manufactura para sistemas computarizados en la fabricaci\u00f3n de medicamentos.\n     - **IN n\u00ba 47 (2019):** Buenas Pr\u00e1cticas de Manufactura para actividades de calificaci\u00f3n y validaci\u00f3n.\n\n#### 2. **Conceptos Clave**\n   - **Comprensi\u00f3n del Proceso y del Producto:**\n     - Es fundamental para definir los requisitos del sistema.\n     - Permite tomar decisiones basadas en ciencia y riesgo, asegurando la idoneidad del sistema para su uso previsto.\n     - Identificaci\u00f3n de Atributos Cr\u00edticos de Calidad (ACQ) y Par\u00e1metros Cr\u00edticos de Proceso para definir requisitos de control.\n\n   - **Enfoque de Ciclo de Vida en el Sistema de Gesti\u00f3n de Calidad (QMS):**\n     - Implica una gesti\u00f3n sistem\u00e1tica desde la concepci\u00f3n hasta el retiro del sistema.\n     - Asegura un enfoque coherente para todos los sistemas involucrados en la manufactura.\n\n#### 3. **Importancia de la Validaci\u00f3n de Sistemas Inform\u00e1ticos**\n   - La validaci\u00f3n es crucial para garantizar la seguridad del paciente, la calidad del producto y la integridad de los datos.\n   - Un entendimiento incompleto del proceso puede dificultar la efectividad y eficiencia del sistema.\n\nEste resumen destaca la importancia de las regulaciones y la comprensi\u00f3n de los procesos en la validaci\u00f3n de sistemas inform\u00e1ticos en la industria farmac\u00e9utica, as\u00ed como la necesidad de un enfoque sistem\u00e1tico a lo largo del ciclo de vida del sistema.", "excerpt_keywords": "Keywords: validation, quality management, risk assessment, life cycle, supplier involvement"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "5617ce46-ab7d-4bb6-9091-e9bfdc17a96b", "node_type": "4", "metadata": {"page_label": "7", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "As more knowledge of the system is acquired during use, the Quality Management (QMS) should allow continuous improvement of the process and the system, based on periodic reviews and evaluations of operational and performance data and analysis of the root causes of failures occurred. Improvements identified and corrective actions taken should follow change management.\n\nAn appropriate life-cycle approach allows for quality assurance and suitability for the intended use system, in addition to obtaining and maintaining compliance with regulatory requirements.\n\n## 4.1.3 Scalable Life Cycle Activities\n\nLife cycle activities should be staggered according to:\n\n- The impact of the system on patient safety, product quality and data integrity (risk assessment);\n- The complexity of the system and its innovation (architecture and categorization of system components);\n- The result of the supplier's assessment (capability);\n- The impact of the system on business (can also motivate escalation).\n\nThe scheduling strategy must be clearly defined in a plan and follow policies and procedures established and approved.\n\n## 4.1.4 Science-Based Quality Risk Management\n\nQuality risk management is a systematic process for assessing, controlling, communicating and risk review. Its application allows efforts to be concentrated on the critical aspects of a system computerized in a controlled and justified manner.\n\nGuide for Computer Systems Validation\nGuide n\u00b0 33/2020 - version 1, of 03/26/2020\n\nQuality risk management should be based on a clear understanding of the process and the impact potential for patient safety, product quality and data integrity. For systems that control or monitor Critical Process Parameters, they must be traceable to Critical Attributes of Quality and to the regulatory submissions of the manufacturing systems.\n\nQuantitative and qualitative techniques can be used to identify and manage risks. Controls and measures mitigation measures are developed to reduce risks to an acceptable level. The implemented controls must be monitored during day-to-day operation to ensure continuous effectiveness.\n\n## 4.1.5 Leveraging Supplier Involvement\n\nCompanies in the regulated sector should seek to maximize supplier engagement throughout the life cycle of the system, if it has a satisfactory evaluation, with the purpose of using its knowledge, experience and documentation.\n\nThe supplier can assist in determining user requirements, in risk assessments, in creating functional and other specifications, system configuration, testing, support and system maintenance.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "6820b730d7a558ea11abfb3e78c307ac34a1a5c1cedac8d61c9ac64701f2f679", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "As more knowledge of the system is acquired during use, the Quality Management (QMS) should allow continuous improvement of the process and the system, based on periodic reviews and evaluations of operational and performance data and analysis of the root causes of failures occurred. Improvements identified and corrective actions taken should follow change management.\n\nAn appropriate life-cycle approach allows for quality assurance and suitability for the intended use system, in addition to obtaining and maintaining compliance with regulatory requirements.\n\n## 4.1.3 Scalable Life Cycle Activities\n\nLife cycle activities should be staggered according to:\n\n- The impact of the system on patient safety, product quality and data integrity (risk assessment);\n- The complexity of the system and its innovation (architecture and categorization of system components);\n- The result of the supplier's assessment (capability);\n- The impact of the system on business (can also motivate escalation).\n\nThe scheduling strategy must be clearly defined in a plan and follow policies and procedures established and approved.\n\n## 4.1.4 Science-Based Quality Risk Management\n\nQuality risk management is a systematic process for assessing, controlling, communicating and risk review. Its application allows efforts to be concentrated on the critical aspects of a system computerized in a controlled and justified manner.\n\nGuide for Computer Systems Validation\nGuide n\u00b0 33/2020 - version 1, of 03/26/2020\n\nQuality risk management should be based on a clear understanding of the process and the impact potential for patient safety, product quality and data integrity. For systems that control or monitor Critical Process Parameters, they must be traceable to Critical Attributes of Quality and to the regulatory submissions of the manufacturing systems.\n\nQuantitative and qualitative techniques can be used to identify and manage risks. Controls and measures mitigation measures are developed to reduce risks to an acceptable level. The implemented controls must be monitored during day-to-day operation to ensure continuous effectiveness.\n\n## 4.1.5 Leveraging Supplier Involvement\n\nCompanies in the regulated sector should seek to maximize supplier engagement throughout the life cycle of the system, if it has a satisfactory evaluation, with the purpose of using its knowledge, experience and documentation.\n\nThe supplier can assist in determining user requirements, in risk assessments, in creating functional and other specifications, system configuration, testing, support and system maintenance.", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 2585, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "301dbbb2-75d9-462c-aaf8-b96445f3aa43": {"__data__": {"id_": "301dbbb2-75d9-462c-aaf8-b96445f3aa43", "embedding": null, "metadata": {"page_label": "8", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "Planning should determine how to use the vendor's documentation, including tests, to avoid wasted effort and duplication. The justification for using this documentation should be based on your satisfactory assessment of the supplier, which may include conducting on-site audits.\n\nThis documentation must be assessed for suitability, accuracy and comprehensiveness and made available during the life cycle of the system.\n\n## 4.2 KEY TERMS\n\n### 4.2.1 Service to BPx\n\nCompliance with all pharmaceutical regulatory requirements and associated with life science.\n\n### 4.2.2 Process owner (Process Owner)\n\nThe process owner is responsible for ensuring that the computerized system and its operation are compliant and suitable for the intended use according to standard operating procedures (POP) by its entire life cycle. It is the individual responsible for the business process or managed processes. It is person may be the head of the unit or department using the system, but responsibility should be based primarily on specific knowledge of the process rather than position in the organization.\n\n### Owner System 4.2.3 (System Owner)\n\nIt is the individual responsible for the availability, support and maintenance of a computerized system, as well as the security of the data kept in this system. It is usually the head of the department responsible for support and maintenance of the system, the role of which must be based on specific knowledge of the system rather than the position in the organization. The system owner is responsible for ensuring that the system has support and maintenance in accordance with applicable procedures.\n\n**NOTE:** Responsibility for controlling access to the system must be agreed between the process owner and the system owner. In some situations the owner of the process may also be the owner of the system.\n\nThe ownership of the data kept in the system must be defined and normally belongs to the owner of the process.\n\n### 4.2.4 Expert Opinion (Subject Matter Expert)\n\nIt is the individual with deep knowledge in a specific area or field (chromatography, management materials, manufacturing process, etc.). The specialist's responsibilities include planning and definition of the verification strategy, definition of acceptance criteria, selection of the appropriate methods, execution of the verification tests and review of the results obtained in the tests.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "### Res\u00famenes de nivel superior del contexto:\n\n1. **Importancia de la Documentaci\u00f3n del Proveedor**: La planificaci\u00f3n en la validaci\u00f3n de sistemas inform\u00e1ticos debe incluir una evaluaci\u00f3n cuidadosa de la documentaci\u00f3n proporcionada por el proveedor, asegurando que sea adecuada, precisa y completa a lo largo del ciclo de vida del sistema. Esto ayuda a evitar esfuerzos duplicados y a garantizar la conformidad con los requisitos regulatorios.\n\n2. **Roles y Responsabilidades**: Se definen claramente los roles del propietario del proceso y del propietario del sistema. El propietario del proceso es responsable de la conformidad y adecuaci\u00f3n del sistema, mientras que el propietario del sistema se encarga de su disponibilidad, soporte y mantenimiento. La colaboraci\u00f3n entre ambos es crucial para el control de acceso y la propiedad de los datos.\n\n3. **Expertos en la Materia**: Los expertos en la materia juegan un papel fundamental en la validaci\u00f3n de sistemas inform\u00e1ticos, ya que son responsables de definir estrategias de verificaci\u00f3n, criterios de aceptaci\u00f3n y llevar a cabo pruebas de verificaci\u00f3n, asegurando que el sistema cumpla con los est\u00e1ndares requeridos.\n\n### Preguntas espec\u00edficas que el contexto puede responder:\n\n1. **\u00bfCu\u00e1les son los criterios que deben considerarse al evaluar la documentaci\u00f3n del proveedor para la validaci\u00f3n de sistemas inform\u00e1ticos?**\n   - El contexto menciona que la documentaci\u00f3n debe ser evaluada por su idoneidad, precisi\u00f3n y exhaustividad, y debe estar disponible durante todo el ciclo de vida del sistema.\n\n2. **\u00bfQu\u00e9 responsabilidades espec\u00edficas tiene el propietario del proceso en relaci\u00f3n con el sistema inform\u00e1tico?**\n   - El propietario del proceso es responsable de garantizar que el sistema y su operaci\u00f3n sean conformes y adecuados para el uso previsto, siguiendo los procedimientos operativos est\u00e1ndar a lo largo de todo su ciclo de vida.\n\n3. **\u00bfQu\u00e9 papel desempe\u00f1a un experto en la materia en el proceso de validaci\u00f3n de sistemas inform\u00e1ticos?**\n   - Un experto en la materia es responsable de planificar y definir la estrategia de verificaci\u00f3n, establecer criterios de aceptaci\u00f3n, seleccionar m\u00e9todos apropiados, ejecutar pruebas de verificaci\u00f3n y revisar los resultados obtenidos.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Mejora Continua**: Se enfatiza la importancia de la mejora continua de los procesos y sistemas a trav\u00e9s de revisiones peri\u00f3dicas y an\u00e1lisis de datos operativos y de rendimiento, as\u00ed como la identificaci\u00f3n de causas ra\u00edz de fallos.\n\n2. **Enfoque del Ciclo de Vida**: Se propone un enfoque escalable para las actividades del ciclo de vida de los sistemas inform\u00e1ticos, que debe considerar:\n   - Impacto en la seguridad del paciente, calidad del producto e integridad de los datos.\n   - Complejidad e innovaci\u00f3n del sistema.\n   - Resultados de la evaluaci\u00f3n del proveedor.\n   - Impacto en el negocio.\n\n3. **Gesti\u00f3n de Riesgos de Calidad**: Se describe la gesti\u00f3n de riesgos de calidad como un proceso sistem\u00e1tico que incluye la evaluaci\u00f3n, control, comunicaci\u00f3n y revisi\u00f3n de riesgos. Debe centrarse en aspectos cr\u00edticos que afectan la seguridad del paciente y la calidad del producto.\n\n4. **T\u00e9cnicas de Gesti\u00f3n de Riesgos**: Se pueden utilizar t\u00e9cnicas cuantitativas y cualitativas para identificar y gestionar riesgos. Se deben desarrollar controles y medidas de mitigaci\u00f3n, que deben ser monitoreados para asegurar su efectividad continua.\n\n5. **Involucramiento de Proveedores**: Se sugiere que las empresas del sector regulado maximicen la participaci\u00f3n de los proveedores a lo largo del ciclo de vida del sistema, aprovechando su conocimiento y experiencia en diversas \u00e1reas, como la determinaci\u00f3n de requisitos, evaluaciones de riesgo, especificaciones funcionales, configuraci\u00f3n del sistema, pruebas y mantenimiento.\n\n### Entidades Clave\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil.\n- **QMS (Quality Management System)**: Sistema de Gesti\u00f3n de Calidad.\n- **Proveedores**: Entidades que ofrecen servicios o productos relacionados con el sistema inform\u00e1tico.\n- **Par\u00e1metros Cr\u00edticos de Proceso**: Elementos que deben ser controlados para asegurar la calidad del producto.\n- **Atributos Cr\u00edticos de Calidad**: Caracter\u00edsticas esenciales que deben ser monitoreadas para cumplir con los est\u00e1ndares regulatorios. \n\nEste resumen destaca la importancia de un enfoque estructurado y colaborativo en la validaci\u00f3n de sistemas inform\u00e1ticos en el contexto regulado, asegurando la calidad y la seguridad en el uso de estos sistemas.", "excerpt_keywords": "Keywords: validation, documentation, process owner, system owner, subject matter expert"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "469f6b51-7c6b-4827-804a-e5b763865f1b", "node_type": "4", "metadata": {"page_label": "8", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "Planning should determine how to use the vendor's documentation, including tests, to avoid wasted effort and duplication. The justification for using this documentation should be based on your satisfactory assessment of the supplier, which may include conducting on-site audits.\n\nThis documentation must be assessed for suitability, accuracy and comprehensiveness and made available during the life cycle of the system.\n\n## 4.2 KEY TERMS\n\n### 4.2.1 Service to BPx\n\nCompliance with all pharmaceutical regulatory requirements and associated with life science.\n\n### 4.2.2 Process owner (Process Owner)\n\nThe process owner is responsible for ensuring that the computerized system and its operation are compliant and suitable for the intended use according to standard operating procedures (POP) by its entire life cycle. It is the individual responsible for the business process or managed processes. It is person may be the head of the unit or department using the system, but responsibility should be based primarily on specific knowledge of the process rather than position in the organization.\n\n### Owner System 4.2.3 (System Owner)\n\nIt is the individual responsible for the availability, support and maintenance of a computerized system, as well as the security of the data kept in this system. It is usually the head of the department responsible for support and maintenance of the system, the role of which must be based on specific knowledge of the system rather than the position in the organization. The system owner is responsible for ensuring that the system has support and maintenance in accordance with applicable procedures.\n\n**NOTE:** Responsibility for controlling access to the system must be agreed between the process owner and the system owner. In some situations the owner of the process may also be the owner of the system.\n\nThe ownership of the data kept in the system must be defined and normally belongs to the owner of the process.\n\n### 4.2.4 Expert Opinion (Subject Matter Expert)\n\nIt is the individual with deep knowledge in a specific area or field (chromatography, management materials, manufacturing process, etc.). The specialist's responsibilities include planning and definition of the verification strategy, definition of acceptance criteria, selection of the appropriate methods, execution of the verification tests and review of the results obtained in the tests.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "a856a1e8eedf082a9ffebf48a4c29d97fbca41c25a45ea23ecedc7ced09eac53", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "Planning should determine how to use the vendor's documentation, including tests, to avoid wasted effort and duplication. The justification for using this documentation should be based on your satisfactory assessment of the supplier, which may include conducting on-site audits.\n\nThis documentation must be assessed for suitability, accuracy and comprehensiveness and made available during the life cycle of the system.\n\n## 4.2 KEY TERMS\n\n### 4.2.1 Service to BPx\n\nCompliance with all pharmaceutical regulatory requirements and associated with life science.\n\n### 4.2.2 Process owner (Process Owner)\n\nThe process owner is responsible for ensuring that the computerized system and its operation are compliant and suitable for the intended use according to standard operating procedures (POP) by its entire life cycle. It is the individual responsible for the business process or managed processes. It is person may be the head of the unit or department using the system, but responsibility should be based primarily on specific knowledge of the process rather than position in the organization.\n\n### Owner System 4.2.3 (System Owner)\n\nIt is the individual responsible for the availability, support and maintenance of a computerized system, as well as the security of the data kept in this system. It is usually the head of the department responsible for support and maintenance of the system, the role of which must be based on specific knowledge of the system rather than the position in the organization. The system owner is responsible for ensuring that the system has support and maintenance in accordance with applicable procedures.\n\n**NOTE:** Responsibility for controlling access to the system must be agreed between the process owner and the system owner. In some situations the owner of the process may also be the owner of the system.\n\nThe ownership of the data kept in the system must be defined and normally belongs to the owner of the process.\n\n### 4.2.4 Expert Opinion (Subject Matter Expert)\n\nIt is the individual with deep knowledge in a specific area or field (chromatography, management materials, manufacturing process, etc.). The specialist's responsibilities include planning and definition of the verification strategy, definition of acceptance criteria, selection of the appropriate methods, execution of the verification tests and review of the results obtained in the tests.", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 2397, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "da5c0c36-aff5-4886-a7bd-edd89d4792a7": {"__data__": {"id_": "da5c0c36-aff5-4886-a7bd-edd89d4792a7", "embedding": null, "metadata": {"page_label": "9", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "## 4.2.5 BPx Regulations\n\nInternational pharmaceutical requirements, such as those established by ANVISA, FDA, Directives European regulations, Japanese regulations and other applicable national laws or internal regulations of the companies.\n\nBPX regulations include, but are not limited to: GMP; BPC; BPL; BPD; Good Quality Practices; Good Pharmacovigilance Practices and Medical Product Regulations.\n\n## 4.2.6 Quality Management System\n\nManagement system to direct and control an organization with respect to quality.\n\n## 4.2.7 Computerized System\n\nA computerized system consists of: **hardware**, **software** and network components, together with the controlled functions and associated documentation. Figure 1 shows a schematic representation of a computerized system.\n\n## 4.2.8 Computerized System Meeting BPx\n\nComputerized systems subject to BPx regulations. The regulated company must ensure that such systems meet the appropriate regulations.\n\n## 4.2.9 Computer Systems Validation\n\nObtaining and maintaining compliance with the applicable BPx regulations and their suitability for the intended use through the use of:\n\n- Adoption of life cycle principles, approaches and activities within the framework of plans and validation reports;\n- The application of appropriate operational controls throughout the system's life cycle.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, as\u00ed como un resumen de nivel superior del contenido:\n\n### Resumen de Nivel Superior\nEl documento \"ANVISA - Guide for Computer Systems Validation 33/2020\" aborda las regulaciones internacionales en la industria farmac\u00e9utica, destacando la importancia de cumplir con las normativas BPx, que incluyen Buenas Pr\u00e1cticas de Manufactura (GMP), Buenas Pr\u00e1cticas de Calidad (BPC), y Buenas Pr\u00e1cticas de Farmacovigilancia, entre otras. Tambi\u00e9n se define un sistema computarizado como un conjunto de hardware, software y componentes de red, y se enfatiza la necesidad de validar estos sistemas para asegurar su conformidad con las regulaciones aplicables y su idoneidad para el uso previsto.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfQu\u00e9 componentes se consideran parte de un sistema computarizado seg\u00fan el documento de ANVISA?**\n   - Respuesta: Un sistema computarizado consiste en hardware, software y componentes de red, junto con las funciones controladas y la documentaci\u00f3n asociada.\n\n2. **\u00bfCu\u00e1les son algunos ejemplos de regulaciones BPx mencionadas en el documento?**\n   - Respuesta: Las regulaciones BPx incluyen, pero no se limitan a, Buenas Pr\u00e1cticas de Manufactura (GMP), Buenas Pr\u00e1cticas de Calidad (BPC), Buenas Pr\u00e1cticas de Laboratorio (BPL), Buenas Pr\u00e1cticas de Documentaci\u00f3n (BPD), Buenas Pr\u00e1cticas de Calidad y Buenas Pr\u00e1cticas de Farmacovigilancia.\n\n3. **\u00bfQu\u00e9 enfoques se deben adoptar para asegurar la validaci\u00f3n de sistemas computarizados seg\u00fan el documento?**\n   - Respuesta: Se deben adoptar principios del ciclo de vida, enfoques y actividades dentro del marco de planes y reportes de validaci\u00f3n, as\u00ed como la aplicaci\u00f3n de controles operativos apropiados a lo largo del ciclo de vida del sistema.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Documentaci\u00f3n del Proveedor**:\n   - La planificaci\u00f3n en la validaci\u00f3n de sistemas inform\u00e1ticos debe incluir el uso adecuado de la documentaci\u00f3n del proveedor para evitar esfuerzos duplicados. \n   - La documentaci\u00f3n debe ser evaluada en t\u00e9rminos de idoneidad, precisi\u00f3n y exhaustividad, y debe estar disponible durante todo el ciclo de vida del sistema.\n\n2. **Roles y Responsabilidades**:\n   - **Propietario del Proceso**: Responsable de la conformidad y adecuaci\u00f3n del sistema para su uso previsto, siguiendo los procedimientos operativos est\u00e1ndar a lo largo de su ciclo de vida. Este rol se basa en el conocimiento espec\u00edfico del proceso m\u00e1s que en la posici\u00f3n jer\u00e1rquica.\n   - **Propietario del Sistema**: Encargado de la disponibilidad, soporte y mantenimiento del sistema, as\u00ed como de la seguridad de los datos. Tambi\u00e9n se basa en el conocimiento espec\u00edfico del sistema. La responsabilidad del control de acceso debe ser acordada entre el propietario del proceso y el propietario del sistema.\n\n3. **Expertos en la Materia**:\n   - Individuos con profundo conocimiento en \u00e1reas espec\u00edficas (como cromatograf\u00eda o procesos de fabricaci\u00f3n). Sus responsabilidades incluyen la planificaci\u00f3n de la estrategia de verificaci\u00f3n, definici\u00f3n de criterios de aceptaci\u00f3n, selecci\u00f3n de m\u00e9todos, ejecuci\u00f3n de pruebas de verificaci\u00f3n y revisi\u00f3n de resultados.\n\n### Entidades Clave:\n- **Documentaci\u00f3n del Proveedor**\n- **Propietario del Proceso**\n- **Propietario del Sistema**\n- **Experto en la Materia (Subject Matter Expert)**\n\nEste resumen destaca la importancia de la documentaci\u00f3n adecuada, la definici\u00f3n clara de roles y la participaci\u00f3n de expertos en la validaci\u00f3n de sistemas inform\u00e1ticos en el contexto regulatorio farmac\u00e9utico.", "excerpt_keywords": "Keywords: ANVISA, BPx regulations, Computer Systems Validation, Quality Management System, Pharmaceutical Compliance"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "d1ce5258-0704-4fd1-9da3-cf2354ae25d6", "node_type": "4", "metadata": {"page_label": "9", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "## 4.2.5 BPx Regulations\n\nInternational pharmaceutical requirements, such as those established by ANVISA, FDA, Directives European regulations, Japanese regulations and other applicable national laws or internal regulations of the companies.\n\nBPX regulations include, but are not limited to: GMP; BPC; BPL; BPD; Good Quality Practices; Good Pharmacovigilance Practices and Medical Product Regulations.\n\n## 4.2.6 Quality Management System\n\nManagement system to direct and control an organization with respect to quality.\n\n## 4.2.7 Computerized System\n\nA computerized system consists of: **hardware**, **software** and network components, together with the controlled functions and associated documentation. Figure 1 shows a schematic representation of a computerized system.\n\n## 4.2.8 Computerized System Meeting BPx\n\nComputerized systems subject to BPx regulations. The regulated company must ensure that such systems meet the appropriate regulations.\n\n## 4.2.9 Computer Systems Validation\n\nObtaining and maintaining compliance with the applicable BPx regulations and their suitability for the intended use through the use of:\n\n- Adoption of life cycle principles, approaches and activities within the framework of plans and validation reports;\n- The application of appropriate operational controls throughout the system's life cycle.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "7864fd9a002ef2887a823c688a73172d4dc682b777757990e81671a8846c630f", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "## 4.2.5 BPx Regulations\n\nInternational pharmaceutical requirements, such as those established by ANVISA, FDA, Directives European regulations, Japanese regulations and other applicable national laws or internal regulations of the companies.\n\nBPX regulations include, but are not limited to: GMP; BPC; BPL; BPD; Good Quality Practices; Good Pharmacovigilance Practices and Medical Product Regulations.\n\n## 4.2.6 Quality Management System\n\nManagement system to direct and control an organization with respect to quality.\n\n## 4.2.7 Computerized System\n\nA computerized system consists of: **hardware**, **software** and network components, together with the controlled functions and associated documentation. Figure 1 shows a schematic representation of a computerized system.\n\n## 4.2.8 Computerized System Meeting BPx\n\nComputerized systems subject to BPx regulations. The regulated company must ensure that such systems meet the appropriate regulations.\n\n## 4.2.9 Computer Systems Validation\n\nObtaining and maintaining compliance with the applicable BPx regulations and their suitability for the intended use through the use of:\n\n- Adoption of life cycle principles, approaches and activities within the framework of plans and validation reports;\n- The application of appropriate operational controls throughout the system's life cycle.", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 1334, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "25b3af9f-ac91-443c-92e6-3f2f02b79c98": {"__data__": {"id_": "25b3af9f-ac91-443c-92e6-3f2f02b79c98", "embedding": null, "metadata": {"page_label": "10", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 5. LIFE CYCLE APPROACH\n\n## 5.1 INTRODUCTION\n\nCompliance with regulatory requirements and suitability for the intended use can be achieved by adopting a life cycle approach following Best Practices.\n\nA life cycle approach implies defining and carrying out activities in a systematic way from the conception, understanding of requirements from development, release and operational use, to system retirement.\n\nThis section of the guide presents: the life cycle of the computerized system, a general approach to specification and verification and a structure for the validation of a computerized system.\n\nAn important part of implementing the lifecycle approach for computer systems is the definition, by the regulated company, of the employees who will exercise the roles of Process Owner, System Owner and Subject Specialist, for each of the systems installed in the company.\n\nThe understanding and qualification of the employees chosen from / in their respective functions are the stone fundamental for all computerized systems to be properly chosen, validated, operationalized and retired, meeting the relevant GMP and regulatory demands.\n\n## 5.2 LIFE CYCLE OF COMPUTERIZED SYSTEMS\n\nThe life cycle of a computerized system covers all activities from the initial concept to the retirement.\n\nThe life cycle of any system consists of four phases:", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas que se pueden formular a partir del contexto proporcionado, junto con respuestas espec\u00edficas que probablemente no se encuentren en otro lugar:\n\n### Preguntas y Respuestas\n\n1. **\u00bfCu\u00e1les son los roles clave que deben definirse en una empresa regulada para implementar adecuadamente el enfoque del ciclo de vida en los sistemas computarizados?**\n   - **Respuesta:** Los roles clave que deben definirse son el Propietario del Proceso, el Propietario del Sistema y el Especialista en la Materia. Cada uno de estos roles es fundamental para asegurar que los sistemas sean elegidos, validados, operados y retirados de manera adecuada, cumpliendo con las demandas de Buenas Pr\u00e1cticas de Manufactura (GMP) y regulaciones pertinentes.\n\n2. **\u00bfQu\u00e9 implica un enfoque de ciclo de vida en la validaci\u00f3n de sistemas computarizados seg\u00fan la gu\u00eda de ANVISA?**\n   - **Respuesta:** Un enfoque de ciclo de vida implica llevar a cabo actividades de manera sistem\u00e1tica desde la concepci\u00f3n del sistema, pasando por la comprensi\u00f3n de los requisitos durante el desarrollo, hasta su liberaci\u00f3n, uso operativo y eventual retiro. Este enfoque asegura que se cumplan los requisitos regulatorios y que el sistema sea adecuado para su uso previsto.\n\n3. **\u00bfPor qu\u00e9 es fundamental la comprensi\u00f3n y calificaci\u00f3n de los empleados en el contexto de la validaci\u00f3n de sistemas computarizados?**\n   - **Respuesta:** La comprensi\u00f3n y calificaci\u00f3n de los empleados en sus respectivas funciones son fundamentales porque garantizan que los sistemas computarizados sean seleccionados, validados, operados y retirados correctamente. Esto es esencial para cumplir con las demandas regulatorias y de GMP, asegurando la integridad y eficacia del sistema a lo largo de su ciclo de vida.\n\n### Resumen de Nivel Superior\n\nEl enfoque del ciclo de vida en la validaci\u00f3n de sistemas computarizados, seg\u00fan la gu\u00eda de ANVISA, es un proceso sistem\u00e1tico que abarca desde la concepci\u00f3n del sistema hasta su retiro. Este enfoque requiere la definici\u00f3n de roles espec\u00edficos dentro de la empresa y la calificaci\u00f3n adecuada de los empleados para asegurar que se cumplan los requisitos regulatorios y de calidad. La gu\u00eda enfatiza la importancia de seguir las mejores pr\u00e1cticas para garantizar la idoneidad del sistema para su uso previsto y el cumplimiento de las normativas aplicables.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Regulaciones BPx**: \n   - Se refiere a los requisitos internacionales en la industria farmac\u00e9utica, incluyendo regulaciones de ANVISA, FDA, y normativas europeas y japonesas.\n   - Ejemplos de regulaciones BPx: Buenas Pr\u00e1cticas de Manufactura (GMP), Buenas Pr\u00e1cticas de Calidad (BPC), Buenas Pr\u00e1cticas de Laboratorio (BPL), Buenas Pr\u00e1cticas de Documentaci\u00f3n (BPD), Buenas Pr\u00e1cticas de Calidad y Buenas Pr\u00e1cticas de Farmacovigilancia.\n\n2. **Sistema de Gesti\u00f3n de Calidad**: \n   - Un sistema que dirige y controla una organizaci\u00f3n en relaci\u00f3n con la calidad.\n\n3. **Sistema Computarizado**: \n   - Compuesto por hardware, software y componentes de red, junto con funciones controladas y documentaci\u00f3n asociada.\n\n4. **Cumplimiento de Regulaciones BPx**: \n   - Los sistemas computarizados deben cumplir con las regulaciones BPx pertinentes, asegurando su conformidad.\n\n5. **Validaci\u00f3n de Sistemas Computarizados**: \n   - Proceso de obtener y mantener la conformidad con las regulaciones BPx y asegurar la idoneidad para el uso previsto.\n   - Implica la adopci\u00f3n de principios del ciclo de vida y la aplicaci\u00f3n de controles operativos a lo largo del ciclo de vida del sistema.\n\n### Entidades Clave\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil.\n- **FDA**: Administraci\u00f3n de Alimentos y Medicamentos de EE. UU.\n- **Regulaciones Internacionales**: Normativas de diferentes pa\u00edses y organizaciones que rigen la industria farmac\u00e9utica.\n- **BPx**: Conjunto de regulaciones que incluyen GMP, BPC, BPL, BPD, Buenas Pr\u00e1cticas de Calidad y Buenas Pr\u00e1cticas de Farmacovigilancia. \n\nEste resumen destaca la importancia de la regulaci\u00f3n y validaci\u00f3n de sistemas computarizados en la industria farmac\u00e9utica, as\u00ed como los componentes y principios que deben considerarse para asegurar la calidad y conformidad.", "excerpt_keywords": "Keywords: life cycle approach, computerized systems, validation, regulatory compliance, roles and responsibilities"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "94f75d3e-f2eb-4b11-a89a-0f04baee7d73", "node_type": "4", "metadata": {"page_label": "10", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 5. LIFE CYCLE APPROACH\n\n## 5.1 INTRODUCTION\n\nCompliance with regulatory requirements and suitability for the intended use can be achieved by adopting a life cycle approach following Best Practices.\n\nA life cycle approach implies defining and carrying out activities in a systematic way from the conception, understanding of requirements from development, release and operational use, to system retirement.\n\nThis section of the guide presents: the life cycle of the computerized system, a general approach to specification and verification and a structure for the validation of a computerized system.\n\nAn important part of implementing the lifecycle approach for computer systems is the definition, by the regulated company, of the employees who will exercise the roles of Process Owner, System Owner and Subject Specialist, for each of the systems installed in the company.\n\nThe understanding and qualification of the employees chosen from / in their respective functions are the stone fundamental for all computerized systems to be properly chosen, validated, operationalized and retired, meeting the relevant GMP and regulatory demands.\n\n## 5.2 LIFE CYCLE OF COMPUTERIZED SYSTEMS\n\nThe life cycle of a computerized system covers all activities from the initial concept to the retirement.\n\nThe life cycle of any system consists of four phases:", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "01747d42a5811865d1073ad1df55912b7caa7b7a1da87db89bbbb5ec4cc565e2", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "# 5. LIFE CYCLE APPROACH\n\n## 5.1 INTRODUCTION\n\nCompliance with regulatory requirements and suitability for the intended use can be achieved by adopting a life cycle approach following Best Practices.\n\nA life cycle approach implies defining and carrying out activities in a systematic way from the conception, understanding of requirements from development, release and operational use, to system retirement.\n\nThis section of the guide presents: the life cycle of the computerized system, a general approach to specification and verification and a structure for the validation of a computerized system.\n\nAn important part of implementing the lifecycle approach for computer systems is the definition, by the regulated company, of the employees who will exercise the roles of Process Owner, System Owner and Subject Specialist, for each of the systems installed in the company.\n\nThe understanding and qualification of the employees chosen from / in their respective functions are the stone fundamental for all computerized systems to be properly chosen, validated, operationalized and retired, meeting the relevant GMP and regulatory demands.\n\n## 5.2 LIFE CYCLE OF COMPUTERIZED SYSTEMS\n\nThe life cycle of a computerized system covers all activities from the initial concept to the retirement.\n\nThe life cycle of any system consists of four phases:", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 1345, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "c8676a15-2747-415c-9e97-fa49a6267697": {"__data__": {"id_": "c8676a15-2747-415c-9e97-fa49a6267697", "embedding": null, "metadata": {"page_label": "11", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "- Concept\n- Project\n- Operation\n- Retirement\n\nAn inventory of computerized systems must be maintained. An impact assessment on BPx should be carried out at the beginning of the design phase to determine whether a system is regulated by BPX, and if so, what specific regulations apply. This should be done as part of the initial risk assessment of the system. For similar systems, it may be appropriate to base the BPx assessment on the results of an assessment above, as long as the regulated company has a procedure established for such activity.\n\n## 5.2.1 Concept\n\nDuring the concept phase, the regulated company considers the opportunity to automate one or more processes based on business needs and benefits. Usually at this stage the initial requirements are developed and potential solutions are considered. Based on an initial understanding of the scope, costs and benefits, a decision is made about the progress of the design phase. It is the stage in which company makes the decision to change an activity performed manually by a system computerized.\n\n## 5.2.2 Project\n\nThe design phase involves planning, evaluating and selecting the supplier, the various levels of specification, configuration (or coding for custom applications) and verification that leads to acceptance and release for operation. Risk management is applied to identify risks and to remove or reduce them at an acceptable level.\n\nThis phase covers the activities of defining the user's requirements, based on the decision taken in the concept, followed by the evaluation and selection of the supplier to acquire the system, with consequent installation and validation of the computerized system by the regulated company. **In summary, in this stage the computerized system acquisition and validation activities.**\n\n## 5.2.3 Operation\n\nThis is usually the longest phase and is managed through the use of defined operating procedures and updated by people who have been properly trained, educated and experienced. **This phase is equivalent to practical use of the computerized system validated by the regulated company.** The maintenance control (including safety), adequacy of intended use and compliance with BPx are aspects-key. Managing changes of different impacts, scope and complexity is an activity important during this phase.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos describe un proceso estructurado que abarca cuatro fases: Concepto, Proyecto, Operaci\u00f3n y Retiro. Se enfatiza la importancia de mantener un inventario de sistemas inform\u00e1ticos y realizar una evaluaci\u00f3n de impacto en BPx al inicio de la fase de dise\u00f1o. Cada fase tiene objetivos y actividades espec\u00edficas, desde la identificaci\u00f3n de oportunidades de automatizaci\u00f3n hasta la gesti\u00f3n de cambios durante la operaci\u00f3n del sistema.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfCu\u00e1l es el prop\u00f3sito de realizar una evaluaci\u00f3n de impacto en BPx al inicio de la fase de dise\u00f1o?**\n   - La evaluaci\u00f3n de impacto en BPx tiene como objetivo determinar si un sistema est\u00e1 regulado por BPx y qu\u00e9 regulaciones espec\u00edficas se aplican, lo cual es crucial para la gesti\u00f3n de riesgos y el cumplimiento normativo desde el inicio del proyecto.\n\n2. **\u00bfQu\u00e9 actividades se llevan a cabo durante la fase de Proyecto en el proceso de validaci\u00f3n de sistemas inform\u00e1ticos?**\n   - Durante la fase de Proyecto, se realizan actividades como la planificaci\u00f3n, evaluaci\u00f3n y selecci\u00f3n del proveedor, especificaci\u00f3n de requisitos del usuario, configuraci\u00f3n o codificaci\u00f3n de aplicaciones personalizadas, y verificaci\u00f3n que conduce a la aceptaci\u00f3n y liberaci\u00f3n del sistema para su operaci\u00f3n.\n\n3. **\u00bfCu\u00e1les son los aspectos clave que se deben gestionar durante la fase de Operaci\u00f3n de un sistema inform\u00e1tico validado?**\n   - En la fase de Operaci\u00f3n, los aspectos clave incluyen el control de mantenimiento (incluyendo la seguridad), la adecuaci\u00f3n del uso previsto y el cumplimiento con BPx, as\u00ed como la gesti\u00f3n de cambios que pueden tener diferentes impactos, alcance y complejidad.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n**1. Enfoque del Ciclo de Vida:**\n   - Se propone un enfoque sistem\u00e1tico para la validaci\u00f3n de sistemas computarizados, que abarca desde la concepci\u00f3n hasta el retiro del sistema.\n   - Este enfoque asegura el cumplimiento de requisitos regulatorios y la idoneidad del sistema para su uso previsto.\n\n**2. Fases del Ciclo de Vida:**\n   - El ciclo de vida de un sistema computarizado incluye todas las actividades desde la idea inicial hasta su eventual retiro, aunque no se detallan las cuatro fases en el extracto proporcionado.\n\n**3. Roles Clave:**\n   - **Propietario del Proceso:** Responsable de la gesti\u00f3n del proceso relacionado con el sistema.\n   - **Propietario del Sistema:** Encargado de la supervisi\u00f3n y mantenimiento del sistema computarizado.\n   - **Especialista en la Materia:** Proporciona conocimientos t\u00e9cnicos y experiencia sobre el sistema.\n\n**4. Importancia de la Comprensi\u00f3n y Calificaci\u00f3n:**\n   - La comprensi\u00f3n y calificaci\u00f3n de los empleados en sus roles son fundamentales para garantizar que los sistemas sean seleccionados, validados, operados y retirados adecuadamente, cumpliendo con las Buenas Pr\u00e1cticas de Manufactura (GMP) y regulaciones pertinentes.\n\n**5. Mejores Pr\u00e1cticas:**\n   - Se enfatiza la adopci\u00f3n de mejores pr\u00e1cticas para asegurar la efectividad y cumplimiento de los sistemas computarizados a lo largo de su ciclo de vida.\n\nEste resumen destaca la importancia de un enfoque estructurado y la definici\u00f3n clara de roles en la gesti\u00f3n de sistemas computarizados dentro de un marco regulatorio.", "excerpt_keywords": "Keywords: validation, computerized systems, BPx, risk assessment, regulatory compliance"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "dbf54242-7f90-49bf-a42a-72d7f92b5c5b", "node_type": "4", "metadata": {"page_label": "11", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "- Concept\n- Project\n- Operation\n- Retirement\n\nAn inventory of computerized systems must be maintained. An impact assessment on BPx should be carried out at the beginning of the design phase to determine whether a system is regulated by BPX, and if so, what specific regulations apply. This should be done as part of the initial risk assessment of the system. For similar systems, it may be appropriate to base the BPx assessment on the results of an assessment above, as long as the regulated company has a procedure established for such activity.\n\n## 5.2.1 Concept\n\nDuring the concept phase, the regulated company considers the opportunity to automate one or more processes based on business needs and benefits. Usually at this stage the initial requirements are developed and potential solutions are considered. Based on an initial understanding of the scope, costs and benefits, a decision is made about the progress of the design phase. It is the stage in which company makes the decision to change an activity performed manually by a system computerized.\n\n## 5.2.2 Project\n\nThe design phase involves planning, evaluating and selecting the supplier, the various levels of specification, configuration (or coding for custom applications) and verification that leads to acceptance and release for operation. Risk management is applied to identify risks and to remove or reduce them at an acceptable level.\n\nThis phase covers the activities of defining the user's requirements, based on the decision taken in the concept, followed by the evaluation and selection of the supplier to acquire the system, with consequent installation and validation of the computerized system by the regulated company. **In summary, in this stage the computerized system acquisition and validation activities.**\n\n## 5.2.3 Operation\n\nThis is usually the longest phase and is managed through the use of defined operating procedures and updated by people who have been properly trained, educated and experienced. **This phase is equivalent to practical use of the computerized system validated by the regulated company.** The maintenance control (including safety), adequacy of intended use and compliance with BPx are aspects-key. Managing changes of different impacts, scope and complexity is an activity important during this phase.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "f41db2ca3e014ab82e98763ec0f844f2bfabd1fcd3923e2a9e8a5959e5ae9d26", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "- Concept\n- Project\n- Operation\n- Retirement\n\nAn inventory of computerized systems must be maintained. An impact assessment on BPx should be carried out at the beginning of the design phase to determine whether a system is regulated by BPX, and if so, what specific regulations apply. This should be done as part of the initial risk assessment of the system. For similar systems, it may be appropriate to base the BPx assessment on the results of an assessment above, as long as the regulated company has a procedure established for such activity.\n\n## 5.2.1 Concept\n\nDuring the concept phase, the regulated company considers the opportunity to automate one or more processes based on business needs and benefits. Usually at this stage the initial requirements are developed and potential solutions are considered. Based on an initial understanding of the scope, costs and benefits, a decision is made about the progress of the design phase. It is the stage in which company makes the decision to change an activity performed manually by a system computerized.\n\n## 5.2.2 Project\n\nThe design phase involves planning, evaluating and selecting the supplier, the various levels of specification, configuration (or coding for custom applications) and verification that leads to acceptance and release for operation. Risk management is applied to identify risks and to remove or reduce them at an acceptable level.\n\nThis phase covers the activities of defining the user's requirements, based on the decision taken in the concept, followed by the evaluation and selection of the supplier to acquire the system, with consequent installation and validation of the computerized system by the regulated company. **In summary, in this stage the computerized system acquisition and validation activities.**\n\n## 5.2.3 Operation\n\nThis is usually the longest phase and is managed through the use of defined operating procedures and updated by people who have been properly trained, educated and experienced. **This phase is equivalent to practical use of the computerized system validated by the regulated company.** The maintenance control (including safety), adequacy of intended use and compliance with BPx are aspects-key. Managing changes of different impacts, scope and complexity is an activity important during this phase.", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 2313, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "84a23a5f-9d44-43f0-8cb1-bd700b02eaae": {"__data__": {"id_": "84a23a5f-9d44-43f0-8cb1-bd700b02eaae", "embedding": null, "metadata": {"page_label": "12", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "## 5.2.3 Retirement\n\nIt is the final stage of the life cycle of the computerized system. **As the name says: the system is retired.** It involves decisions about data retention, migration or destruction and the management of these processes.\n\nSuppliers of products and services should be involved, where appropriate, throughout the life cycle. It may be appropriate to delegate many of the activities described to suppliers, if their assessment is satisfactory and control measures are in place. The life cycle phases are shown in figure 2.\n\n!Figure 2. The Life Cycle Stages.\n\n## 5.3 COMPUTERIZED SYSTEM VALIDATION STRUCTURE\n\n### 5.3.1 Introduction\n\nThere must be a structure for the validation of computerized systems that ensures obtaining and maintenance of service to BPX throughout the life cycle of the computerized system.\n\nThis structure is based on specific plans and reports per system and the application of operational controls appropriate. Validation plans and reports provide a consistent and disciplined approach to compliance with regulatory requirements. Such documents are valuable for preparation for / and during regulatory inspections.\n\nThe regulated company's Quality Risk Management System has the role of effectively and efficiently cover the wide variety of existing systems.\n\nIf the computerized system is part of a larger manufacturing process or system, mainly in an integrated Quality by Project (QbD) environment, the validation of the system carried out in a specific and separate may not be necessary. This environment requires a complete understanding of both process and the product and that the critical process parameters can be accurately and accurately reliability, planned and controlled within the project space. In this case, the adequacy of the system computerized to the intended use within the process, can be adequately demonstrated by the", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "### Res\u00famenes de nivel superior del contexto circundante\n\n1. **Ciclo de vida de los sistemas computarizados**: El ciclo de vida de un sistema computarizado incluye varias etapas, desde su desarrollo hasta su retiro. Cada etapa implica decisiones cr\u00edticas sobre la gesti\u00f3n del sistema, incluyendo la participaci\u00f3n de proveedores y la delegaci\u00f3n de actividades, siempre que se mantengan controles adecuados.\n\n2. **Estructura de validaci\u00f3n de sistemas computarizados**: Es esencial contar con una estructura de validaci\u00f3n que garantice el mantenimiento del servicio a lo largo del ciclo de vida del sistema. Esto incluye la elaboraci\u00f3n de planes y reportes espec\u00edficos que aseguren el cumplimiento de los requisitos regulatorios y faciliten las inspecciones.\n\n3. **Integraci\u00f3n en procesos m\u00e1s amplios**: En entornos donde el sistema computarizado forma parte de un proceso de fabricaci\u00f3n m\u00e1s amplio, especialmente en un contexto de Calidad por Dise\u00f1o (QbD), la validaci\u00f3n separada del sistema puede no ser necesaria. La comprensi\u00f3n integral del proceso y del producto es crucial para demostrar la adecuaci\u00f3n del sistema.\n\n### Preguntas espec\u00edficas que el contexto puede responder\n\n1. **\u00bfQu\u00e9 decisiones deben tomarse durante la etapa de retiro de un sistema computarizado?**\n   - El contexto menciona que durante la etapa de retiro se deben tomar decisiones sobre la retenci\u00f3n, migraci\u00f3n o destrucci\u00f3n de datos, as\u00ed como la gesti\u00f3n de estos procesos.\n\n2. **\u00bfCu\u00e1l es el papel de los proveedores en el ciclo de vida de un sistema computarizado?**\n   - Se indica que los proveedores de productos y servicios deben estar involucrados a lo largo del ciclo de vida del sistema y que es posible delegar actividades a ellos, siempre que se realice una evaluaci\u00f3n satisfactoria y se implementen medidas de control.\n\n3. **\u00bfPor qu\u00e9 puede no ser necesaria una validaci\u00f3n separada en un entorno de Calidad por Dise\u00f1o (QbD)?**\n   - En un entorno QbD, la validaci\u00f3n separada del sistema puede no ser necesaria porque se requiere una comprensi\u00f3n completa del proceso y del producto, lo que permite demostrar adecuadamente la adecuaci\u00f3n del sistema a su uso previsto dentro del proceso.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos se centra en un proceso estructurado que abarca cuatro fases principales: **Concepto**, **Proyecto**, **Operaci\u00f3n** y **Retiro**. A continuaci\u00f3n se presentan los temas clave y entidades relevantes de cada fase:\n\n1. **Concepto**\n   - **Objetivo**: Evaluar la oportunidad de automatizar procesos basados en necesidades y beneficios empresariales.\n   - **Actividades**: Desarrollo de requisitos iniciales y consideraci\u00f3n de soluciones potenciales.\n   - **Decisi\u00f3n**: Determinar si avanzar a la fase de dise\u00f1o.\n\n2. **Proyecto**\n   - **Objetivo**: Planificaci\u00f3n y dise\u00f1o del sistema inform\u00e1tico.\n   - **Actividades**: \n     - Evaluaci\u00f3n y selecci\u00f3n del proveedor.\n     - Especificaci\u00f3n de requisitos del usuario.\n     - Configuraci\u00f3n o codificaci\u00f3n de aplicaciones personalizadas.\n     - Verificaci\u00f3n para aceptaci\u00f3n y liberaci\u00f3n del sistema.\n   - **Gesti\u00f3n de Riesgos**: Identificaci\u00f3n y mitigaci\u00f3n de riesgos.\n\n3. **Operaci\u00f3n**\n   - **Objetivo**: Uso pr\u00e1ctico del sistema validado.\n   - **Actividades**: \n     - Mantenimiento controlado del sistema.\n     - Aseguramiento de la adecuaci\u00f3n del uso previsto.\n     - Cumplimiento con regulaciones BPx.\n     - Gesti\u00f3n de cambios con diferentes impactos y complejidades.\n   - **Importancia**: Esta fase es la m\u00e1s prolongada y requiere personal capacitado.\n\n4. **Retiro**\n   - Aunque no se detalla en el texto proporcionado, se infiere que esta fase implica la desactivaci\u00f3n y eliminaci\u00f3n segura de sistemas obsoletos o no utilizados.\n\n### Entidades Clave\n- **BPx**: Regulaciones que deben ser consideradas durante la evaluaci\u00f3n de impacto y gesti\u00f3n de riesgos.\n- **Sistemas Inform\u00e1ticos**: Elementos que deben ser validados y mantenidos a lo largo de su ciclo de vida.\n- **Proveedor**: Entidad seleccionada para la adquisici\u00f3n del sistema.\n\nEste resumen destaca la importancia de un enfoque sistem\u00e1tico en la validaci\u00f3n de sistemas inform\u00e1ticos, asegurando el cumplimiento normativo y la gesti\u00f3n efectiva de riesgos a lo largo de todas las fases del ciclo de vida del sistema.", "excerpt_keywords": "Keywords: retirement, computerized systems, validation structure, regulatory compliance, Quality by Design"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "1235ada1-552c-4c0b-bb7f-bbd6d854393c", "node_type": "4", "metadata": {"page_label": "12", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "## 5.2.3 Retirement\n\nIt is the final stage of the life cycle of the computerized system. **As the name says: the system is retired.** It involves decisions about data retention, migration or destruction and the management of these processes.\n\nSuppliers of products and services should be involved, where appropriate, throughout the life cycle. It may be appropriate to delegate many of the activities described to suppliers, if their assessment is satisfactory and control measures are in place. The life cycle phases are shown in figure 2.\n\n!Figure 2. The Life Cycle Stages.\n\n## 5.3 COMPUTERIZED SYSTEM VALIDATION STRUCTURE\n\n### 5.3.1 Introduction\n\nThere must be a structure for the validation of computerized systems that ensures obtaining and maintenance of service to BPX throughout the life cycle of the computerized system.\n\nThis structure is based on specific plans and reports per system and the application of operational controls appropriate. Validation plans and reports provide a consistent and disciplined approach to compliance with regulatory requirements. Such documents are valuable for preparation for / and during regulatory inspections.\n\nThe regulated company's Quality Risk Management System has the role of effectively and efficiently cover the wide variety of existing systems.\n\nIf the computerized system is part of a larger manufacturing process or system, mainly in an integrated Quality by Project (QbD) environment, the validation of the system carried out in a specific and separate may not be necessary. This environment requires a complete understanding of both process and the product and that the critical process parameters can be accurately and accurately reliability, planned and controlled within the project space. In this case, the adequacy of the system computerized to the intended use within the process, can be adequately demonstrated by the", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "0b87552832a978686fa026c5367fc6530c26522f913d7499674a43bc48c55552", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "## 5.2.3 Retirement\n\nIt is the final stage of the life cycle of the computerized system. **As the name says: the system is retired.** It involves decisions about data retention, migration or destruction and the management of these processes.\n\nSuppliers of products and services should be involved, where appropriate, throughout the life cycle. It may be appropriate to delegate many of the activities described to suppliers, if their assessment is satisfactory and control measures are in place. The life cycle phases are shown in figure 2.\n\n!Figure 2. The Life Cycle Stages.\n\n## 5.3 COMPUTERIZED SYSTEM VALIDATION STRUCTURE\n\n### 5.3.1 Introduction\n\nThere must be a structure for the validation of computerized systems that ensures obtaining and maintenance of service to BPX throughout the life cycle of the computerized system.\n\nThis structure is based on specific plans and reports per system and the application of operational controls appropriate. Validation plans and reports provide a consistent and disciplined approach to compliance with regulatory requirements. Such documents are valuable for preparation for / and during regulatory inspections.\n\nThe regulated company's Quality Risk Management System has the role of effectively and efficiently cover the wide variety of existing systems.\n\nIf the computerized system is part of a larger manufacturing process or system, mainly in an integrated Quality by Project (QbD) environment, the validation of the system carried out in a specific and separate may not be necessary. This environment requires a complete understanding of both process and the product and that the critical process parameters can be accurately and accurately reliability, planned and controlled within the project space. In this case, the adequacy of the system computerized to the intended use within the process, can be adequately demonstrated by the", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 1884, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "0ed97d4b-d4d7-4fb3-a169-8946a117ebbf": {"__data__": {"id_": "0ed97d4b-d4d7-4fb3-a169-8946a117ebbf", "embedding": null, "metadata": {"page_label": "13", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 5.3.2 Terminology\n\nThe specific terminology used to describe life cycle activities varies from company to company. System type to another. There are several reasons for this:\n\n- Regulated companies use different approaches;\n- There is a difference in emphasis on BLP, BPC, GMP and medical devices;\n- There are differences in the requirements of the various regulatory agencies;\n- Different standards, local and international, are followed;\n- There are different types of computerized systems (IT, manufacturing, laboratories);\n- Suppliers use different models and development approaches.\n\nThis Guide, in harmony with the document GAMP 5, is intended to be flexible and is not intended to prescribe a single set of terms, excluding others.\n\nTable 1 shows the relationship between the traditional terminology for Qualification and the activities described in this Guide.\n\nThe terms used to describe the systems verification stage are the ones that have the greatest diversity. This section describes how the terminology traditionally used for qualification relates to with the activities described in this Guide.\n\nWhatever the terminology used by the company, the requirement that overlaps everything is that the regulated company can demonstrate that the system is compliant and suitable for its intended use.\n\nThe use of qualification terminology in relation to computerized systems and the relationship between QO and QD particularly, varies from company to company.\n\nIt is up to companies to decide on the verification strategy they will use.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas que pueden proporcionar respuestas espec\u00edficas basadas en el contexto proporcionado:\n\n1. **\u00bfCu\u00e1les son las razones por las que la terminolog\u00eda utilizada para describir las actividades del ciclo de vida var\u00eda entre diferentes empresas y tipos de sistemas?**\n   - Respuesta: La variaci\u00f3n en la terminolog\u00eda se debe a varios factores, incluyendo diferentes enfoques utilizados por empresas reguladas, diferencias en el \u00e9nfasis en BLP, BPC, GMP y dispositivos m\u00e9dicos, requisitos diversos de agencias regulatorias, est\u00e1ndares locales e internacionales, tipos de sistemas computarizados (como IT, manufactura y laboratorios), y modelos y enfoques de desarrollo utilizados por los proveedores.\n\n2. **\u00bfQu\u00e9 relaci\u00f3n existe entre la terminolog\u00eda tradicional de calificaci\u00f3n y las actividades descritas en la Gu\u00eda de ANVISA?**\n   - Respuesta: La Gu\u00eda de ANVISA, en armon\u00eda con el documento GAMP 5, establece una relaci\u00f3n entre la terminolog\u00eda tradicional de calificaci\u00f3n y las actividades descritas en la gu\u00eda. Aunque la terminolog\u00eda puede variar, el requisito fundamental es que la empresa regulada demuestre que el sistema es conforme y adecuado para su uso previsto.\n\n3. **\u00bfQu\u00e9 papel juega la flexibilidad en la terminolog\u00eda utilizada en la Gu\u00eda de ANVISA en comparaci\u00f3n con otros est\u00e1ndares?**\n   - Respuesta: La Gu\u00eda de ANVISA es intencionadamente flexible y no prescribe un conjunto \u00fanico de t\u00e9rminos, lo que permite a las empresas adaptar su terminolog\u00eda y estrategias de verificaci\u00f3n seg\u00fan sus necesidades espec\u00edficas y el contexto regulatorio en el que operan.\n\n### Resumen de nivel superior del contexto circundante:\nEl contexto se centra en la variabilidad de la terminolog\u00eda utilizada en la validaci\u00f3n de sistemas computarizados en empresas reguladas. Destaca la importancia de que las empresas demuestren la conformidad y adecuaci\u00f3n de sus sistemas, independientemente de la terminolog\u00eda espec\u00edfica que utilicen. La Gu\u00eda de ANVISA busca ser flexible y se alinea con el documento GAMP 5, permitiendo a las empresas decidir su propia estrategia de verificaci\u00f3n.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Retiro de Sistemas Computarizados**:\n   - El retiro es la etapa final del ciclo de vida de un sistema computarizado, donde se toman decisiones sobre la retenci\u00f3n, migraci\u00f3n o destrucci\u00f3n de datos.\n   - Es fundamental gestionar adecuadamente estos procesos.\n\n2. **Participaci\u00f3n de Proveedores**:\n   - Los proveedores de productos y servicios deben estar involucrados a lo largo del ciclo de vida del sistema.\n   - Se puede delegar actividades a proveedores, siempre que se realice una evaluaci\u00f3n satisfactoria y se implementen controles adecuados.\n\n3. **Estructura de Validaci\u00f3n**:\n   - Es esencial contar con una estructura de validaci\u00f3n que garantice el mantenimiento del servicio durante todo el ciclo de vida del sistema.\n   - Esta estructura incluye planes y reportes espec\u00edficos que aseguran el cumplimiento de requisitos regulatorios y facilitan las inspecciones.\n\n4. **Calidad por Dise\u00f1o (QbD)**:\n   - En entornos donde el sistema computarizado forma parte de un proceso de fabricaci\u00f3n m\u00e1s amplio, la validaci\u00f3n separada puede no ser necesaria.\n   - Se requiere una comprensi\u00f3n integral del proceso y del producto para demostrar la adecuaci\u00f3n del sistema a su uso previsto.\n\n### Entidades Clave\n- **Ciclo de Vida del Sistema Computarizado**: Incluye etapas desde el desarrollo hasta el retiro.\n- **Proveedores**: Entidades que ofrecen productos y servicios relacionados con el sistema.\n- **Planes y Reportes de Validaci\u00f3n**: Documentos que aseguran el cumplimiento regulatorio.\n- **Sistema de Gesti\u00f3n de Riesgos de Calidad**: Herramienta utilizada por la empresa regulada para gestionar la variedad de sistemas existentes.\n- **Entorno de Calidad por Dise\u00f1o (QbD)**: Contexto en el que se eval\u00faa la necesidad de validaci\u00f3n separada del sistema.", "excerpt_keywords": "Keywords: validation, terminology, compliance, computerized systems, regulatory agencies"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "e7b278b6-e0af-45d1-a230-c28eb69e443f", "node_type": "4", "metadata": {"page_label": "13", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 5.3.2 Terminology\n\nThe specific terminology used to describe life cycle activities varies from company to company. System type to another. There are several reasons for this:\n\n- Regulated companies use different approaches;\n- There is a difference in emphasis on BLP, BPC, GMP and medical devices;\n- There are differences in the requirements of the various regulatory agencies;\n- Different standards, local and international, are followed;\n- There are different types of computerized systems (IT, manufacturing, laboratories);\n- Suppliers use different models and development approaches.\n\nThis Guide, in harmony with the document GAMP 5, is intended to be flexible and is not intended to prescribe a single set of terms, excluding others.\n\nTable 1 shows the relationship between the traditional terminology for Qualification and the activities described in this Guide.\n\nThe terms used to describe the systems verification stage are the ones that have the greatest diversity. This section describes how the terminology traditionally used for qualification relates to with the activities described in this Guide.\n\nWhatever the terminology used by the company, the requirement that overlaps everything is that the regulated company can demonstrate that the system is compliant and suitable for its intended use.\n\nThe use of qualification terminology in relation to computerized systems and the relationship between QO and QD particularly, varies from company to company.\n\nIt is up to companies to decide on the verification strategy they will use.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "13fc50834e1c51f6d7ec8e2ba7bf5d1f073d6f86e065c46234206cd34ed55849", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "# 5.3.2 Terminology\n\nThe specific terminology used to describe life cycle activities varies from company to company. System type to another. There are several reasons for this:\n\n- Regulated companies use different approaches;\n- There is a difference in emphasis on BLP, BPC, GMP and medical devices;\n- There are differences in the requirements of the various regulatory agencies;\n- Different standards, local and international, are followed;\n- There are different types of computerized systems (IT, manufacturing, laboratories);\n- Suppliers use different models and development approaches.\n\nThis Guide, in harmony with the document GAMP 5, is intended to be flexible and is not intended to prescribe a single set of terms, excluding others.\n\nTable 1 shows the relationship between the traditional terminology for Qualification and the activities described in this Guide.\n\nThe terms used to describe the systems verification stage are the ones that have the greatest diversity. This section describes how the terminology traditionally used for qualification relates to with the activities described in this Guide.\n\nWhatever the terminology used by the company, the requirement that overlaps everything is that the regulated company can demonstrate that the system is compliant and suitable for its intended use.\n\nThe use of qualification terminology in relation to computerized systems and the relationship between QO and QD particularly, varies from company to company.\n\nIt is up to companies to decide on the verification strategy they will use.", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 1546, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "d1711c4a-a00f-4a42-b5ec-3ca221788f30": {"__data__": {"id_": "d1711c4a-a00f-4a42-b5ec-3ca221788f30", "embedding": null, "metadata": {"page_label": "14", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# Table 1. Relationship between the traditional terminology for qualification and the activities described in this Guide.\n\n| Traditional term                | description                                                                 | Verification Activity - Guide                                                                 |\n|---------------------------------|-----------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------|\n| Project Qualification (QP / DQ) | Documented verification of that the proposed project for installations, systems and equipment is suitable for the intended purpose | Project Review                                                                                |\n| Installation Qualification (IQ / IQ) | Documented verification of that the system has been installed according written specifications is pre-approved. | Verification, testing or other verification to demonstrate that the activities of installation and configuration of **hardware and software** were realized correctly |\n| Operational Qualification (QO / OQ) | Documented verification of that the system operates according to specifications writing is pre-approved and across the operational range specified. | Conducting tests or another system check against specifications for demonstrate correct functionality operation that supports the process specific business across to written specifications is pre-approved |\n| Performance Qualification (QD / PQ) | Documented verification of that the system is capable of perform activities processes as expected, according to written specifications is pre-approved, within the scope of the business process and operating environment. | Conducting tests or another system check to demonstrate suitability intended use and for allow acceptance of the system from specified requirements |\n\n# 6. QUALITY RISK MANAGEMENT\n\n## 6.1 INTRODUCTION\n\nQuality risk management consists of a systematic process for assessing, controlling, communication and risk review. It is an iterative process used throughout the life cycle of the system from conception to retirement. Figure 3 presents this concept graphically.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos establece una relaci\u00f3n entre la terminolog\u00eda tradicional de calificaci\u00f3n y las actividades descritas en la gu\u00eda. Se detallan cuatro tipos de calificaci\u00f3n: calificaci\u00f3n de proyecto (QP/DQ), calificaci\u00f3n de instalaci\u00f3n (IQ/IQ), calificaci\u00f3n operativa (QO/OQ) y calificaci\u00f3n de rendimiento (QD/PQ). Cada tipo incluye una descripci\u00f3n y las actividades de verificaci\u00f3n correspondientes. Adem\u00e1s, se introduce el concepto de gesti\u00f3n de riesgos de calidad, que es un proceso sistem\u00e1tico y continuo a lo largo del ciclo de vida del sistema.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfCu\u00e1l es la diferencia entre la calificaci\u00f3n de instalaci\u00f3n (IQ) y la calificaci\u00f3n operativa (OQ) seg\u00fan la gu\u00eda de ANVISA?**\n   - La calificaci\u00f3n de instalaci\u00f3n (IQ) se centra en verificar que el sistema se haya instalado de acuerdo con las especificaciones escritas y preaprobadas, mientras que la calificaci\u00f3n operativa (OQ) se enfoca en verificar que el sistema funcione correctamente seg\u00fan las especificaciones a lo largo de su rango operativo.\n\n2. **\u00bfQu\u00e9 actividades de verificaci\u00f3n se recomiendan para la calificaci\u00f3n de rendimiento (PQ) en el contexto de la gu\u00eda de ANVISA?**\n   - Para la calificaci\u00f3n de rendimiento (PQ), se recomienda realizar pruebas u otras verificaciones para demostrar que el sistema es adecuado para su uso previsto y que cumple con los requisitos especificados.\n\n3. **\u00bfC\u00f3mo se describe el proceso de gesti\u00f3n de riesgos de calidad en el ciclo de vida del sistema seg\u00fan el documento?**\n   - La gesti\u00f3n de riesgos de calidad se describe como un proceso sistem\u00e1tico que incluye la evaluaci\u00f3n, control, comunicaci\u00f3n y revisi\u00f3n de riesgos. Este proceso es iterativo y se utiliza a lo largo de todo el ciclo de vida del sistema, desde su concepci\u00f3n hasta su retiro.", "prev_section_summary": "### Resumen de la Secci\u00f3n 5.3.2: Terminolog\u00eda\n\n**Temas Clave:**\n\n1. **Variabilidad de la Terminolog\u00eda:**\n   - La terminolog\u00eda utilizada para describir las actividades del ciclo de vida de los sistemas computarizados var\u00eda entre empresas y tipos de sistemas debido a diversos factores, como enfoques regulatorios, \u00e9nfasis en diferentes normativas (BLP, BPC, GMP, dispositivos m\u00e9dicos), requisitos de agencias regulatorias, y est\u00e1ndares locales e internacionales.\n\n2. **Flexibilidad de la Gu\u00eda:**\n   - La Gu\u00eda de ANVISA, en consonancia con el documento GAMP 5, busca ser flexible y no prescribe un conjunto \u00fanico de t\u00e9rminos, permitiendo a las empresas adaptar su terminolog\u00eda seg\u00fan sus necesidades.\n\n3. **Relaci\u00f3n entre Terminolog\u00eda y Actividades:**\n   - Se establece una relaci\u00f3n entre la terminolog\u00eda tradicional de calificaci\u00f3n y las actividades descritas en la gu\u00eda, especialmente en la etapa de verificaci\u00f3n de sistemas, que presenta la mayor diversidad terminol\u00f3gica.\n\n4. **Requisitos de Conformidad:**\n   - Independientemente de la terminolog\u00eda utilizada, las empresas reguladas deben demostrar que sus sistemas son conformes y adecuados para su uso previsto.\n\n5. **Estrategia de Verificaci\u00f3n:**\n   - Las empresas tienen la libertad de decidir su propia estrategia de verificaci\u00f3n, lo que implica que la terminolog\u00eda y los enfoques pueden variar significativamente entre diferentes organizaciones.\n\n**Entidades:**\n\n- **ANVISA:** Agencia Nacional de Vigilancia Sanitaria de Brasil.\n- **GAMP 5:** Buenas Pr\u00e1cticas de Automatizaci\u00f3n y Validaci\u00f3n de Sistemas.\n- **BLP, BPC, GMP:** Normativas relacionadas con la calidad y regulaci\u00f3n en la industria.\n- **Tipos de Sistemas Computarizados:** IT, manufactura, laboratorios.\n- **Agencias Regulatorias:** Entidades que establecen requisitos y est\u00e1ndares para la conformidad de los sistemas. \n\nEste resumen destaca la importancia de la flexibilidad y la adaptabilidad en la terminolog\u00eda y enfoques utilizados por las empresas reguladas en la validaci\u00f3n de sistemas computarizados.", "excerpt_keywords": "Keywords: validation, qualification, risk management, ANVISA, computer systems"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "5d32fec2-7ef7-429b-9904-0bc2d4d9daef", "node_type": "4", "metadata": {"page_label": "14", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# Table 1. Relationship between the traditional terminology for qualification and the activities described in this Guide.\n\n| Traditional term                | description                                                                 | Verification Activity - Guide                                                                 |\n|---------------------------------|-----------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------|\n| Project Qualification (QP / DQ) | Documented verification of that the proposed project for installations, systems and equipment is suitable for the intended purpose | Project Review                                                                                |\n| Installation Qualification (IQ / IQ) | Documented verification of that the system has been installed according written specifications is pre-approved. | Verification, testing or other verification to demonstrate that the activities of installation and configuration of **hardware and software** were realized correctly |\n| Operational Qualification (QO / OQ) | Documented verification of that the system operates according to specifications writing is pre-approved and across the operational range specified. | Conducting tests or another system check against specifications for demonstrate correct functionality operation that supports the process specific business across to written specifications is pre-approved |\n| Performance Qualification (QD / PQ) | Documented verification of that the system is capable of perform activities processes as expected, according to written specifications is pre-approved, within the scope of the business process and operating environment. | Conducting tests or another system check to demonstrate suitability intended use and for allow acceptance of the system from specified requirements |\n\n# 6. QUALITY RISK MANAGEMENT\n\n## 6.1 INTRODUCTION\n\nQuality risk management consists of a systematic process for assessing, controlling, communication and risk review. It is an iterative process used throughout the life cycle of the system from conception to retirement. Figure 3 presents this concept graphically.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "fef3acec414d737c9013417650c062905f3f7e352404b98ffe2c94b75b2def87", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "# Table 1. Relationship between the traditional terminology for qualification and the activities described in this Guide.\n\n| Traditional term                | description                                                                 | Verification Activity - Guide                                                                 |\n|---------------------------------|-----------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------|\n| Project Qualification (QP / DQ) | Documented verification of that the proposed project for installations, systems and equipment is suitable for the intended purpose | Project Review                                                                                |\n| Installation Qualification (IQ / IQ) | Documented verification of that the system has been installed according written specifications is pre-approved. | Verification, testing or other verification to demonstrate that the activities of installation and configuration of **hardware and software** were realized correctly |\n| Operational Qualification (QO / OQ) | Documented verification of that the system operates according to specifications writing is pre-approved and across the operational range specified. | Conducting tests or another system check against specifications for demonstrate correct functionality operation that supports the process specific business across to written specifications is pre-approved |\n| Performance Qualification (QD / PQ) | Documented verification of that the system is capable of perform activities processes as expected, according to written specifications is pre-approved, within the scope of the business process and operating environment. | Conducting tests or another system check to demonstrate suitability intended use and for allow acceptance of the system from specified requirements |\n\n# 6. QUALITY RISK MANAGEMENT\n\n## 6.1 INTRODUCTION\n\nQuality risk management consists of a systematic process for assessing, controlling, communication and risk review. It is an iterative process used throughout the life cycle of the system from conception to retirement. Figure 3 presents this concept graphically.", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 2254, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "4f11fb41-89c6-48ef-8841-01b6f2d72544": {"__data__": {"id_": "4f11fb41-89c6-48ef-8841-01b6f2d72544", "embedding": null, "metadata": {"page_label": "15", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 6.2 QUALITY RISK MANAGEMENT WITH SCIENTIFIC BASIS\n\nDetermining the risks inherent in a computerized system requires an understanding of the following points:\n\n- The impact of the computerized system on patient safety, product quality and data integrity;\n- The business processes supported by the system;\n- Critical Quality Attributes (CQA) for systems that monitor or control Parameters Process Critics (CPPs);\n- User requirements;\n- Regulatory requirements;\n- The project approach (contracts, methods, schedules);\n- System components and architecture;\n- System functions;\n- Supplier capability.\n\nThe company must also consider other applicable risks such as safety, health and the environment.\n\n----\n\n**Figure 3. A Risk-Based Approach for Computer Systems Compatible with BPx.**\nSource: GAMP5", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior que puede ayudar a formularlas:\n\n### Resumen de Nivel Superior:\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos destaca la importancia de la gesti\u00f3n de riesgos de calidad con base cient\u00edfica. Para determinar los riesgos inherentes a un sistema computarizado, se deben considerar varios factores, como el impacto en la seguridad del paciente, la calidad del producto y la integridad de los datos. Tambi\u00e9n se enfatiza la necesidad de evaluar atributos cr\u00edticos de calidad, requisitos de usuario y regulaciones, as\u00ed como la capacidad del proveedor y otros riesgos aplicables.\n\n### Preguntas:\n1. **\u00bfCu\u00e1les son los Atributos Cr\u00edticos de Calidad (CQA) que deben considerarse al evaluar un sistema que controla Par\u00e1metros Cr\u00edticos de Proceso (CPP)?**\n   - Esta pregunta busca informaci\u00f3n espec\u00edfica sobre los CQA relevantes en el contexto de la validaci\u00f3n de sistemas inform\u00e1ticos, que no se detalla en otras fuentes.\n\n2. **\u00bfQu\u00e9 aspectos del enfoque del proyecto deben ser considerados para la gesti\u00f3n de riesgos en la validaci\u00f3n de sistemas inform\u00e1ticos?**\n   - Esta pregunta se centra en los elementos del enfoque del proyecto, como contratos y m\u00e9todos, que son cruciales para la gesti\u00f3n de riesgos, y que pueden no estar claramente definidos en otros documentos.\n\n3. **\u00bfQu\u00e9 tipo de riesgos adicionales, m\u00e1s all\u00e1 de los relacionados con la calidad y la seguridad del paciente, deben ser considerados por las empresas al validar sistemas inform\u00e1ticos?**\n   - Esta pregunta busca explorar otros riesgos aplicables, como los relacionados con la salud y el medio ambiente, que son mencionados en el contexto pero que pueden no ser ampliamente discutidos en otras gu\u00edas o normativas.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Terminolog\u00eda de Calificaci\u00f3n**:\n   - El documento establece una relaci\u00f3n entre t\u00e9rminos tradicionales de calificaci\u00f3n y actividades de verificaci\u00f3n.\n   - Se identifican cuatro tipos de calificaci\u00f3n:\n     - **Calificaci\u00f3n de Proyecto (QP/DQ)**: Verificaci\u00f3n documentada de la idoneidad del proyecto.\n     - **Calificaci\u00f3n de Instalaci\u00f3n (IQ/IQ)**: Verificaci\u00f3n de que el sistema se ha instalado seg\u00fan especificaciones preaprobadas.\n     - **Calificaci\u00f3n Operativa (OQ)**: Verificaci\u00f3n de que el sistema opera correctamente dentro de su rango operativo.\n     - **Calificaci\u00f3n de Rendimiento (PQ)**: Verificaci\u00f3n de que el sistema puede realizar actividades seg\u00fan lo esperado.\n\n2. **Actividades de Verificaci\u00f3n**:\n   - Cada tipo de calificaci\u00f3n incluye actividades espec\u00edficas de verificaci\u00f3n, como revisiones de proyectos, pruebas de instalaci\u00f3n, y chequeos de funcionalidad.\n\n3. **Gesti\u00f3n de Riesgos de Calidad**:\n   - Se introduce el concepto de gesti\u00f3n de riesgos de calidad como un proceso sistem\u00e1tico que abarca la evaluaci\u00f3n, control, comunicaci\u00f3n y revisi\u00f3n de riesgos.\n   - Este proceso es iterativo y se aplica a lo largo del ciclo de vida del sistema, desde su concepci\u00f3n hasta su retiro.\n\n### Entidades Clave:\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil.\n- **Calificaci\u00f3n de Proyecto (QP/DQ)**.\n- **Calificaci\u00f3n de Instalaci\u00f3n (IQ/IQ)**.\n- **Calificaci\u00f3n Operativa (OQ)**.\n- **Calificaci\u00f3n de Rendimiento (PQ)**.\n- **Gesti\u00f3n de Riesgos de Calidad**. \n\nEste resumen destaca la estructura y los conceptos fundamentales presentados en la gu\u00eda de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos.", "excerpt_keywords": "Keywords: Quality Risk Management, Computerized Systems, Critical Quality Attributes, Regulatory Requirements, Supplier Capability"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "8ab28ffd-7b16-434d-b047-d1a558e705db", "node_type": "4", "metadata": {"page_label": "15", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 6.2 QUALITY RISK MANAGEMENT WITH SCIENTIFIC BASIS\n\nDetermining the risks inherent in a computerized system requires an understanding of the following points:\n\n- The impact of the computerized system on patient safety, product quality and data integrity;\n- The business processes supported by the system;\n- Critical Quality Attributes (CQA) for systems that monitor or control Parameters Process Critics (CPPs);\n- User requirements;\n- Regulatory requirements;\n- The project approach (contracts, methods, schedules);\n- System components and architecture;\n- System functions;\n- Supplier capability.\n\nThe company must also consider other applicable risks such as safety, health and the environment.\n\n----\n\n**Figure 3. A Risk-Based Approach for Computer Systems Compatible with BPx.**\nSource: GAMP5", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "d35b757f043139b5f5df31c3dd4668f114f54c7710a7c0654ba9c5484dfa95cc", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "# 6.2 QUALITY RISK MANAGEMENT WITH SCIENTIFIC BASIS\n\nDetermining the risks inherent in a computerized system requires an understanding of the following points:\n\n- The impact of the computerized system on patient safety, product quality and data integrity;\n- The business processes supported by the system;\n- Critical Quality Attributes (CQA) for systems that monitor or control Parameters Process Critics (CPPs);\n- User requirements;\n- Regulatory requirements;\n- The project approach (contracts, methods, schedules);\n- System components and architecture;\n- System functions;\n- Supplier capability.\n\nThe company must also consider other applicable risks such as safety, health and the environment.\n\n----\n\n**Figure 3. A Risk-Based Approach for Computer Systems Compatible with BPx.**\nSource: GAMP5", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 795, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "9d7f17e3-ce33-48e0-8a01-9ccf3c5c291f": {"__data__": {"id_": "9d7f17e3-ce33-48e0-8a01-9ccf3c5c291f", "embedding": null, "metadata": {"page_label": "16", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 6.3 QUALITY RISK MANAGEMENT PROCESS\n\nThere is an international guide available (ICH Q9) that deals with quality risk management within the pharmaceutical industry.\n\nIt defines the two primary principles of quality risk management, namely:\n\n* Quality risk assessment should be based on scientific knowledge and linked to the patient protection;\n* The level of effort, formality and documentation of the quality risk management process must be commensurate with the level of risk.\n\nIn the context of computerized systems, scientific knowledge is based on the specifications of the system and the business process that the system supports.\n\nThe quality risk management process involves the execution of 05 (five) steps:\n\n1. Performing the initial risk assessment and determining the impact of the system;\n2. Identification of functions that have an impact on patient safety, product quality and data integrity;\n3. Performing functional risk assessments and identifying the necessary controls;\n4. Implementation and verification of appropriate controls;\n5. Review of risks and monitoring of implemented controls.\n\nThese steps are detailed below.\n\n## 6.3.1 Step 1 - Initial Risk Assessment\n\nAn initial risk analysis should be carried out based on an understanding of the processes and risk assessments business requirements, user requirements, regulatory requirements and known functional areas.\n\nThe results of this initial risk assessment should include the decision on whether the system is regulated by BPx (BPx evaluation). A general assessment of the system's impact should also be included.\n\nBased on this initial risk assessment and system impact it may not be necessary to perform the steps subsequent risks if the risk is already at an acceptable level.\n\nThe necessary effort, formalization and documentation of the subsequent steps must be determined with based on the level of risk and the impact of the system on BPx.\n\n## 6.3.2 Step 2 - Identification of Functions\n\nFunctions that impact patient safety, product quality and data integrity should be identified by the construction of the information gathered in step 1, referring to the specifications relevant and taking into account the project approach, the system architecture and the categorization of system components.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos establece un proceso de gesti\u00f3n de riesgos de calidad que se basa en principios internacionales, espec\u00edficamente el ICH Q9. Este proceso consta de cinco pasos que incluyen la evaluaci\u00f3n inicial de riesgos, la identificaci\u00f3n de funciones cr\u00edticas, la evaluaci\u00f3n de riesgos funcionales, la implementaci\u00f3n de controles y la revisi\u00f3n continua de riesgos. Se enfatiza que la evaluaci\u00f3n de riesgos debe estar fundamentada en el conocimiento cient\u00edfico y que el esfuerzo y la documentaci\u00f3n deben ser proporcionales al nivel de riesgo identificado.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfCu\u00e1les son los dos principios fundamentales de la gesti\u00f3n de riesgos de calidad seg\u00fan el ICH Q9 y c\u00f3mo se aplican en el contexto de los sistemas inform\u00e1ticos?**\n   - Respuesta: Los dos principios fundamentales son que la evaluaci\u00f3n de riesgos de calidad debe basarse en el conocimiento cient\u00edfico y estar vinculada a la protecci\u00f3n del paciente, y que el nivel de esfuerzo, formalidad y documentaci\u00f3n del proceso de gesti\u00f3n de riesgos debe ser proporcional al nivel de riesgo.\n\n2. **\u00bfQu\u00e9 factores se deben considerar al realizar la evaluaci\u00f3n inicial de riesgos en un sistema inform\u00e1tico?**\n   - Respuesta: La evaluaci\u00f3n inicial de riesgos debe basarse en la comprensi\u00f3n de los procesos y requisitos de negocio, requisitos de usuario, requisitos regulatorios y \u00e1reas funcionales conocidas.\n\n3. **\u00bfQu\u00e9 pasos se deben seguir despu\u00e9s de la identificaci\u00f3n de funciones que impactan la seguridad del paciente y la calidad del producto?**\n   - Respuesta: Despu\u00e9s de identificar las funciones cr\u00edticas, se deben realizar evaluaciones de riesgos funcionales, identificar los controles necesarios, implementar y verificar los controles apropiados, y finalmente revisar los riesgos y monitorear los controles implementados.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\nLa secci\u00f3n 6.2 del documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos se centra en la gesti\u00f3n de riesgos de calidad con base cient\u00edfica. Los temas clave incluyen:\n\n1. **Riesgos Inherentes a Sistemas Computarizados**: Se enfatiza la necesidad de comprender los riesgos asociados a los sistemas inform\u00e1ticos, considerando su impacto en la seguridad del paciente, la calidad del producto y la integridad de los datos.\n\n2. **Factores a Considerar**:\n   - **Impacto en la Seguridad del Paciente**: Evaluar c\u00f3mo el sistema afecta la salud y seguridad de los pacientes.\n   - **Calidad del Producto**: Asegurar que el sistema mantenga los est\u00e1ndares de calidad del producto.\n   - **Integridad de los Datos**: Proteger la precisi\u00f3n y consistencia de los datos gestionados por el sistema.\n   - **Procesos de Negocio**: Identificar los procesos que el sistema soporta.\n   - **Atributos Cr\u00edticos de Calidad (CQA)**: Considerar los CQA relevantes para sistemas que controlan Par\u00e1metros Cr\u00edticos de Proceso (CPP).\n   - **Requisitos de Usuario y Regulatorios**: Evaluar las necesidades de los usuarios y las normativas aplicables.\n   - **Enfoque del Proyecto**: Incluir aspectos como contratos, m\u00e9todos y cronogramas en la gesti\u00f3n de riesgos.\n   - **Componentes y Arquitectura del Sistema**: Analizar la estructura y funciones del sistema.\n   - **Capacidad del Proveedor**: Evaluar la competencia y capacidad del proveedor del sistema.\n\n3. **Riesgos Adicionales**: Las empresas deben considerar otros riesgos aplicables, como los relacionados con la seguridad, la salud y el medio ambiente.\n\n### Entidades Clave\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil.\n- **CQA (Atributos Cr\u00edticos de Calidad)**: Elementos esenciales que deben ser controlados para asegurar la calidad del producto.\n- **CPP (Par\u00e1metros Cr\u00edticos de Proceso)**: Variables que deben ser controladas para garantizar la calidad del proceso.\n- **GAMP5**: Buenas Pr\u00e1cticas de Automatizaci\u00f3n y Validaci\u00f3n de Sistemas.\n\nEste resumen destaca la importancia de un enfoque integral y basado en riesgos para la validaci\u00f3n de sistemas inform\u00e1ticos en el contexto de la regulaci\u00f3n sanitaria.", "excerpt_keywords": "Keywords: quality risk management, ANVISA, computerized systems, patient safety, regulatory requirements"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "5a11b3f2-3c48-4c12-a4f1-a005f6dcc9b7", "node_type": "4", "metadata": {"page_label": "16", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 6.3 QUALITY RISK MANAGEMENT PROCESS\n\nThere is an international guide available (ICH Q9) that deals with quality risk management within the pharmaceutical industry.\n\nIt defines the two primary principles of quality risk management, namely:\n\n* Quality risk assessment should be based on scientific knowledge and linked to the patient protection;\n* The level of effort, formality and documentation of the quality risk management process must be commensurate with the level of risk.\n\nIn the context of computerized systems, scientific knowledge is based on the specifications of the system and the business process that the system supports.\n\nThe quality risk management process involves the execution of 05 (five) steps:\n\n1. Performing the initial risk assessment and determining the impact of the system;\n2. Identification of functions that have an impact on patient safety, product quality and data integrity;\n3. Performing functional risk assessments and identifying the necessary controls;\n4. Implementation and verification of appropriate controls;\n5. Review of risks and monitoring of implemented controls.\n\nThese steps are detailed below.\n\n## 6.3.1 Step 1 - Initial Risk Assessment\n\nAn initial risk analysis should be carried out based on an understanding of the processes and risk assessments business requirements, user requirements, regulatory requirements and known functional areas.\n\nThe results of this initial risk assessment should include the decision on whether the system is regulated by BPx (BPx evaluation). A general assessment of the system's impact should also be included.\n\nBased on this initial risk assessment and system impact it may not be necessary to perform the steps subsequent risks if the risk is already at an acceptable level.\n\nThe necessary effort, formalization and documentation of the subsequent steps must be determined with based on the level of risk and the impact of the system on BPx.\n\n## 6.3.2 Step 2 - Identification of Functions\n\nFunctions that impact patient safety, product quality and data integrity should be identified by the construction of the information gathered in step 1, referring to the specifications relevant and taking into account the project approach, the system architecture and the categorization of system components.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "38bb092615258c2d44fbaf79701ac2c3ccc0dba06856e3545a77883f81b9883e", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "# 6.3 QUALITY RISK MANAGEMENT PROCESS\n\nThere is an international guide available (ICH Q9) that deals with quality risk management within the pharmaceutical industry.\n\nIt defines the two primary principles of quality risk management, namely:\n\n* Quality risk assessment should be based on scientific knowledge and linked to the patient protection;\n* The level of effort, formality and documentation of the quality risk management process must be commensurate with the level of risk.\n\nIn the context of computerized systems, scientific knowledge is based on the specifications of the system and the business process that the system supports.\n\nThe quality risk management process involves the execution of 05 (five) steps:\n\n1. Performing the initial risk assessment and determining the impact of the system;\n2. Identification of functions that have an impact on patient safety, product quality and data integrity;\n3. Performing functional risk assessments and identifying the necessary controls;\n4. Implementation and verification of appropriate controls;\n5. Review of risks and monitoring of implemented controls.\n\nThese steps are detailed below.\n\n## 6.3.1 Step 1 - Initial Risk Assessment\n\nAn initial risk analysis should be carried out based on an understanding of the processes and risk assessments business requirements, user requirements, regulatory requirements and known functional areas.\n\nThe results of this initial risk assessment should include the decision on whether the system is regulated by BPx (BPx evaluation). A general assessment of the system's impact should also be included.\n\nBased on this initial risk assessment and system impact it may not be necessary to perform the steps subsequent risks if the risk is already at an acceptable level.\n\nThe necessary effort, formalization and documentation of the subsequent steps must be determined with based on the level of risk and the impact of the system on BPx.\n\n## 6.3.2 Step 2 - Identification of Functions\n\nFunctions that impact patient safety, product quality and data integrity should be identified by the construction of the information gathered in step 1, referring to the specifications relevant and taking into account the project approach, the system architecture and the categorization of system components.", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 2284, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "1cef5e62-ef32-44a4-8cc0-fdf95becdca7": {"__data__": {"id_": "1cef5e62-ef32-44a4-8cc0-fdf95becdca7", "embedding": null, "metadata": {"page_label": "17", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 6.3.3 Step 3 - Functional Risk Assessment\n\nThe functions identified in step 2 must be evaluated considering the possible dangers and how the potential damage from these hazards can be controlled.\n\nIt may be necessary to perform a more detailed assessment that subsequently analyzes the severity of the damage, the probability of occurrence and the probability of detection.\n\n*Guide for Computer Systems Validation*\n*Guide n\u00b0 33/2020 - version 1, of 03/26/2020*\n\n----\n\n## Page 16\n\nThe judgment, on whether or not to carry out a detailed assessment of specific functions, must be carried out case by case and the criteria may vary. The criteria to be taken into account are:\n\n- The criticality of the supported processes;\n- The specific impact of functions within the process;\n- The nature of the system (complexity and innovation).\n\nAppropriate controls should be identified based on the assessment carried out. There are a range of options available to carry out the required control depending on the identified risk. Controls include, among others:\n\n- Modification of the process design;\n- Modification of the system design;\n- Application of external procedures;\n- Increased details or formality of specifications;\n- Increasing the number and level of details of design reviews;\n- Increasing the extent or rigor of verification activities.\n\nWhere possible, it is preferable that risk elimination is carried out at the project level.\n\n# 6.3.4 Implementation and Verification of Controls\n\nThe control measures identified in step 3 should be implemented and verified to ensure that they have been successfully deployed. Controls must be traceable to the relevant risks identified.\n\nThe verification activity must demonstrate that the controls are effective in implementing the risk reduction required.\n\n# 6.3.5 Risk Review and Monitoring of Controls\n\nDuring the periodic system review, or at other defined opportunities, the company must review the risks. The check must show whether the controls are still effective and corrective actions must be taken, carried out if deficiencies are found.\n\nThe company should also consider the following points:", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior del contenido:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos establece un proceso estructurado para la evaluaci\u00f3n de riesgos funcionales en sistemas. En la secci\u00f3n 6.3.3, se enfatiza la importancia de evaluar las funciones identificadas en funci\u00f3n de los peligros potenciales y el da\u00f1o que pueden causar. Se sugiere que la evaluaci\u00f3n de riesgos debe ser detallada y considerar la gravedad del da\u00f1o, la probabilidad de ocurrencia y la probabilidad de detecci\u00f3n. Adem\u00e1s, se deben identificar controles apropiados basados en la evaluaci\u00f3n de riesgos, y estos controles deben ser implementados y verificados para asegurar su efectividad. Finalmente, se menciona la necesidad de revisar peri\u00f3dicamente los riesgos y la efectividad de los controles.\n\n### Preguntas Espec\u00edficas\n1. **\u00bfCu\u00e1les son los criterios que se deben considerar al decidir si realizar una evaluaci\u00f3n detallada de funciones espec\u00edficas en un sistema?**\n   - La decisi\u00f3n debe basarse en la criticalidad de los procesos soportados, el impacto espec\u00edfico de las funciones dentro del proceso y la naturaleza del sistema, que incluye su complejidad e innovaci\u00f3n.\n\n2. **\u00bfQu\u00e9 tipos de controles se pueden implementar para mitigar los riesgos identificados en la evaluaci\u00f3n funcional?**\n   - Los controles pueden incluir la modificaci\u00f3n del dise\u00f1o del proceso o del sistema, la aplicaci\u00f3n de procedimientos externos, el aumento de detalles o formalidad en las especificaciones, y el incremento en el n\u00famero y rigor de las revisiones de dise\u00f1o y actividades de verificaci\u00f3n.\n\n3. **\u00bfQu\u00e9 pasos deben seguirse para asegurar que los controles implementados son efectivos en la reducci\u00f3n de riesgos?**\n   - Los controles deben ser implementados y verificados para asegurar que han sido desplegados con \u00e9xito. La actividad de verificaci\u00f3n debe demostrar que los controles son efectivos en la reducci\u00f3n del riesgo requerido, y se deben realizar revisiones peri\u00f3dicas para evaluar la efectividad continua de los controles y tomar acciones correctivas si se encuentran deficiencias.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n**Temas Clave:**\n\n1. **Gesti\u00f3n de Riesgos de Calidad:** Se basa en el ICH Q9 y establece principios fundamentales para la evaluaci\u00f3n de riesgos en la industria farmac\u00e9utica.\n2. **Principios Fundamentales:**\n   - La evaluaci\u00f3n de riesgos debe fundamentarse en el conocimiento cient\u00edfico y estar vinculada a la protecci\u00f3n del paciente.\n   - El esfuerzo y la documentaci\u00f3n del proceso deben ser proporcionales al nivel de riesgo.\n3. **Proceso de Gesti\u00f3n de Riesgos:** Comprende cinco pasos:\n   - Evaluaci\u00f3n inicial de riesgos.\n   - Identificaci\u00f3n de funciones cr\u00edticas.\n   - Evaluaciones de riesgos funcionales.\n   - Implementaci\u00f3n y verificaci\u00f3n de controles.\n   - Revisi\u00f3n y monitoreo de riesgos y controles.\n4. **Evaluaci\u00f3n Inicial de Riesgos:** Implica entender procesos, requisitos de negocio, de usuario y regulatorios, as\u00ed como determinar el impacto del sistema.\n5. **Identificaci\u00f3n de Funciones:** Se centra en identificar funciones que afectan la seguridad del paciente, la calidad del producto y la integridad de los datos, bas\u00e1ndose en la informaci\u00f3n recopilada en la evaluaci\u00f3n inicial.\n\n**Entidades:**\n\n- **ICH Q9:** Gu\u00eda internacional sobre gesti\u00f3n de riesgos de calidad.\n- **BPx:** Referencia a la regulaci\u00f3n que puede aplicar al sistema evaluado.\n- **Sistemas Inform\u00e1ticos:** Contexto en el que se aplica la gesti\u00f3n de riesgos de calidad.\n\nEste resumen destaca la importancia de un enfoque sistem\u00e1tico y basado en el riesgo para la validaci\u00f3n de sistemas inform\u00e1ticos en la industria farmac\u00e9utica, asegurando la protecci\u00f3n del paciente y la calidad del producto.", "excerpt_keywords": "Keywords: risk assessment, controls implementation, system validation, functional evaluation, regulatory compliance"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "b647fc95-5d2f-4a34-bbbd-cc7bb64d1536", "node_type": "4", "metadata": {"page_label": "17", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 6.3.3 Step 3 - Functional Risk Assessment\n\nThe functions identified in step 2 must be evaluated considering the possible dangers and how the potential damage from these hazards can be controlled.\n\nIt may be necessary to perform a more detailed assessment that subsequently analyzes the severity of the damage, the probability of occurrence and the probability of detection.\n\n*Guide for Computer Systems Validation*\n*Guide n\u00b0 33/2020 - version 1, of 03/26/2020*\n\n----\n\n## Page 16\n\nThe judgment, on whether or not to carry out a detailed assessment of specific functions, must be carried out case by case and the criteria may vary. The criteria to be taken into account are:\n\n- The criticality of the supported processes;\n- The specific impact of functions within the process;\n- The nature of the system (complexity and innovation).\n\nAppropriate controls should be identified based on the assessment carried out. There are a range of options available to carry out the required control depending on the identified risk. Controls include, among others:\n\n- Modification of the process design;\n- Modification of the system design;\n- Application of external procedures;\n- Increased details or formality of specifications;\n- Increasing the number and level of details of design reviews;\n- Increasing the extent or rigor of verification activities.\n\nWhere possible, it is preferable that risk elimination is carried out at the project level.\n\n# 6.3.4 Implementation and Verification of Controls\n\nThe control measures identified in step 3 should be implemented and verified to ensure that they have been successfully deployed. Controls must be traceable to the relevant risks identified.\n\nThe verification activity must demonstrate that the controls are effective in implementing the risk reduction required.\n\n# 6.3.5 Risk Review and Monitoring of Controls\n\nDuring the periodic system review, or at other defined opportunities, the company must review the risks. The check must show whether the controls are still effective and corrective actions must be taken, carried out if deficiencies are found.\n\nThe company should also consider the following points:", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "cd6eefda3ff1325bbd36745874824c072629c6879329297115ff178028b15dd9", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "# 6.3.3 Step 3 - Functional Risk Assessment\n\nThe functions identified in step 2 must be evaluated considering the possible dangers and how the potential damage from these hazards can be controlled.\n\nIt may be necessary to perform a more detailed assessment that subsequently analyzes the severity of the damage, the probability of occurrence and the probability of detection.\n\n*Guide for Computer Systems Validation*\n*Guide n\u00b0 33/2020 - version 1, of 03/26/2020*\n\n----\n\n## Page 16\n\nThe judgment, on whether or not to carry out a detailed assessment of specific functions, must be carried out case by case and the criteria may vary. The criteria to be taken into account are:\n\n- The criticality of the supported processes;\n- The specific impact of functions within the process;\n- The nature of the system (complexity and innovation).\n\nAppropriate controls should be identified based on the assessment carried out. There are a range of options available to carry out the required control depending on the identified risk. Controls include, among others:\n\n- Modification of the process design;\n- Modification of the system design;\n- Application of external procedures;\n- Increased details or formality of specifications;\n- Increasing the number and level of details of design reviews;\n- Increasing the extent or rigor of verification activities.\n\nWhere possible, it is preferable that risk elimination is carried out at the project level.\n\n# 6.3.4 Implementation and Verification of Controls\n\nThe control measures identified in step 3 should be implemented and verified to ensure that they have been successfully deployed. Controls must be traceable to the relevant risks identified.\n\nThe verification activity must demonstrate that the controls are effective in implementing the risk reduction required.\n\n# 6.3.5 Risk Review and Monitoring of Controls\n\nDuring the periodic system review, or at other defined opportunities, the company must review the risks. The check must show whether the controls are still effective and corrective actions must be taken, carried out if deficiencies are found.\n\nThe company should also consider the following points:", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 2149, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "00e0e258-c7b5-4d48-af42-0241fff302c4": {"__data__": {"id_": "00e0e258-c7b5-4d48-af42-0241fff302c4", "embedding": null, "metadata": {"page_label": "18", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 7. SOFTWARE AND HARDWARE CATEGORIZATION\n\n## 7.1 INTRODUCTION\n\nThis section describes how the **software** and **hardware** components can be analyzed and categorized. These **software** and **hardware** categories can then be used in conjunction with the Risk Assessment and Assessment Supplier to establish an appropriate life cycle strategy.\n\nCategories 3 to 5 have no absolute boundaries and that the activities recommended for a given category may be suitable for a system or component that belongs to the other category.\n\n## 7.2 USE OF GAMP CATEGORIES\n\nThere is usually an increased risk of failure and defects when progressing a set **software-hardware** standard for a set **software - hardware** customized. The increased risk comes from combination of greater complexity and less user experience. Categorization can be part of an effective approach to quality risk management when coupled with risk assessment and supplier evaluation.\n\nMost systems have components of varying complexity, such as an operating system, non-configured components, and configured or customized components. The effort must be concentrated in the following proportion: Customized > Configured > Not Configured > Infrastructure. Categorization can help focus the effort where the risk is greatest.\n\nThere are two main ways of using categories:\n\n- Evaluation of the system in a holistic way;\n- Detailed evaluation by component.\n\nIn the holistic assessment, the main component category can be used to help define the approach for supplier evaluation or selection of results to be delivered in the life cycle. The combination of categorization with the impact assessment of the system can help you decide whether a supplier audit is necessary.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "### Resumen del contexto\n\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos aborda la categorizaci\u00f3n de software y hardware como parte de un enfoque de gesti\u00f3n de riesgos de calidad. Se enfatiza la importancia de clasificar los componentes de software y hardware para identificar y mitigar riesgos, especialmente en sistemas personalizados que presentan mayor complejidad. Se mencionan dos enfoques para la categorizaci\u00f3n: una evaluaci\u00f3n hol\u00edstica del sistema y una evaluaci\u00f3n detallada por componente. La categorizaci\u00f3n ayuda a enfocar los esfuerzos de validaci\u00f3n donde el riesgo es mayor y puede influir en la necesidad de auditor\u00edas de proveedores.\n\n### Preguntas espec\u00edficas\n\n1. **\u00bfCu\u00e1les son las proporciones recomendadas para concentrar los esfuerzos de validaci\u00f3n en funci\u00f3n de la complejidad de los componentes de software y hardware?**\n   - La proporci\u00f3n recomendada es: Personalizado > Configurado > No Configurado > Infraestructura.\n\n2. **\u00bfQu\u00e9 dos enfoques se sugieren para utilizar las categor\u00edas en la evaluaci\u00f3n de sistemas?**\n   - Los dos enfoques son: la evaluaci\u00f3n del sistema de manera hol\u00edstica y la evaluaci\u00f3n detallada por componente.\n\n3. **\u00bfC\u00f3mo puede la categorizaci\u00f3n ayudar en la decisi\u00f3n de realizar una auditor\u00eda de proveedores?**\n   - La combinaci\u00f3n de la categorizaci\u00f3n con la evaluaci\u00f3n de impacto del sistema puede ayudar a determinar si es necesaria una auditor\u00eda de proveedores, bas\u00e1ndose en el riesgo asociado a los componentes del sistema.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Evaluaci\u00f3n de Riesgos Funcionales**:\n   - La secci\u00f3n 6.3.3 se centra en la evaluaci\u00f3n de las funciones identificadas en un sistema, considerando los peligros potenciales y el da\u00f1o que pueden causar.\n   - Se sugiere realizar una evaluaci\u00f3n detallada que analice la gravedad del da\u00f1o, la probabilidad de ocurrencia y la probabilidad de detecci\u00f3n.\n\n2. **Criterios para Evaluaci\u00f3n Detallada**:\n   - La decisi\u00f3n de llevar a cabo una evaluaci\u00f3n detallada debe basarse en:\n     - La criticalidad de los procesos soportados.\n     - El impacto espec\u00edfico de las funciones dentro del proceso.\n     - La naturaleza del sistema, incluyendo su complejidad e innovaci\u00f3n.\n\n3. **Controles Apropiados**:\n   - Se deben identificar controles basados en la evaluaci\u00f3n de riesgos. Las opciones de control incluyen:\n     - Modificaci\u00f3n del dise\u00f1o del proceso o del sistema.\n     - Aplicaci\u00f3n de procedimientos externos.\n     - Aumento de detalles o formalidad en las especificaciones.\n     - Incremento en el n\u00famero y rigor de las revisiones de dise\u00f1o y actividades de verificaci\u00f3n.\n\n4. **Implementaci\u00f3n y Verificaci\u00f3n de Controles**:\n   - Los controles deben ser implementados y verificados para asegurar su efectividad en la reducci\u00f3n de riesgos.\n   - La verificaci\u00f3n debe demostrar que los controles son efectivos y est\u00e1n relacionados con los riesgos identificados.\n\n5. **Revisi\u00f3n y Monitoreo de Riesgos**:\n   - Se debe realizar una revisi\u00f3n peri\u00f3dica de los riesgos y de la efectividad de los controles.\n   - Si se encuentran deficiencias, se deben tomar acciones correctivas.\n\n### Entidades Clave\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil.\n- **Gu\u00eda n\u00b0 33/2020**: Documento que establece directrices para la validaci\u00f3n de sistemas inform\u00e1ticos.\n- **Controles**: Medidas implementadas para mitigar riesgos.\n- **Riesgos**: Peligros potenciales asociados a las funciones del sistema.\n\nEste resumen destaca la importancia de un enfoque estructurado para la evaluaci\u00f3n y gesti\u00f3n de riesgos en sistemas inform\u00e1ticos, enfatizando la necesidad de controles efectivos y revisiones peri\u00f3dicas.", "excerpt_keywords": "Keywords: software categorization, hardware categorization, risk assessment, GAMP categories, supplier evaluation"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "0f629c74-6df3-43ab-9eb1-75dc782d9d21", "node_type": "4", "metadata": {"page_label": "18", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 7. SOFTWARE AND HARDWARE CATEGORIZATION\n\n## 7.1 INTRODUCTION\n\nThis section describes how the **software** and **hardware** components can be analyzed and categorized. These **software** and **hardware** categories can then be used in conjunction with the Risk Assessment and Assessment Supplier to establish an appropriate life cycle strategy.\n\nCategories 3 to 5 have no absolute boundaries and that the activities recommended for a given category may be suitable for a system or component that belongs to the other category.\n\n## 7.2 USE OF GAMP CATEGORIES\n\nThere is usually an increased risk of failure and defects when progressing a set **software-hardware** standard for a set **software - hardware** customized. The increased risk comes from combination of greater complexity and less user experience. Categorization can be part of an effective approach to quality risk management when coupled with risk assessment and supplier evaluation.\n\nMost systems have components of varying complexity, such as an operating system, non-configured components, and configured or customized components. The effort must be concentrated in the following proportion: Customized > Configured > Not Configured > Infrastructure. Categorization can help focus the effort where the risk is greatest.\n\nThere are two main ways of using categories:\n\n- Evaluation of the system in a holistic way;\n- Detailed evaluation by component.\n\nIn the holistic assessment, the main component category can be used to help define the approach for supplier evaluation or selection of results to be delivered in the life cycle. The combination of categorization with the impact assessment of the system can help you decide whether a supplier audit is necessary.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "edfdeaa647b97921eea864d977282358126bc66730cf3d624e844b79a277cad9", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "# 7. SOFTWARE AND HARDWARE CATEGORIZATION\n\n## 7.1 INTRODUCTION\n\nThis section describes how the **software** and **hardware** components can be analyzed and categorized. These **software** and **hardware** categories can then be used in conjunction with the Risk Assessment and Assessment Supplier to establish an appropriate life cycle strategy.\n\nCategories 3 to 5 have no absolute boundaries and that the activities recommended for a given category may be suitable for a system or component that belongs to the other category.\n\n## 7.2 USE OF GAMP CATEGORIES\n\nThere is usually an increased risk of failure and defects when progressing a set **software-hardware** standard for a set **software - hardware** customized. The increased risk comes from combination of greater complexity and less user experience. Categorization can be part of an effective approach to quality risk management when coupled with risk assessment and supplier evaluation.\n\nMost systems have components of varying complexity, such as an operating system, non-configured components, and configured or customized components. The effort must be concentrated in the following proportion: Customized > Configured > Not Configured > Infrastructure. Categorization can help focus the effort where the risk is greatest.\n\nThere are two main ways of using categories:\n\n- Evaluation of the system in a holistic way;\n- Detailed evaluation by component.\n\nIn the holistic assessment, the main component category can be used to help define the approach for supplier evaluation or selection of results to be delivered in the life cycle. The combination of categorization with the impact assessment of the system can help you decide whether a supplier audit is necessary.", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 1727, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "cc109235-45cb-4ae1-9679-0e8c67978f37": {"__data__": {"id_": "cc109235-45cb-4ae1-9679-0e8c67978f37", "embedding": null, "metadata": {"page_label": "19", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 7.3 SOFTWARE CATEGORIES\n\n## 7.3.1 Category 1 - Infrastructure Software\n\nInfrastructure elements interconnect to form an integrated environment to run and support applications and services.\n\nThere are two types of software in this category:\n\n1. **Software Layer (Layered Software) Commercially Available or Settled** - Applications are developed to run under the control of this type of software. This type of software includes: operating systems, database managers, statistical programming tools, and spreadsheet packages (but not applications developed using these packages).\n\n2. **Tools Software Infrastructure** - This type includes tools such as software to network monitoring; batch job scheduling tools; security software; antivirus and configuration management tools. Risk assessment must be carried out, however, in the tools with high potential impact, such as password or security management to determine if additional controls are appropriate.\n\nThe software layer are not subject to specific functional verification, although their characteristics are functionally tested and challenged indirectly during testing in the application. The identities and the version numbers of the software of layer and operating system should be documented and verified during installation.\n\nInfrastructure tools and software are generally highly reliable and significantly removed from any aspect of risk to the patient. All software infrastructure should be controlled and managed.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas basadas en el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos clasifica el software en diferentes categor\u00edas, enfoc\u00e1ndose en la **Categor\u00eda 1 - Software de Infraestructura**. Esta categor\u00eda incluye dos tipos de software: el **Software Layer**, que abarca sistemas operativos y herramientas de gesti\u00f3n de bases de datos, y el **Tools Software Infrastructure**, que incluye herramientas de monitoreo de red y gesti\u00f3n de seguridad. Se enfatiza la importancia de realizar evaluaciones de riesgo, especialmente en herramientas con un alto potencial de impacto, y se menciona que el software de infraestructura generalmente es confiable y debe ser controlado y gestionado adecuadamente.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfQu\u00e9 tipo de software se considera parte del \"Software Layer\" y cu\u00e1les son sus caracter\u00edsticas clave seg\u00fan la gu\u00eda de ANVISA?**\n   - Respuesta: El \"Software Layer\" incluye sistemas operativos, gestores de bases de datos, herramientas de programaci\u00f3n estad\u00edstica y paquetes de hojas de c\u00e1lculo. Este tipo de software es utilizado para desarrollar aplicaciones y no est\u00e1 sujeto a verificaciones funcionales espec\u00edficas, aunque sus caracter\u00edsticas son probadas indirectamente durante las pruebas de las aplicaciones.\n\n2. **\u00bfQu\u00e9 medidas se deben tomar en cuenta al evaluar el riesgo de las herramientas de infraestructura de software con alto potencial de impacto?**\n   - Respuesta: Se debe realizar una evaluaci\u00f3n de riesgo en herramientas como la gesti\u00f3n de contrase\u00f1as o la gesti\u00f3n de seguridad para determinar si son necesarios controles adicionales, dado su alto potencial de impacto en la seguridad y la integridad del sistema.\n\n3. **\u00bfCu\u00e1l es la importancia de documentar las identidades y n\u00fameros de versi\u00f3n del software de capa y del sistema operativo durante la instalaci\u00f3n?**\n   - Respuesta: La documentaci\u00f3n y verificaci\u00f3n de las identidades y n\u00fameros de versi\u00f3n del software de capa y del sistema operativo son cruciales para asegurar que se est\u00e1 utilizando la versi\u00f3n correcta y para mantener un registro que facilite la gesti\u00f3n y el control del software, contribuyendo as\u00ed a la integridad del sistema y a la mitigaci\u00f3n de riesgos.", "prev_section_summary": "### Resumen de la Secci\u00f3n 7: Categorizaci\u00f3n de Software y Hardware\n\n#### Temas Clave:\n1. **Categorizaci\u00f3n de Componentes**: Se describe c\u00f3mo analizar y clasificar los componentes de software y hardware para establecer estrategias adecuadas de ciclo de vida en conjunto con la evaluaci\u00f3n de riesgos y proveedores.\n  \n2. **Riesgo Asociado**: Se menciona que los sistemas personalizados presentan un mayor riesgo de fallos y defectos debido a su complejidad y menor experiencia del usuario. La categorizaci\u00f3n es una herramienta \u00fatil para la gesti\u00f3n de riesgos de calidad.\n\n3. **Proporciones de Esfuerzo**: Se recomienda concentrar los esfuerzos de validaci\u00f3n en el siguiente orden de complejidad: \n   - Personalizado > Configurado > No Configurado > Infraestructura.\n\n4. **Enfoques de Evaluaci\u00f3n**: Se sugieren dos enfoques para utilizar las categor\u00edas:\n   - Evaluaci\u00f3n hol\u00edstica del sistema.\n   - Evaluaci\u00f3n detallada por componente.\n\n5. **Auditor\u00eda de Proveedores**: La categorizaci\u00f3n, combinada con la evaluaci\u00f3n de impacto del sistema, puede ayudar a determinar la necesidad de realizar auditor\u00edas a proveedores.\n\n#### Entidades:\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil.\n- **GAMP**: Buenas Pr\u00e1cticas de Automatizaci\u00f3n de Sistemas.\n- **Componentes de Software y Hardware**: Incluyen sistemas operativos, componentes no configurados, y componentes configurados o personalizados.\n- **Riesgo**: Relacionado con la complejidad y la experiencia del usuario en sistemas personalizados.\n\nEste resumen destaca la importancia de la categorizaci\u00f3n en la validaci\u00f3n de sistemas inform\u00e1ticos y su papel en la gesti\u00f3n de riesgos y la evaluaci\u00f3n de proveedores.", "excerpt_keywords": "Keywords: software categories, infrastructure software, risk assessment, validation, ANVISA"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "877a7c4c-cb00-4bf3-892c-bdd6e1392f0c", "node_type": "4", "metadata": {"page_label": "19", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 7.3 SOFTWARE CATEGORIES\n\n## 7.3.1 Category 1 - Infrastructure Software\n\nInfrastructure elements interconnect to form an integrated environment to run and support applications and services.\n\nThere are two types of software in this category:\n\n1. **Software Layer (Layered Software) Commercially Available or Settled** - Applications are developed to run under the control of this type of software. This type of software includes: operating systems, database managers, statistical programming tools, and spreadsheet packages (but not applications developed using these packages).\n\n2. **Tools Software Infrastructure** - This type includes tools such as software to network monitoring; batch job scheduling tools; security software; antivirus and configuration management tools. Risk assessment must be carried out, however, in the tools with high potential impact, such as password or security management to determine if additional controls are appropriate.\n\nThe software layer are not subject to specific functional verification, although their characteristics are functionally tested and challenged indirectly during testing in the application. The identities and the version numbers of the software of layer and operating system should be documented and verified during installation.\n\nInfrastructure tools and software are generally highly reliable and significantly removed from any aspect of risk to the patient. All software infrastructure should be controlled and managed.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "62f891e83dd11547a5943339b2d4bd637eb8ee310832f7e97292e64cce6c2bc5", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "# 7.3 SOFTWARE CATEGORIES\n\n## 7.3.1 Category 1 - Infrastructure Software\n\nInfrastructure elements interconnect to form an integrated environment to run and support applications and services.\n\nThere are two types of software in this category:\n\n1. **Software Layer (Layered Software) Commercially Available or Settled** - Applications are developed to run under the control of this type of software. This type of software includes: operating systems, database managers, statistical programming tools, and spreadsheet packages (but not applications developed using these packages).\n\n2. **Tools Software Infrastructure** - This type includes tools such as software to network monitoring; batch job scheduling tools; security software; antivirus and configuration management tools. Risk assessment must be carried out, however, in the tools with high potential impact, such as password or security management to determine if additional controls are appropriate.\n\nThe software layer are not subject to specific functional verification, although their characteristics are functionally tested and challenged indirectly during testing in the application. The identities and the version numbers of the software of layer and operating system should be documented and verified during installation.\n\nInfrastructure tools and software are generally highly reliable and significantly removed from any aspect of risk to the patient. All software infrastructure should be controlled and managed.", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 1478, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "fcdc40a9-53f9-4e24-a5a0-d9d9eb5c8ea2": {"__data__": {"id_": "fcdc40a9-53f9-4e24-a5a0-d9d9eb5c8ea2", "embedding": null, "metadata": {"page_label": "20", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "## 7.3.2 Category 3 - Non-Configured Products\n\nThis category includes off-the-shelf products used for the business process. It covers both systems that cannot be configured to suit business processes as well as the systems that are configurable, but that only the *default* configuration is used. In both cases, the setting for run in the likely user environment (eg, printer setting). Risk-based judgment and complexity should determine whether systems used with the *default* configuration can be considered Category 3 or 4.\n\nA simplified approach to the life cycle can be applied to this category. Supplier evaluation may not be necessary. The need and extent of the supplier's assessment should be based on risk. User requirements are necessary and should focus on the key aspects of use. The specifications functional and design are not necessary, although there is a need for sufficient specification (usually in the ERU / URS) to allow testing. The verification basically consists of a single testing phase.\n\nAll changes must be controlled, including the *patch* packages provided by the supplier. Standard Operating Procedures must be established for the use and management of the system and training should be implemented.\n\nConfiguration management must be applied. For systems where the *default* configuration is used, the Configuration management demonstrates that the \u201c*default*\u201d option is selected correctly.\n\n----\n\n## 7.3.3 Category 4 - Configured Products\n\nConfigurable *software* provides standard *interfaces* and functions that allow the configuration of specific business for the user. This usually involves configuring *software* modules predefined.\n\nMuch of the risk associated with the *software* depends on how well the system is configured to meet user needs. There may be an increased risk associated with new *software* and major updates.\n\nDetailed user requirements document (ERU / URS) is required for this *software* category. THE The approach for evaluating the supplier and the configurable product must be risk-based and must be documented.\n\nThe Functional Specification document may not be owned by the regulated user / company, but must sufficient documentation to ensure traceability of functional specifications and their respective tests.\n\nThe approach used by the regulated company must cover the layers of *software* involved and their respective categories. The approach should reflect the result of the supplier's assessment, the risk to GMP, system size and complexity. It should define strategies to mitigate any weaknesses identified during the supplier assessment process.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos clasifica los productos en diferentes categor\u00edas seg\u00fan su configuraci\u00f3n y uso. La **Categor\u00eda 3** incluye productos no configurados que utilizan configuraciones predeterminadas, mientras que la **Categor\u00eda 4** abarca productos configurables que requieren una documentaci\u00f3n m\u00e1s detallada y un enfoque basado en riesgos para su evaluaci\u00f3n. Ambos tipos de productos requieren un control de cambios y gesti\u00f3n de configuraciones, pero la complejidad y el riesgo asociado var\u00edan seg\u00fan la categor\u00eda.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfQu\u00e9 tipo de documentaci\u00f3n se requiere para los productos de la Categor\u00eda 4 y por qu\u00e9 es importante?**\n   - La Categor\u00eda 4 requiere un documento detallado de requisitos del usuario (ERU / URS) para garantizar que el software est\u00e9 configurado adecuadamente para satisfacer las necesidades del usuario. Esta documentaci\u00f3n es crucial para asegurar la trazabilidad de las especificaciones funcionales y sus respectivas pruebas, lo que ayuda a mitigar riesgos asociados con la configuraci\u00f3n del software.\n\n2. **\u00bfC\u00f3mo se determina si un sistema con configuraci\u00f3n predeterminada debe clasificarse como Categor\u00eda 3 o 4?**\n   - La clasificaci\u00f3n de un sistema con configuraci\u00f3n predeterminada como Categor\u00eda 3 o 4 se basa en un juicio de riesgo y complejidad. Si el sistema se utiliza con la configuraci\u00f3n predeterminada y no se adapta a los procesos comerciales, puede considerarse Categor\u00eda 3. Sin embargo, si hay un riesgo significativo asociado con su uso o si se requiere una configuraci\u00f3n m\u00e1s espec\u00edfica, podr\u00eda clasificarse como Categor\u00eda 4.\n\n3. **\u00bfQu\u00e9 procedimientos deben establecerse para la gesti\u00f3n de cambios en productos de la Categor\u00eda 3?**\n   - Para los productos de la Categor\u00eda 3, todos los cambios deben ser controlados, incluyendo los paquetes de parches proporcionados por el proveedor. Adem\u00e1s, se deben establecer Procedimientos Operativos Est\u00e1ndar (SOP) para el uso y gesti\u00f3n del sistema, y se debe implementar capacitaci\u00f3n para los usuarios, asegurando as\u00ed que se mantenga la integridad del sistema a lo largo de su ciclo de vida.", "prev_section_summary": "### Resumen de Temas Clave y Entidades de la Secci\u00f3n\n\n**Categor\u00eda 1 - Software de Infraestructura**: Esta categor\u00eda se centra en los elementos de infraestructura que interconectan para formar un entorno integrado que soporta aplicaciones y servicios. Se divide en dos tipos principales de software:\n\n1. **Software Layer (Software de Capa)**:\n   - **Definici\u00f3n**: Software comercialmente disponible o asentado bajo el cual se desarrollan aplicaciones.\n   - **Ejemplos**: Sistemas operativos, gestores de bases de datos, herramientas de programaci\u00f3n estad\u00edstica y paquetes de hojas de c\u00e1lculo.\n   - **Caracter\u00edsticas**: No est\u00e1 sujeto a verificaciones funcionales espec\u00edficas, pero sus caracter\u00edsticas son probadas indirectamente durante las pruebas de las aplicaciones.\n\n2. **Tools Software Infrastructure (Herramientas de Infraestructura de Software)**:\n   - **Definici\u00f3n**: Herramientas que ayudan en la gesti\u00f3n y monitoreo de la infraestructura de software.\n   - **Ejemplos**: Software de monitoreo de red, herramientas de programaci\u00f3n de trabajos por lotes, software de seguridad, antivirus y herramientas de gesti\u00f3n de configuraci\u00f3n.\n   - **Evaluaci\u00f3n de Riesgo**: Se requiere una evaluaci\u00f3n de riesgo para herramientas con alto potencial de impacto, como la gesti\u00f3n de contrase\u00f1as y la gesti\u00f3n de seguridad, para determinar la necesidad de controles adicionales.\n\n**Importancia de la Documentaci\u00f3n**:\n- Se enfatiza la necesidad de documentar y verificar las identidades y n\u00fameros de versi\u00f3n del software de capa y del sistema operativo durante la instalaci\u00f3n para asegurar la correcta gesti\u00f3n y control del software.\n\n**Fiabilidad**:\n- Se menciona que las herramientas y software de infraestructura son generalmente altamente confiables y est\u00e1n significativamente alejados de cualquier riesgo para el paciente, lo que subraya la importancia de su control y gesti\u00f3n adecuada. \n\n### Entidades Clave\n- **Software Layer**: Sistemas operativos, gestores de bases de datos, herramientas de programaci\u00f3n estad\u00edstica, paquetes de hojas de c\u00e1lculo.\n- **Tools Software Infrastructure**: Herramientas de monitoreo de red, programaci\u00f3n de trabajos, software de seguridad, antivirus, gesti\u00f3n de configuraci\u00f3n.\n- **Riesgo**: Evaluaci\u00f3n de riesgo en herramientas cr\u00edticas como gesti\u00f3n de contrase\u00f1as y seguridad.\n- **Documentaci\u00f3n**: Identidades y n\u00fameros de versi\u00f3n del software.", "excerpt_keywords": "Keywords: validation, computer systems, risk-based approach, configurable products, user requirements"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "6f2de107-1150-4718-92c1-9375d716b98c", "node_type": "4", "metadata": {"page_label": "20", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "## 7.3.2 Category 3 - Non-Configured Products\n\nThis category includes off-the-shelf products used for the business process. It covers both systems that cannot be configured to suit business processes as well as the systems that are configurable, but that only the *default* configuration is used. In both cases, the setting for run in the likely user environment (eg, printer setting). Risk-based judgment and complexity should determine whether systems used with the *default* configuration can be considered Category 3 or 4.\n\nA simplified approach to the life cycle can be applied to this category. Supplier evaluation may not be necessary. The need and extent of the supplier's assessment should be based on risk. User requirements are necessary and should focus on the key aspects of use. The specifications functional and design are not necessary, although there is a need for sufficient specification (usually in the ERU / URS) to allow testing. The verification basically consists of a single testing phase.\n\nAll changes must be controlled, including the *patch* packages provided by the supplier. Standard Operating Procedures must be established for the use and management of the system and training should be implemented.\n\nConfiguration management must be applied. For systems where the *default* configuration is used, the Configuration management demonstrates that the \u201c*default*\u201d option is selected correctly.\n\n----\n\n## 7.3.3 Category 4 - Configured Products\n\nConfigurable *software* provides standard *interfaces* and functions that allow the configuration of specific business for the user. This usually involves configuring *software* modules predefined.\n\nMuch of the risk associated with the *software* depends on how well the system is configured to meet user needs. There may be an increased risk associated with new *software* and major updates.\n\nDetailed user requirements document (ERU / URS) is required for this *software* category. THE The approach for evaluating the supplier and the configurable product must be risk-based and must be documented.\n\nThe Functional Specification document may not be owned by the regulated user / company, but must sufficient documentation to ensure traceability of functional specifications and their respective tests.\n\nThe approach used by the regulated company must cover the layers of *software* involved and their respective categories. The approach should reflect the result of the supplier's assessment, the risk to GMP, system size and complexity. It should define strategies to mitigate any weaknesses identified during the supplier assessment process.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "15d989cf9ae1e846f324c61c175a5a8cd4dc0e4879319f4bd25819b6041bd968", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "## 7.3.2 Category 3 - Non-Configured Products\n\nThis category includes off-the-shelf products used for the business process. It covers both systems that cannot be configured to suit business processes as well as the systems that are configurable, but that only the *default* configuration is used. In both cases, the setting for run in the likely user environment (eg, printer setting). Risk-based judgment and complexity should determine whether systems used with the *default* configuration can be considered Category 3 or 4.\n\nA simplified approach to the life cycle can be applied to this category. Supplier evaluation may not be necessary. The need and extent of the supplier's assessment should be based on risk. User requirements are necessary and should focus on the key aspects of use. The specifications functional and design are not necessary, although there is a need for sufficient specification (usually in the ERU / URS) to allow testing. The verification basically consists of a single testing phase.\n\nAll changes must be controlled, including the *patch* packages provided by the supplier. Standard Operating Procedures must be established for the use and management of the system and training should be implemented.\n\nConfiguration management must be applied. For systems where the *default* configuration is used, the Configuration management demonstrates that the \u201c*default*\u201d option is selected correctly.\n\n----\n\n## 7.3.3 Category 4 - Configured Products\n\nConfigurable *software* provides standard *interfaces* and functions that allow the configuration of specific business for the user. This usually involves configuring *software* modules predefined.\n\nMuch of the risk associated with the *software* depends on how well the system is configured to meet user needs. There may be an increased risk associated with new *software* and major updates.\n\nDetailed user requirements document (ERU / URS) is required for this *software* category. THE The approach for evaluating the supplier and the configurable product must be risk-based and must be documented.\n\nThe Functional Specification document may not be owned by the regulated user / company, but must sufficient documentation to ensure traceability of functional specifications and their respective tests.\n\nThe approach used by the regulated company must cover the layers of *software* involved and their respective categories. The approach should reflect the result of the supplier's assessment, the risk to GMP, system size and complexity. It should define strategies to mitigate any weaknesses identified during the supplier assessment process.", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 2618, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "e1fcca3b-7aa9-43b8-9eca-6024c171017c": {"__data__": {"id_": "e1fcca3b-7aa9-43b8-9eca-6024c171017c", "embedding": null, "metadata": {"page_label": "21", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "## 7.3.4 Category 5 - Custom Applications\n\nThese systems and subsystems are developed to meet the specific needs of the regulated company. The risk inherent in customized *software* is high. The life-cycle approach and system decisions should take this high risk into account, because there is no user experience or information about system reliability.\n\nThe approach used to assess the supplier must be risk-based and documented. An audit at the supplier is required to confirm that an adequate Quality Management System exists for control development and ongoing support for the application. In the absence of a Management System Quality Assurance, suppliers must adapt to provide an appropriate basis for managing application development and support.\n\nThe approach used by the regulated company must cover the layers of *software* involved and their respective categories. The approach should reflect the result of the supplier's assessment, the risk to GMP, system size and complexity. It should define strategies to mitigate any weaknesses identified during the supplier evaluation process.\n\n## 7.3.5 Typical Examples and Approaches\n\n**Table 2. Categories of Software, Description and Typical Approach to the Life Cycle.**\n\n| Category                       | description                                                                                                                 | Typical Examples                                                                                                                                                                                                       | Typical Approach                                                                                                                                |\n| ------------------------------ | --------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- |\n| Software of Infrastructure (1) | * *software* of Layer (that is, over which applications are built)\n* *Software* used for manage the environment operational | - Operational systems\n- Mechanisms for databases\n- Middleware\n- Languages programming\n- Statistical packages\n- Spreadsheets\n- Tools network monitoring\n- Tools scheduling\n- Tools version control\n- Based Applications | * Registration of the version and verification of correct installation\n* See GAMP Good Practice Guide: IT Infrastructure Control and Compliance |\n|                                | Non-*Software* Time parameters                                                                                              |                                                                                                                                                                                                                        | Shortened life cycle                                                                                                                            |\n", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos destaca la importancia de evaluar y gestionar los riesgos asociados con el software personalizado en empresas reguladas. Se enfatiza la necesidad de un enfoque basado en riesgos para la evaluaci\u00f3n de proveedores y la implementaci\u00f3n de un sistema de gesti\u00f3n de calidad adecuado. Adem\u00e1s, se presentan categor\u00edas de software y enfoques t\u00edpicos para su ciclo de vida, subrayando la importancia de la documentaci\u00f3n y el control en el desarrollo y soporte de aplicaciones.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfCu\u00e1les son las implicaciones de no contar con un Sistema de Gesti\u00f3n de Calidad en el desarrollo de software personalizado?**\n   - La falta de un Sistema de Gesti\u00f3n de Calidad puede llevar a que los proveedores no tengan una base adecuada para gestionar el desarrollo y soporte de la aplicaci\u00f3n, aumentando as\u00ed el riesgo de fallos en el software y afectando la conformidad con las Buenas Pr\u00e1cticas de Manufactura (GMP).\n\n2. **\u00bfQu\u00e9 estrategias se deben definir para mitigar debilidades identificadas durante la evaluaci\u00f3n del proveedor?**\n   - Las estrategias deben ser espec\u00edficas y basadas en los resultados de la evaluaci\u00f3n del proveedor, el riesgo para GMP, as\u00ed como el tama\u00f1o y la complejidad del sistema. Esto puede incluir la implementaci\u00f3n de controles adicionales, auditor\u00edas m\u00e1s frecuentes o la capacitaci\u00f3n del personal.\n\n3. **\u00bfQu\u00e9 tipo de software se clasifica como \"Software de Infraestructura\" y cu\u00e1l es su enfoque t\u00edpico en el ciclo de vida?**\n   - El \"Software de Infraestructura\" incluye sistemas operativos, mecanismos para bases de datos, middleware, lenguajes de programaci\u00f3n, paquetes estad\u00edsticos, hojas de c\u00e1lculo, herramientas de monitoreo de red, herramientas de programaci\u00f3n y control de versiones. Su enfoque t\u00edpico en el ciclo de vida incluye el registro de versiones y la verificaci\u00f3n de la correcta instalaci\u00f3n, siguiendo las buenas pr\u00e1cticas de GAMP para el control y cumplimiento de la infraestructura de TI.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n#### Temas Clave\n\n1. **Clasificaci\u00f3n de Productos**:\n   - **Categor\u00eda 3 - Productos No Configurados**: Incluye productos de estanter\u00eda que utilizan configuraciones predeterminadas. Se aplica un enfoque simplificado al ciclo de vida, donde la evaluaci\u00f3n del proveedor puede no ser necesaria y se requiere un control de cambios riguroso.\n   - **Categor\u00eda 4 - Productos Configurados**: Comprende software configurable que permite personalizar funciones seg\u00fan las necesidades del usuario. Requiere documentaci\u00f3n detallada de requisitos del usuario (ERU / URS) y un enfoque basado en riesgos para la evaluaci\u00f3n del proveedor.\n\n2. **Gesti\u00f3n de Cambios y Configuraci\u00f3n**:\n   - En ambas categor\u00edas, todos los cambios deben ser controlados, incluyendo parches del proveedor. Se deben establecer Procedimientos Operativos Est\u00e1ndar (SOP) para la gesti\u00f3n del sistema y la capacitaci\u00f3n de usuarios.\n\n3. **Documentaci\u00f3n y Trazabilidad**:\n   - La documentaci\u00f3n es esencial para asegurar la trazabilidad de las especificaciones funcionales y las pruebas realizadas, especialmente en la Categor\u00eda 4, donde se requiere un enfoque m\u00e1s riguroso debido a la complejidad y riesgo asociado.\n\n4. **Evaluaci\u00f3n Basada en Riesgos**:\n   - La evaluaci\u00f3n de proveedores y productos debe basarse en un juicio de riesgo, considerando la complejidad del sistema y su adecuaci\u00f3n a los procesos comerciales.\n\n#### Entidades\n\n- **Categor\u00eda 3**: Productos No Configurados\n- **Categor\u00eda 4**: Productos Configurados\n- **ERU / URS**: Documentos de Requisitos del Usuario\n- **SOP**: Procedimientos Operativos Est\u00e1ndar\n- **Gesti\u00f3n de Configuraci\u00f3n**: Proceso para asegurar que las configuraciones predeterminadas se seleccionen y mantengan correctamente.\n- **Riesgo**: Consideraci\u00f3n clave en la evaluaci\u00f3n de productos y proveedores.\n\nEste resumen destaca la importancia de la clasificaci\u00f3n de productos en la validaci\u00f3n de sistemas inform\u00e1ticos, as\u00ed como la necesidad de una gesti\u00f3n adecuada de cambios y documentaci\u00f3n para garantizar la conformidad y la eficacia en el uso de software en entornos regulados.", "excerpt_keywords": "Keywords: validation, software, risk management, quality assurance, infrastructure"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "76e8b089-1a40-4e02-94f9-011528c911a5", "node_type": "4", "metadata": {"page_label": "21", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "## 7.3.4 Category 5 - Custom Applications\n\nThese systems and subsystems are developed to meet the specific needs of the regulated company. The risk inherent in customized *software* is high. The life-cycle approach and system decisions should take this high risk into account, because there is no user experience or information about system reliability.\n\nThe approach used to assess the supplier must be risk-based and documented. An audit at the supplier is required to confirm that an adequate Quality Management System exists for control development and ongoing support for the application. In the absence of a Management System Quality Assurance, suppliers must adapt to provide an appropriate basis for managing application development and support.\n\nThe approach used by the regulated company must cover the layers of *software* involved and their respective categories. The approach should reflect the result of the supplier's assessment, the risk to GMP, system size and complexity. It should define strategies to mitigate any weaknesses identified during the supplier evaluation process.\n\n## 7.3.5 Typical Examples and Approaches\n\n**Table 2. Categories of Software, Description and Typical Approach to the Life Cycle.**\n\n| Category                       | description                                                                                                                 | Typical Examples                                                                                                                                                                                                       | Typical Approach                                                                                                                                |\n| ------------------------------ | --------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- |\n| Software of Infrastructure (1) | * *software* of Layer (that is, over which applications are built)\n* *Software* used for manage the environment operational | - Operational systems\n- Mechanisms for databases\n- Middleware\n- Languages programming\n- Statistical packages\n- Spreadsheets\n- Tools network monitoring\n- Tools scheduling\n- Tools version control\n- Based Applications | * Registration of the version and verification of correct installation\n* See GAMP Good Practice Guide: IT Infrastructure Control and Compliance |\n|                                | Non-*Software* Time parameters                                                                                              |                                                                                                                                                                                                                        | Shortened life cycle                                                                                                                            |\n", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "5f84be9ba2c3c4e7422268cd1ca1688b73f8371e452802bd2f2d5d5b1148db07", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "## 7.3.4 Category 5 - Custom Applications\n\nThese systems and subsystems are developed to meet the specific needs of the regulated company. The risk inherent in customized *software* is high. The life-cycle approach and system decisions should take this high risk into account, because there is no user experience or information about system reliability.\n\nThe approach used to assess the supplier must be risk-based and documented. An audit at the supplier is required to confirm that an adequate Quality Management System exists for control development and ongoing support for the application. In the absence of a Management System Quality Assurance, suppliers must adapt to provide an appropriate basis for managing application development and support.\n\nThe approach used by the regulated company must cover the layers of *software* involved and their respective categories. The approach should reflect the result of the supplier's assessment, the risk to GMP, system size and complexity. It should define strategies to mitigate any weaknesses identified during the supplier evaluation process.\n\n## 7.3.5 Typical Examples and Approaches\n\n**Table 2. Categories of Software, Description and Typical Approach to the Life Cycle.**\n\n| Category                       | description                                                                                                                 | Typical Examples                                                                                                                                                                                                       | Typical Approach                                                                                                                                |\n| ------------------------------ | --------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- |\n| Software of Infrastructure (1) | * *software* of Layer (that is, over which applications are built)\n* *Software* used for manage the environment operational | - Operational systems\n- Mechanisms for databases\n- Middleware\n- Languages programming\n- Statistical packages\n- Spreadsheets\n- Tools network monitoring\n- Tools scheduling\n- Tools version control\n- Based Applications | * Registration of the version and verification of correct installation\n* See GAMP Good Practice Guide: IT Infrastructure Control and Compliance |\n|                                | Non-*Software* Time parameters                                                                                              |                                                                                                                                                                                                                        | Shortened life cycle                                                                                                                            |", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 3324, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "fc5a006b-3c37-4cd9-b03b-88f0909e63fa": {"__data__": {"id_": "fc5a006b-3c37-4cd9-b03b-88f0909e63fa", "embedding": null, "metadata": {"page_label": "22", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# Guide for Computer Systems Validation\n\n## Table 2: Software Categories, Description and Typical Life Cycle Approach (continued).\n\n| Category                | description                                                                 | Typical Examples                                                                 | Typical Approach                                                                 |\n|-------------------------|-----------------------------------------------------------------------------|----------------------------------------------------------------------------------|----------------------------------------------------------------------------------|\n| Configured Software (4) | Software, usually more complex, which can be configured by the user to meet your specific needs. THE software code is not changed. | - LIMS\n- Systems data acquisition\n- SCADA\n- ERU\n- MRPII\n- DCS\n- CDS\n- EDMS\n- BMS\n- Spreadsheets\n- HMI (Human Simple Machine Interfaces)\nNOTE: Specific examples of system types above can contain elements substantial custom features. | - Cycle approach of life\n- Approach to supplier assessment with risk based\n- Demonstration of that the supplier has a Management System Quality\n- Some cycle documentation life maintained by the supplier (ex: Specifications of Project)\n- Number registration version and verification correct installation |\n| Custom software (5)     | software customized designed and coded for                                 | It varies, but includes:\n- IT Applications                                    | - Testing based on risk for demonstrate that the application works as designed, in a test environment\n- Testing based on risk for demonstrate that the application works as designed, in an environment of production\n- Existence of procedures for maintenance of care and suitability for use and data management\nSame approach used for Category 4, plus: |\n\n----\n\nGuide for Computer Systems Validation\nGuide n\u00b0 33/2020 - version 1, of 03/26/2020", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas que pueden proporcionar respuestas espec\u00edficas basadas en el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento es una gu\u00eda de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos, espec\u00edficamente la Gu\u00eda n\u00b0 33/2020. En la secci\u00f3n presentada, se describen dos categor\u00edas de software: \"Software Configurado\" y \"Software Personalizado\". Se detallan sus descripciones, ejemplos t\u00edpicos y enfoques de ciclo de vida. El software configurado permite ajustes por parte del usuario sin modificar el c\u00f3digo, mientras que el software personalizado es dise\u00f1ado y codificado espec\u00edficamente para necesidades particulares. Ambos tipos requieren enfoques de validaci\u00f3n basados en riesgos y documentaci\u00f3n adecuada.\n\n### Preguntas\n1. **\u00bfCu\u00e1les son los requisitos espec\u00edficos de documentaci\u00f3n que deben mantener los proveedores de software configurado seg\u00fan la gu\u00eda de ANVISA?**\n   - Esta pregunta busca detalles sobre la documentaci\u00f3n que los proveedores deben proporcionar, lo cual no se encuentra f\u00e1cilmente en otras fuentes.\n\n2. **\u00bfQu\u00e9 diferencias clave existen en el enfoque de validaci\u00f3n entre el software configurado y el software personalizado seg\u00fan la gu\u00eda?**\n   - Esta pregunta se centra en las diferencias en los m\u00e9todos de validaci\u00f3n, lo que puede no ser evidente sin un an\u00e1lisis detallado del documento.\n\n3. **\u00bfQu\u00e9 ejemplos de software configurado se mencionan en la gu\u00eda y c\u00f3mo se relacionan con las pr\u00e1cticas de gesti\u00f3n de calidad?**\n   - Esta pregunta busca ejemplos concretos y su conexi\u00f3n con la gesti\u00f3n de calidad, lo que puede no estar disponible en otras gu\u00edas o documentos.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Categor\u00eda 5 - Aplicaciones Personalizadas**:\n   - Las aplicaciones personalizadas son sistemas desarrollados para satisfacer necesidades espec\u00edficas de empresas reguladas.\n   - Se destaca el alto riesgo asociado con el software personalizado, debido a la falta de experiencia del usuario y datos sobre la fiabilidad del sistema.\n\n2. **Evaluaci\u00f3n de Proveedores**:\n   - La evaluaci\u00f3n de proveedores debe ser basada en riesgos y documentada.\n   - Es necesario realizar auditor\u00edas a los proveedores para confirmar la existencia de un Sistema de Gesti\u00f3n de Calidad adecuado que controle el desarrollo y soporte de la aplicaci\u00f3n.\n   - En ausencia de un Sistema de Gesti\u00f3n de Calidad, los proveedores deben adaptarse para gestionar adecuadamente el desarrollo y soporte de la aplicaci\u00f3n.\n\n3. **Enfoque de la Empresa Regulada**:\n   - La empresa regulada debe considerar las capas de software involucradas y sus respectivas categor\u00edas en su enfoque.\n   - Debe reflejar los resultados de la evaluaci\u00f3n del proveedor, el riesgo para las Buenas Pr\u00e1cticas de Manufactura (GMP), as\u00ed como el tama\u00f1o y complejidad del sistema.\n   - Se deben definir estrategias para mitigar debilidades identificadas durante la evaluaci\u00f3n del proveedor.\n\n4. **Categor\u00edas de Software**:\n   - Se presenta una tabla que clasifica diferentes tipos de software, incluyendo el \"Software de Infraestructura\".\n   - Ejemplos de software de infraestructura incluyen sistemas operativos, bases de datos, middleware, lenguajes de programaci\u00f3n, herramientas de monitoreo de red, entre otros.\n   - El enfoque t\u00edpico para el ciclo de vida del software de infraestructura incluye el registro de versiones y la verificaci\u00f3n de la correcta instalaci\u00f3n, siguiendo las buenas pr\u00e1cticas de GAMP.\n\n### Entidades Clave\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria en Brasil.\n- **GMP**: Buenas Pr\u00e1cticas de Manufactura.\n- **GAMP**: Buenas Pr\u00e1cticas de Control y Cumplimiento de Infraestructura de TI.\n- **Software Personalizado**: Software desarrollado espec\u00edficamente para una empresa regulada.\n- **Sistema de Gesti\u00f3n de Calidad**: Sistema que asegura el control del desarrollo y soporte de aplicaciones. \n\nEste resumen encapsula los puntos m\u00e1s importantes de la secci\u00f3n, destacando la importancia de la gesti\u00f3n de riesgos y la calidad en el desarrollo de software en entornos regulados.", "excerpt_keywords": "Keywords: ANVISA, Computer Systems Validation, Configured Software, Custom Software, Quality Management"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "5435101f-974e-4cfb-952e-1c37b395f2ed", "node_type": "4", "metadata": {"page_label": "22", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# Guide for Computer Systems Validation\n\n## Table 2: Software Categories, Description and Typical Life Cycle Approach (continued).\n\n| Category                | description                                                                 | Typical Examples                                                                 | Typical Approach                                                                 |\n|-------------------------|-----------------------------------------------------------------------------|----------------------------------------------------------------------------------|----------------------------------------------------------------------------------|\n| Configured Software (4) | Software, usually more complex, which can be configured by the user to meet your specific needs. THE software code is not changed. | - LIMS\n- Systems data acquisition\n- SCADA\n- ERU\n- MRPII\n- DCS\n- CDS\n- EDMS\n- BMS\n- Spreadsheets\n- HMI (Human Simple Machine Interfaces)\nNOTE: Specific examples of system types above can contain elements substantial custom features. | - Cycle approach of life\n- Approach to supplier assessment with risk based\n- Demonstration of that the supplier has a Management System Quality\n- Some cycle documentation life maintained by the supplier (ex: Specifications of Project)\n- Number registration version and verification correct installation |\n| Custom software (5)     | software customized designed and coded for                                 | It varies, but includes:\n- IT Applications                                    | - Testing based on risk for demonstrate that the application works as designed, in a test environment\n- Testing based on risk for demonstrate that the application works as designed, in an environment of production\n- Existence of procedures for maintenance of care and suitability for use and data management\nSame approach used for Category 4, plus: |\n\n----\n\nGuide for Computer Systems Validation\nGuide n\u00b0 33/2020 - version 1, of 03/26/2020", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "1fbc0460d6f7fafb8a50aba4d134d7aaba723e63192bb2e188a2d171bda9241e", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "# Guide for Computer Systems Validation\n\n## Table 2: Software Categories, Description and Typical Life Cycle Approach (continued).\n\n| Category                | description                                                                 | Typical Examples                                                                 | Typical Approach                                                                 |\n|-------------------------|-----------------------------------------------------------------------------|----------------------------------------------------------------------------------|----------------------------------------------------------------------------------|\n| Configured Software (4) | Software, usually more complex, which can be configured by the user to meet your specific needs. THE software code is not changed. | - LIMS\n- Systems data acquisition\n- SCADA\n- ERU\n- MRPII\n- DCS\n- CDS\n- EDMS\n- BMS\n- Spreadsheets\n- HMI (Human Simple Machine Interfaces)\nNOTE: Specific examples of system types above can contain elements substantial custom features. | - Cycle approach of life\n- Approach to supplier assessment with risk based\n- Demonstration of that the supplier has a Management System Quality\n- Some cycle documentation life maintained by the supplier (ex: Specifications of Project)\n- Number registration version and verification correct installation |\n| Custom software (5)     | software customized designed and coded for                                 | It varies, but includes:\n- IT Applications                                    | - Testing based on risk for demonstrate that the application works as designed, in a test environment\n- Testing based on risk for demonstrate that the application works as designed, in an environment of production\n- Existence of procedures for maintenance of care and suitability for use and data management\nSame approach used for Category 4, plus: |\n\n----\n\nGuide for Computer Systems Validation\nGuide n\u00b0 33/2020 - version 1, of 03/26/2020", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 2000, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "5e04fbf7-bb13-4899-8553-d09dfb47369c": {"__data__": {"id_": "5e04fbf7-bb13-4899-8553-d09dfb47369c", "embedding": null, "metadata": {"page_label": "23", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 7.4 HARDWARE CATEGORIES\n\n## 7.4.1 Hardware Category 1 - Standard Hardware Components\n\nMost of the hardware used by regulated companies falls into this category.\n\nStandard hardware components must be documented including details about the supplier or manufacturer and version number. The correct installation and connections of the components must be checked. THE model, version number and if available and the serial number of the pre-assembled hardware must be registered. Pre-assembled hardware does not have to be disassembled. In such cases the details of the hardware can be purchased from the hardware data sheet or other material specification. Configuration management and change control are applicable.\n\n## 7.4.2 Hardware Category 2 - Custom Built-in Hardware Components\n\nIn addition to the requirements described in the item above, those described in this item are applicable. Custom items from hardware must have a Project Specification (EP / DS) and be subject to acceptance testing. THE approach to supplier assessment should be risk-based and documented. In most cases a Supplier audit must be performed for the development of customized hardware. Systems assembled using custom hardware from different sources requires verification to confirm the compatibility of interconnected hardware components. Any hardware configuration must be defined in the design documentation and verified. Configuration management and change control are applicable.\n\n# 8. INVENTORY LIST\n\nRegulated companies must maintain an inventory of their computerized systems.\n\nThe inventory must present summary information about each system, describing: name of the system; associated equipment or application; impact / criticality; category; ownership (sector, system owner, process owner); current version; provider; validation date and status.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos clasifica el hardware en dos categor\u00edas: componentes de hardware est\u00e1ndar y componentes de hardware personalizados. Se requiere documentaci\u00f3n detallada para ambos tipos, incluyendo informaci\u00f3n sobre proveedores, especificaciones de proyecto y pruebas de aceptaci\u00f3n. Adem\u00e1s, las empresas reguladas deben mantener un inventario de sus sistemas inform\u00e1ticos, que incluya informaci\u00f3n cr\u00edtica sobre cada sistema.\n\n### Preguntas\n\n1. **\u00bfQu\u00e9 informaci\u00f3n espec\u00edfica debe incluirse en la documentaci\u00f3n de los componentes de hardware est\u00e1ndar seg\u00fan la gu\u00eda de ANVISA?**\n   - La documentaci\u00f3n debe incluir detalles sobre el proveedor o fabricante, el n\u00famero de versi\u00f3n, el modelo, el n\u00famero de serie (si est\u00e1 disponible) y la verificaci\u00f3n de la instalaci\u00f3n y conexiones de los componentes.\n\n2. **\u00bfCu\u00e1les son los requisitos adicionales para los componentes de hardware personalizados en comparaci\u00f3n con los componentes est\u00e1ndar?**\n   - Los componentes personalizados deben tener una Especificaci\u00f3n de Proyecto (EP/DS), estar sujetos a pruebas de aceptaci\u00f3n, y se debe realizar una auditor\u00eda del proveedor. Adem\u00e1s, se requiere verificaci\u00f3n de la compatibilidad de los componentes de hardware interconectados.\n\n3. **\u00bfQu\u00e9 informaci\u00f3n debe contener el inventario de sistemas inform\u00e1ticos que deben mantener las empresas reguladas?**\n   - El inventario debe incluir el nombre del sistema, el equipo o aplicaci\u00f3n asociada, el impacto/cr\u00edtica, la categor\u00eda, la propiedad (sector, propietario del sistema, propietario del proceso), la versi\u00f3n actual, el proveedor, la fecha de validaci\u00f3n y el estado.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\nEl contenido presentado proviene de la \"Gu\u00eda para la Validaci\u00f3n de Sistemas Inform\u00e1ticos\" de ANVISA, espec\u00edficamente la Gu\u00eda n\u00b0 33/2020. En esta secci\u00f3n se abordan dos categor\u00edas principales de software:\n\n1. **Software Configurado**:\n   - **Descripci\u00f3n**: Software complejo que puede ser configurado por el usuario para satisfacer necesidades espec\u00edficas sin modificar el c\u00f3digo fuente.\n   - **Ejemplos T\u00edpicos**: \n     - LIMS (Laboratory Information Management Systems)\n     - Sistemas de adquisici\u00f3n de datos\n     - SCADA (Supervisory Control and Data Acquisition)\n     - ERU (Emergency Response Unit)\n     - MRPII (Manufacturing Resource Planning)\n     - DCS (Distributed Control Systems)\n     - CDS (Clinical Data Systems)\n     - EDMS (Electronic Document Management Systems)\n     - BMS (Building Management Systems)\n     - Hojas de c\u00e1lculo\n     - HMI (Interfaz Hombre-M\u00e1quina)\n   - **Enfoque T\u00edpico**: \n     - Ciclo de vida del software\n     - Evaluaci\u00f3n del proveedor basada en riesgos\n     - Demostraci\u00f3n de un sistema de gesti\u00f3n de calidad por parte del proveedor\n     - Mantenimiento de documentaci\u00f3n del ciclo de vida (ej: especificaciones del proyecto)\n     - Registro de versiones y verificaci\u00f3n de instalaci\u00f3n correcta.\n\n2. **Software Personalizado**:\n   - **Descripci\u00f3n**: Software dise\u00f1ado y codificado espec\u00edficamente para satisfacer necesidades particulares.\n   - **Ejemplos T\u00edpicos**: Var\u00edan, pero incluyen aplicaciones de TI.\n   - **Enfoque T\u00edpico**:\n     - Pruebas basadas en riesgos para demostrar que la aplicaci\u00f3n funciona como se dise\u00f1\u00f3, tanto en entornos de prueba como de producci\u00f3n.\n     - Procedimientos para el mantenimiento y gesti\u00f3n de datos.\n     - Se utiliza un enfoque similar al del software configurado, pero con requisitos adicionales.\n\n### Entidades Clave\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil, responsable de la regulaci\u00f3n y supervisi\u00f3n de productos y servicios relacionados con la salud.\n- **Software Configurado**: Categor\u00eda de software que permite configuraciones sin cambios en el c\u00f3digo.\n- **Software Personalizado**: Software dise\u00f1ado espec\u00edficamente para necesidades particulares.\n- **Ejemplos de Software**: LIMS, SCADA, Hojas de c\u00e1lculo, entre otros.\n- **Enfoques de Validaci\u00f3n**: Ciclo de vida, evaluaci\u00f3n de proveedores, pruebas basadas en riesgos, mantenimiento de documentaci\u00f3n.\n\nEste resumen proporciona una visi\u00f3n general de las categor\u00edas de software y sus enfoques de validaci\u00f3n seg\u00fan la gu\u00eda de ANVISA, destacando la importancia de la gesti\u00f3n de calidad y la documentaci\u00f3n en el proceso de validaci\u00f3n.", "excerpt_keywords": "Keywords: ANVISA, hardware categories, validation, inventory list, regulated companies"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "6de85024-463c-476c-9bdc-fb2066a7c0ac", "node_type": "4", "metadata": {"page_label": "23", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 7.4 HARDWARE CATEGORIES\n\n## 7.4.1 Hardware Category 1 - Standard Hardware Components\n\nMost of the hardware used by regulated companies falls into this category.\n\nStandard hardware components must be documented including details about the supplier or manufacturer and version number. The correct installation and connections of the components must be checked. THE model, version number and if available and the serial number of the pre-assembled hardware must be registered. Pre-assembled hardware does not have to be disassembled. In such cases the details of the hardware can be purchased from the hardware data sheet or other material specification. Configuration management and change control are applicable.\n\n## 7.4.2 Hardware Category 2 - Custom Built-in Hardware Components\n\nIn addition to the requirements described in the item above, those described in this item are applicable. Custom items from hardware must have a Project Specification (EP / DS) and be subject to acceptance testing. THE approach to supplier assessment should be risk-based and documented. In most cases a Supplier audit must be performed for the development of customized hardware. Systems assembled using custom hardware from different sources requires verification to confirm the compatibility of interconnected hardware components. Any hardware configuration must be defined in the design documentation and verified. Configuration management and change control are applicable.\n\n# 8. INVENTORY LIST\n\nRegulated companies must maintain an inventory of their computerized systems.\n\nThe inventory must present summary information about each system, describing: name of the system; associated equipment or application; impact / criticality; category; ownership (sector, system owner, process owner); current version; provider; validation date and status.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "0cab0fd5608bb358d40f94b365fcab6bb87a35c4e68ba78c3c3f97c5976176b7", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "# 7.4 HARDWARE CATEGORIES\n\n## 7.4.1 Hardware Category 1 - Standard Hardware Components\n\nMost of the hardware used by regulated companies falls into this category.\n\nStandard hardware components must be documented including details about the supplier or manufacturer and version number. The correct installation and connections of the components must be checked. THE model, version number and if available and the serial number of the pre-assembled hardware must be registered. Pre-assembled hardware does not have to be disassembled. In such cases the details of the hardware can be purchased from the hardware data sheet or other material specification. Configuration management and change control are applicable.\n\n## 7.4.2 Hardware Category 2 - Custom Built-in Hardware Components\n\nIn addition to the requirements described in the item above, those described in this item are applicable. Custom items from hardware must have a Project Specification (EP / DS) and be subject to acceptance testing. THE approach to supplier assessment should be risk-based and documented. In most cases a Supplier audit must be performed for the development of customized hardware. Systems assembled using custom hardware from different sources requires verification to confirm the compatibility of interconnected hardware components. Any hardware configuration must be defined in the design documentation and verified. Configuration management and change control are applicable.\n\n# 8. INVENTORY LIST\n\nRegulated companies must maintain an inventory of their computerized systems.\n\nThe inventory must present summary information about each system, describing: name of the system; associated equipment or application; impact / criticality; category; ownership (sector, system owner, process owner); current version; provider; validation date and status.", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 1833, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "64ba19f4-b70a-44f6-ab1f-53ac04faa227": {"__data__": {"id_": "64ba19f4-b70a-44f6-ab1f-53ac04faa227", "embedding": null, "metadata": {"page_label": "24", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# VALIDATION OF COMPUTERIZED SYSTEMS\n\n## 9.1 INTRODUCTION\n\nA strategy will be presented to carry out the computerized system validation, from the definition user requirements, system selection, execution and approval of the validation report.\n\nThis strategy is applicable to systems belonging to categories 3, 4 and 5, which are the vast majority of systems computerized systems in the pharmaceutical and pharmaceutical industries.\n\nThis section will also describe the auxiliary risk management, change and configuration, project review, traceability and documentation management.\n\nTerminologies that are commonly used by the pharmaceutical and chemical industries will be used in this guide. pharmaceutical companies, namely: Validation Policies, Master Validation Plan and Validation Plan.\n\nThe regulated company must include the validation of computerized systems in its validation policy and/or Master Validation Plan. These documents should express the overall corporate or plant approach to company for the activity of validation of computerized systems and for maintaining their situation of validated.\n\nIt is recommended that a Validation Plan be prepared for each computer system that has relevance in GMP, focusing on aspects related to patient quality, product quality and data integrity.\n\nFor automated manufacturing equipment, the validation of the separate computerized system must be avoided. The specification and verification of the computerized system should be part of an approach integrated engineering to ensure compliance and suitability for the intended use of the equipment automated within a whole.\n\n----\n\nPage 23\n\nFigure 4 shows the steps involved in validating the systems that form part of the system's life cycle computerized, from the definition of user requirements, through the acquisition and validation of the system computerized and execution of the pertinent auxiliary processes.\n\nThese steps are also applicable to the design phase and the subsequent changes that occurred during the phase operating system.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas computarizados presenta una estrategia para llevar a cabo la validaci\u00f3n de estos sistemas en la industria farmac\u00e9utica. Se enfoca en la definici\u00f3n de requisitos del usuario, selecci\u00f3n del sistema, ejecuci\u00f3n y aprobaci\u00f3n del informe de validaci\u00f3n. Se aplica a sistemas de categor\u00edas 3, 4 y 5, que son comunes en la industria. Adem\u00e1s, se discuten aspectos como la gesti\u00f3n de riesgos, cambios, trazabilidad y documentaci\u00f3n. Se enfatiza la importancia de incluir la validaci\u00f3n en la pol\u00edtica de la empresa y se recomienda preparar un Plan de Validaci\u00f3n para cada sistema relevante en Buenas Pr\u00e1cticas de Manufactura (GMP).\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfQu\u00e9 categor\u00edas de sistemas computarizados son relevantes para la estrategia de validaci\u00f3n presentada en el documento?**\n   - La estrategia de validaci\u00f3n es aplicable a sistemas pertenecientes a las categor\u00edas 3, 4 y 5, que son las m\u00e1s comunes en la industria farmac\u00e9utica.\n\n2. **\u00bfCu\u00e1l es la recomendaci\u00f3n sobre la validaci\u00f3n de sistemas computarizados en relaci\u00f3n con el equipo de fabricaci\u00f3n automatizado?**\n   - Se recomienda evitar la validaci\u00f3n de sistemas computarizados separados para el equipo de fabricaci\u00f3n automatizado. En su lugar, la especificaci\u00f3n y verificaci\u00f3n del sistema computarizado deben formar parte de un enfoque de ingenier\u00eda integrado.\n\n3. **\u00bfQu\u00e9 documentos deben incluir la validaci\u00f3n de sistemas computarizados seg\u00fan el contexto del documento?**\n   - La validaci\u00f3n de sistemas computarizados debe incluirse en la pol\u00edtica de validaci\u00f3n de la empresa y/o en el Plan Maestro de Validaci\u00f3n, que deben expresar el enfoque general de la empresa hacia la validaci\u00f3n y el mantenimiento del estado validado de los sistemas.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Categor\u00edas de Hardware**:\n   - **Hardware Est\u00e1ndar (Categor\u00eda 1)**:\n     - Documentaci\u00f3n requerida: detalles del proveedor, n\u00famero de versi\u00f3n, modelo, n\u00famero de serie (si est\u00e1 disponible).\n     - Verificaci\u00f3n de instalaci\u00f3n y conexiones.\n     - No es necesario desensamblar hardware preensamblado; se puede obtener informaci\u00f3n de la hoja de datos del hardware.\n     - Aplicaci\u00f3n de gesti\u00f3n de configuraci\u00f3n y control de cambios.\n\n   - **Hardware Personalizado (Categor\u00eda 2)**:\n     - Requisitos adicionales: Especificaci\u00f3n de Proyecto (EP/DS) y pruebas de aceptaci\u00f3n.\n     - Evaluaci\u00f3n del proveedor basada en riesgos y documentaci\u00f3n.\n     - Auditor\u00eda del proveedor para el desarrollo de hardware personalizado.\n     - Verificaci\u00f3n de compatibilidad de componentes de hardware interconectados.\n     - Definici\u00f3n de la configuraci\u00f3n de hardware en la documentaci\u00f3n de dise\u00f1o.\n\n2. **Inventario de Sistemas Inform\u00e1ticos**:\n   - Las empresas reguladas deben mantener un inventario que incluya:\n     - Nombre del sistema.\n     - Equipos o aplicaciones asociadas.\n     - Impacto/cr\u00edtica.\n     - Categor\u00eda.\n     - Propiedad (sector, propietario del sistema, propietario del proceso).\n     - Versi\u00f3n actual.\n     - Proveedor.\n     - Fecha de validaci\u00f3n y estado.\n\n### Entidades Clave:\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil.\n- **Hardware Est\u00e1ndar**: Componentes de hardware com\u00fanmente utilizados.\n- **Hardware Personalizado**: Componentes de hardware dise\u00f1ados espec\u00edficamente para un prop\u00f3sito.\n- **Especificaci\u00f3n de Proyecto (EP/DS)**: Documentaci\u00f3n que detalla los requisitos y dise\u00f1o del hardware personalizado.\n- **Auditor\u00eda del Proveedor**: Evaluaci\u00f3n de los proveedores de hardware personalizado.\n- **Inventario de Sistemas**: Registro de todos los sistemas inform\u00e1ticos utilizados por empresas reguladas.", "excerpt_keywords": "Keywords: validation, computerized systems, pharmaceutical industry, risk management, GMP"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "66c91d9d-ac86-4430-8fa3-d94b775b57ea", "node_type": "4", "metadata": {"page_label": "24", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# VALIDATION OF COMPUTERIZED SYSTEMS\n\n## 9.1 INTRODUCTION\n\nA strategy will be presented to carry out the computerized system validation, from the definition user requirements, system selection, execution and approval of the validation report.\n\nThis strategy is applicable to systems belonging to categories 3, 4 and 5, which are the vast majority of systems computerized systems in the pharmaceutical and pharmaceutical industries.\n\nThis section will also describe the auxiliary risk management, change and configuration, project review, traceability and documentation management.\n\nTerminologies that are commonly used by the pharmaceutical and chemical industries will be used in this guide. pharmaceutical companies, namely: Validation Policies, Master Validation Plan and Validation Plan.\n\nThe regulated company must include the validation of computerized systems in its validation policy and/or Master Validation Plan. These documents should express the overall corporate or plant approach to company for the activity of validation of computerized systems and for maintaining their situation of validated.\n\nIt is recommended that a Validation Plan be prepared for each computer system that has relevance in GMP, focusing on aspects related to patient quality, product quality and data integrity.\n\nFor automated manufacturing equipment, the validation of the separate computerized system must be avoided. The specification and verification of the computerized system should be part of an approach integrated engineering to ensure compliance and suitability for the intended use of the equipment automated within a whole.\n\n----\n\nPage 23\n\nFigure 4 shows the steps involved in validating the systems that form part of the system's life cycle computerized, from the definition of user requirements, through the acquisition and validation of the system computerized and execution of the pertinent auxiliary processes.\n\nThese steps are also applicable to the design phase and the subsequent changes that occurred during the phase operating system.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "2a7c01a16f7bf2e004f16931086389ad0683f1aa222a4f70b2ffa8fc1d569f7c", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "# VALIDATION OF COMPUTERIZED SYSTEMS\n\n## 9.1 INTRODUCTION\n\nA strategy will be presented to carry out the computerized system validation, from the definition user requirements, system selection, execution and approval of the validation report.\n\nThis strategy is applicable to systems belonging to categories 3, 4 and 5, which are the vast majority of systems computerized systems in the pharmaceutical and pharmaceutical industries.\n\nThis section will also describe the auxiliary risk management, change and configuration, project review, traceability and documentation management.\n\nTerminologies that are commonly used by the pharmaceutical and chemical industries will be used in this guide. pharmaceutical companies, namely: Validation Policies, Master Validation Plan and Validation Plan.\n\nThe regulated company must include the validation of computerized systems in its validation policy and/or Master Validation Plan. These documents should express the overall corporate or plant approach to company for the activity of validation of computerized systems and for maintaining their situation of validated.\n\nIt is recommended that a Validation Plan be prepared for each computer system that has relevance in GMP, focusing on aspects related to patient quality, product quality and data integrity.\n\nFor automated manufacturing equipment, the validation of the separate computerized system must be avoided. The specification and verification of the computerized system should be part of an approach integrated engineering to ensure compliance and suitability for the intended use of the equipment automated within a whole.\n\n----\n\nPage 23\n\nFigure 4 shows the steps involved in validating the systems that form part of the system's life cycle computerized, from the definition of user requirements, through the acquisition and validation of the system computerized and execution of the pertinent auxiliary processes.\n\nThese steps are also applicable to the design phase and the subsequent changes that occurred during the phase operating system.", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 2044, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "02820a20-016d-417c-b944-ab6ded78ddcc": {"__data__": {"id_": "02820a20-016d-417c-b944-ab6ded78ddcc", "embedding": null, "metadata": {"page_label": "25", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "NO_CONTENT_HERE", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas que podr\u00edan derivarse del contexto proporcionado, junto con un breve resumen del contenido:\n\n### Resumen del Contexto\nEl documento mencionado es la \"Gu\u00eda para la Validaci\u00f3n de Sistemas Inform\u00e1ticos\" de ANVISA, publicada en 2020. Esta gu\u00eda proporciona directrices sobre c\u00f3mo validar sistemas inform\u00e1ticos en el \u00e1mbito de la salud, asegurando que estos sistemas cumplan con los requisitos regulatorios y de calidad necesarios para su uso en la industria farmac\u00e9utica y de dispositivos m\u00e9dicos en Brasil.\n\n### Preguntas\n1. **\u00bfCu\u00e1les son los principales requisitos que deben cumplirse para la validaci\u00f3n de sistemas inform\u00e1ticos seg\u00fan la gu\u00eda de ANVISA?**\n   - Esta pregunta busca detalles espec\u00edficos sobre los criterios y est\u00e1ndares que ANVISA establece para la validaci\u00f3n de sistemas inform\u00e1ticos.\n\n2. **\u00bfQu\u00e9 metodolog\u00edas o enfoques recomienda ANVISA para llevar a cabo la validaci\u00f3n de sistemas inform\u00e1ticos?**\n   - Aqu\u00ed se busca informaci\u00f3n sobre las estrategias o m\u00e9todos que la gu\u00eda sugiere para realizar una validaci\u00f3n efectiva.\n\n3. **\u00bfQu\u00e9 implicaciones tiene la falta de validaci\u00f3n de sistemas inform\u00e1ticos en el cumplimiento regulatorio en Brasil?**\n   - Esta pregunta se enfoca en las consecuencias que pueden surgir si una empresa no sigue las directrices de validaci\u00f3n establecidas por ANVISA, lo que podr\u00eda incluir sanciones o problemas de calidad. \n\nEstas preguntas est\u00e1n dise\u00f1adas para obtener informaci\u00f3n espec\u00edfica que probablemente no se encuentre f\u00e1cilmente en otros documentos o fuentes.", "prev_section_summary": "### Temas Clave\n\n1. **Estrategia de Validaci\u00f3n**: Se presenta un enfoque para llevar a cabo la validaci\u00f3n de sistemas computarizados, que incluye la definici\u00f3n de requisitos del usuario, selecci\u00f3n del sistema, ejecuci\u00f3n y aprobaci\u00f3n del informe de validaci\u00f3n.\n\n2. **Categor\u00edas de Sistemas**: La estrategia es aplicable a sistemas de categor\u00edas 3, 4 y 5, que son comunes en la industria farmac\u00e9utica.\n\n3. **Gesti\u00f3n de Riesgos y Cambios**: Se abordan aspectos auxiliares como la gesti\u00f3n de riesgos, cambios, configuraci\u00f3n, revisi\u00f3n de proyectos, trazabilidad y gesti\u00f3n de documentaci\u00f3n.\n\n4. **Documentaci\u00f3n Requerida**: Se enfatiza la necesidad de incluir la validaci\u00f3n de sistemas computarizados en la pol\u00edtica de validaci\u00f3n de la empresa y/o en el Plan Maestro de Validaci\u00f3n.\n\n5. **Plan de Validaci\u00f3n**: Se recomienda elaborar un Plan de Validaci\u00f3n para cada sistema relevante en Buenas Pr\u00e1cticas de Manufactura (GMP), centr\u00e1ndose en la calidad del paciente, calidad del producto e integridad de los datos.\n\n6. **Integraci\u00f3n con Equipos Automatizados**: Se sugiere evitar la validaci\u00f3n de sistemas computarizados separados para equipos de fabricaci\u00f3n automatizados, promoviendo un enfoque de ingenier\u00eda integrado.\n\n### Entidades\n\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil.\n- **Categor\u00edas de Sistemas**: 3, 4 y 5.\n- **Documentos Clave**: Pol\u00edtica de Validaci\u00f3n, Plan Maestro de Validaci\u00f3n, Plan de Validaci\u00f3n.\n- **Conceptos**: Validaci\u00f3n de sistemas computarizados, Buenas Pr\u00e1cticas de Manufactura (GMP), gesti\u00f3n de riesgos, trazabilidad, documentaci\u00f3n.\n\nEste resumen destaca los elementos esenciales de la secci\u00f3n sobre la validaci\u00f3n de sistemas computarizados, proporcionando una visi\u00f3n clara de los temas tratados y las entidades involucradas.", "excerpt_keywords": "Keywords: ANVISA, validaci\u00f3n, sistemas inform\u00e1ticos, Buenas Pr\u00e1cticas de Manufactura, gesti\u00f3n de riesgos"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "49d7f001-25fa-4f15-8fb5-a3b7cd17f6ef", "node_type": "4", "metadata": {"page_label": "25", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "NO_CONTENT_HERE", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "067ff4a80d17e3e72738a557d892ff95bc6b044e67d2e7ae02fb7d8fc763b64a", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "NO_CONTENT_HERE", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 15, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "3cf3da5a-c30c-4361-9275-af504462ca0e": {"__data__": {"id_": "3cf3da5a-c30c-4361-9275-af504462ca0e", "embedding": null, "metadata": {"page_label": "26", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 9.2.1 Introduction\n\nIt is in the validation plan where the project is described, the actions to be carried out for an successful validation and acceptance criteria for clearing the system are clearly defined.\n\nYou must define:\n\n- What activities are needed;\n- How the activities will be carried out and who are responsible;\n- What are the expected results;\n- What are the acceptance criteria;\n- How the compliance situation will be maintained throughout the life of the system.\n\nPlanning should start as soon as possible, ideally during document development describing the specifications of user requirements (ERU / URS).\n\nA similar or generic plan can be generated for similar systems, but one that adequately reflects the characteristics of each system.\n\nRegarding the roles and responsibilities, the validation plan is the responsibility of the Process Owner. It may be delegated to the Project Manager, if applicable, and the Project Owner may also be involved System.\n\n# 9.2.2 Content of the Plan\n\n## 9.2.2.1 Introduction and Scope\n\nIt should contain:\n\n- The scope of the system;\n- The objectives of the validation process;\n- Review, maintenance or update of the plan itself.\n\n## 9.2.2.2 System Overview\n\nThe general description of the system should contain:\n\n- Business purpose and intended use for the system;\n- A high-level description of the system;\n- An overview of the system architecture;\n- System diagrams.\n\n## 9.2.2.3 Organizational Structure\n\nRoles and responsibilities should be described, such as:\n\n----\n\nGuide for Computer Systems Validation\nGuide n\u00b0 33/2020 - version 1, of 03/26/2020\n\nPage 25", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas que pueden proporcionar respuestas espec\u00edficas basadas en el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos establece la importancia de un plan de validaci\u00f3n que defina claramente las actividades necesarias, los responsables, los resultados esperados y los criterios de aceptaci\u00f3n. Se enfatiza que la planificaci\u00f3n debe comenzar lo antes posible, idealmente durante la elaboraci\u00f3n de documentos que describen los requisitos del usuario. Adem\u00e1s, se detalla el contenido que debe incluir el plan, como el alcance del sistema, los objetivos del proceso de validaci\u00f3n y la estructura organizativa.\n\n### Preguntas\n1. **\u00bfCu\u00e1les son los elementos clave que deben incluirse en un plan de validaci\u00f3n seg\u00fan la gu\u00eda de ANVISA?**\n   - Esta pregunta busca una lista detallada de los componentes que deben estar presentes en el plan de validaci\u00f3n, como el alcance del sistema, los objetivos y la estructura organizativa.\n\n2. **\u00bfQui\u00e9n es responsable de la elaboraci\u00f3n del plan de validaci\u00f3n y qu\u00e9 roles pueden estar involucrados en su desarrollo?**\n   - Esta pregunta se centra en identificar las responsabilidades espec\u00edficas en la creaci\u00f3n del plan de validaci\u00f3n y c\u00f3mo pueden ser delegadas a otros roles dentro de la organizaci\u00f3n.\n\n3. **\u00bfPor qu\u00e9 es importante iniciar la planificaci\u00f3n de la validaci\u00f3n durante la fase de desarrollo de los requisitos del usuario?**\n   - Esta pregunta busca explorar la raz\u00f3n detr\u00e1s de la recomendaci\u00f3n de comenzar la planificaci\u00f3n en una etapa temprana y c\u00f3mo esto puede impactar la efectividad del proceso de validaci\u00f3n a largo plazo.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n**Documento:** ANVISA - Gu\u00eda para la Validaci\u00f3n de Sistemas Inform\u00e1ticos 33/2020\n\n**Temas Clave:**\n1. **Validaci\u00f3n de Sistemas Inform\u00e1ticos:** Directrices sobre c\u00f3mo validar sistemas inform\u00e1ticos en el sector salud.\n2. **Cumplimiento Regulatorio:** Aseguramiento de que los sistemas cumplen con los requisitos regulatorios y de calidad.\n3. **Industria Farmac\u00e9utica y Dispositivos M\u00e9dicos:** Enfoque espec\u00edfico en la aplicaci\u00f3n de la validaci\u00f3n en estas \u00e1reas en Brasil.\n\n**Entidades:**\n- **ANVISA:** Agencia Nacional de Vigilancia Sanitaria de Brasil, responsable de la regulaci\u00f3n y supervisi\u00f3n de productos de salud.\n- **Sistemas Inform\u00e1ticos:** Herramientas y software utilizados en la industria de la salud que requieren validaci\u00f3n para garantizar su eficacia y seguridad.\n\nEste resumen destaca la importancia de la validaci\u00f3n de sistemas inform\u00e1ticos en el contexto regulatorio brasile\u00f1o, as\u00ed como el papel de ANVISA en establecer directrices para asegurar la calidad y cumplimiento en la industria de la salud.", "excerpt_keywords": "Keywords: validation plan, acceptance criteria, system overview, roles and responsibilities, compliance situation"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "b45b42aa-5a09-45d7-96c2-b3d71f97e566", "node_type": "4", "metadata": {"page_label": "26", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 9.2.1 Introduction\n\nIt is in the validation plan where the project is described, the actions to be carried out for an successful validation and acceptance criteria for clearing the system are clearly defined.\n\nYou must define:\n\n- What activities are needed;\n- How the activities will be carried out and who are responsible;\n- What are the expected results;\n- What are the acceptance criteria;\n- How the compliance situation will be maintained throughout the life of the system.\n\nPlanning should start as soon as possible, ideally during document development describing the specifications of user requirements (ERU / URS).\n\nA similar or generic plan can be generated for similar systems, but one that adequately reflects the characteristics of each system.\n\nRegarding the roles and responsibilities, the validation plan is the responsibility of the Process Owner. It may be delegated to the Project Manager, if applicable, and the Project Owner may also be involved System.\n\n# 9.2.2 Content of the Plan\n\n## 9.2.2.1 Introduction and Scope\n\nIt should contain:\n\n- The scope of the system;\n- The objectives of the validation process;\n- Review, maintenance or update of the plan itself.\n\n## 9.2.2.2 System Overview\n\nThe general description of the system should contain:\n\n- Business purpose and intended use for the system;\n- A high-level description of the system;\n- An overview of the system architecture;\n- System diagrams.\n\n## 9.2.2.3 Organizational Structure\n\nRoles and responsibilities should be described, such as:\n\n----\n\nGuide for Computer Systems Validation\nGuide n\u00b0 33/2020 - version 1, of 03/26/2020\n\nPage 25", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "eefe7ec61d09d45ed6a7cdc40b1bbe1d84453a13970b93f0a95d43b84f636439", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "# 9.2.1 Introduction\n\nIt is in the validation plan where the project is described, the actions to be carried out for an successful validation and acceptance criteria for clearing the system are clearly defined.\n\nYou must define:\n\n- What activities are needed;\n- How the activities will be carried out and who are responsible;\n- What are the expected results;\n- What are the acceptance criteria;\n- How the compliance situation will be maintained throughout the life of the system.\n\nPlanning should start as soon as possible, ideally during document development describing the specifications of user requirements (ERU / URS).\n\nA similar or generic plan can be generated for similar systems, but one that adequately reflects the characteristics of each system.\n\nRegarding the roles and responsibilities, the validation plan is the responsibility of the Process Owner. It may be delegated to the Project Manager, if applicable, and the Project Owner may also be involved System.\n\n# 9.2.2 Content of the Plan\n\n## 9.2.2.1 Introduction and Scope\n\nIt should contain:\n\n- The scope of the system;\n- The objectives of the validation process;\n- Review, maintenance or update of the plan itself.\n\n## 9.2.2.2 System Overview\n\nThe general description of the system should contain:\n\n- Business purpose and intended use for the system;\n- A high-level description of the system;\n- An overview of the system architecture;\n- System diagrams.\n\n## 9.2.2.3 Organizational Structure\n\nRoles and responsibilities should be described, such as:\n\n----\n\nGuide for Computer Systems Validation\nGuide n\u00b0 33/2020 - version 1, of 03/26/2020\n\nPage 25", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 1614, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "45f476a3-b9dc-4651-b69f-a838f188c788": {"__data__": {"id_": "45f476a3-b9dc-4651-b69f-a838f188c788", "embedding": null, "metadata": {"page_label": "27", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "- Project manager;\n- Project planning and management;\n- Control of project activities, resources and costs;\n- Monitoring the progress of the work and initiation of CAPA;\n- Ensure that the problems and objectives of the project are resolved and met;\n- Manage quality deviations involving the system:\n- Respond to the sponsor or top management;\n- Ensure system compliance in conjunction with the Quality Unit.\n- Quality Unit;\n- Ensuring system compliance with regulatory, quality and policy requirements company;\n- Provide support for the review and approval of the results generated by the validation work;\n- Evaluation and approval of closing quality deviations;\n- Approval of the system release for use.\n- Process Owner and / or System Owner\n- System deployment and management by the community of system users;\n- Approval of each stage of the validation process.\n\nSubject matter experts (SME) are those individuals with specific *expertise* and responsibility in a particular area or field, for example, chromatographic analysis, quality unit, engineering, automation, development, etc.\n\nThe responsibilities of these experts may include: planning and defining verification strategies of the system; performing reviews; definition of acceptance criteria; selection of method tests appropriate; execution of verification tests and review of the results.\n\n## 9.2.2.4 Quality Risk Management\n\nThe approach used to manage quality risk should be described.\n\nA risk assessment must be performed based on an understanding of the business processes, requirements of the regulatory requirements and known functional areas. The results obtained must include a decision on whether the system is relevant to GMP and a general assessment of the impact of the system.\n\nComplex systems, such as ERP-type systems, may have some features that are relevant to GMP and others that are not. In such cases, the method used to make such a decision should be described and should consider the following points:\n\n- The requirements for deciding on the impact levels on BPx;\n- The procedures for carrying out the assessment;\n- The current status of the process, recognizing that this assessment can be repeated and updated.\n\nAny specific procedures or standards used to perform quality risk management must be defined.\n\n## 9.2.2.5 Validation Strategy\n\nThe strategy to be used for system validation should be described, based on the following considerations:", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos detalla las responsabilidades de los diferentes roles involucrados en un proyecto de validaci\u00f3n, incluyendo al gerente de proyecto, la unidad de calidad y expertos en la materia (SME). Tambi\u00e9n aborda la gesti\u00f3n de riesgos de calidad, enfatizando la necesidad de realizar evaluaciones de riesgo basadas en procesos comerciales y requisitos regulatorios. Adem\u00e1s, se menciona la importancia de definir una estrategia de validaci\u00f3n adecuada para sistemas complejos, como los sistemas ERP.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfCu\u00e1les son las responsabilidades clave del gerente de proyecto en el proceso de validaci\u00f3n de sistemas inform\u00e1ticos seg\u00fan la gu\u00eda de ANVISA?**\n   - Respuesta: El gerente de proyecto es responsable de la planificaci\u00f3n y gesti\u00f3n del proyecto, control de actividades, recursos y costos, monitoreo del progreso, gesti\u00f3n de desviaciones de calidad, y asegurar el cumplimiento del sistema en colaboraci\u00f3n con la unidad de calidad.\n\n2. **\u00bfQu\u00e9 criterios se deben considerar al realizar una evaluaci\u00f3n de riesgo de calidad para sistemas complejos como los ERP?**\n   - Respuesta: Se deben considerar los requisitos para decidir sobre los niveles de impacto en los procesos de negocio, los procedimientos para llevar a cabo la evaluaci\u00f3n y el estado actual del proceso, reconociendo que esta evaluaci\u00f3n puede ser repetida y actualizada.\n\n3. **\u00bfQu\u00e9 papel desempe\u00f1an los expertos en la materia (SME) en el proceso de validaci\u00f3n de sistemas y cu\u00e1les son algunas de sus responsabilidades espec\u00edficas?**\n   - Respuesta: Los SME son individuos con experiencia espec\u00edfica en \u00e1reas como an\u00e1lisis cromatogr\u00e1fico o ingenier\u00eda. Sus responsabilidades incluyen la planificaci\u00f3n y definici\u00f3n de estrategias de verificaci\u00f3n del sistema, realizaci\u00f3n de revisiones, definici\u00f3n de criterios de aceptaci\u00f3n, selecci\u00f3n de m\u00e9todos de prueba apropiados, ejecuci\u00f3n de pruebas de verificaci\u00f3n y revisi\u00f3n de resultados.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\nLa secci\u00f3n del documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos se centra en la importancia de un plan de validaci\u00f3n bien estructurado. A continuaci\u00f3n se presentan los temas clave y las entidades mencionadas:\n\n#### Temas Clave:\n1. **Plan de Validaci\u00f3n**: Es fundamental para describir el proyecto, las acciones necesarias para la validaci\u00f3n y los criterios de aceptaci\u00f3n.\n2. **Elementos a Definir**:\n   - Actividades necesarias.\n   - M\u00e9todos de ejecuci\u00f3n y responsables.\n   - Resultados esperados.\n   - Criterios de aceptaci\u00f3n.\n   - Mantenimiento de la conformidad a lo largo de la vida del sistema.\n3. **Inicio Temprano de la Planificaci\u00f3n**: Se recomienda comenzar la planificaci\u00f3n durante la fase de desarrollo de los requisitos del usuario para asegurar una validaci\u00f3n efectiva.\n4. **Contenido del Plan**:\n   - Introducci\u00f3n y alcance.\n   - Descripci\u00f3n general del sistema.\n   - Estructura organizativa.\n5. **Roles y Responsabilidades**: El Plan de Validaci\u00f3n es responsabilidad del Propietario del Proceso, con posibilidad de delegaci\u00f3n al Gerente de Proyecto.\n\n#### Entidades:\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil, responsable de la regulaci\u00f3n.\n- **Propietario del Proceso**: Principal responsable de la elaboraci\u00f3n del plan de validaci\u00f3n.\n- **Gerente de Proyecto**: Puede ser delegado para ayudar en la creaci\u00f3n del plan.\n- **Propietario del Proyecto**: Puede estar involucrado en el proceso de validaci\u00f3n.\n\nEste resumen destaca la estructura y los componentes esenciales que deben considerarse al desarrollar un plan de validaci\u00f3n para sistemas inform\u00e1ticos, as\u00ed como la importancia de la planificaci\u00f3n anticipada y la claridad en roles y responsabilidades.", "excerpt_keywords": "Keywords: validation, quality risk management, project management, regulatory compliance, subject matter experts"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "b06664d2-716f-4168-8e50-e517dc380321", "node_type": "4", "metadata": {"page_label": "27", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "- Project manager;\n- Project planning and management;\n- Control of project activities, resources and costs;\n- Monitoring the progress of the work and initiation of CAPA;\n- Ensure that the problems and objectives of the project are resolved and met;\n- Manage quality deviations involving the system:\n- Respond to the sponsor or top management;\n- Ensure system compliance in conjunction with the Quality Unit.\n- Quality Unit;\n- Ensuring system compliance with regulatory, quality and policy requirements company;\n- Provide support for the review and approval of the results generated by the validation work;\n- Evaluation and approval of closing quality deviations;\n- Approval of the system release for use.\n- Process Owner and / or System Owner\n- System deployment and management by the community of system users;\n- Approval of each stage of the validation process.\n\nSubject matter experts (SME) are those individuals with specific *expertise* and responsibility in a particular area or field, for example, chromatographic analysis, quality unit, engineering, automation, development, etc.\n\nThe responsibilities of these experts may include: planning and defining verification strategies of the system; performing reviews; definition of acceptance criteria; selection of method tests appropriate; execution of verification tests and review of the results.\n\n## 9.2.2.4 Quality Risk Management\n\nThe approach used to manage quality risk should be described.\n\nA risk assessment must be performed based on an understanding of the business processes, requirements of the regulatory requirements and known functional areas. The results obtained must include a decision on whether the system is relevant to GMP and a general assessment of the impact of the system.\n\nComplex systems, such as ERP-type systems, may have some features that are relevant to GMP and others that are not. In such cases, the method used to make such a decision should be described and should consider the following points:\n\n- The requirements for deciding on the impact levels on BPx;\n- The procedures for carrying out the assessment;\n- The current status of the process, recognizing that this assessment can be repeated and updated.\n\nAny specific procedures or standards used to perform quality risk management must be defined.\n\n## 9.2.2.5 Validation Strategy\n\nThe strategy to be used for system validation should be described, based on the following considerations:", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "fb513a1d37a9fa9c3899dcdaa72a05d8c4c013660d31d4d82f127088b0cf0292", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "- Project manager;\n- Project planning and management;\n- Control of project activities, resources and costs;\n- Monitoring the progress of the work and initiation of CAPA;\n- Ensure that the problems and objectives of the project are resolved and met;\n- Manage quality deviations involving the system:\n- Respond to the sponsor or top management;\n- Ensure system compliance in conjunction with the Quality Unit.\n- Quality Unit;\n- Ensuring system compliance with regulatory, quality and policy requirements company;\n- Provide support for the review and approval of the results generated by the validation work;\n- Evaluation and approval of closing quality deviations;\n- Approval of the system release for use.\n- Process Owner and / or System Owner\n- System deployment and management by the community of system users;\n- Approval of each stage of the validation process.\n\nSubject matter experts (SME) are those individuals with specific *expertise* and responsibility in a particular area or field, for example, chromatographic analysis, quality unit, engineering, automation, development, etc.\n\nThe responsibilities of these experts may include: planning and defining verification strategies of the system; performing reviews; definition of acceptance criteria; selection of method tests appropriate; execution of verification tests and review of the results.\n\n## 9.2.2.4 Quality Risk Management\n\nThe approach used to manage quality risk should be described.\n\nA risk assessment must be performed based on an understanding of the business processes, requirements of the regulatory requirements and known functional areas. The results obtained must include a decision on whether the system is relevant to GMP and a general assessment of the impact of the system.\n\nComplex systems, such as ERP-type systems, may have some features that are relevant to GMP and others that are not. In such cases, the method used to make such a decision should be described and should consider the following points:\n\n- The requirements for deciding on the impact levels on BPx;\n- The procedures for carrying out the assessment;\n- The current status of the process, recognizing that this assessment can be repeated and updated.\n\nAny specific procedures or standards used to perform quality risk management must be defined.\n\n## 9.2.2.5 Validation Strategy\n\nThe strategy to be used for system validation should be described, based on the following considerations:", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 2433, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "ce8294e8-23e5-41b3-ba42-4cb5c9672a7e": {"__data__": {"id_": "ce8294e8-23e5-41b3-ba42-4cb5c9672a7e", "embedding": null, "metadata": {"page_label": "28", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# Guide for Computer Systems Validation\n\n- Risk assessment;\n- Evaluation of the system components and their architecture;\n- Supplier assessment.\n\nThe key conclusions of any evaluation carried out must be formalized.\n\nAny specific procedures or standards used must be defined.\n\nThe validation strategy should include:\n- The life cycle model;\n- The system's *hardware and software* categories;\n- The requirements and results required for each stage of the project;\n- The acceptance criteria for each stage;\n- Approach used to ensure the traceability of data and documents;\n- Approach used to review the project.\n\n## 9.2.2.6 Expected Results\n\nThe results to be produced should be listed, including the responsibility for production (of documents, tests, results), review and approval.\n\n## 9.2.2.7 Acceptance Criteria\n\nThe general acceptance criteria for the system, such as the successful execution of a defined stage of the project, should be described.\n\n## 9.2.2.8 Change Control\n\nThe requirements for project change control should be defined, including reference to the relevant procedures.\n\nThe stage at which operational change control will be applied must be defined.\n\n## 9.2.2.9 Standard Operating Procedures\n\nStandard operating procedures (SOPs) that will be created or updated as a result of the deployment of the system must be defined and the responsibilities for its elaboration, revision and approval defined.\n\n## 9.2.2.10 Auxiliary Processes\n\nDetails of ancillary processes should be defined or referenced, including, but not limited to:\n- Training;\n- Documentation management;", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas que pueden proporcionar respuestas espec\u00edficas basadas en el contexto del documento sobre la validaci\u00f3n de sistemas inform\u00e1ticos de ANVISA:\n\n1. **\u00bfCu\u00e1les son los elementos clave que deben incluirse en la estrategia de validaci\u00f3n seg\u00fan la gu\u00eda de ANVISA?**\n   - Respuesta: La estrategia de validaci\u00f3n debe incluir el modelo de ciclo de vida, las categor\u00edas de hardware y software del sistema, los requisitos y resultados necesarios para cada etapa del proyecto, los criterios de aceptaci\u00f3n para cada etapa, el enfoque para asegurar la trazabilidad de datos y documentos, y el enfoque utilizado para revisar el proyecto.\n\n2. **\u00bfQu\u00e9 se debe considerar al definir los criterios de aceptaci\u00f3n para un sistema en el contexto de la validaci\u00f3n?**\n   - Respuesta: Los criterios de aceptaci\u00f3n deben describir los criterios generales para el sistema, como la ejecuci\u00f3n exitosa de una etapa definida del proyecto, asegurando que se cumplan los requisitos establecidos.\n\n3. **\u00bfQu\u00e9 procedimientos deben ser establecidos en relaci\u00f3n con el control de cambios en un proyecto de validaci\u00f3n de sistemas?**\n   - Respuesta: Se deben definir los requisitos para el control de cambios del proyecto, incluyendo la referencia a los procedimientos relevantes, as\u00ed como la etapa en la que se aplicar\u00e1 el control de cambios operacionales.\n\n### Resumen de nivel superior del contexto:\nEl documento de ANVISA proporciona directrices sobre la validaci\u00f3n de sistemas inform\u00e1ticos, enfatizando la importancia de la evaluaci\u00f3n de riesgos, la arquitectura del sistema y la evaluaci\u00f3n de proveedores. Se detalla la necesidad de formalizar conclusiones de evaluaciones, definir procedimientos espec\u00edficos y establecer una estrategia de validaci\u00f3n que abarque el ciclo de vida del sistema, criterios de aceptaci\u00f3n, control de cambios y procedimientos operativos est\u00e1ndar. Adem\u00e1s, se menciona la importancia de los procesos auxiliares como la capacitaci\u00f3n y la gesti\u00f3n de documentaci\u00f3n.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos aborda varios aspectos fundamentales relacionados con la gesti\u00f3n de proyectos de validaci\u00f3n, la gesti\u00f3n de riesgos de calidad y la estrategia de validaci\u00f3n. A continuaci\u00f3n se presentan los temas clave y las entidades mencionadas:\n\n#### Temas Clave\n\n1. **Roles y Responsabilidades**:\n   - **Gerente de Proyecto**: Encargado de la planificaci\u00f3n, gesti\u00f3n de actividades, recursos y costos, monitoreo del progreso, gesti\u00f3n de desviaciones de calidad y aseguramiento del cumplimiento del sistema.\n   - **Unidad de Calidad**: Asegura el cumplimiento de requisitos regulatorios y de calidad, apoya la revisi\u00f3n y aprobaci\u00f3n de resultados de validaci\u00f3n, y eval\u00faa y aprueba desviaciones de calidad.\n   - **Expertos en la Materia (SME)**: Profesionales con experiencia espec\u00edfica que participan en la planificaci\u00f3n de estrategias de verificaci\u00f3n, realizaci\u00f3n de revisiones, definici\u00f3n de criterios de aceptaci\u00f3n y ejecuci\u00f3n de pruebas de verificaci\u00f3n.\n\n2. **Gesti\u00f3n de Riesgos de Calidad**:\n   - Importancia de realizar evaluaciones de riesgo basadas en procesos comerciales y requisitos regulatorios.\n   - Evaluaci\u00f3n del impacto del sistema en relaci\u00f3n con las Buenas Pr\u00e1cticas de Manufactura (GMP).\n   - Consideraciones para sistemas complejos como los ERP, incluyendo la repetibilidad y actualizaci\u00f3n de las evaluaciones.\n\n3. **Estrategia de Validaci\u00f3n**:\n   - Necesidad de definir una estrategia de validaci\u00f3n adecuada que contemple las caracter\u00edsticas espec\u00edficas del sistema y su relevancia para los procesos de negocio.\n\n#### Entidades\n\n- **Gerente de Proyecto**: Responsable de la gesti\u00f3n del proyecto de validaci\u00f3n.\n- **Unidad de Calidad**: Asegura el cumplimiento normativo y de calidad.\n- **Expertos en la Materia (SME)**: Proporcionan conocimientos especializados en \u00e1reas espec\u00edficas.\n- **Sistemas ERP**: Ejemplo de sistemas complejos que requieren una evaluaci\u00f3n cuidadosa en el contexto de GMP.\n\nEste resumen destaca la estructura organizativa y los procesos necesarios para llevar a cabo una validaci\u00f3n efectiva de sistemas inform\u00e1ticos, enfatizando la colaboraci\u00f3n entre diferentes roles y la importancia de la gesti\u00f3n de riesgos.", "excerpt_keywords": "Keywords: validation, risk assessment, acceptance criteria, change control, standard operating procedures"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "f582481a-ebdc-4a01-bb07-47b6e4aea29f", "node_type": "4", "metadata": {"page_label": "28", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# Guide for Computer Systems Validation\n\n- Risk assessment;\n- Evaluation of the system components and their architecture;\n- Supplier assessment.\n\nThe key conclusions of any evaluation carried out must be formalized.\n\nAny specific procedures or standards used must be defined.\n\nThe validation strategy should include:\n- The life cycle model;\n- The system's *hardware and software* categories;\n- The requirements and results required for each stage of the project;\n- The acceptance criteria for each stage;\n- Approach used to ensure the traceability of data and documents;\n- Approach used to review the project.\n\n## 9.2.2.6 Expected Results\n\nThe results to be produced should be listed, including the responsibility for production (of documents, tests, results), review and approval.\n\n## 9.2.2.7 Acceptance Criteria\n\nThe general acceptance criteria for the system, such as the successful execution of a defined stage of the project, should be described.\n\n## 9.2.2.8 Change Control\n\nThe requirements for project change control should be defined, including reference to the relevant procedures.\n\nThe stage at which operational change control will be applied must be defined.\n\n## 9.2.2.9 Standard Operating Procedures\n\nStandard operating procedures (SOPs) that will be created or updated as a result of the deployment of the system must be defined and the responsibilities for its elaboration, revision and approval defined.\n\n## 9.2.2.10 Auxiliary Processes\n\nDetails of ancillary processes should be defined or referenced, including, but not limited to:\n- Training;\n- Documentation management;", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "61a345c33c70462adc20152f15ae045df7a227d693b7055918b99c0530dfbb5c", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "# Guide for Computer Systems Validation\n\n- Risk assessment;\n- Evaluation of the system components and their architecture;\n- Supplier assessment.\n\nThe key conclusions of any evaluation carried out must be formalized.\n\nAny specific procedures or standards used must be defined.\n\nThe validation strategy should include:\n- The life cycle model;\n- The system's *hardware and software* categories;\n- The requirements and results required for each stage of the project;\n- The acceptance criteria for each stage;\n- Approach used to ensure the traceability of data and documents;\n- Approach used to review the project.\n\n## 9.2.2.6 Expected Results\n\nThe results to be produced should be listed, including the responsibility for production (of documents, tests, results), review and approval.\n\n## 9.2.2.7 Acceptance Criteria\n\nThe general acceptance criteria for the system, such as the successful execution of a defined stage of the project, should be described.\n\n## 9.2.2.8 Change Control\n\nThe requirements for project change control should be defined, including reference to the relevant procedures.\n\nThe stage at which operational change control will be applied must be defined.\n\n## 9.2.2.9 Standard Operating Procedures\n\nStandard operating procedures (SOPs) that will be created or updated as a result of the deployment of the system must be defined and the responsibilities for its elaboration, revision and approval defined.\n\n## 9.2.2.10 Auxiliary Processes\n\nDetails of ancillary processes should be defined or referenced, including, but not limited to:\n- Training;\n- Documentation management;", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 1588, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "aee154af-6447-48ca-9b55-47fc6442b3d3": {"__data__": {"id_": "aee154af-6447-48ca-9b55-47fc6442b3d3", "embedding": null, "metadata": {"page_label": "29", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "- Configuration management;\n- Maintaining your validated status.\n\n## 9.2.2.11 Glossary\n\nDefinitions of any terms and abbreviations that may be little known should be included.\n\n## 9.3 DOCUMENT CONTAINING USER REQUIREMENTS SPECIFICATIONS (ERU / URS)\n\n### 9.3.1 Introduction\n\nThe User Requirements Specifications (ERU / URS) document defines the requirements for a system computerized system component.\n\nThe length and detail of this document must be commensurate with risk, innovation and system complexity and must be sufficient to support subsequent risk analysis activities, specification, configuration / design and verification, if necessary.\n\nFor a low risk and commercially available system, it may be appropriate to include this document in the purchase documentation of the system, while for a complex and customized application can be Several levels of specification are required.\n\nThe ERU / URS document is the responsibility of the regulated company, but it can be written by a company outsourced or by the system supplier.\n\nThe User Requirements Specifications (ERU / URS) document clearly and precisely defines what the regulated company wants the system to do. It is driven by the needs of the business process.\n\nFor category 4 and 5 systems the requirements must be developed independently from the solutions available on the market.\n\nFor category 3 systems, in particular, there may be a limited number of suppliers or even a preferred supplier for a particular type of system, which justifies the use of solutions available in the market.\n\nThe requirements must cover the following points, and may include others that are not listed:\n\n- Operational;\n- Functional;\n- Dice;\n- Technical;\n- *Interface*;\n- Environmental;\n- Performance;\n- Availability;", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas basadas en el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas computacionales establece directrices para la creaci\u00f3n de un documento de Especificaciones de Requisitos del Usuario (ERU / URS). Este documento debe definir claramente los requisitos de un componente del sistema computarizado, considerando factores como el riesgo, la innovaci\u00f3n y la complejidad del sistema. La responsabilidad de elaborar este documento recae en la empresa regulada, aunque puede ser redactado por un tercero o el proveedor del sistema. Adem\u00e1s, se especifican diferentes categor\u00edas de sistemas y c\u00f3mo deben desarrollarse los requisitos en funci\u00f3n de estas categor\u00edas.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfQu\u00e9 factores deben considerarse al determinar la longitud y el nivel de detalle del documento ERU / URS?**\n   - La longitud y el detalle del documento deben ser proporcionales al riesgo, la innovaci\u00f3n y la complejidad del sistema, y deben ser suficientes para respaldar actividades posteriores de an\u00e1lisis de riesgos, especificaci\u00f3n, configuraci\u00f3n/dise\u00f1o y verificaci\u00f3n.\n\n2. **\u00bfQui\u00e9n es responsable de la elaboraci\u00f3n del documento ERU / URS y qui\u00e9n puede redactarlo?**\n   - La responsabilidad de elaborar el documento ERU / URS recae en la empresa regulada, pero puede ser redactado por una empresa externa o por el proveedor del sistema.\n\n3. **\u00bfCu\u00e1les son los puntos clave que deben cubrirse en los requisitos del documento ERU / URS?**\n   - Los requisitos deben cubrir aspectos operacionales, funcionales, t\u00e9cnicos, de interfaz, ambientales, de rendimiento y de disponibilidad, entre otros que puedan ser relevantes.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Evaluaci\u00f3n de Riesgos**: Importancia de identificar y evaluar riesgos asociados con el sistema inform\u00e1tico.\n\n2. **Evaluaci\u00f3n de Componentes del Sistema**: An\u00e1lisis de la arquitectura y los componentes del sistema para asegurar su adecuaci\u00f3n.\n\n3. **Evaluaci\u00f3n de Proveedores**: Consideraci\u00f3n de la capacidad y fiabilidad de los proveedores involucrados en el sistema.\n\n4. **Formalizaci\u00f3n de Conclusiones**: Necesidad de documentar y formalizar las conclusiones de las evaluaciones realizadas.\n\n5. **Estrategia de Validaci\u00f3n**:\n   - **Modelo de Ciclo de Vida**: Definici\u00f3n del enfoque a seguir durante el desarrollo del sistema.\n   - **Categor\u00edas de Hardware y Software**: Clasificaci\u00f3n de los componentes del sistema.\n   - **Requisitos y Resultados**: Especificaci\u00f3n de lo que se necesita lograr en cada etapa del proyecto.\n   - **Criterios de Aceptaci\u00f3n**: Establecimiento de los est\u00e1ndares para considerar una etapa como exitosa.\n   - **Trazabilidad**: M\u00e9todos para asegurar que los datos y documentos sean rastreables.\n   - **Revisi\u00f3n del Proyecto**: Enfoque para evaluar el progreso y la calidad del proyecto.\n\n6. **Resultados Esperados**: Listado de los resultados que deben producirse, junto con las responsabilidades de producci\u00f3n, revisi\u00f3n y aprobaci\u00f3n.\n\n7. **Criterios de Aceptaci\u00f3n**: Descripci\u00f3n de los criterios generales que determinan el \u00e9xito de cada etapa del proyecto.\n\n8. **Control de Cambios**: Definici\u00f3n de los requisitos y procedimientos para gestionar cambios en el proyecto, as\u00ed como la etapa en la que se aplicar\u00e1 el control de cambios operacionales.\n\n9. **Procedimientos Operativos Est\u00e1ndar (SOPs)**: Creaci\u00f3n o actualizaci\u00f3n de SOPs como resultado de la implementaci\u00f3n del sistema, incluyendo responsabilidades para su elaboraci\u00f3n, revisi\u00f3n y aprobaci\u00f3n.\n\n10. **Procesos Auxiliares**: Detalles sobre procesos complementarios, como capacitaci\u00f3n y gesti\u00f3n de documentaci\u00f3n, que son esenciales para el \u00e9xito del sistema.\n\n### Entidades Clave\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil.\n- **Sistema Inform\u00e1tico**: Conjunto de hardware y software que requiere validaci\u00f3n.\n- **Proveedores**: Entidades que suministran componentes o servicios para el sistema.\n- **Documentaci\u00f3n**: Registros y documentos que deben ser producidos y gestionados durante el proceso de validaci\u00f3n.", "excerpt_keywords": "Keywords: validation, user requirements, specifications, risk analysis, regulatory compliance"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "e6359bf0-11b9-42e5-9008-8bd9933a81a9", "node_type": "4", "metadata": {"page_label": "29", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "- Configuration management;\n- Maintaining your validated status.\n\n## 9.2.2.11 Glossary\n\nDefinitions of any terms and abbreviations that may be little known should be included.\n\n## 9.3 DOCUMENT CONTAINING USER REQUIREMENTS SPECIFICATIONS (ERU / URS)\n\n### 9.3.1 Introduction\n\nThe User Requirements Specifications (ERU / URS) document defines the requirements for a system computerized system component.\n\nThe length and detail of this document must be commensurate with risk, innovation and system complexity and must be sufficient to support subsequent risk analysis activities, specification, configuration / design and verification, if necessary.\n\nFor a low risk and commercially available system, it may be appropriate to include this document in the purchase documentation of the system, while for a complex and customized application can be Several levels of specification are required.\n\nThe ERU / URS document is the responsibility of the regulated company, but it can be written by a company outsourced or by the system supplier.\n\nThe User Requirements Specifications (ERU / URS) document clearly and precisely defines what the regulated company wants the system to do. It is driven by the needs of the business process.\n\nFor category 4 and 5 systems the requirements must be developed independently from the solutions available on the market.\n\nFor category 3 systems, in particular, there may be a limited number of suppliers or even a preferred supplier for a particular type of system, which justifies the use of solutions available in the market.\n\nThe requirements must cover the following points, and may include others that are not listed:\n\n- Operational;\n- Functional;\n- Dice;\n- Technical;\n- *Interface*;\n- Environmental;\n- Performance;\n- Availability;", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "f96d4647c8e9a4e6611ed42fe2e2340ea819d9e06583ad9088de665182519751", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "- Configuration management;\n- Maintaining your validated status.\n\n## 9.2.2.11 Glossary\n\nDefinitions of any terms and abbreviations that may be little known should be included.\n\n## 9.3 DOCUMENT CONTAINING USER REQUIREMENTS SPECIFICATIONS (ERU / URS)\n\n### 9.3.1 Introduction\n\nThe User Requirements Specifications (ERU / URS) document defines the requirements for a system computerized system component.\n\nThe length and detail of this document must be commensurate with risk, innovation and system complexity and must be sufficient to support subsequent risk analysis activities, specification, configuration / design and verification, if necessary.\n\nFor a low risk and commercially available system, it may be appropriate to include this document in the purchase documentation of the system, while for a complex and customized application can be Several levels of specification are required.\n\nThe ERU / URS document is the responsibility of the regulated company, but it can be written by a company outsourced or by the system supplier.\n\nThe User Requirements Specifications (ERU / URS) document clearly and precisely defines what the regulated company wants the system to do. It is driven by the needs of the business process.\n\nFor category 4 and 5 systems the requirements must be developed independently from the solutions available on the market.\n\nFor category 3 systems, in particular, there may be a limited number of suppliers or even a preferred supplier for a particular type of system, which justifies the use of solutions available in the market.\n\nThe requirements must cover the following points, and may include others that are not listed:\n\n- Operational;\n- Functional;\n- Dice;\n- Technical;\n- *Interface*;\n- Environmental;\n- Performance;\n- Availability;", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 1764, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "7251ee91-e46f-4db2-8a48-a07e76aaa196": {"__data__": {"id_": "7251ee91-e46f-4db2-8a48-a07e76aaa196", "embedding": null, "metadata": {"page_label": "30", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# Guide for Computer Systems Validation\n\n- Safety;\n- Maintenance;\n- Regulatory;\n- Migration of any electronic data;\n\n## Page 28\n\n- Restrictions to be observed;\n- Life cycle.\n\nThe requirements should address applicable BPx regulations and highlight aspects that are critical to the patient safety, product quality and data integrity. The ERU document must not include requirements such as \"meets 21CFR Part 11\" or \"meets Anvisa legislation\" and to define what functionality the system must have to manage the risk to patient safety, product quality and integrity of the data.\n\nThe requirements must have the following characteristics:\n\n- Sufficient and adequate (Specific; Measurable, Attainable; Realistic; Testable);\n- Specific enough to carry out tests and verifications (Unequivocal; Clear; Precise; Complete);\n- Able to assist traceability along the requirement chain \u2192 configuration / design \u2192 test;\n- Provide the basis for formal testing and be used for supplier selection;\n- Prioritized with an emphasis on identifying mandatory requirements. The approach can be used three levels of priority, described below:\n- \u2713 Mandatory (high);\n- \u2713 Beneficial (average);\n- \u2713 Good to have (low).\n- Uniquely identified, with controlled version and maintenance of its control; Able to be used as a means of communication and management of critical requirements throughout the life cycle of the system rather than just an exercise;\n- Provide the system supplier with the definitive statement of mandatory and desirable requirements.\n\nThe ownership of the requirements belongs to the regulated company. The operational needs of the business and any associated problems can never be fully understood and captured without the effective participation of system users. Documented requirements form the basis for system acceptance by users.\n\n## 9.3.2 Content of the ERU / URS Document\n\n### 9.3.2.1 Introduction\n\nThe introduction item should provide information on:\n\n- Who produced the document, under what authority and for what purpose;\n- The contractual status of the document (if applicable), such as custom development or outsourced;", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas que pueden proporcionar respuestas espec\u00edficas basadas en el contexto proporcionado, as\u00ed como un resumen de nivel superior del contenido:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos establece directrices sobre c\u00f3mo formular requisitos para sistemas regulados en el \u00e1mbito de la salud. Se enfatiza la importancia de que los requisitos sean espec\u00edficos, medibles y priorizados, y que reflejen aspectos cr\u00edticos para la seguridad del paciente, la calidad del producto y la integridad de los datos. Adem\u00e1s, se menciona que la propiedad de los requisitos recae en la empresa regulada y que la participaci\u00f3n de los usuarios del sistema es esencial para comprender las necesidades operativas.\n\n### Preguntas\n1. **\u00bfCu\u00e1les son las caracter\u00edsticas clave que deben tener los requisitos seg\u00fan el documento de ANVISA?**\n   - Respuesta: Los requisitos deben ser espec\u00edficos, medibles, alcanzables, realistas y verificables; claros y completos; facilitar la trazabilidad; servir como base para pruebas formales y selecci\u00f3n de proveedores; estar priorizados; identificados de manera \u00fanica y controlados; y proporcionar una declaraci\u00f3n definitiva de requisitos obligatorios y deseables al proveedor del sistema.\n\n2. **\u00bfQu\u00e9 aspectos cr\u00edticos deben ser abordados en los requisitos para garantizar la seguridad del paciente y la calidad del producto?**\n   - Respuesta: Los requisitos deben abordar regulaciones aplicables y resaltar aspectos cr\u00edticos para la seguridad del paciente, la calidad del producto y la integridad de los datos, evitando incluir requisitos gen\u00e9ricos como \"cumple con 21CFR Part 11\" o \"cumple con la legislaci\u00f3n de Anvisa\".\n\n3. **\u00bfCu\u00e1l es la importancia de la participaci\u00f3n de los usuarios del sistema en la formulaci\u00f3n de requisitos?**\n   - Respuesta: La participaci\u00f3n efectiva de los usuarios del sistema es crucial para comprender y capturar completamente las necesidades operativas del negocio y los problemas asociados, lo que a su vez forma la base para la aceptaci\u00f3n del sistema por parte de los usuarios.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Especificaciones de Requisitos del Usuario (ERU / URS)**:\n   - Documento que define los requisitos para un componente de sistema computarizado.\n   - Debe ser proporcional al riesgo, innovaci\u00f3n y complejidad del sistema.\n\n2. **Responsabilidad**:\n   - La elaboraci\u00f3n del documento es responsabilidad de la empresa regulada, aunque puede ser redactado por un tercero o el proveedor del sistema.\n\n3. **Categor\u00edas de Sistemas**:\n   - **Categor\u00edas 4 y 5**: Los requisitos deben desarrollarse independientemente de las soluciones disponibles en el mercado.\n   - **Categor\u00eda 3**: Puede haber un n\u00famero limitado de proveedores, lo que justifica el uso de soluciones comerciales.\n\n4. **Puntos Clave a Cubrir en el Documento ERU / URS**:\n   - Requisitos operacionales.\n   - Requisitos funcionales.\n   - Requisitos t\u00e9cnicos.\n   - Requisitos de interfaz.\n   - Requisitos ambientales.\n   - Requisitos de rendimiento.\n   - Requisitos de disponibilidad.\n\n5. **Importancia del Documento**:\n   - Debe ser suficiente para respaldar actividades de an\u00e1lisis de riesgos, especificaci\u00f3n, configuraci\u00f3n/dise\u00f1o y verificaci\u00f3n.\n\n### Entidades Clave\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil.\n- **ERU / URS**: Especificaciones de Requisitos del Usuario.\n- **Categor\u00edas de Sistemas**: Clasificaci\u00f3n de sistemas seg\u00fan su riesgo y complejidad. \n\nEste resumen destaca los aspectos fundamentales y las entidades relevantes en la secci\u00f3n sobre las Especificaciones de Requisitos del Usuario en el contexto de la validaci\u00f3n de sistemas computacionales seg\u00fan ANVISA.", "excerpt_keywords": "Keywords: validation, requirements, patient safety, data integrity, ANVISA"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "173bccdd-a95d-433a-b7ba-46be0d9f78db", "node_type": "4", "metadata": {"page_label": "30", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# Guide for Computer Systems Validation\n\n- Safety;\n- Maintenance;\n- Regulatory;\n- Migration of any electronic data;\n\n## Page 28\n\n- Restrictions to be observed;\n- Life cycle.\n\nThe requirements should address applicable BPx regulations and highlight aspects that are critical to the patient safety, product quality and data integrity. The ERU document must not include requirements such as \"meets 21CFR Part 11\" or \"meets Anvisa legislation\" and to define what functionality the system must have to manage the risk to patient safety, product quality and integrity of the data.\n\nThe requirements must have the following characteristics:\n\n- Sufficient and adequate (Specific; Measurable, Attainable; Realistic; Testable);\n- Specific enough to carry out tests and verifications (Unequivocal; Clear; Precise; Complete);\n- Able to assist traceability along the requirement chain \u2192 configuration / design \u2192 test;\n- Provide the basis for formal testing and be used for supplier selection;\n- Prioritized with an emphasis on identifying mandatory requirements. The approach can be used three levels of priority, described below:\n- \u2713 Mandatory (high);\n- \u2713 Beneficial (average);\n- \u2713 Good to have (low).\n- Uniquely identified, with controlled version and maintenance of its control; Able to be used as a means of communication and management of critical requirements throughout the life cycle of the system rather than just an exercise;\n- Provide the system supplier with the definitive statement of mandatory and desirable requirements.\n\nThe ownership of the requirements belongs to the regulated company. The operational needs of the business and any associated problems can never be fully understood and captured without the effective participation of system users. Documented requirements form the basis for system acceptance by users.\n\n## 9.3.2 Content of the ERU / URS Document\n\n### 9.3.2.1 Introduction\n\nThe introduction item should provide information on:\n\n- Who produced the document, under what authority and for what purpose;\n- The contractual status of the document (if applicable), such as custom development or outsourced;", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "0ecff65c529e53845b944d5a001ea39e5f5741caab169da2d2c4ef25c1440a6e", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "# Guide for Computer Systems Validation\n\n- Safety;\n- Maintenance;\n- Regulatory;\n- Migration of any electronic data;\n\n## Page 28\n\n- Restrictions to be observed;\n- Life cycle.\n\nThe requirements should address applicable BPx regulations and highlight aspects that are critical to the patient safety, product quality and data integrity. The ERU document must not include requirements such as \"meets 21CFR Part 11\" or \"meets Anvisa legislation\" and to define what functionality the system must have to manage the risk to patient safety, product quality and integrity of the data.\n\nThe requirements must have the following characteristics:\n\n- Sufficient and adequate (Specific; Measurable, Attainable; Realistic; Testable);\n- Specific enough to carry out tests and verifications (Unequivocal; Clear; Precise; Complete);\n- Able to assist traceability along the requirement chain \u2192 configuration / design \u2192 test;\n- Provide the basis for formal testing and be used for supplier selection;\n- Prioritized with an emphasis on identifying mandatory requirements. The approach can be used three levels of priority, described below:\n- \u2713 Mandatory (high);\n- \u2713 Beneficial (average);\n- \u2713 Good to have (low).\n- Uniquely identified, with controlled version and maintenance of its control; Able to be used as a means of communication and management of critical requirements throughout the life cycle of the system rather than just an exercise;\n- Provide the system supplier with the definitive statement of mandatory and desirable requirements.\n\nThe ownership of the requirements belongs to the regulated company. The operational needs of the business and any associated problems can never be fully understood and captured without the effective participation of system users. Documented requirements form the basis for system acceptance by users.\n\n## 9.3.2 Content of the ERU / URS Document\n\n### 9.3.2.1 Introduction\n\nThe introduction item should provide information on:\n\n- Who produced the document, under what authority and for what purpose;\n- The contractual status of the document (if applicable), such as custom development or outsourced;", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 2122, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "05d76d05-cf6a-4b68-a9f9-ea6f174fd999": {"__data__": {"id_": "05d76d05-cf6a-4b68-a9f9-ea6f174fd999", "embedding": null, "metadata": {"page_label": "31", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 9.3.2.2 Overview\n\nAn overview of the system should be provided, explaining why the system is needed and what is required of the system. The following points should be considered:\n\n- **Contextualization**: describes the general objective of the system in the current context and the desired situation;\n\n## Scope\n\n- The insertion of the system in the company's long-term vision;\n- System boundaries and boundaries: what part of the business process is being automated;\n- Key objectives and benefits;\n- BPx requirements applicable;\n- Other applicable regulations.\n\n# 9.3.2.3 Operational Requirements\n\nOperational requirements include:\n\n- **Functions** - are the functional requirements that enable the system to execute the business process that is being automated, such as:\n- Calculations, including all critical algorithms;\n- Safety against damage;\n- Security including access control;\n- Audit trails;\n- Use of electronic signatures;\n- Outputs (e.g., reports);\n- Clear error messages.\n\n- **Data** - requirements related to data handling, considering its impact on security, patient, product quality and data integrity, covering the following points:\n- Definition of electronic records;\n- Definition of data types, including identification of characteristics, formatting, critical parameters, valid date range and format, limits and accuracy, and so on;\n- Where and how data will be recorded (e.g., relational databases, files encrypted, etc.)\n- Required fields;\n- Data migration (import and export);\n- Data entry and subsequent editing;\n- Backup and recovery;\n- Archiving requirements;", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas que pueden proporcionar respuestas espec\u00edficas basadas en el contexto proporcionado, as\u00ed como un resumen de nivel superior del contenido:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos establece directrices para la creaci\u00f3n de un sistema que cumpla con los requisitos operativos y de datos necesarios para automatizar procesos empresariales en el sector de la salud. Se enfatiza la importancia de contextualizar el sistema dentro de la visi\u00f3n a largo plazo de la empresa, as\u00ed como la necesidad de definir claramente los requisitos funcionales y de manejo de datos para garantizar la seguridad, la integridad de los datos y el cumplimiento normativo.\n\n### Preguntas\n\n1. **\u00bfCu\u00e1les son los elementos clave que deben incluirse en la contextualizaci\u00f3n del sistema para asegurar su alineaci\u00f3n con la visi\u00f3n a largo plazo de la empresa?**\n   - Esta pregunta busca respuestas espec\u00edficas sobre c\u00f3mo se debe articular la relaci\u00f3n entre el sistema y los objetivos estrat\u00e9gicos de la empresa, lo que no se detalla en otros documentos.\n\n2. **\u00bfQu\u00e9 consideraciones espec\u00edficas deben tenerse en cuenta al definir los requisitos de datos para garantizar la integridad y seguridad de la informaci\u00f3n en el sistema?**\n   - Aqu\u00ed se busca profundizar en los aspectos t\u00e9cnicos y normativos que afectan la gesti\u00f3n de datos, lo que puede no estar claramente especificado en otras gu\u00edas o documentos.\n\n3. **\u00bfC\u00f3mo se deben abordar las necesidades de auditor\u00eda y control de acceso en el dise\u00f1o del sistema para cumplir con las regulaciones aplicables?**\n   - Esta pregunta se centra en los requisitos de seguridad y auditor\u00eda, que son cr\u00edticos para la validaci\u00f3n de sistemas en el sector de la salud, y que pueden no estar suficientemente cubiertos en otras fuentes de informaci\u00f3n. \n\nEstas preguntas est\u00e1n dise\u00f1adas para extraer informaci\u00f3n detallada y espec\u00edfica que es crucial para la implementaci\u00f3n y validaci\u00f3n de sistemas inform\u00e1ticos en el contexto regulatorio de Brasil.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos aborda varios temas clave relacionados con la formulaci\u00f3n de requisitos para sistemas regulados en el \u00e1mbito de la salud. A continuaci\u00f3n se presentan los puntos m\u00e1s destacados:\n\n1. **Caracter\u00edsticas de los Requisitos**:\n   - Los requisitos deben ser **espec\u00edficos**, **medibles**, **alcanzables**, **realistas** y **verificables**.\n   - Deben ser **claros**, **precisos** y **completos** para facilitar pruebas y verificaciones.\n   - Es esencial que los requisitos permitan la **trazabilidad** a lo largo de la cadena de requisitos, configuraci\u00f3n, dise\u00f1o y pruebas.\n   - Deben servir como base para **pruebas formales** y ser utilizados en la **selecci\u00f3n de proveedores**.\n   - Los requisitos deben estar **priorizados**, identificando aquellos que son **obligatorios**, **beneficiosos** o **deseables**.\n   - Cada requisito debe tener una **identificaci\u00f3n \u00fanica** y un control de versi\u00f3n adecuado.\n\n2. **Importancia de la Seguridad del Paciente y Calidad del Producto**:\n   - Los requisitos deben abordar regulaciones aplicables y resaltar aspectos cr\u00edticos para la **seguridad del paciente**, **calidad del producto** e **integridad de los datos**.\n   - Se debe evitar incluir requisitos gen\u00e9ricos como \"cumple con 21CFR Part 11\" o \"cumple con la legislaci\u00f3n de Anvisa\".\n\n3. **Participaci\u00f3n de los Usuarios del Sistema**:\n   - La **participaci\u00f3n efectiva** de los usuarios es crucial para entender completamente las necesidades operativas y problemas asociados, lo que forma la base para la **aceptaci\u00f3n del sistema** por parte de los usuarios.\n\n4. **Contenido del Documento ERU / URS**:\n   - La introducci\u00f3n del documento debe incluir informaci\u00f3n sobre qui\u00e9n lo produjo, bajo qu\u00e9 autoridad y con qu\u00e9 prop\u00f3sito, as\u00ed como el estado contractual del documento (desarrollo personalizado o subcontratado).\n\n### Entidades Clave\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil.\n- **BPx**: Regulaciones aplicables en el contexto de la salud.\n- **ERU / URS**: Documentos de requisitos de usuario y requisitos de sistema.\n- **Sistema**: Se refiere a los sistemas inform\u00e1ticos regulados en el \u00e1mbito de la salud.\n\nEste resumen destaca la importancia de establecer requisitos claros y bien definidos para garantizar la seguridad y calidad en los sistemas inform\u00e1ticos utilizados en el sector salud.", "excerpt_keywords": "Keywords: ANVISA, computer systems validation, operational requirements, data integrity, regulatory compliance"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "ee4fc947-9c1b-4654-bdab-6aab89b63f14", "node_type": "4", "metadata": {"page_label": "31", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 9.3.2.2 Overview\n\nAn overview of the system should be provided, explaining why the system is needed and what is required of the system. The following points should be considered:\n\n- **Contextualization**: describes the general objective of the system in the current context and the desired situation;\n\n## Scope\n\n- The insertion of the system in the company's long-term vision;\n- System boundaries and boundaries: what part of the business process is being automated;\n- Key objectives and benefits;\n- BPx requirements applicable;\n- Other applicable regulations.\n\n# 9.3.2.3 Operational Requirements\n\nOperational requirements include:\n\n- **Functions** - are the functional requirements that enable the system to execute the business process that is being automated, such as:\n- Calculations, including all critical algorithms;\n- Safety against damage;\n- Security including access control;\n- Audit trails;\n- Use of electronic signatures;\n- Outputs (e.g., reports);\n- Clear error messages.\n\n- **Data** - requirements related to data handling, considering its impact on security, patient, product quality and data integrity, covering the following points:\n- Definition of electronic records;\n- Definition of data types, including identification of characteristics, formatting, critical parameters, valid date range and format, limits and accuracy, and so on;\n- Where and how data will be recorded (e.g., relational databases, files encrypted, etc.)\n- Required fields;\n- Data migration (import and export);\n- Data entry and subsequent editing;\n- Backup and recovery;\n- Archiving requirements;", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "3e2e40d15c19f5b5dbfebf86d3094bf8d5e9e02de813852d4a786503e2403793", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "# 9.3.2.2 Overview\n\nAn overview of the system should be provided, explaining why the system is needed and what is required of the system. The following points should be considered:\n\n- **Contextualization**: describes the general objective of the system in the current context and the desired situation;\n\n## Scope\n\n- The insertion of the system in the company's long-term vision;\n- System boundaries and boundaries: what part of the business process is being automated;\n- Key objectives and benefits;\n- BPx requirements applicable;\n- Other applicable regulations.\n\n# 9.3.2.3 Operational Requirements\n\nOperational requirements include:\n\n- **Functions** - are the functional requirements that enable the system to execute the business process that is being automated, such as:\n- Calculations, including all critical algorithms;\n- Safety against damage;\n- Security including access control;\n- Audit trails;\n- Use of electronic signatures;\n- Outputs (e.g., reports);\n- Clear error messages.\n\n- **Data** - requirements related to data handling, considering its impact on security, patient, product quality and data integrity, covering the following points:\n- Definition of electronic records;\n- Definition of data types, including identification of characteristics, formatting, critical parameters, valid date range and format, limits and accuracy, and so on;\n- Where and how data will be recorded (e.g., relational databases, files encrypted, etc.)\n- Required fields;\n- Data migration (import and export);\n- Data entry and subsequent editing;\n- Backup and recovery;\n- Archiving requirements;", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 1586, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "ab407e80-d9c0-4b55-8dd4-29c7589d232b": {"__data__": {"id_": "ab407e80-d9c0-4b55-8dd4-29c7589d232b", "embedding": null, "metadata": {"page_label": "32", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "- Data security and integrity.\n\n- **Technical Requirements** - Covers the following points:\n- Changes in system operation (start, stop, test, failures);\n- Disaster recovery;\n- Performance and time requirements. They must be quantitative and unambiguous;\n- Action required in case of failure;\n- Capacity requirements;\n- Access speed requirements for reading and writing data;\n- Hardware requirements (e.g., touch-screen, keyboard type; type of mouse and mouse pad; type and number of physical processors, network card);\n- Portability and remote access;\n\n----\n\n- Efficiency (screen and system loading speeds, screen refresh and generation reporting);\n- Type and version of the platform on which the system will work (Windows, Unix, Linux etc.);\n- Types and versions of the protocols used;\n- Configurability.\n\n- **Interfaces** - must be defined (if applicable), covering the following points:\n- User interface(s) - defined in terms of access levels (operator, administrator, system manager) or roles where appropriate;\n- Interface(s) with other systems;\n- Interface(s) with equipment, such as sensors or actuators. This may include I/O lists (input and output) for systems used for process control;\n- Form of input and output of data by users (e.g., keyboard, barcode reader, printers, etc.).\n\n- **Environment** - involves the environment in which the system will work, covering the following points:\n- Layout - physical layout of the plant or other workplace that may impact the system, such as remote links (remote access) or space limitations;\n- Physical conditions (e.g., temperature; humidity; external interference; protection against radio frequency, electromagnetic and/or UV interference; dust, high vibration);\n- Physical requirements;\n- Power/energy requirements (e.g., voltage, amperage; filtering; frequency; protection of grounding; uninterrupted power supply/UPS);\n- Any physical or logical requirements.\n\n## 9.3.2.4 Restrictions\n\nAny restrictions in the specifications or operation of the system must be identified and documented, covering the following points:\n\n- [Content not provided in the image]", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas que se pueden responder espec\u00edficamente con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos establece requisitos t\u00e9cnicos, de interfaz y ambientales que deben cumplirse para garantizar la seguridad y la integridad de los datos. Se detallan aspectos como la recuperaci\u00f3n ante desastres, requisitos de rendimiento, configurabilidad, y las condiciones f\u00edsicas en las que operar\u00e1 el sistema. Tambi\u00e9n se enfatiza la importancia de documentar cualquier restricci\u00f3n en las especificaciones o en la operaci\u00f3n del sistema.\n\n### Preguntas\n\n1. **\u00bfCu\u00e1les son los requisitos espec\u00edficos que deben cumplirse para garantizar la recuperaci\u00f3n ante desastres en un sistema inform\u00e1tico seg\u00fan la gu\u00eda de ANVISA?**\n   - La gu\u00eda menciona que se deben establecer procedimientos claros para la recuperaci\u00f3n ante desastres, aunque no se detallan en el texto proporcionado. Sin embargo, se espera que estos procedimientos sean documentados y que incluyan acciones espec\u00edficas a seguir en caso de fallos.\n\n2. **\u00bfQu\u00e9 consideraciones f\u00edsicas deben tenerse en cuenta al implementar un sistema inform\u00e1tico en un entorno de trabajo seg\u00fan la gu\u00eda?**\n   - La gu\u00eda destaca la importancia de considerar el dise\u00f1o f\u00edsico del lugar de trabajo, las condiciones ambientales (como temperatura y humedad), y los requisitos de energ\u00eda (como voltaje y frecuencia) para asegurar que el sistema funcione correctamente.\n\n3. **\u00bfC\u00f3mo se deben definir las interfaces de usuario en un sistema inform\u00e1tico seg\u00fan las recomendaciones de ANVISA?**\n   - Las interfaces de usuario deben definirse en t\u00e9rminos de niveles de acceso (como operador, administrador y gestor del sistema) y deben incluir detalles sobre la interacci\u00f3n con otros sistemas y equipos, as\u00ed como los m\u00e9todos de entrada y salida de datos utilizados por los usuarios.", "prev_section_summary": "### Resumen de Temas Clave y Entidades de la Secci\u00f3n\n\n#### Temas Clave\n\n1. **Contextualizaci\u00f3n del Sistema**:\n   - Importancia de explicar el objetivo general del sistema en el contexto actual y la situaci\u00f3n deseada.\n   - Relaci\u00f3n del sistema con la visi\u00f3n a largo plazo de la empresa.\n\n2. **Alcance del Sistema**:\n   - Definici\u00f3n de los l\u00edmites del sistema y el proceso empresarial que se automatiza.\n   - Identificaci\u00f3n de los objetivos clave y beneficios esperados.\n   - Consideraci\u00f3n de requisitos regulatorios aplicables.\n\n3. **Requisitos Operacionales**:\n   - **Funciones**: Requisitos funcionales necesarios para la automatizaci\u00f3n del proceso, incluyendo:\n     - C\u00e1lculos y algoritmos cr\u00edticos.\n     - Seguridad y control de acceso.\n     - Trazabilidad y auditor\u00eda.\n     - Uso de firmas electr\u00f3nicas.\n     - Generaci\u00f3n de informes y mensajes de error claros.\n   \n   - **Datos**: Requisitos relacionados con el manejo de datos, que incluyen:\n     - Definici\u00f3n de registros electr\u00f3nicos y tipos de datos.\n     - Especificaciones sobre el almacenamiento y formato de datos.\n     - Requisitos de migraci\u00f3n, entrada y edici\u00f3n de datos.\n     - Estrategias de respaldo, recuperaci\u00f3n y archivo de datos.\n\n#### Entidades\n\n- **Sistema**: Herramienta o conjunto de herramientas que automatizan procesos empresariales.\n- **Empresa**: Organizaci\u00f3n que implementa el sistema en su estrategia a largo plazo.\n- **Regulaciones**: Normativas que deben cumplirse en el contexto de la validaci\u00f3n de sistemas inform\u00e1ticos, especialmente en el sector de la salud.\n- **Datos**: Informaci\u00f3n que el sistema maneja, incluyendo registros electr\u00f3nicos y su integridad.\n- **Funciones**: Capacidades espec\u00edficas que el sistema debe tener para cumplir con los procesos automatizados.\n\nEste resumen destaca la importancia de una planificaci\u00f3n cuidadosa y la consideraci\u00f3n de requisitos operativos y de datos para asegurar la efectividad y cumplimiento del sistema en el contexto regulatorio.", "excerpt_keywords": "Keywords: validation, data integrity, technical requirements, user interfaces, environmental conditions"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "1eede705-799b-4f4e-a048-745494508601", "node_type": "4", "metadata": {"page_label": "32", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "- Data security and integrity.\n\n- **Technical Requirements** - Covers the following points:\n- Changes in system operation (start, stop, test, failures);\n- Disaster recovery;\n- Performance and time requirements. They must be quantitative and unambiguous;\n- Action required in case of failure;\n- Capacity requirements;\n- Access speed requirements for reading and writing data;\n- Hardware requirements (e.g., touch-screen, keyboard type; type of mouse and mouse pad; type and number of physical processors, network card);\n- Portability and remote access;\n\n----\n\n- Efficiency (screen and system loading speeds, screen refresh and generation reporting);\n- Type and version of the platform on which the system will work (Windows, Unix, Linux etc.);\n- Types and versions of the protocols used;\n- Configurability.\n\n- **Interfaces** - must be defined (if applicable), covering the following points:\n- User interface(s) - defined in terms of access levels (operator, administrator, system manager) or roles where appropriate;\n- Interface(s) with other systems;\n- Interface(s) with equipment, such as sensors or actuators. This may include I/O lists (input and output) for systems used for process control;\n- Form of input and output of data by users (e.g., keyboard, barcode reader, printers, etc.).\n\n- **Environment** - involves the environment in which the system will work, covering the following points:\n- Layout - physical layout of the plant or other workplace that may impact the system, such as remote links (remote access) or space limitations;\n- Physical conditions (e.g., temperature; humidity; external interference; protection against radio frequency, electromagnetic and/or UV interference; dust, high vibration);\n- Physical requirements;\n- Power/energy requirements (e.g., voltage, amperage; filtering; frequency; protection of grounding; uninterrupted power supply/UPS);\n- Any physical or logical requirements.\n\n## 9.3.2.4 Restrictions\n\nAny restrictions in the specifications or operation of the system must be identified and documented, covering the following points:\n\n- [Content not provided in the image]", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "eddfb8e99f7fb14c6e426e4deaf5279bf20332b57aa3c48d3d51bf628b877cd8", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "- Data security and integrity.\n\n- **Technical Requirements** - Covers the following points:\n- Changes in system operation (start, stop, test, failures);\n- Disaster recovery;\n- Performance and time requirements. They must be quantitative and unambiguous;\n- Action required in case of failure;\n- Capacity requirements;\n- Access speed requirements for reading and writing data;\n- Hardware requirements (e.g., touch-screen, keyboard type; type of mouse and mouse pad; type and number of physical processors, network card);\n- Portability and remote access;\n\n----\n\n- Efficiency (screen and system loading speeds, screen refresh and generation reporting);\n- Type and version of the platform on which the system will work (Windows, Unix, Linux etc.);\n- Types and versions of the protocols used;\n- Configurability.\n\n- **Interfaces** - must be defined (if applicable), covering the following points:\n- User interface(s) - defined in terms of access levels (operator, administrator, system manager) or roles where appropriate;\n- Interface(s) with other systems;\n- Interface(s) with equipment, such as sensors or actuators. This may include I/O lists (input and output) for systems used for process control;\n- Form of input and output of data by users (e.g., keyboard, barcode reader, printers, etc.).\n\n- **Environment** - involves the environment in which the system will work, covering the following points:\n- Layout - physical layout of the plant or other workplace that may impact the system, such as remote links (remote access) or space limitations;\n- Physical conditions (e.g., temperature; humidity; external interference; protection against radio frequency, electromagnetic and/or UV interference; dust, high vibration);\n- Physical requirements;\n- Power/energy requirements (e.g., voltage, amperage; filtering; frequency; protection of grounding; uninterrupted power supply/UPS);\n- Any physical or logical requirements.\n\n## 9.3.2.4 Restrictions\n\nAny restrictions in the specifications or operation of the system must be identified and documented, covering the following points:\n\n- [Content not provided in the image]", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 2113, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "583850af-1bd9-43e7-a376-d7319e2f881f": {"__data__": {"id_": "583850af-1bd9-43e7-a376-d7319e2f881f", "embedding": null, "metadata": {"page_label": "33", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 9.3.2.5 Life Cycle\n\nAny requirements that may impact the development of the cycle should be identified and documented at the supplier and any subsequent verification activities.\n\nThe following points should be covered:\n\n- Development requirements (eg, minimum standards to be met by the provider);\n- Procedures for project management and quality assurance;\n- Mandatory design methods;\n- Special testing requirements;\n- Test data;\n- Loading test;\n- Necessary simulations;\n- Factory Acceptance Test (FAT);\n- How the items to be delivered should be provided (eg, format and media);\n- Documentation to be delivered by the supplier (eg functional specifications; test specifications; minimum hardware and software requirements; design specifications; maintenance guides or manuals and user);\n- Data to be prepared or converted;\n- Testing, maintenance, data and access management tools;\n- Training courses;\n- Archiving facilities;\n- Support and maintenance required after acceptance.\n\n# 9.3.2.6 Glossary\n\nNO_CONTENT_HERE", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas que pueden proporcionar respuestas espec\u00edficas basadas en el contexto proporcionado:\n\n1. **\u00bfCu\u00e1les son los requisitos m\u00ednimos que deben cumplir los proveedores seg\u00fan la gu\u00eda de ANVISA para la validaci\u00f3n de sistemas inform\u00e1ticos?**\n   - Esta pregunta se centra en los \"requisitos de desarrollo\" mencionados en el contexto, que son cruciales para asegurar que los proveedores cumplan con los est\u00e1ndares necesarios.\n\n2. **\u00bfQu\u00e9 tipo de documentaci\u00f3n debe entregar el proveedor al finalizar el ciclo de desarrollo seg\u00fan la gu\u00eda de ANVISA?**\n   - Esta pregunta aborda el punto sobre la \"documentaci\u00f3n a ser entregada por el proveedor\", lo que es esencial para garantizar que se cumplan todas las especificaciones y requisitos necesarios.\n\n3. **\u00bfQu\u00e9 actividades de verificaci\u00f3n se deben realizar despu\u00e9s de la aceptaci\u00f3n del sistema seg\u00fan la gu\u00eda de ANVISA?**\n   - Esta pregunta se refiere a las \"actividades de verificaci\u00f3n\" que deben documentarse y realizarse, lo que es fundamental para asegurar el correcto funcionamiento y mantenimiento del sistema despu\u00e9s de su aceptaci\u00f3n.\n\n### Resumen de nivel superior del contexto circundante:\nLa secci\u00f3n 9.3.2.5 del documento de ANVISA se centra en el ciclo de vida de los sistemas inform\u00e1ticos, destacando la importancia de identificar y documentar requisitos que puedan impactar el desarrollo. Se enumeran varios aspectos clave que deben ser considerados, como los requisitos de desarrollo, procedimientos de gesti\u00f3n de proyectos, m\u00e9todos de dise\u00f1o, pruebas especiales, y la documentaci\u00f3n que debe ser proporcionada por el proveedor. Esto es esencial para asegurar que los sistemas inform\u00e1ticos cumplan con los est\u00e1ndares de calidad y regulaciones pertinentes.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Seguridad e Integridad de los Datos**: Se enfatiza la importancia de proteger la informaci\u00f3n y asegurar su integridad en los sistemas inform\u00e1ticos.\n\n2. **Requisitos T\u00e9cnicos**:\n   - **Operaci\u00f3n del Sistema**: Cambios en el funcionamiento del sistema, recuperaci\u00f3n ante desastres, requisitos de rendimiento y capacidad.\n   - **Requisitos de Hardware**: Especificaciones sobre dispositivos de entrada/salida, procesadores, y conectividad.\n   - **Eficiencia**: Velocidades de carga y actualizaci\u00f3n de pantalla, as\u00ed como la configurabilidad del sistema.\n\n3. **Interfaces**:\n   - **Interfaz de Usuario**: Definici\u00f3n de niveles de acceso y roles.\n   - **Interacci\u00f3n con Otros Sistemas y Equipos**: Detalles sobre c\u00f3mo el sistema se conecta y comunica con otros dispositivos y sistemas.\n\n4. **Entorno**:\n   - **Condiciones F\u00edsicas**: Consideraciones sobre el dise\u00f1o del espacio de trabajo, condiciones ambientales (temperatura, humedad) y requisitos de energ\u00eda.\n   - **Requisitos F\u00edsicos y L\u00f3gicos**: Necesidades espec\u00edficas que deben cumplirse para el correcto funcionamiento del sistema.\n\n5. **Restricciones**: Necesidad de identificar y documentar cualquier limitaci\u00f3n en las especificaciones o en la operaci\u00f3n del sistema.\n\n### Entidades Clave\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil, responsable de la regulaci\u00f3n y validaci\u00f3n de sistemas inform\u00e1ticos en el \u00e1mbito de la salud.\n- **Sistemas Inform\u00e1ticos**: Plataformas y aplicaciones que requieren validaci\u00f3n para garantizar su funcionamiento seguro y efectivo.\n- **Requisitos de Hardware y Software**: Especificaciones t\u00e9cnicas necesarias para la implementaci\u00f3n y operaci\u00f3n de sistemas inform\u00e1ticos.\n- **Interfaz de Usuario**: Componentes que permiten la interacci\u00f3n entre el usuario y el sistema, incluyendo niveles de acceso y m\u00e9todos de entrada/salida.\n\nEste resumen abarca los aspectos fundamentales y las entidades relevantes mencionadas en la secci\u00f3n del documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos.", "excerpt_keywords": "Keywords: ANVISA, Computer Systems Validation, Life Cycle, Development Requirements, Documentation"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "4364c695-55ac-4c09-b882-33be2ff148d2", "node_type": "4", "metadata": {"page_label": "33", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 9.3.2.5 Life Cycle\n\nAny requirements that may impact the development of the cycle should be identified and documented at the supplier and any subsequent verification activities.\n\nThe following points should be covered:\n\n- Development requirements (eg, minimum standards to be met by the provider);\n- Procedures for project management and quality assurance;\n- Mandatory design methods;\n- Special testing requirements;\n- Test data;\n- Loading test;\n- Necessary simulations;\n- Factory Acceptance Test (FAT);\n- How the items to be delivered should be provided (eg, format and media);\n- Documentation to be delivered by the supplier (eg functional specifications; test specifications; minimum hardware and software requirements; design specifications; maintenance guides or manuals and user);\n- Data to be prepared or converted;\n- Testing, maintenance, data and access management tools;\n- Training courses;\n- Archiving facilities;\n- Support and maintenance required after acceptance.\n\n# 9.3.2.6 Glossary\n\nNO_CONTENT_HERE", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "795a3da8745d2d9e2cf05d0ef2146e3a75201f5d86301f0583cbcc4c8d7e4ea8", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "# 9.3.2.5 Life Cycle\n\nAny requirements that may impact the development of the cycle should be identified and documented at the supplier and any subsequent verification activities.\n\nThe following points should be covered:\n\n- Development requirements (eg, minimum standards to be met by the provider);\n- Procedures for project management and quality assurance;\n- Mandatory design methods;\n- Special testing requirements;\n- Test data;\n- Loading test;\n- Necessary simulations;\n- Factory Acceptance Test (FAT);\n- How the items to be delivered should be provided (eg, format and media);\n- Documentation to be delivered by the supplier (eg functional specifications; test specifications; minimum hardware and software requirements; design specifications; maintenance guides or manuals and user);\n- Data to be prepared or converted;\n- Testing, maintenance, data and access management tools;\n- Training courses;\n- Archiving facilities;\n- Support and maintenance required after acceptance.\n\n# 9.3.2.6 Glossary\n\nNO_CONTENT_HERE", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 1016, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "9a12ea6b-8f72-4c28-8816-5cfe5ea15130": {"__data__": {"id_": "9a12ea6b-8f72-4c28-8816-5cfe5ea15130", "embedding": null, "metadata": {"page_label": "34", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "Definitions of any little-known terms should be provided.\n\n## 9.3.2.7 Approvals\n\nApprovers must be defined. At a minimum, one of the approvers must be the owner of the process. Others approvers could be the owner of the system and the quality unit.\n\nOnce the ERU document has been approved, any changes must be made through the control of changes.\n\n## 9.3.3 Out of Scope Topics\n\nThis section is intended for systems with multiple levels of specification and verification and may not be applicable to Category 3 systems, low risk and commercially available.\n\nThe following items should not be included in the ERU / URS:\n\n- System configuration / project details;\n- Implementation details;\n\nGuide for Computer Systems Validation\nGuide n\u00b0 33/2020 - version 1, of 03/26/2020\n\n- Project deadlines;\n- Costs;\n- Organizational details of the project.\n\nThe system configuration / project details item is part of the solution of how requirements will be met, being defined in the subsequent specifications. Implementation details are also totally dependent on the solution, not being part of this step.\n\n## 9.3.4 Capture of Requirements\n\nFor category 4 and 5 systems, it is often more difficult and time consuming to prepare the ERU / URS document. The development of this document is one of the most important tasks that the regulated company will undertake within the project to implement a computerized system.\n\nIt is essential that the process to be automated is properly mapped before defining ERP / URS. Thus, it is important to detail the process step by step, defining the input and output information. This activity should be carried out by a multidisciplinary team, including the operational level.\n\nBelow is a list of the different modes that can be used by the regulated company for the capture and refinement of user requirements:\n\n- Discussions and interviews;\n- Observation (understanding of the process as a whole);\n- Workshops - multidisciplinary team;\n- Understanding the pitfalls that can occur when defining requirements.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas basadas en el contexto proporcionado, junto con sus respuestas:\n\n1. **\u00bfQui\u00e9nes deben ser los aprobadores del documento ERU y cu\u00e1l es su rol?**\n   - Los aprobadores deben ser definidos, y al menos uno de ellos debe ser el propietario del proceso. Otros aprobadores pueden incluir al propietario del sistema y a la unidad de calidad. Su rol es garantizar que el documento cumpla con los requisitos necesarios antes de su implementaci\u00f3n y que cualquier cambio posterior se gestione a trav\u00e9s del control de cambios.\n\n2. **\u00bfQu\u00e9 elementos no deben incluirse en el documento ERU/URS para sistemas de categor\u00eda 3?**\n   - Para sistemas de categor\u00eda 3, que son de bajo riesgo y comercialmente disponibles, no se deben incluir en el documento ERU/URS los siguientes elementos: detalles de configuraci\u00f3n del sistema/proyecto, detalles de implementaci\u00f3n, plazos del proyecto, costos y detalles organizacionales del proyecto. Estos elementos son considerados fuera del alcance del documento en esta etapa.\n\n3. **\u00bfCu\u00e1l es la importancia de mapear el proceso antes de definir el ERU/URS?**\n   - Es esencial mapear adecuadamente el proceso que se va a automatizar antes de definir el ERU/URS, ya que esto permite detallar el proceso paso a paso y definir la informaci\u00f3n de entrada y salida. Esta actividad debe ser realizada por un equipo multidisciplinario, incluyendo el nivel operativo, para asegurar que todos los requisitos del usuario sean capturados y refinados de manera efectiva.\n\n### Resumen de nivel superior del contexto:\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos establece directrices sobre la aprobaci\u00f3n de documentos ERU/URS, los elementos que deben excluirse de estos documentos y la importancia de un mapeo adecuado del proceso antes de su definici\u00f3n. Se enfatiza la necesidad de un enfoque multidisciplinario para la captura y refinamiento de requisitos, especialmente en sistemas de categor\u00edas m\u00e1s altas, donde la complejidad y el tiempo de preparaci\u00f3n son mayores.", "prev_section_summary": "### Resumen de la Secci\u00f3n 9.3.2.5 - Ciclo de Vida\n\nLa secci\u00f3n 9.3.2.5 del documento de ANVISA se enfoca en la importancia de identificar y documentar los requisitos que pueden influir en el desarrollo del ciclo de vida de los sistemas inform\u00e1ticos. A continuaci\u00f3n se presentan los temas clave y entidades mencionadas:\n\n1. **Requisitos de Desarrollo**: Se deben establecer est\u00e1ndares m\u00ednimos que los proveedores deben cumplir.\n   \n2. **Gesti\u00f3n de Proyectos y Aseguramiento de Calidad**: Se deben definir procedimientos claros para la gesti\u00f3n del proyecto y la garant\u00eda de calidad.\n\n3. **M\u00e9todos de Dise\u00f1o**: Se especifican m\u00e9todos de dise\u00f1o obligatorios que deben seguirse.\n\n4. **Requisitos de Pruebas Especiales**: Se deben identificar y documentar pruebas espec\u00edficas necesarias para el sistema.\n\n5. **Datos de Prueba**: Se requiere la preparaci\u00f3n de datos que se utilizar\u00e1n en las pruebas.\n\n6. **Pruebas de Carga**: Se deben realizar pruebas para evaluar el rendimiento del sistema bajo condiciones de carga.\n\n7. **Simulaciones Necesarias**: Se deben llevar a cabo simulaciones que sean relevantes para el sistema.\n\n8. **Prueba de Aceptaci\u00f3n en F\u00e1brica (FAT)**: Se debe realizar una prueba de aceptaci\u00f3n antes de la entrega final del sistema.\n\n9. **Formato y Medios de Entrega**: Se debe especificar c\u00f3mo se entregar\u00e1n los elementos (formato y medios).\n\n10. **Documentaci\u00f3n del Proveedor**: El proveedor debe entregar documentaci\u00f3n esencial, que incluye especificaciones funcionales, especificaciones de prueba, requisitos m\u00ednimos de hardware y software, especificaciones de dise\u00f1o, gu\u00edas de mantenimiento y manuales de usuario.\n\n11. **Preparaci\u00f3n o Conversi\u00f3n de Datos**: Se debe planificar la preparaci\u00f3n o conversi\u00f3n de datos necesarios.\n\n12. **Herramientas de Gesti\u00f3n**: Se deben definir herramientas para pruebas, mantenimiento, gesti\u00f3n de datos y acceso.\n\n13. **Cursos de Capacitaci\u00f3n**: Se deben ofrecer cursos de formaci\u00f3n para los usuarios del sistema.\n\n14. **Instalaciones de Archivo**: Se deben establecer instalaciones para el archivo de documentaci\u00f3n y datos.\n\n15. **Soporte y Mantenimiento**: Se debe planificar el soporte y mantenimiento necesarios despu\u00e9s de la aceptaci\u00f3n del sistema.\n\nEste enfoque integral asegura que todos los aspectos del ciclo de vida del sistema inform\u00e1tico sean considerados y documentados, garantizando as\u00ed el cumplimiento de los est\u00e1ndares de calidad y regulaciones pertinentes.", "excerpt_keywords": "Keywords: approvals, ERU, URS, requirements capture, system validation"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "cdd7265a-089b-42c9-84ac-beecc831b31d", "node_type": "4", "metadata": {"page_label": "34", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "Definitions of any little-known terms should be provided.\n\n## 9.3.2.7 Approvals\n\nApprovers must be defined. At a minimum, one of the approvers must be the owner of the process. Others approvers could be the owner of the system and the quality unit.\n\nOnce the ERU document has been approved, any changes must be made through the control of changes.\n\n## 9.3.3 Out of Scope Topics\n\nThis section is intended for systems with multiple levels of specification and verification and may not be applicable to Category 3 systems, low risk and commercially available.\n\nThe following items should not be included in the ERU / URS:\n\n- System configuration / project details;\n- Implementation details;\n\nGuide for Computer Systems Validation\nGuide n\u00b0 33/2020 - version 1, of 03/26/2020\n\n- Project deadlines;\n- Costs;\n- Organizational details of the project.\n\nThe system configuration / project details item is part of the solution of how requirements will be met, being defined in the subsequent specifications. Implementation details are also totally dependent on the solution, not being part of this step.\n\n## 9.3.4 Capture of Requirements\n\nFor category 4 and 5 systems, it is often more difficult and time consuming to prepare the ERU / URS document. The development of this document is one of the most important tasks that the regulated company will undertake within the project to implement a computerized system.\n\nIt is essential that the process to be automated is properly mapped before defining ERP / URS. Thus, it is important to detail the process step by step, defining the input and output information. This activity should be carried out by a multidisciplinary team, including the operational level.\n\nBelow is a list of the different modes that can be used by the regulated company for the capture and refinement of user requirements:\n\n- Discussions and interviews;\n- Observation (understanding of the process as a whole);\n- Workshops - multidisciplinary team;\n- Understanding the pitfalls that can occur when defining requirements.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "473a61feea7182d1935156465247944bc2f499e176c0c69ac73b45646ef51d5c", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "Definitions of any little-known terms should be provided.\n\n## 9.3.2.7 Approvals\n\nApprovers must be defined. At a minimum, one of the approvers must be the owner of the process. Others approvers could be the owner of the system and the quality unit.\n\nOnce the ERU document has been approved, any changes must be made through the control of changes.\n\n## 9.3.3 Out of Scope Topics\n\nThis section is intended for systems with multiple levels of specification and verification and may not be applicable to Category 3 systems, low risk and commercially available.\n\nThe following items should not be included in the ERU / URS:\n\n- System configuration / project details;\n- Implementation details;\n\nGuide for Computer Systems Validation\nGuide n\u00b0 33/2020 - version 1, of 03/26/2020\n\n- Project deadlines;\n- Costs;\n- Organizational details of the project.\n\nThe system configuration / project details item is part of the solution of how requirements will be met, being defined in the subsequent specifications. Implementation details are also totally dependent on the solution, not being part of this step.\n\n## 9.3.4 Capture of Requirements\n\nFor category 4 and 5 systems, it is often more difficult and time consuming to prepare the ERU / URS document. The development of this document is one of the most important tasks that the regulated company will undertake within the project to implement a computerized system.\n\nIt is essential that the process to be automated is properly mapped before defining ERP / URS. Thus, it is important to detail the process step by step, defining the input and output information. This activity should be carried out by a multidisciplinary team, including the operational level.\n\nBelow is a list of the different modes that can be used by the regulated company for the capture and refinement of user requirements:\n\n- Discussions and interviews;\n- Observation (understanding of the process as a whole);\n- Workshops - multidisciplinary team;\n- Understanding the pitfalls that can occur when defining requirements.", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 2031, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "cb0ffbae-5b26-4d72-b4bd-9ffc30bf7b3b": {"__data__": {"id_": "cb0ffbae-5b26-4d72-b4bd-9ffc30bf7b3b", "embedding": null, "metadata": {"page_label": "35", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 9.4 SELECTION OF COMPUTER SYSTEMS SUPPLIER\n\n## 9.4.1 Introduction\n\nAfter the construction of the document containing the user's requirements (ERU / URS), the regulated company will select the supplier of the computerized system that meets the requirements established and described previously.\n\nRegulated companies must perform formal assessment of each computer system supplier relevant to GMP and related services. This assessment should be based on the criticality of the system / service to be provided.\n\nThere must be a formal justification for not carrying out the evaluation of system / service providers relevant to GMP.\n\n## 9.4.2 Types of Evaluation\n\nThere are three options for conducting a system / service provider assessment:\n\n- Basic assessment based on available information;\n- Auditing using a questionnaire;\n- Audit with a visit to the supplier by a specialist, auditor or audit team.\n\nNormally, a basic audit is sufficient for low-impact systems, whereas for high-impact systems impact it may be necessary to carry out a more in-depth assessment.\n\nAuditing using a questionnaire may be suitable for suppliers of products and services standard and configurable.\n\n## 9.4.3 Evaluation Process\n\nThe main steps for supplier assessment are as follows:\n\n1. Decision-making based on risk, the most appropriate route for carrying out the assessment;\n2. Performing the basic assessment, if sufficient, or the assessment using a questionnaire or assessment through visiting the supplier, depending on the decision made above;\n3. Evaluation report;\n4. Determination of corrective and follow-up actions, which may involve a visit from monitoring at the supplier's company;\n5. Supplier approval or rejection.\n\nIf the supplier is approved, it must be periodically reassessed by the regulated company, in accordance with the frequency defined in standard operating procedure.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos establece un proceso formal para la selecci\u00f3n y evaluaci\u00f3n de proveedores de sistemas inform\u00e1ticos en empresas reguladas. Este proceso incluye la elaboraci\u00f3n de un documento de requisitos del usuario (ERU/URS) y la evaluaci\u00f3n de proveedores basada en la criticidad del sistema o servicio. Se describen diferentes tipos de evaluaciones (b\u00e1sica, mediante cuestionario o auditor\u00eda en el sitio) y un proceso de evaluaci\u00f3n que incluye la toma de decisiones, la realizaci\u00f3n de la evaluaci\u00f3n, la elaboraci\u00f3n de un informe y la aprobaci\u00f3n o rechazo del proveedor.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfQu\u00e9 criterios se deben considerar al decidir el tipo de evaluaci\u00f3n a realizar para un proveedor de sistemas inform\u00e1ticos?**\n   - La decisi\u00f3n debe basarse en el riesgo y la criticidad del sistema o servicio que el proveedor va a ofrecer.\n\n2. **\u00bfQu\u00e9 acciones deben tomarse si un proveedor es aprobado tras la evaluaci\u00f3n inicial?**\n   - El proveedor aprobado debe ser reevaluado peri\u00f3dicamente por la empresa regulada, de acuerdo con la frecuencia definida en el procedimiento operativo est\u00e1ndar.\n\n3. **\u00bfCu\u00e1l es la justificaci\u00f3n necesaria si una empresa decide no evaluar a un proveedor de sistemas relevantes para GMP?**\n   - Debe haber una justificaci\u00f3n formal para no llevar a cabo la evaluaci\u00f3n de los proveedores de sistemas o servicios relevantes para las Buenas Pr\u00e1cticas de Manufactura (GMP).", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Aprobaciones (9.3.2.7)**:\n   - **Aprobadores**: Se deben definir los aprobadores del documento ERU. Al menos uno debe ser el propietario del proceso, y otros pueden incluir al propietario del sistema y a la unidad de calidad.\n   - **Control de Cambios**: Una vez aprobado el documento ERU, cualquier cambio debe gestionarse a trav\u00e9s de un control de cambios.\n\n2. **Temas Fuera de Alcance (9.3.3)**:\n   - **Exclusiones del ERU/URS**: Para sistemas de categor\u00eda 3 (bajo riesgo y comercialmente disponibles), no se deben incluir:\n     - Detalles de configuraci\u00f3n del sistema/proyecto.\n     - Detalles de implementaci\u00f3n.\n     - Plazos del proyecto.\n     - Costos.\n     - Detalles organizacionales del proyecto.\n   - **Justificaci\u00f3n**: Estos elementos son considerados parte de la soluci\u00f3n que se definir\u00e1 en especificaciones posteriores.\n\n3. **Captura de Requisitos (9.3.4)**:\n   - **Dificultad en la Preparaci\u00f3n**: La preparaci\u00f3n del documento ERU/URS es m\u00e1s compleja y requiere m\u00e1s tiempo para sistemas de categor\u00edas 4 y 5.\n   - **Importancia del Mapeo**: Es crucial mapear adecuadamente el proceso a automatizar antes de definir el ERU/URS, detallando los pasos y la informaci\u00f3n de entrada y salida.\n   - **Equipo Multidisciplinario**: La actividad debe ser realizada por un equipo multidisciplinario, incluyendo personal operativo.\n\n4. **M\u00e9todos para Captura de Requisitos**:\n   - **T\u00e9cnicas**: Se sugieren varias t\u00e9cnicas para la captura y refinamiento de requisitos, tales como:\n     - Discusiones y entrevistas.\n     - Observaci\u00f3n del proceso.\n     - Talleres con un equipo multidisciplinario.\n     - Comprensi\u00f3n de posibles errores al definir requisitos.\n\n### Entidades Clave:\n- **Documentos**: ERU (Especificaci\u00f3n de Requisitos de Usuario) / URS (User Requirements Specification).\n- **Roles**: Aprobadores, propietario del proceso, propietario del sistema, unidad de calidad, equipo multidisciplinario.\n- **Categor\u00edas de Sistemas**: Categor\u00eda 3 (bajo riesgo), Categor\u00eda 4 y 5 (mayor complejidad).\n- **Actividades**: Mapeo de procesos, captura de requisitos, control de cambios. \n\nEste resumen destaca la importancia de la definici\u00f3n clara de roles, la exclusi\u00f3n de ciertos elementos en documentos espec\u00edficos y la necesidad de un enfoque colaborativo en la captura de requisitos para la validaci\u00f3n de sistemas inform\u00e1ticos.", "excerpt_keywords": "Keywords: supplier selection, computer systems validation, GMP assessment, evaluation process, risk-based assessment"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "850ab2bb-012a-42bc-bd46-6470cc141e7a", "node_type": "4", "metadata": {"page_label": "35", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 9.4 SELECTION OF COMPUTER SYSTEMS SUPPLIER\n\n## 9.4.1 Introduction\n\nAfter the construction of the document containing the user's requirements (ERU / URS), the regulated company will select the supplier of the computerized system that meets the requirements established and described previously.\n\nRegulated companies must perform formal assessment of each computer system supplier relevant to GMP and related services. This assessment should be based on the criticality of the system / service to be provided.\n\nThere must be a formal justification for not carrying out the evaluation of system / service providers relevant to GMP.\n\n## 9.4.2 Types of Evaluation\n\nThere are three options for conducting a system / service provider assessment:\n\n- Basic assessment based on available information;\n- Auditing using a questionnaire;\n- Audit with a visit to the supplier by a specialist, auditor or audit team.\n\nNormally, a basic audit is sufficient for low-impact systems, whereas for high-impact systems impact it may be necessary to carry out a more in-depth assessment.\n\nAuditing using a questionnaire may be suitable for suppliers of products and services standard and configurable.\n\n## 9.4.3 Evaluation Process\n\nThe main steps for supplier assessment are as follows:\n\n1. Decision-making based on risk, the most appropriate route for carrying out the assessment;\n2. Performing the basic assessment, if sufficient, or the assessment using a questionnaire or assessment through visiting the supplier, depending on the decision made above;\n3. Evaluation report;\n4. Determination of corrective and follow-up actions, which may involve a visit from monitoring at the supplier's company;\n5. Supplier approval or rejection.\n\nIf the supplier is approved, it must be periodically reassessed by the regulated company, in accordance with the frequency defined in standard operating procedure.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "454896bffe82fd4fd72dd43314622befaae734763a5b9024606e73b4ca08bdd0", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "# 9.4 SELECTION OF COMPUTER SYSTEMS SUPPLIER\n\n## 9.4.1 Introduction\n\nAfter the construction of the document containing the user's requirements (ERU / URS), the regulated company will select the supplier of the computerized system that meets the requirements established and described previously.\n\nRegulated companies must perform formal assessment of each computer system supplier relevant to GMP and related services. This assessment should be based on the criticality of the system / service to be provided.\n\nThere must be a formal justification for not carrying out the evaluation of system / service providers relevant to GMP.\n\n## 9.4.2 Types of Evaluation\n\nThere are three options for conducting a system / service provider assessment:\n\n- Basic assessment based on available information;\n- Auditing using a questionnaire;\n- Audit with a visit to the supplier by a specialist, auditor or audit team.\n\nNormally, a basic audit is sufficient for low-impact systems, whereas for high-impact systems impact it may be necessary to carry out a more in-depth assessment.\n\nAuditing using a questionnaire may be suitable for suppliers of products and services standard and configurable.\n\n## 9.4.3 Evaluation Process\n\nThe main steps for supplier assessment are as follows:\n\n1. Decision-making based on risk, the most appropriate route for carrying out the assessment;\n2. Performing the basic assessment, if sufficient, or the assessment using a questionnaire or assessment through visiting the supplier, depending on the decision made above;\n3. Evaluation report;\n4. Determination of corrective and follow-up actions, which may involve a visit from monitoring at the supplier's company;\n5. Supplier approval or rejection.\n\nIf the supplier is approved, it must be periodically reassessed by the regulated company, in accordance with the frequency defined in standard operating procedure.", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 1879, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "b87f51bd-ff00-4117-a5e2-6448238b02bf": {"__data__": {"id_": "b87f51bd-ff00-4117-a5e2-6448238b02bf", "embedding": null, "metadata": {"page_label": "36", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 9.5 DOCUMENT CONTAINING FUNCTIONAL SPECIFICATIONS (EF / FS)\n\n## 9.5.1 Introduction\n\nFunctional specifications (EF / FS) define the system that meets the user's needs, described in specifications of user requirements (ERU / URS).\n\nFor some systems, such as those commercially available and low risk, belonging to category 3, a simple approach consisting of a simple level of specification and verification is appropriate and a document containing the functional specifications is not necessary.\n\nA Functional Specifications document defines what the system should do and what functions and facilities will be provided. It provides a list of project objectives for the system. Formal tests will be based on functional specifications.\n\nThe document containing the functional specifications is produced by the supplier and must be reviewed and approved by the regulated company. It is often considered a contract document.\n\nThe following guidelines must be followed when producing the specification:\n\n- All design constraints (e.g., the externally defined limitations that a system must meet, such as hardware / software platform, speed, power, test, environmental and operational conditions) must be explicitly documented;\n- Ambiguity, duplication and contradiction must be avoided;\n- Consistent nomenclature conventions must be adopted;\n- Each function and installation described must be testable;\n- Internal and external interfaces must be clearly defined;\n- The functional specifications must be clear enough to allow the project to proceed without there is frequent need to consult the author of these specifications\n- Both users and programmers must understand the functional specifications;\n\nGuide for Computer Systems Validation\nGuide n\u00b0 33/2020 - version 1, of 03/26/2020\n\n\u2713 The use of diagrams and graphs is recommended when appropriate.\n\nFunctional specifications must be prepared and organized in a way that allows traceability by the entire life cycle, from individual requirements to associated tests.\n\n## 9.5.2 Content of the EF / FS Document\n\nBelow is a list of topics that may be part of the EF / FS document, not intended to be neither exhaustive nor prescriptive.\n\n### 9.5.2.1 Introduction\n\nThe following information must be provided:\n\n- Document ownership;\n- Who produced the document, under what authority and for what purpose;", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos establece la importancia de las especificaciones funcionales (EF/FS) en el desarrollo de sistemas que satisfacen las necesidades del usuario. Estas especificaciones deben ser claras, testables y organizadas para permitir la trazabilidad a lo largo del ciclo de vida del sistema. Se enfatiza que el documento debe ser producido por el proveedor y revisado por la empresa regulada, y se ofrecen directrices sobre c\u00f3mo redactar estas especificaciones para evitar ambig\u00fcedades y asegurar la comprensi\u00f3n tanto por parte de los usuarios como de los programadores.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfCu\u00e1les son las caracter\u00edsticas que deben evitarse al redactar un documento de especificaciones funcionales seg\u00fan ANVISA?**\n   - El documento debe evitar ambig\u00fcedades, duplicaciones y contradicciones, y debe adoptar convenciones de nomenclatura consistentes.\n\n2. **\u00bfQu\u00e9 tipo de sistemas no requieren un documento de especificaciones funcionales seg\u00fan la gu\u00eda de ANVISA?**\n   - Los sistemas comercialmente disponibles y de bajo riesgo, que pertenecen a la categor\u00eda 3, pueden no necesitar un documento de especificaciones funcionales, ya que se puede aplicar un enfoque m\u00e1s simple de especificaci\u00f3n y verificaci\u00f3n.\n\n3. **\u00bfQu\u00e9 se recomienda incluir en el documento de especificaciones funcionales para facilitar la comprensi\u00f3n y la trazabilidad?**\n   - Se recomienda el uso de diagramas y gr\u00e1ficos cuando sea apropiado, y el documento debe estar organizado de manera que permita la trazabilidad desde los requisitos individuales hasta las pruebas asociadas.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n**Temas Clave:**\n\n1. **Selecci\u00f3n de Proveedores de Sistemas Inform\u00e1ticos:**\n   - Importancia de seleccionar un proveedor que cumpla con los requisitos del usuario (ERU/URS).\n   - Evaluaci\u00f3n formal de proveedores relevante a las Buenas Pr\u00e1cticas de Manufactura (GMP).\n\n2. **Criterios de Evaluaci\u00f3n:**\n   - La evaluaci\u00f3n debe basarse en la criticidad del sistema o servicio proporcionado.\n   - Justificaci\u00f3n formal necesaria si se decide no evaluar a un proveedor.\n\n3. **Tipos de Evaluaci\u00f3n:**\n   - Evaluaci\u00f3n b\u00e1sica basada en informaci\u00f3n disponible.\n   - Auditor\u00eda mediante cuestionario.\n   - Auditor\u00eda con visita al proveedor.\n\n4. **Proceso de Evaluaci\u00f3n:**\n   - Toma de decisiones basada en riesgo.\n   - Realizaci\u00f3n de la evaluaci\u00f3n (b\u00e1sica, cuestionario o visita).\n   - Elaboraci\u00f3n de un informe de evaluaci\u00f3n.\n   - Determinaci\u00f3n de acciones correctivas y seguimiento.\n   - Aprobaci\u00f3n o rechazo del proveedor.\n   - Reevaluaci\u00f3n peri\u00f3dica de proveedores aprobados.\n\n**Entidades:**\n\n- **Regulated Company (Empresa Regulada):** Entidad que selecciona y eval\u00faa proveedores.\n- **Supplier (Proveedor):** Entidad que ofrece sistemas inform\u00e1ticos y servicios relacionados.\n- **GMP (Good Manufacturing Practices - Buenas Pr\u00e1cticas de Manufactura):** Normativa que gu\u00eda la evaluaci\u00f3n de proveedores.\n- **ERU/URS (User Requirements Document / User Requirement Specification - Documento de Requisitos del Usuario):** Documento que establece los requisitos que debe cumplir el proveedor.\n- **Auditor / Audit Team (Auditor / Equipo de Auditor\u00eda):** Especialistas que realizan la evaluaci\u00f3n de los proveedores.\n\nEste resumen destaca los aspectos fundamentales del proceso de selecci\u00f3n y evaluaci\u00f3n de proveedores de sistemas inform\u00e1ticos seg\u00fan la gu\u00eda de ANVISA.", "excerpt_keywords": "Keywords: functional specifications, user requirements, validation, traceability, guidelines"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "52a74506-6878-42c0-a05a-69933984d353", "node_type": "4", "metadata": {"page_label": "36", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 9.5 DOCUMENT CONTAINING FUNCTIONAL SPECIFICATIONS (EF / FS)\n\n## 9.5.1 Introduction\n\nFunctional specifications (EF / FS) define the system that meets the user's needs, described in specifications of user requirements (ERU / URS).\n\nFor some systems, such as those commercially available and low risk, belonging to category 3, a simple approach consisting of a simple level of specification and verification is appropriate and a document containing the functional specifications is not necessary.\n\nA Functional Specifications document defines what the system should do and what functions and facilities will be provided. It provides a list of project objectives for the system. Formal tests will be based on functional specifications.\n\nThe document containing the functional specifications is produced by the supplier and must be reviewed and approved by the regulated company. It is often considered a contract document.\n\nThe following guidelines must be followed when producing the specification:\n\n- All design constraints (e.g., the externally defined limitations that a system must meet, such as hardware / software platform, speed, power, test, environmental and operational conditions) must be explicitly documented;\n- Ambiguity, duplication and contradiction must be avoided;\n- Consistent nomenclature conventions must be adopted;\n- Each function and installation described must be testable;\n- Internal and external interfaces must be clearly defined;\n- The functional specifications must be clear enough to allow the project to proceed without there is frequent need to consult the author of these specifications\n- Both users and programmers must understand the functional specifications;\n\nGuide for Computer Systems Validation\nGuide n\u00b0 33/2020 - version 1, of 03/26/2020\n\n\u2713 The use of diagrams and graphs is recommended when appropriate.\n\nFunctional specifications must be prepared and organized in a way that allows traceability by the entire life cycle, from individual requirements to associated tests.\n\n## 9.5.2 Content of the EF / FS Document\n\nBelow is a list of topics that may be part of the EF / FS document, not intended to be neither exhaustive nor prescriptive.\n\n### 9.5.2.1 Introduction\n\nThe following information must be provided:\n\n- Document ownership;\n- Who produced the document, under what authority and for what purpose;", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "7a167b1745da6f862d7d38e20c2ed81ba696b53711ae412db544d01300f3aefc", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "# 9.5 DOCUMENT CONTAINING FUNCTIONAL SPECIFICATIONS (EF / FS)\n\n## 9.5.1 Introduction\n\nFunctional specifications (EF / FS) define the system that meets the user's needs, described in specifications of user requirements (ERU / URS).\n\nFor some systems, such as those commercially available and low risk, belonging to category 3, a simple approach consisting of a simple level of specification and verification is appropriate and a document containing the functional specifications is not necessary.\n\nA Functional Specifications document defines what the system should do and what functions and facilities will be provided. It provides a list of project objectives for the system. Formal tests will be based on functional specifications.\n\nThe document containing the functional specifications is produced by the supplier and must be reviewed and approved by the regulated company. It is often considered a contract document.\n\nThe following guidelines must be followed when producing the specification:\n\n- All design constraints (e.g., the externally defined limitations that a system must meet, such as hardware / software platform, speed, power, test, environmental and operational conditions) must be explicitly documented;\n- Ambiguity, duplication and contradiction must be avoided;\n- Consistent nomenclature conventions must be adopted;\n- Each function and installation described must be testable;\n- Internal and external interfaces must be clearly defined;\n- The functional specifications must be clear enough to allow the project to proceed without there is frequent need to consult the author of these specifications\n- Both users and programmers must understand the functional specifications;\n\nGuide for Computer Systems Validation\nGuide n\u00b0 33/2020 - version 1, of 03/26/2020\n\n\u2713 The use of diagrams and graphs is recommended when appropriate.\n\nFunctional specifications must be prepared and organized in a way that allows traceability by the entire life cycle, from individual requirements to associated tests.\n\n## 9.5.2 Content of the EF / FS Document\n\nBelow is a list of topics that may be part of the EF / FS document, not intended to be neither exhaustive nor prescriptive.\n\n### 9.5.2.1 Introduction\n\nThe following information must be provided:\n\n- Document ownership;\n- Who produced the document, under what authority and for what purpose;", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 2346, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "9fc8611f-c591-4572-84a6-ebbff9015309": {"__data__": {"id_": "9fc8611f-c591-4572-84a6-ebbff9015309", "embedding": null, "metadata": {"page_label": "37", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "- The contractual status of the document (if applicable);\n- Relationship with other documents (eg ERU / URS).\n\n## 9.5.2.2 Overview\n\nIt should cover the following topics, where appropriate:\n\n- Scope and objectives;\n- Reference to the relevant GMP regulations;\n- Impact on patient safety, product quality and data integrity;\n- High-level description (subdivide into primary system components);\n- The main interfaces between the system and other systems and / or the environment;\n- Assumptions / restrictions;\n- Non-conformities in relation to the specifications of the users' requirements, which must be documented and justified.\n\n## 9.5.2.3 Functions\n\nThe high-level description should be divided into individual functions.\n\nThe following aspects should be addressed, where appropriate:\n\n- The purpose of the function and the details of its use, including interface with other parts of the system. Inputs, outputs, critical calculations, algorithms and the impact on other functions and / or systems and / or environment must be highlighted;\n- Performance: response, scaling, centralized or distributed processing and throughput transfer - These points must be quantitative and unambiguous;\n- Security and protection - Action in case the selected software or hardware fails; self check; verification of input value; redundancy; access restrictions; downtime and data recovery;\n- Functions that are configurable and any limits for configuration;\n- Traceability to the specific requirements of the ERU / URS;\n\nGuide for Computer Systems Validation\nGuide n\u00b0 33/2020 - version 1, of 03/26/2020\n\nPage 35\n\n- Fault conditions, fault actions, log files and diagnostics.\n\n## 9.5.2.4 Data\n\nThe following aspects should be addressed, where appropriate:\n\n- Definition - data must be defined in a hierarchical manner, with complex objects being constructed from simpler objects (eg, log files). Critical parameters must be highlighted;\n- Access;\n- Allowable range for input and output values;\n- Required fields;\n- Verification of data validation;", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas que se pueden formular a partir del contexto proporcionado, junto con sus respuestas espec\u00edficas:\n\n### Preguntas y Respuestas\n\n1. **\u00bfCu\u00e1les son los aspectos clave que deben abordarse en la descripci\u00f3n de alto nivel de un sistema seg\u00fan la gu\u00eda de ANVISA?**\n   - La descripci\u00f3n de alto nivel debe incluir el alcance y objetivos del sistema, referencias a las regulaciones GMP relevantes, el impacto en la seguridad del paciente, la calidad del producto y la integridad de los datos. Tambi\u00e9n debe proporcionar una descripci\u00f3n de los componentes principales del sistema, las interfaces con otros sistemas y el entorno, as\u00ed como las suposiciones y restricciones aplicables.\n\n2. **\u00bfQu\u00e9 elementos se deben considerar al detallar las funciones de un sistema en el contexto de la validaci\u00f3n de sistemas inform\u00e1ticos?**\n   - Al detallar las funciones, se deben considerar el prop\u00f3sito de cada funci\u00f3n, su uso y la interfaz con otras partes del sistema. Adem\u00e1s, se deben resaltar los inputs, outputs, c\u00e1lculos cr\u00edticos, algoritmos, rendimiento (respuesta, escalabilidad, procesamiento centralizado o distribuido), seguridad y protecci\u00f3n, configurabilidad de las funciones, y la trazabilidad a los requisitos espec\u00edficos del ERU/URS.\n\n3. **\u00bfC\u00f3mo se debe definir y validar la data en un sistema seg\u00fan la gu\u00eda de ANVISA?**\n   - La data debe definirse de manera jer\u00e1rquica, construyendo objetos complejos a partir de objetos m\u00e1s simples. Se deben destacar los par\u00e1metros cr\u00edticos, establecer el acceso a los datos, definir los rangos permitidos para los valores de entrada y salida, identificar los campos requeridos y verificar la validaci\u00f3n de los datos.\n\n### Resumen de Nivel Superior\n\nLa gu\u00eda de ANVISA para la validaci\u00f3n de sistemas inform\u00e1ticos establece directrices claras sobre c\u00f3mo documentar y validar sistemas en el contexto de las regulaciones de Buenas Pr\u00e1cticas de Manufactura (GMP). Se enfatiza la importancia de una descripci\u00f3n clara del sistema, sus funciones y la gesti\u00f3n de datos, asegurando que se aborden aspectos cr\u00edticos como la seguridad, la integridad de los datos y la trazabilidad a los requisitos del usuario. La gu\u00eda tambi\u00e9n destaca la necesidad de documentar no conformidades y justificaciones en relaci\u00f3n con los requisitos del usuario, lo que es esencial para garantizar la calidad y la seguridad en el \u00e1mbito de la salud.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n**Temas Clave:**\n\n1. **Especificaciones Funcionales (EF/FS):** Definen el sistema que satisface las necesidades del usuario y se basan en las especificaciones de requisitos del usuario (ERU/URS).\n   \n2. **Documentaci\u00f3n:** Un documento de especificaciones funcionales es esencial para definir las funciones y objetivos del sistema, y debe ser producido por el proveedor y revisado por la empresa regulada.\n\n3. **Directrices para la Redacci\u00f3n:**\n   - Documentar todas las limitaciones de dise\u00f1o.\n   - Evitar ambig\u00fcedades, duplicaciones y contradicciones.\n   - Adoptar convenciones de nomenclatura consistentes.\n   - Asegurar que cada funci\u00f3n sea testable.\n   - Definir claramente las interfaces internas y externas.\n   - Facilitar la comprensi\u00f3n tanto para usuarios como para programadores.\n   - Organizar el documento para permitir la trazabilidad a lo largo del ciclo de vida del sistema.\n\n4. **Sistemas de Bajo Riesgo:** Para sistemas comercialmente disponibles y de bajo riesgo (categor\u00eda 3), puede no ser necesario un documento de especificaciones funcionales.\n\n5. **Uso de Diagramas:** Se recomienda el uso de diagramas y gr\u00e1ficos para mejorar la claridad del documento.\n\n**Entidades:**\n\n- **ANVISA:** Agencia Nacional de Vigilancia Sanitaria de Brasil, responsable de la regulaci\u00f3n.\n- **Proveedor:** Entidad que produce el documento de especificaciones funcionales.\n- **Empresa Regulada:** Entidad que revisa y aprueba el documento.\n- **Sistemas:** Se refiere a los sistemas inform\u00e1ticos que deben cumplir con las especificaciones funcionales.\n\nEste resumen destaca la importancia de las especificaciones funcionales en el desarrollo de sistemas inform\u00e1ticos y las directrices que deben seguirse para su correcta elaboraci\u00f3n y revisi\u00f3n.", "excerpt_keywords": "Keywords: validation, GMP regulations, data integrity, system functions, ANVISA"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "4e9099ba-e104-4ef4-88d0-dc186687db1b", "node_type": "4", "metadata": {"page_label": "37", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "- The contractual status of the document (if applicable);\n- Relationship with other documents (eg ERU / URS).\n\n## 9.5.2.2 Overview\n\nIt should cover the following topics, where appropriate:\n\n- Scope and objectives;\n- Reference to the relevant GMP regulations;\n- Impact on patient safety, product quality and data integrity;\n- High-level description (subdivide into primary system components);\n- The main interfaces between the system and other systems and / or the environment;\n- Assumptions / restrictions;\n- Non-conformities in relation to the specifications of the users' requirements, which must be documented and justified.\n\n## 9.5.2.3 Functions\n\nThe high-level description should be divided into individual functions.\n\nThe following aspects should be addressed, where appropriate:\n\n- The purpose of the function and the details of its use, including interface with other parts of the system. Inputs, outputs, critical calculations, algorithms and the impact on other functions and / or systems and / or environment must be highlighted;\n- Performance: response, scaling, centralized or distributed processing and throughput transfer - These points must be quantitative and unambiguous;\n- Security and protection - Action in case the selected software or hardware fails; self check; verification of input value; redundancy; access restrictions; downtime and data recovery;\n- Functions that are configurable and any limits for configuration;\n- Traceability to the specific requirements of the ERU / URS;\n\nGuide for Computer Systems Validation\nGuide n\u00b0 33/2020 - version 1, of 03/26/2020\n\nPage 35\n\n- Fault conditions, fault actions, log files and diagnostics.\n\n## 9.5.2.4 Data\n\nThe following aspects should be addressed, where appropriate:\n\n- Definition - data must be defined in a hierarchical manner, with complex objects being constructed from simpler objects (eg, log files). Critical parameters must be highlighted;\n- Access;\n- Allowable range for input and output values;\n- Required fields;\n- Verification of data validation;", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "14df5a59a6c429e95f5dfde43ccb47e675f2f96abd03be4fc6a077089c3059a1", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "- The contractual status of the document (if applicable);\n- Relationship with other documents (eg ERU / URS).\n\n## 9.5.2.2 Overview\n\nIt should cover the following topics, where appropriate:\n\n- Scope and objectives;\n- Reference to the relevant GMP regulations;\n- Impact on patient safety, product quality and data integrity;\n- High-level description (subdivide into primary system components);\n- The main interfaces between the system and other systems and / or the environment;\n- Assumptions / restrictions;\n- Non-conformities in relation to the specifications of the users' requirements, which must be documented and justified.\n\n## 9.5.2.3 Functions\n\nThe high-level description should be divided into individual functions.\n\nThe following aspects should be addressed, where appropriate:\n\n- The purpose of the function and the details of its use, including interface with other parts of the system. Inputs, outputs, critical calculations, algorithms and the impact on other functions and / or systems and / or environment must be highlighted;\n- Performance: response, scaling, centralized or distributed processing and throughput transfer - These points must be quantitative and unambiguous;\n- Security and protection - Action in case the selected software or hardware fails; self check; verification of input value; redundancy; access restrictions; downtime and data recovery;\n- Functions that are configurable and any limits for configuration;\n- Traceability to the specific requirements of the ERU / URS;\n\nGuide for Computer Systems Validation\nGuide n\u00b0 33/2020 - version 1, of 03/26/2020\n\nPage 35\n\n- Fault conditions, fault actions, log files and diagnostics.\n\n## 9.5.2.4 Data\n\nThe following aspects should be addressed, where appropriate:\n\n- Definition - data must be defined in a hierarchical manner, with complex objects being constructed from simpler objects (eg, log files). Critical parameters must be highlighted;\n- Access;\n- Allowable range for input and output values;\n- Required fields;\n- Verification of data validation;", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 2032, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "b8506d63-27cf-4e6a-a53c-c38f26d487f8": {"__data__": {"id_": "b8506d63-27cf-4e6a-a53c-c38f26d487f8", "embedding": null, "metadata": {"page_label": "38", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "- Data relationship;\n- Data storage capacity, retention time and details on data archiving;\n- Data integrity and protection;\n- Data migration (import and export).\n\n## 9.5.2.5 Interfaces\n\nThe interfaces between systems should be described, defining how the systems and subsystems interact, which they come and what they need. For systems regulated by BPx, protection of the interfaces is important. The following points should be addressed when appropriate:\n\n- **Interfaces with users.** This should be defined in roles (access profile), such as, operator, administrator, system manager, etc. Topics to be considered: types of peripherals; general format of screens and reports; error handling and reporting and security. User input mode(s) should be set(s), such as, keyboard and mouse, touchscreen; pen calligraphy;\n- **Interfaces with equipment,** such as sensors and plant equipment;\n- **Interfaces with other systems.** This should cover the nature and time of interaction and the methods and rules that govern the interaction between systems. If there are any middleware restrictions, this should be registered.\n\nThe following topics should be considered for any type of interface:\n\n- Data transmitted and received;\n- Data type, format, intervals and meaning of the values;\n- Time;\n- Data transfer fees;\n- Communication protocols: initiation and order of execution;\n- Any data sharing, creation, duplication, use, storage or destruction;\n- Initiation and interruption mechanisms;\n- Communication through parameters, common data areas or messages;\n- Direct access to internal data;\n- Error handling, recovery and reporting;\n- Access and security.\n\n## 9.5.2.6 Non-Functional Attributes\n\nHow the system will meet non-functional requirements should be described. The following items should be addressed when appropriate:\n\n- Availability (reliability, redundancy, error checking, stand-by operation);\n- Maintenance (possibilities for expansion and improvement; extra capacity; probable changes in environment and service life).\n\n## 9.5.2.7 Environment", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas que pueden proporcionar respuestas espec\u00edficas basadas en el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos detalla aspectos cr\u00edticos relacionados con la gesti\u00f3n de datos, interfaces entre sistemas, atributos no funcionales y el entorno en el que operan estos sistemas. Se enfatiza la importancia de la protecci\u00f3n de interfaces, la definici\u00f3n de roles de usuario, y la consideraci\u00f3n de requisitos no funcionales como disponibilidad y mantenimiento.\n\n### Preguntas\n\n1. **\u00bfCu\u00e1les son los roles de usuario espec\u00edficos que deben definirse en las interfaces con los usuarios, y qu\u00e9 consideraciones deben tenerse en cuenta para cada uno?**\n   - Esta pregunta busca respuestas sobre los diferentes perfiles de acceso y las especificaciones que deben cumplirse para cada rol, lo que no se detalla en otros documentos.\n\n2. **\u00bfQu\u00e9 mecanismos de manejo de errores y recuperaci\u00f3n se deben implementar en las interfaces entre sistemas, y c\u00f3mo se deben documentar?**\n   - Esta pregunta se centra en los procedimientos espec\u00edficos para manejar errores y asegurar la continuidad del sistema, lo cual es crucial para la validaci\u00f3n y no se aborda de manera general en otros contextos.\n\n3. **\u00bfQu\u00e9 aspectos de mantenimiento y expansi\u00f3n se deben considerar al dise\u00f1ar un sistema inform\u00e1tico seg\u00fan las directrices de ANVISA?**\n   - Esta pregunta busca informaci\u00f3n sobre las expectativas de mantenimiento y la capacidad de adaptaci\u00f3n del sistema a cambios futuros, lo que es esencial para la planificaci\u00f3n a largo plazo y puede no estar claramente definido en otros documentos.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\nLa secci\u00f3n del documento \"Gu\u00eda de ANVISA para la Validaci\u00f3n de Sistemas Inform\u00e1ticos\" aborda varios aspectos fundamentales relacionados con la validaci\u00f3n de sistemas en el contexto de las Buenas Pr\u00e1cticas de Manufactura (GMP). A continuaci\u00f3n se resumen los temas clave y entidades mencionados:\n\n#### Temas Clave\n\n1. **Estado Contractual del Documento**: Se menciona la importancia de definir el estado contractual del documento y su relaci\u00f3n con otros documentos relevantes, como el ERU (Especificaci\u00f3n de Requisitos del Usuario) y el URS (Especificaci\u00f3n de Requisitos del Usuario).\n\n2. **Descripci\u00f3n General**:\n   - **Alcance y Objetivos**: Definici\u00f3n clara de lo que se pretende lograr con el sistema.\n   - **Regulaciones GMP**: Referencias a las normativas pertinentes que rigen la operaci\u00f3n del sistema.\n   - **Impacto en Seguridad y Calidad**: Evaluaci\u00f3n del impacto del sistema en la seguridad del paciente, la calidad del producto y la integridad de los datos.\n   - **Descripci\u00f3n de Componentes**: Desglose de los componentes principales del sistema y sus interfaces con otros sistemas y el entorno.\n   - **Suposiciones y Restricciones**: Identificaci\u00f3n de las suposiciones y limitaciones que pueden afectar el sistema.\n   - **No Conformidades**: Documentaci\u00f3n y justificaci\u00f3n de cualquier no conformidad respecto a los requisitos del usuario.\n\n3. **Funciones del Sistema**:\n   - **Prop\u00f3sito y Uso**: Detalle del prop\u00f3sito de cada funci\u00f3n y su interacci\u00f3n con otras partes del sistema.\n   - **Rendimiento**: Evaluaci\u00f3n cuantitativa de la respuesta, escalabilidad y procesamiento.\n   - **Seguridad y Protecci\u00f3n**: Medidas de seguridad ante fallos de software o hardware, incluyendo redundancia y recuperaci\u00f3n de datos.\n   - **Configurabilidad**: Identificaci\u00f3n de funciones configurables y sus l\u00edmites.\n   - **Trazabilidad**: Conexi\u00f3n de las funciones a los requisitos espec\u00edficos del ERU/URS.\n   - **Condiciones de Fallo**: Manejo de condiciones de fallo y diagn\u00f3sticos.\n\n4. **Datos**:\n   - **Definici\u00f3n Jer\u00e1rquica**: Los datos deben definirse de manera jer\u00e1rquica, destacando par\u00e1metros cr\u00edticos.\n   - **Acceso y Rango Permitido**: Establecimiento de acceso a los datos y rangos permitidos para valores de entrada y salida.\n   - **Campos Requeridos**: Identificaci\u00f3n de campos que son obligatorios.\n   - **Validaci\u00f3n de Datos**: Verificaci\u00f3n de la validez de los datos ingresados.\n\n#### Entidades\n\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil, responsable de regular y supervisar la salud p\u00fablica.\n- **GMP**: Buenas Pr\u00e1cticas de Manufactura, regulaciones que aseguran la calidad y seguridad en la producci\u00f3n.\n- **ERU/URS**: Documentos que especifican los requisitos del usuario para el sistema.\n\nEste resumen destaca la importancia de una documentaci\u00f3n clara y detallada en la validaci\u00f3n de sistemas inform\u00e1ticos, asegurando que se cumplan los est\u00e1ndares de calidad y seguridad en el \u00e1mbito de la salud.", "excerpt_keywords": "Keywords: validation, interfaces, data integrity, non-functional requirements, ANVISA"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "13589dfe-4b52-4471-b972-2f62d3f7780a", "node_type": "4", "metadata": {"page_label": "38", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "- Data relationship;\n- Data storage capacity, retention time and details on data archiving;\n- Data integrity and protection;\n- Data migration (import and export).\n\n## 9.5.2.5 Interfaces\n\nThe interfaces between systems should be described, defining how the systems and subsystems interact, which they come and what they need. For systems regulated by BPx, protection of the interfaces is important. The following points should be addressed when appropriate:\n\n- **Interfaces with users.** This should be defined in roles (access profile), such as, operator, administrator, system manager, etc. Topics to be considered: types of peripherals; general format of screens and reports; error handling and reporting and security. User input mode(s) should be set(s), such as, keyboard and mouse, touchscreen; pen calligraphy;\n- **Interfaces with equipment,** such as sensors and plant equipment;\n- **Interfaces with other systems.** This should cover the nature and time of interaction and the methods and rules that govern the interaction between systems. If there are any middleware restrictions, this should be registered.\n\nThe following topics should be considered for any type of interface:\n\n- Data transmitted and received;\n- Data type, format, intervals and meaning of the values;\n- Time;\n- Data transfer fees;\n- Communication protocols: initiation and order of execution;\n- Any data sharing, creation, duplication, use, storage or destruction;\n- Initiation and interruption mechanisms;\n- Communication through parameters, common data areas or messages;\n- Direct access to internal data;\n- Error handling, recovery and reporting;\n- Access and security.\n\n## 9.5.2.6 Non-Functional Attributes\n\nHow the system will meet non-functional requirements should be described. The following items should be addressed when appropriate:\n\n- Availability (reliability, redundancy, error checking, stand-by operation);\n- Maintenance (possibilities for expansion and improvement; extra capacity; probable changes in environment and service life).\n\n## 9.5.2.7 Environment", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "3252ea2bbf5cd8d405ebdaea97547c6ba6c9fee805bcd84773cff92414682f8b", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "- Data relationship;\n- Data storage capacity, retention time and details on data archiving;\n- Data integrity and protection;\n- Data migration (import and export).\n\n## 9.5.2.5 Interfaces\n\nThe interfaces between systems should be described, defining how the systems and subsystems interact, which they come and what they need. For systems regulated by BPx, protection of the interfaces is important. The following points should be addressed when appropriate:\n\n- **Interfaces with users.** This should be defined in roles (access profile), such as, operator, administrator, system manager, etc. Topics to be considered: types of peripherals; general format of screens and reports; error handling and reporting and security. User input mode(s) should be set(s), such as, keyboard and mouse, touchscreen; pen calligraphy;\n- **Interfaces with equipment,** such as sensors and plant equipment;\n- **Interfaces with other systems.** This should cover the nature and time of interaction and the methods and rules that govern the interaction between systems. If there are any middleware restrictions, this should be registered.\n\nThe following topics should be considered for any type of interface:\n\n- Data transmitted and received;\n- Data type, format, intervals and meaning of the values;\n- Time;\n- Data transfer fees;\n- Communication protocols: initiation and order of execution;\n- Any data sharing, creation, duplication, use, storage or destruction;\n- Initiation and interruption mechanisms;\n- Communication through parameters, common data areas or messages;\n- Direct access to internal data;\n- Error handling, recovery and reporting;\n- Access and security.\n\n## 9.5.2.6 Non-Functional Attributes\n\nHow the system will meet non-functional requirements should be described. The following items should be addressed when appropriate:\n\n- Availability (reliability, redundancy, error checking, stand-by operation);\n- Maintenance (possibilities for expansion and improvement; extra capacity; probable changes in environment and service life).\n\n## 9.5.2.7 Environment", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 2051, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "0d196aa7-c82a-4523-be73-ad088e908b69": {"__data__": {"id_": "0d196aa7-c82a-4523-be73-ad088e908b69", "embedding": null, "metadata": {"page_label": "39", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 9.5.2.8 Glossary\n\nDefinitions of any little-known terms should be provided.\n\n# 9.5.2.9 Appendices\n\nWhere appropriate, for example, for small systems, appendices should be provided to define the specifications *hardware* and *software*.\n\n# 9.6 DOCUMENT CONTAINING THE CONFIGURATION AND DESIGN\n\n## 9.6.1 Introduction\n\nThis section discusses how to define the required configuration of the system components and the project system.\n\nDepending on the type of system (configurable or customized), the configuration and design specifications provide a detailed technical expansion of the functional specifications. Define the features and flexibility of the system, properties and specifications. The information generated forms the basis for subsequent configuration management activity.\n\nThere is no need to prepare separate documents to define the configuration and the project. An specification hierarchy may be necessary for larger and more complex systems, as for systems smaller ones or considered low-risk specifications can be combined.\n\n## 9.6.2 Overview\n\n### 9.6.2.1 Configuration\n\nFor configurable products, configuration specifications that make up the system must be prepared for that it meets the user's requirements. This includes defining all settings and parameters.\n\nThese configuration specifications are produced by the system supplier and reviewed and approved by regulated company.\n\nIt is possible to maintain this set of configuration specifications on systems that are managed robust configuration (detailed and complete *audit trails*). Such an approach must be well documented.\n\n## 9.6.2.2 Project (*Design*)\n\nFor customized applications, a document containing the *hardware* and software design must be prepared.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos establece directrices sobre c\u00f3mo definir la configuraci\u00f3n y el dise\u00f1o de los sistemas, tanto configurables como personalizados. Se enfatiza la importancia de las especificaciones de configuraci\u00f3n para cumplir con los requisitos del usuario y la necesidad de documentaci\u00f3n adecuada para la gesti\u00f3n de configuraciones. Adem\u00e1s, se menciona que no es necesario crear documentos separados para la configuraci\u00f3n y el proyecto, aunque en sistemas m\u00e1s complejos puede ser \u00fatil establecer una jerarqu\u00eda de especificaciones.\n\n### Preguntas\n\n1. **\u00bfQu\u00e9 tipo de documentaci\u00f3n se requiere para los sistemas configurables y personalizados seg\u00fan el documento de ANVISA?**\n   - El documento establece que para sistemas configurables se deben preparar especificaciones de configuraci\u00f3n que definan todos los ajustes y par\u00e1metros necesarios para cumplir con los requisitos del usuario. Para aplicaciones personalizadas, se debe preparar un documento que contenga el dise\u00f1o del hardware y del software.\n\n2. **\u00bfCu\u00e1l es la importancia de las especificaciones de configuraci\u00f3n en la gesti\u00f3n de sistemas inform\u00e1ticos?**\n   - Las especificaciones de configuraci\u00f3n son fundamentales porque proporcionan una expansi\u00f3n t\u00e9cnica detallada de las especificaciones funcionales, definiendo las caracter\u00edsticas y flexibilidad del sistema. Esta informaci\u00f3n es la base para las actividades posteriores de gesti\u00f3n de configuraciones.\n\n3. **\u00bfC\u00f3mo se debe manejar la documentaci\u00f3n de las especificaciones de configuraci\u00f3n en sistemas con gesti\u00f3n robusta de configuraciones?**\n   - En sistemas que cuentan con una gesti\u00f3n robusta de configuraciones, se debe mantener un conjunto de especificaciones de configuraci\u00f3n bien documentado, que incluya auditor\u00edas detalladas y completas. Esto asegura que todos los cambios y configuraciones sean rastreables y est\u00e9n debidamente aprobados.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos aborda varios aspectos fundamentales que son esenciales para garantizar la integridad y funcionalidad de los sistemas en un entorno regulado. A continuaci\u00f3n se presentan los temas clave y las entidades mencionadas en la secci\u00f3n:\n\n1. **Relaci\u00f3n de Datos**:\n   - Se enfatiza la importancia de definir c\u00f3mo se relacionan los datos dentro del sistema.\n\n2. **Capacidad de Almacenamiento de Datos**:\n   - Detalles sobre la capacidad de almacenamiento, el tiempo de retenci\u00f3n y el archivo de datos.\n\n3. **Integridad y Protecci\u00f3n de Datos**:\n   - Se requiere asegurar la integridad de los datos y su protecci\u00f3n contra accesos no autorizados.\n\n4. **Migraci\u00f3n de Datos**:\n   - Aspectos relacionados con la importaci\u00f3n y exportaci\u00f3n de datos.\n\n5. **Interfaces**:\n   - **Interfaces con Usuarios**: Definici\u00f3n de roles de acceso (operador, administrador, etc.) y consideraciones sobre la interacci\u00f3n del usuario, incluyendo tipos de perif\u00e9ricos y manejo de errores.\n   - **Interfaces con Equipos**: Conexiones con sensores y equipos de planta.\n   - **Interfaces con Otros Sistemas**: Naturaleza de la interacci\u00f3n, m\u00e9todos y reglas que rigen la comunicaci\u00f3n entre sistemas, incluyendo restricciones de middleware.\n\n6. **Atributos No Funcionales**:\n   - **Disponibilidad**: Fiabilidad, redundancia, verificaci\u00f3n de errores y operaci\u00f3n en espera.\n   - **Mantenimiento**: Posibilidades de expansi\u00f3n, mejora y adaptaci\u00f3n a cambios en el entorno.\n\n7. **Entorno**:\n   - Consideraciones sobre el entorno en el que operan los sistemas inform\u00e1ticos.\n\n### Entidades Clave\n- **Roles de Usuario**: Operador, administrador, gerente de sistema.\n- **Tipos de Interfaces**: Interfaces con usuarios, equipos y otros sistemas.\n- **Protocolos de Comunicaci\u00f3n**: M\u00e9todos de interacci\u00f3n y reglas de comunicaci\u00f3n.\n- **Mecanismos de Manejo de Errores**: Procedimientos para la recuperaci\u00f3n y manejo de errores.\n- **Requisitos No Funcionales**: Disponibilidad y mantenimiento del sistema.\n\nEste resumen destaca la importancia de una planificaci\u00f3n cuidadosa y la documentaci\u00f3n detallada en la validaci\u00f3n de sistemas inform\u00e1ticos, asegurando que se cumplan tanto los requisitos funcionales como los no funcionales.", "excerpt_keywords": "Keywords: validation, configuration, specifications, hardware, software"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "d049c578-fc0a-4eec-ba62-7eba5d500b10", "node_type": "4", "metadata": {"page_label": "39", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 9.5.2.8 Glossary\n\nDefinitions of any little-known terms should be provided.\n\n# 9.5.2.9 Appendices\n\nWhere appropriate, for example, for small systems, appendices should be provided to define the specifications *hardware* and *software*.\n\n# 9.6 DOCUMENT CONTAINING THE CONFIGURATION AND DESIGN\n\n## 9.6.1 Introduction\n\nThis section discusses how to define the required configuration of the system components and the project system.\n\nDepending on the type of system (configurable or customized), the configuration and design specifications provide a detailed technical expansion of the functional specifications. Define the features and flexibility of the system, properties and specifications. The information generated forms the basis for subsequent configuration management activity.\n\nThere is no need to prepare separate documents to define the configuration and the project. An specification hierarchy may be necessary for larger and more complex systems, as for systems smaller ones or considered low-risk specifications can be combined.\n\n## 9.6.2 Overview\n\n### 9.6.2.1 Configuration\n\nFor configurable products, configuration specifications that make up the system must be prepared for that it meets the user's requirements. This includes defining all settings and parameters.\n\nThese configuration specifications are produced by the system supplier and reviewed and approved by regulated company.\n\nIt is possible to maintain this set of configuration specifications on systems that are managed robust configuration (detailed and complete *audit trails*). Such an approach must be well documented.\n\n## 9.6.2.2 Project (*Design*)\n\nFor customized applications, a document containing the *hardware* and software design must be prepared.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "3abdcee3c6205b1a6db2517278f97f2b2a3b310fa0752376a3e424daa46d43bf", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "# 9.5.2.8 Glossary\n\nDefinitions of any little-known terms should be provided.\n\n# 9.5.2.9 Appendices\n\nWhere appropriate, for example, for small systems, appendices should be provided to define the specifications *hardware* and *software*.\n\n# 9.6 DOCUMENT CONTAINING THE CONFIGURATION AND DESIGN\n\n## 9.6.1 Introduction\n\nThis section discusses how to define the required configuration of the system components and the project system.\n\nDepending on the type of system (configurable or customized), the configuration and design specifications provide a detailed technical expansion of the functional specifications. Define the features and flexibility of the system, properties and specifications. The information generated forms the basis for subsequent configuration management activity.\n\nThere is no need to prepare separate documents to define the configuration and the project. An specification hierarchy may be necessary for larger and more complex systems, as for systems smaller ones or considered low-risk specifications can be combined.\n\n## 9.6.2 Overview\n\n### 9.6.2.1 Configuration\n\nFor configurable products, configuration specifications that make up the system must be prepared for that it meets the user's requirements. This includes defining all settings and parameters.\n\nThese configuration specifications are produced by the system supplier and reviewed and approved by regulated company.\n\nIt is possible to maintain this set of configuration specifications on systems that are managed robust configuration (detailed and complete *audit trails*). Such an approach must be well documented.\n\n## 9.6.2.2 Project (*Design*)\n\nFor customized applications, a document containing the *hardware* and software design must be prepared.", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 1736, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "04a50fa5-2627-4899-b511-ad46b2091cec": {"__data__": {"id_": "04a50fa5-2627-4899-b511-ad46b2091cec", "embedding": null, "metadata": {"page_label": "40", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 9.6.3 General Considerations\n\nThe use of tables and diagrams to illustrate the Configuration and Design Specifications is highly recommended. Standardized tables can help ensure that all parameters and settings have been defined. Diagrams can help within the software project to clarify and explain the data flow, the logical control, data structures and interfaces. Diagrams in hardware design can help understand about architecture and connectivity.\n\nConfiguration and Design must cover both hardware and software aspects. Depending on the risk, size and complexity of the system these points can be covered by a simple specification or can demand a hierarchy of specifications covering hardware and software separately. Each specification must be referenced individually and be traceable to the associated high-level specification.\n\nAll specifications must be structured to support traceability throughout the entire life cycle from the individual application to the test associated with this requirement.\n\n# 9.6.4 Document Content\n\nThe sections described below are not intended to be prescriptive or exhaustive. The level of detail it depends on the risk, complexity and innovation of the system. They can be part of a simple document or of a document hierarchy.\n\n## 9.6.4.1 Introduction\n\nIt should contain the following items:\n\n- Ownership of the document containing the configuration and the project;\n- Who produced the document, under what authority and for what purpose;", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la Validaci\u00f3n de Sistemas Inform\u00e1ticos enfatiza la importancia de las especificaciones de configuraci\u00f3n y dise\u00f1o, tanto para hardware como para software. Se recomienda el uso de tablas y diagramas para ilustrar estos aspectos, asegurando que todos los par\u00e1metros est\u00e9n definidos y que la trazabilidad se mantenga a lo largo del ciclo de vida del sistema. Adem\u00e1s, se menciona que el contenido del documento debe adaptarse al riesgo, complejidad e innovaci\u00f3n del sistema, y se sugiere que la introducci\u00f3n del documento incluya detalles sobre la propiedad y la producci\u00f3n del mismo.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfQu\u00e9 elementos se deben incluir en la introducci\u00f3n del documento de configuraci\u00f3n y dise\u00f1o seg\u00fan la gu\u00eda de ANVISA?**\n   - La introducci\u00f3n debe contener la propiedad del documento, qui\u00e9n lo produjo, bajo qu\u00e9 autoridad y con qu\u00e9 prop\u00f3sito.\n\n2. **\u00bfC\u00f3mo se debe estructurar la documentaci\u00f3n para asegurar la trazabilidad a lo largo del ciclo de vida del sistema?**\n   - Todas las especificaciones deben estar estructuradas para soportar la trazabilidad desde la aplicaci\u00f3n individual hasta las pruebas asociadas con cada requisito.\n\n3. **\u00bfQu\u00e9 factores determinan el nivel de detalle que debe incluirse en las especificaciones de configuraci\u00f3n y dise\u00f1o?**\n   - El nivel de detalle depende del riesgo, la complejidad y la innovaci\u00f3n del sistema, pudiendo ser parte de un documento simple o de una jerarqu\u00eda de documentos.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Documentaci\u00f3n de Configuraci\u00f3n y Dise\u00f1o**:\n   - Se requiere documentaci\u00f3n espec\u00edfica para definir la configuraci\u00f3n y el dise\u00f1o de sistemas inform\u00e1ticos, tanto configurables como personalizados.\n\n2. **Especificaciones de Configuraci\u00f3n**:\n   - Para sistemas configurables, es esencial preparar especificaciones que definan todos los ajustes y par\u00e1metros necesarios para cumplir con los requisitos del usuario. Estas especificaciones son producidas por el proveedor del sistema y deben ser revisadas y aprobadas por la empresa regulada.\n\n3. **Gesti\u00f3n de Configuraciones**:\n   - La informaci\u00f3n generada a partir de las especificaciones de configuraci\u00f3n es fundamental para las actividades de gesti\u00f3n de configuraciones posteriores. En sistemas con gesti\u00f3n robusta de configuraciones, se debe mantener un conjunto bien documentado de especificaciones que incluya auditor\u00edas detalladas.\n\n4. **Dise\u00f1o de Aplicaciones Personalizadas**:\n   - Para aplicaciones personalizadas, es necesario preparar un documento que contenga el dise\u00f1o del hardware y del software.\n\n5. **Jerarqu\u00eda de Especificaciones**:\n   - En sistemas m\u00e1s grandes y complejos, puede ser \u00fatil establecer una jerarqu\u00eda de especificaciones, mientras que en sistemas m\u00e1s peque\u00f1os o de bajo riesgo, las especificaciones pueden combinarse.\n\n### Entidades Clave\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil, responsable de la regulaci\u00f3n de sistemas inform\u00e1ticos en el \u00e1mbito de la salud.\n- **Sistemas Configurables**: Productos que pueden ser ajustados seg\u00fan las necesidades del usuario.\n- **Sistemas Personalizados**: Aplicaciones dise\u00f1adas espec\u00edficamente para cumplir con requisitos particulares.\n- **Especificaciones de Configuraci\u00f3n**: Documentos que detallan los ajustes y par\u00e1metros de un sistema.\n- **Gesti\u00f3n de Configuraciones**: Proceso de mantener y controlar los cambios en los sistemas inform\u00e1ticos. \n\nEste resumen destaca la importancia de la documentaci\u00f3n y la gesti\u00f3n adecuada en la validaci\u00f3n de sistemas inform\u00e1ticos seg\u00fan las directrices de ANVISA.", "excerpt_keywords": "Keywords: ANVISA, Computer Systems Validation, Configuration Specifications, Document Traceability, Hardware and Software Design"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "8634242a-1aa1-4dc4-b36c-aad86e2326a5", "node_type": "4", "metadata": {"page_label": "40", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 9.6.3 General Considerations\n\nThe use of tables and diagrams to illustrate the Configuration and Design Specifications is highly recommended. Standardized tables can help ensure that all parameters and settings have been defined. Diagrams can help within the software project to clarify and explain the data flow, the logical control, data structures and interfaces. Diagrams in hardware design can help understand about architecture and connectivity.\n\nConfiguration and Design must cover both hardware and software aspects. Depending on the risk, size and complexity of the system these points can be covered by a simple specification or can demand a hierarchy of specifications covering hardware and software separately. Each specification must be referenced individually and be traceable to the associated high-level specification.\n\nAll specifications must be structured to support traceability throughout the entire life cycle from the individual application to the test associated with this requirement.\n\n# 9.6.4 Document Content\n\nThe sections described below are not intended to be prescriptive or exhaustive. The level of detail it depends on the risk, complexity and innovation of the system. They can be part of a simple document or of a document hierarchy.\n\n## 9.6.4.1 Introduction\n\nIt should contain the following items:\n\n- Ownership of the document containing the configuration and the project;\n- Who produced the document, under what authority and for what purpose;", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "5df72c41d3fd7af107c5201a96593a9bec879b8b13c0b6de29126bcd4d73da9a", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "# 9.6.3 General Considerations\n\nThe use of tables and diagrams to illustrate the Configuration and Design Specifications is highly recommended. Standardized tables can help ensure that all parameters and settings have been defined. Diagrams can help within the software project to clarify and explain the data flow, the logical control, data structures and interfaces. Diagrams in hardware design can help understand about architecture and connectivity.\n\nConfiguration and Design must cover both hardware and software aspects. Depending on the risk, size and complexity of the system these points can be covered by a simple specification or can demand a hierarchy of specifications covering hardware and software separately. Each specification must be referenced individually and be traceable to the associated high-level specification.\n\nAll specifications must be structured to support traceability throughout the entire life cycle from the individual application to the test associated with this requirement.\n\n# 9.6.4 Document Content\n\nThe sections described below are not intended to be prescriptive or exhaustive. The level of detail it depends on the risk, complexity and innovation of the system. They can be part of a simple document or of a document hierarchy.\n\n## 9.6.4.1 Introduction\n\nIt should contain the following items:\n\n- Ownership of the document containing the configuration and the project;\n- Who produced the document, under what authority and for what purpose;", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 1480, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "7f7fad55-48c4-4bba-9877-36a7b76d2480": {"__data__": {"id_": "7f7fad55-48c4-4bba-9877-36a7b76d2480", "embedding": null, "metadata": {"page_label": "41", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 9.6.4.2 Overview\n\nThis section should briefly describe the configuration and/or design. Depending on the complexity of the system, this can cover the complete system, **hardware** and/or **software**. This section can be illustrated using diagrams.\n\n# 9.6.4.3 Configuration\n\nThe necessary configuration of the components must be provided, including, but not limited to:\n\n- Settings, or configuration parameters, needed;\n- Reason for configuration, with reference to the control specification;\n- Tools or methods that will be used to define the necessary configuration options;\n- Dependencies or impacts of/on other modules or systems;\n- Infrastructure items such as operating systems or layered software;\n- Settings security.\n\nFor small systems it may be possible to incorporate this information into the Specifications document Functional.\n\n# 9.6.4.4 Hardware Design\n\n## 9.6.4.4.1 The Computerized System\n\nThe general architecture of the necessary **hardware** must be defined. At a high level this can be illustrated by block diagram showing both the functions of the parties and their functional relationships. The following items should be covered, where appropriate:\n\n- **Main computer system** - Must describe the primary **hardware** components of the system main computer, such as central processing unit (CPU), memory, **bus** type; accuracy clock etc.;\n- **Storage** - Describe all proposed memory devices with their respective maximum storage capacities, such as **hard disk**; **CD writer**, tapes etc.;\n- **Peripherals** - Must describe the necessary peripheral devices, including any requirements specific to your installation;\n- **Interconnections/networks** - Must describe all **hardware** component interconnections and any connections with other equipment, devices and computer systems. This description may contain the following items: cable specifications; connector specifications; shielding requirements; networks or other external connections, etc.;\n- **Configuration**;\n- **Embedded systems** (inside the process equipment) - Must include the following elements: layout diagrams for detailing the control panel and internal and external arrangements; diagrams of\n\n----\n\n*Guide for Computer Systems Validation*\n*Guide n\u00b0 33/2020 - version 1, of 03/26/2020*", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas que pueden proporcionar respuestas espec\u00edficas basadas en el contexto proporcionado, as\u00ed como un resumen de nivel superior del contenido:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos establece directrices para describir la configuraci\u00f3n y dise\u00f1o de sistemas, tanto de hardware como de software. Se enfatiza la importancia de detallar la configuraci\u00f3n necesaria de los componentes, incluyendo par\u00e1metros, razones de configuraci\u00f3n, herramientas utilizadas, y la interconexi\u00f3n de hardware. Adem\u00e1s, se requiere una descripci\u00f3n de la arquitectura del hardware, que incluye el sistema inform\u00e1tico principal, dispositivos de almacenamiento, perif\u00e9ricos, interconexiones y sistemas embebidos.\n\n### Preguntas\n\n1. **\u00bfQu\u00e9 elementos espec\u00edficos deben incluirse en la descripci\u00f3n de la configuraci\u00f3n de un sistema inform\u00e1tico seg\u00fan la gu\u00eda de ANVISA?**\n   - La gu\u00eda menciona que se deben incluir configuraciones necesarias, par\u00e1metros, razones para la configuraci\u00f3n, herramientas utilizadas, dependencias con otros m\u00f3dulos, elementos de infraestructura y seguridad de la configuraci\u00f3n.\n\n2. **\u00bfC\u00f3mo se debe representar la arquitectura del hardware en la documentaci\u00f3n de validaci\u00f3n de sistemas inform\u00e1ticos?**\n   - La arquitectura del hardware debe ser representada a un alto nivel mediante un diagrama de bloques que muestre las funciones de las partes involucradas y sus relaciones funcionales.\n\n3. **\u00bfQu\u00e9 aspectos se deben considerar al describir los dispositivos de almacenamiento en un sistema inform\u00e1tico?**\n   - Se debe describir todos los dispositivos de memoria propuestos junto con sus capacidades m\u00e1ximas de almacenamiento, como discos duros, grabadoras de CD, cintas, etc. Adem\u00e1s, se deben considerar las especificaciones de los dispositivos perif\u00e9ricos y las interconexiones con otros equipos.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Uso de Tablas y Diagramas**: Se recomienda el uso de tablas estandarizadas y diagramas para ilustrar las Especificaciones de Configuraci\u00f3n y Dise\u00f1o, facilitando la definici\u00f3n de par\u00e1metros y la comprensi\u00f3n del flujo de datos, control l\u00f3gico, estructuras de datos e interfaces.\n\n2. **Cobertura de Hardware y Software**: Las especificaciones de configuraci\u00f3n y dise\u00f1o deben abarcar tanto aspectos de hardware como de software. La complejidad y el riesgo del sistema determinar\u00e1n si se requiere una especificaci\u00f3n simple o una jerarqu\u00eda de especificaciones.\n\n3. **Trazabilidad**: Todas las especificaciones deben estar estructuradas para garantizar la trazabilidad a lo largo del ciclo de vida del sistema, desde la aplicaci\u00f3n individual hasta las pruebas asociadas.\n\n4. **Contenido del Documento**: El contenido del documento no es prescriptivo ni exhaustivo; el nivel de detalle debe ajustarse al riesgo, complejidad e innovaci\u00f3n del sistema. La introducci\u00f3n del documento debe incluir informaci\u00f3n sobre la propiedad, producci\u00f3n y prop\u00f3sito del mismo.\n\n### Entidades Clave\n\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria en Brasil, responsable de la regulaci\u00f3n de sistemas inform\u00e1ticos en el \u00e1mbito de la salud.\n- **Especificaciones de Configuraci\u00f3n y Dise\u00f1o**: Documentos que detallan los par\u00e1metros y configuraciones de un sistema inform\u00e1tico.\n- **Hardware y Software**: Componentes que deben ser considerados en las especificaciones de configuraci\u00f3n y dise\u00f1o.\n- **Trazabilidad**: Proceso de seguimiento y verificaci\u00f3n de requisitos a lo largo del ciclo de vida del sistema. \n\nEste resumen destaca la importancia de la documentaci\u00f3n adecuada y la trazabilidad en la validaci\u00f3n de sistemas inform\u00e1ticos, as\u00ed como la necesidad de adaptar el contenido a las caracter\u00edsticas espec\u00edficas del sistema en cuesti\u00f3n.", "excerpt_keywords": "Keywords: ANVISA, Computer Systems Validation, hardware design, configuration, software specifications"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "f5116f2a-d1a9-4264-9ea9-400fa804bd27", "node_type": "4", "metadata": {"page_label": "41", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 9.6.4.2 Overview\n\nThis section should briefly describe the configuration and/or design. Depending on the complexity of the system, this can cover the complete system, **hardware** and/or **software**. This section can be illustrated using diagrams.\n\n# 9.6.4.3 Configuration\n\nThe necessary configuration of the components must be provided, including, but not limited to:\n\n- Settings, or configuration parameters, needed;\n- Reason for configuration, with reference to the control specification;\n- Tools or methods that will be used to define the necessary configuration options;\n- Dependencies or impacts of/on other modules or systems;\n- Infrastructure items such as operating systems or layered software;\n- Settings security.\n\nFor small systems it may be possible to incorporate this information into the Specifications document Functional.\n\n# 9.6.4.4 Hardware Design\n\n## 9.6.4.4.1 The Computerized System\n\nThe general architecture of the necessary **hardware** must be defined. At a high level this can be illustrated by block diagram showing both the functions of the parties and their functional relationships. The following items should be covered, where appropriate:\n\n- **Main computer system** - Must describe the primary **hardware** components of the system main computer, such as central processing unit (CPU), memory, **bus** type; accuracy clock etc.;\n- **Storage** - Describe all proposed memory devices with their respective maximum storage capacities, such as **hard disk**; **CD writer**, tapes etc.;\n- **Peripherals** - Must describe the necessary peripheral devices, including any requirements specific to your installation;\n- **Interconnections/networks** - Must describe all **hardware** component interconnections and any connections with other equipment, devices and computer systems. This description may contain the following items: cable specifications; connector specifications; shielding requirements; networks or other external connections, etc.;\n- **Configuration**;\n- **Embedded systems** (inside the process equipment) - Must include the following elements: layout diagrams for detailing the control panel and internal and external arrangements; diagrams of\n\n----\n\n*Guide for Computer Systems Validation*\n*Guide n\u00b0 33/2020 - version 1, of 03/26/2020*", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "201fd4e68a9d12779108bae86f02970fea7c98d3d15192525bed157044d67490", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "# 9.6.4.2 Overview\n\nThis section should briefly describe the configuration and/or design. Depending on the complexity of the system, this can cover the complete system, **hardware** and/or **software**. This section can be illustrated using diagrams.\n\n# 9.6.4.3 Configuration\n\nThe necessary configuration of the components must be provided, including, but not limited to:\n\n- Settings, or configuration parameters, needed;\n- Reason for configuration, with reference to the control specification;\n- Tools or methods that will be used to define the necessary configuration options;\n- Dependencies or impacts of/on other modules or systems;\n- Infrastructure items such as operating systems or layered software;\n- Settings security.\n\nFor small systems it may be possible to incorporate this information into the Specifications document Functional.\n\n# 9.6.4.4 Hardware Design\n\n## 9.6.4.4.1 The Computerized System\n\nThe general architecture of the necessary **hardware** must be defined. At a high level this can be illustrated by block diagram showing both the functions of the parties and their functional relationships. The following items should be covered, where appropriate:\n\n- **Main computer system** - Must describe the primary **hardware** components of the system main computer, such as central processing unit (CPU), memory, **bus** type; accuracy clock etc.;\n- **Storage** - Describe all proposed memory devices with their respective maximum storage capacities, such as **hard disk**; **CD writer**, tapes etc.;\n- **Peripherals** - Must describe the necessary peripheral devices, including any requirements specific to your installation;\n- **Interconnections/networks** - Must describe all **hardware** component interconnections and any connections with other equipment, devices and computer systems. This description may contain the following items: cable specifications; connector specifications; shielding requirements; networks or other external connections, etc.;\n- **Configuration**;\n- **Embedded systems** (inside the process equipment) - Must include the following elements: layout diagrams for detailing the control panel and internal and external arrangements; diagrams of\n\n----\n\n*Guide for Computer Systems Validation*\n*Guide n\u00b0 33/2020 - version 1, of 03/26/2020*", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 2282, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "411fe2d7-de39-4de5-b410-8a60bcc09248": {"__data__": {"id_": "411fe2d7-de39-4de5-b410-8a60bcc09248", "embedding": null, "metadata": {"page_label": "42", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "location to indicate where sensors and other devices are installed on the equipment; diagrams of electrical wiring and piping / process drawings and instrumentation diagram (P&ID);\n- Reference to relevant standards / norms.\n\n## 9.6.4.4.2 Inputs and Outputs\n\nThe formats of the inputs and outputs should, when necessary, be specified. These may include the signs digital and / or analog.\n\nFor external equipment the following elements must be considered:\n\n- Accuracy;\n- Isolation;\n- Current and voltage range;\n- Types and number of interface cards;\n- Time.\n\n## 9.6.4.4.3 Environment\n\nThe operating environment for the hardware must be defined. The following topics should be considered:\n\n- Temperature;\n- Moisture;\n- External interference;\n- Physical security;\n- Shielding against radio frequency, electromagnetic and / or UV interference;\n- Protection against physical damage such as dust or vibration.\n\n## 9.6.4.4.4 Power Supply\n\nThe requirements for power supply for the configured hardware must be described. The following elements should be considered:\n\n- Filtration;\n- Loading;\n- Grounding;\n- Stability;\n- Uninterruptible power supplies (UPS);\n- Energy consumption and / or heat emission to calculate the required air conditioning capacity or heating, ventilation and air conditioning (HVAC) system.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "### Resumen del Contexto\n\nEl documento \"ANVISA - Guide for Computer Systems Validation 33/2020\" proporciona directrices sobre la validaci\u00f3n de sistemas inform\u00e1ticos en el contexto de la regulaci\u00f3n de la salud en Brasil. Se enfoca en aspectos t\u00e9cnicos relacionados con la instalaci\u00f3n y operaci\u00f3n de hardware, incluyendo la ubicaci\u00f3n de sensores, diagramas el\u00e9ctricos, especificaciones de entradas y salidas, condiciones ambientales, y requisitos de suministro el\u00e9ctrico. Se enfatiza la importancia de considerar la precisi\u00f3n, la seguridad f\u00edsica, la interferencia externa, y la estabilidad del suministro el\u00e9ctrico, entre otros factores.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfQu\u00e9 consideraciones espec\u00edficas se deben tener en cuenta al definir la precisi\u00f3n de los equipos externos en el contexto de la validaci\u00f3n de sistemas inform\u00e1ticos?**\n   - Esta pregunta busca detalles sobre c\u00f3mo se debe evaluar y documentar la precisi\u00f3n de los equipos, lo cual es crucial para garantizar la fiabilidad de los datos obtenidos.\n\n2. **\u00bfCu\u00e1les son las medidas recomendadas para proteger el hardware contra interferencias externas, y c\u00f3mo se pueden implementar en un entorno de validaci\u00f3n?**\n   - Esta pregunta se centra en las estrategias pr\u00e1cticas que se pueden aplicar para mitigar los efectos de interferencias externas, lo que es vital para mantener la integridad del sistema.\n\n3. **\u00bfQu\u00e9 criterios se deben considerar al seleccionar un sistema de alimentaci\u00f3n ininterrumpida (UPS) para un entorno regulado por ANVISA?**\n   - Esta pregunta busca informaci\u00f3n sobre los aspectos t\u00e9cnicos y normativos que deben guiar la elecci\u00f3n de un UPS, asegurando que cumpla con los requisitos de estabilidad y seguridad en un entorno regulado.\n\nEstas preguntas est\u00e1n dise\u00f1adas para obtener respuestas que son espec\u00edficas y relevantes para el contexto de la validaci\u00f3n de sistemas inform\u00e1ticos seg\u00fan las directrices de ANVISA, y que probablemente no se encuentren en otras fuentes.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Configuraci\u00f3n y Dise\u00f1o del Sistema**:\n   - Se requiere una descripci\u00f3n breve de la configuraci\u00f3n y/o dise\u00f1o del sistema, abarcando tanto hardware como software, dependiendo de la complejidad del sistema.\n\n2. **Configuraci\u00f3n de Componentes**:\n   - Detalles necesarios sobre la configuraci\u00f3n de los componentes, que incluyen:\n     - Par\u00e1metros de configuraci\u00f3n.\n     - Razones para la configuraci\u00f3n, referenciando especificaciones de control.\n     - Herramientas o m\u00e9todos para definir opciones de configuraci\u00f3n.\n     - Dependencias o impactos en otros m\u00f3dulos o sistemas.\n     - Elementos de infraestructura como sistemas operativos.\n     - Seguridad de la configuraci\u00f3n.\n\n3. **Dise\u00f1o de Hardware**:\n   - Se debe definir la arquitectura general del hardware, que puede ser ilustrada mediante un diagrama de bloques. Los elementos a considerar incluyen:\n     - **Sistema inform\u00e1tico principal**: Componentes de hardware como CPU, memoria, tipo de bus, etc.\n     - **Almacenamiento**: Dispositivos de memoria propuestos y sus capacidades m\u00e1ximas.\n     - **Perif\u00e9ricos**: Dispositivos perif\u00e9ricos necesarios y requisitos espec\u00edficos.\n     - **Interconexiones/redes**: Descripci\u00f3n de interconexiones de hardware y conexiones con otros equipos, incluyendo especificaciones de cables y conectores.\n     - **Sistemas embebidos**: Elementos como diagramas de disposici\u00f3n del panel de control y arreglos internos y externos.\n\n### Entidades Clave\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil.\n- **Hardware**: Componentes f\u00edsicos del sistema inform\u00e1tico.\n- **Software**: Programas y aplicaciones que operan en el sistema.\n- **Diagrama de Bloques**: Herramienta visual para representar la arquitectura del hardware.\n- **Par\u00e1metros de Configuraci\u00f3n**: Ajustes necesarios para el funcionamiento del sistema.\n- **Dispositivos de Almacenamiento**: Incluyen discos duros, grabadoras de CD, cintas, etc.\n- **Perif\u00e9ricos**: Dispositivos externos conectados al sistema inform\u00e1tico.\n\nEste resumen proporciona una visi\u00f3n general de los aspectos fundamentales que deben considerarse al documentar la validaci\u00f3n de sistemas inform\u00e1ticos seg\u00fan la gu\u00eda de ANVISA.", "excerpt_keywords": "Keywords: ANVISA, computer systems validation, hardware requirements, environmental conditions, power supply specifications"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "0c6daacb-2fad-43c6-9b94-40496aec89da", "node_type": "4", "metadata": {"page_label": "42", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "location to indicate where sensors and other devices are installed on the equipment; diagrams of electrical wiring and piping / process drawings and instrumentation diagram (P&ID);\n- Reference to relevant standards / norms.\n\n## 9.6.4.4.2 Inputs and Outputs\n\nThe formats of the inputs and outputs should, when necessary, be specified. These may include the signs digital and / or analog.\n\nFor external equipment the following elements must be considered:\n\n- Accuracy;\n- Isolation;\n- Current and voltage range;\n- Types and number of interface cards;\n- Time.\n\n## 9.6.4.4.3 Environment\n\nThe operating environment for the hardware must be defined. The following topics should be considered:\n\n- Temperature;\n- Moisture;\n- External interference;\n- Physical security;\n- Shielding against radio frequency, electromagnetic and / or UV interference;\n- Protection against physical damage such as dust or vibration.\n\n## 9.6.4.4.4 Power Supply\n\nThe requirements for power supply for the configured hardware must be described. The following elements should be considered:\n\n- Filtration;\n- Loading;\n- Grounding;\n- Stability;\n- Uninterruptible power supplies (UPS);\n- Energy consumption and / or heat emission to calculate the required air conditioning capacity or heating, ventilation and air conditioning (HVAC) system.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "561b4ea914f3b762232d5e9934434391b388257aa628bb91209dfa8810a73e3c", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "location to indicate where sensors and other devices are installed on the equipment; diagrams of electrical wiring and piping / process drawings and instrumentation diagram (P&ID);\n- Reference to relevant standards / norms.\n\n## 9.6.4.4.2 Inputs and Outputs\n\nThe formats of the inputs and outputs should, when necessary, be specified. These may include the signs digital and / or analog.\n\nFor external equipment the following elements must be considered:\n\n- Accuracy;\n- Isolation;\n- Current and voltage range;\n- Types and number of interface cards;\n- Time.\n\n## 9.6.4.4.3 Environment\n\nThe operating environment for the hardware must be defined. The following topics should be considered:\n\n- Temperature;\n- Moisture;\n- External interference;\n- Physical security;\n- Shielding against radio frequency, electromagnetic and / or UV interference;\n- Protection against physical damage such as dust or vibration.\n\n## 9.6.4.4.4 Power Supply\n\nThe requirements for power supply for the configured hardware must be described. The following elements should be considered:\n\n- Filtration;\n- Loading;\n- Grounding;\n- Stability;\n- Uninterruptible power supplies (UPS);\n- Energy consumption and / or heat emission to calculate the required air conditioning capacity or heating, ventilation and air conditioning (HVAC) system.", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 1304, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "0fe90363-d79f-44b6-bf0d-46b9efaa7794": {"__data__": {"id_": "0fe90363-d79f-44b6-bf0d-46b9efaa7794", "embedding": null, "metadata": {"page_label": "43", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 9.6.4.5 Software Design\n\nThe software must be designed according to recognized standards for software development, when appropriate.\n\nSoftware design specifications are required for customized applications. These specifications do not are required for configurable systems, as in this case the software project is reviewed or evaluated as part of the computer system supplier's assessment.\n\n## 9.6.4.5.1 Description of the Software\n\nThe modules that will form the computerized system must be described, declaring the purpose of each module. A list detailing all the interfaces between the modules and any interfaces with external systems must be presented. A system diagram is recommended.\n\n## 9.6.4.5.2 System Data\n\nThe system data and the relevant data objects must be defined. The data must be characterized in a hierarchical way, with complex objects being built from simpler objects.\n\nObjects can include the following items:\n\n- Databases and file collections;\n- Files;\n- Records.\n\nA description of the data objects includes, but is not limited to:\n\n- Data types (integers, floating point numbers, characters, Booleans, string (string), objects (images and documents), etc.);\n- Data format (alphanumeric or numeric, field length, dates, etc.);\n- Data accuracy;\n- Data accuracy.\n\nEach file and data structure must be uniquely identified. The use of methods of describing data formats such as \u201cEntity Relationship Model\u201d or similar can be considered.\n\nIt is acceptable for system data to be defined separately as in a dictionary. If this is done therefore, this approach must be clearly explained and documented.\n\n## 9.6.4.5.3 Module Description\n\nFor each module, the following points must be covered:\n\n- Module operation: the description can take the form of a pseudocode or flow chart;\n- Interfaces with other modules: this point can refer to the system diagram, if there is one;", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos establece directrices para el dise\u00f1o de software, enfatizando la necesidad de especificaciones de dise\u00f1o para aplicaciones personalizadas y la descripci\u00f3n detallada de m\u00f3dulos y datos del sistema. Se requiere que cada m\u00f3dulo del sistema est\u00e9 claramente definido, incluyendo su operaci\u00f3n y las interfaces con otros m\u00f3dulos. Adem\u00e1s, se sugiere la utilizaci\u00f3n de diagramas de sistema y modelos de relaci\u00f3n de entidades para describir la estructura de datos.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfQu\u00e9 tipo de especificaciones de dise\u00f1o se requieren para las aplicaciones personalizadas seg\u00fan el documento de ANVISA?**\n   - Las aplicaciones personalizadas requieren especificaciones de dise\u00f1o de software, mientras que para los sistemas configurables no son necesarias, ya que el proyecto de software se eval\u00faa como parte de la evaluaci\u00f3n del proveedor del sistema inform\u00e1tico.\n\n2. **\u00bfC\u00f3mo deben ser descritos los datos del sistema y qu\u00e9 elementos deben incluirse en esta descripci\u00f3n?**\n   - Los datos del sistema deben definirse de manera jer\u00e1rquica, caracterizando objetos complejos construidos a partir de objetos m\u00e1s simples. La descripci\u00f3n debe incluir tipos de datos, formatos de datos, precisi\u00f3n de datos y debe asegurarse que cada archivo y estructura de datos est\u00e9 identificado de manera \u00fanica.\n\n3. **\u00bfQu\u00e9 informaci\u00f3n se debe proporcionar para cada m\u00f3dulo del sistema seg\u00fan las directrices de ANVISA?**\n   - Para cada m\u00f3dulo, se debe cubrir la operaci\u00f3n del m\u00f3dulo (que puede describirse en forma de pseudoc\u00f3digo o diagrama de flujo) y las interfaces con otros m\u00f3dulos, haciendo referencia al diagrama del sistema si existe.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\nEl documento \"ANVISA - Guide for Computer Systems Validation 33/2020\" aborda aspectos fundamentales para la validaci\u00f3n de sistemas inform\u00e1ticos en el \u00e1mbito de la salud en Brasil. A continuaci\u00f3n se resumen los temas clave de la secci\u00f3n:\n\n1. **Instalaci\u00f3n de Equipos**:\n   - Importancia de indicar la ubicaci\u00f3n de sensores y dispositivos en el equipo.\n   - Inclusi\u00f3n de diagramas el\u00e9ctricos y de procesos (P&ID).\n\n2. **Entradas y Salidas (Inputs and Outputs)**:\n   - Especificaci\u00f3n de formatos de entradas y salidas, tanto digitales como anal\u00f3gicas.\n   - Consideraciones para equipos externos: precisi\u00f3n, aislamiento, rango de corriente y voltaje, tipos y n\u00famero de tarjetas de interfaz, y tiempo.\n\n3. **Entorno Operativo**:\n   - Definici\u00f3n del entorno de operaci\u00f3n del hardware, considerando:\n     - Temperatura y humedad.\n     - Interferencias externas.\n     - Seguridad f\u00edsica.\n     - Apantallamiento contra interferencias de radiofrecuencia, electromagn\u00e9ticas y UV.\n     - Protecci\u00f3n contra da\u00f1os f\u00edsicos (polvo, vibraciones).\n\n4. **Suministro El\u00e9ctrico**:\n   - Descripci\u00f3n de los requisitos de suministro el\u00e9ctrico para el hardware configurado, incluyendo:\n     - Filtraci\u00f3n.\n     - Carga.\n     - Puesta a tierra.\n     - Estabilidad.\n     - Sistemas de alimentaci\u00f3n ininterrumpida (UPS).\n     - Consumo de energ\u00eda y emisi\u00f3n de calor para calcular la capacidad necesaria del sistema de climatizaci\u00f3n (HVAC).\n\n### Entidades Clave\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil.\n- **Hardware**: Equipos f\u00edsicos utilizados en sistemas inform\u00e1ticos.\n- **Sensores y Dispositivos**: Elementos que recopilan datos y se integran en el sistema.\n- **Diagramas El\u00e9ctricos y P&ID**: Representaciones gr\u00e1ficas de la instalaci\u00f3n y funcionamiento de los sistemas.\n- **UPS (Sistemas de Alimentaci\u00f3n Ininterrumpida)**: Equipos que proporcionan energ\u00eda continua ante cortes de suministro.\n\nEste resumen destaca la importancia de considerar m\u00faltiples factores t\u00e9cnicos y normativos para garantizar la validaci\u00f3n efectiva de sistemas inform\u00e1ticos en entornos regulados.", "excerpt_keywords": "Keywords: software design, system validation, data objects, module description, ANVISA"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "172fc6d8-cd1a-4723-ad44-b082b5837f92", "node_type": "4", "metadata": {"page_label": "43", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 9.6.4.5 Software Design\n\nThe software must be designed according to recognized standards for software development, when appropriate.\n\nSoftware design specifications are required for customized applications. These specifications do not are required for configurable systems, as in this case the software project is reviewed or evaluated as part of the computer system supplier's assessment.\n\n## 9.6.4.5.1 Description of the Software\n\nThe modules that will form the computerized system must be described, declaring the purpose of each module. A list detailing all the interfaces between the modules and any interfaces with external systems must be presented. A system diagram is recommended.\n\n## 9.6.4.5.2 System Data\n\nThe system data and the relevant data objects must be defined. The data must be characterized in a hierarchical way, with complex objects being built from simpler objects.\n\nObjects can include the following items:\n\n- Databases and file collections;\n- Files;\n- Records.\n\nA description of the data objects includes, but is not limited to:\n\n- Data types (integers, floating point numbers, characters, Booleans, string (string), objects (images and documents), etc.);\n- Data format (alphanumeric or numeric, field length, dates, etc.);\n- Data accuracy;\n- Data accuracy.\n\nEach file and data structure must be uniquely identified. The use of methods of describing data formats such as \u201cEntity Relationship Model\u201d or similar can be considered.\n\nIt is acceptable for system data to be defined separately as in a dictionary. If this is done therefore, this approach must be clearly explained and documented.\n\n## 9.6.4.5.3 Module Description\n\nFor each module, the following points must be covered:\n\n- Module operation: the description can take the form of a pseudocode or flow chart;\n- Interfaces with other modules: this point can refer to the system diagram, if there is one;", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "45c8196429ac4e6ec92e884c538fa82098c1971a7e293407917b0e46ecdd1064", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "# 9.6.4.5 Software Design\n\nThe software must be designed according to recognized standards for software development, when appropriate.\n\nSoftware design specifications are required for customized applications. These specifications do not are required for configurable systems, as in this case the software project is reviewed or evaluated as part of the computer system supplier's assessment.\n\n## 9.6.4.5.1 Description of the Software\n\nThe modules that will form the computerized system must be described, declaring the purpose of each module. A list detailing all the interfaces between the modules and any interfaces with external systems must be presented. A system diagram is recommended.\n\n## 9.6.4.5.2 System Data\n\nThe system data and the relevant data objects must be defined. The data must be characterized in a hierarchical way, with complex objects being built from simpler objects.\n\nObjects can include the following items:\n\n- Databases and file collections;\n- Files;\n- Records.\n\nA description of the data objects includes, but is not limited to:\n\n- Data types (integers, floating point numbers, characters, Booleans, string (string), objects (images and documents), etc.);\n- Data format (alphanumeric or numeric, field length, dates, etc.);\n- Data accuracy;\n- Data accuracy.\n\nEach file and data structure must be uniquely identified. The use of methods of describing data formats such as \u201cEntity Relationship Model\u201d or similar can be considered.\n\nIt is acceptable for system data to be defined separately as in a dictionary. If this is done therefore, this approach must be clearly explained and documented.\n\n## 9.6.4.5.3 Module Description\n\nFor each module, the following points must be covered:\n\n- Module operation: the description can take the form of a pseudocode or flow chart;\n- Interfaces with other modules: this point can refer to the system diagram, if there is one;", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 1886, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "f56798e3-7d61-4ed0-8ec4-5c050fd9f440": {"__data__": {"id_": "f56798e3-7d61-4ed0-8ec4-5c050fd9f440", "embedding": null, "metadata": {"page_label": "44", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "- Error handling and data verification;\n- Data mapping for each module;\n- Software module data.\n\nFor each subprogram of the software module, the following points must be covered:\n\n- Subprogram operation: the description can take the form of a pseudocode;\n- The steps involved in each process to be performed and the inputs and outputs of each step;\n- Parameters: each parameter must be identified as one of the examples below:\n- \u2713 Input parameter;\n- \u2713 Output parameter;\n- \u2713 Input and output parameters.\n- Algorithms;\n- It must be identified how each parameter passes the test, either by value or by reference;\n- Any side effects of the subprogram;\n- Language type, including the \u201ccore\u201d and platform version;\n- Reference to any programming standards;\n- Description or examples of all display screens;\n- Subprogram data.\n- Description or examples of all reports implemented, their meaning and manipulation and when were generated.\n\nThe level of detail can be provided in separate specifications.\n\n### 9.6.4.6 Glossary\n\nDefinitions of any little-known terms should be provided.\n\n### 9.7 TESTING PLAN FOR COMPUTERIZED SYSTEMS\n\n#### 9.7.1 Introduction\n\nThe performance of tests in the system meets the following objectives:\n\n- Identification of defects that can be corrected or removed before use;\n- Failure prevention that can affect patient safety, product quality or integrity of the data;\n- Provision of documented evidence that the system performs its functions as specified;\n- Demonstration that the system meets the intended requirements;\n- Providing confidence that the system is suitable for its intended use;\n- Provision of the basis for user acceptance;\n- Meeting a key regulatory requirement, where appropriate.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas que pueden proporcionar respuestas espec\u00edficas basadas en el contexto proporcionado:\n\n1. **\u00bfCu\u00e1les son los pasos espec\u00edficos que deben seguirse para documentar el funcionamiento de un subprograma en el contexto de la validaci\u00f3n de sistemas inform\u00e1ticos seg\u00fan la gu\u00eda de ANVISA?**\n   - Esta pregunta se centra en los detalles del proceso de documentaci\u00f3n de subprogramas, que incluye la descripci\u00f3n en pseudoc\u00f3digo, los pasos del proceso, y la identificaci\u00f3n de par\u00e1metros, lo cual es fundamental para la validaci\u00f3n.\n\n2. **\u00bfQu\u00e9 objetivos espec\u00edficos se buscan alcanzar al realizar pruebas en sistemas inform\u00e1ticos seg\u00fan la gu\u00eda de ANVISA, y c\u00f3mo se relacionan con la seguridad del paciente y la calidad del producto?**\n   - Esta pregunta aborda los objetivos de las pruebas en sistemas inform\u00e1ticos, destacando su importancia en la prevenci\u00f3n de fallos que puedan afectar la seguridad del paciente y la integridad de los datos.\n\n3. **\u00bfQu\u00e9 tipo de informaci\u00f3n se debe incluir en la secci\u00f3n de \"glosario\" de la documentaci\u00f3n de validaci\u00f3n de sistemas inform\u00e1ticos, y por qu\u00e9 es importante?**\n   - Esta pregunta se enfoca en la necesidad de definir t\u00e9rminos poco conocidos, lo que es crucial para asegurar que todos los involucrados en el proceso de validaci\u00f3n comprendan claramente la documentaci\u00f3n.\n\n### Resumen de nivel superior del contexto circundante:\nLa gu\u00eda de ANVISA para la validaci\u00f3n de sistemas inform\u00e1ticos establece directrices claras sobre c\u00f3mo documentar y probar software en entornos regulados. Se enfatiza la importancia de la identificaci\u00f3n y manejo de errores, la verificaci\u00f3n de datos, y la documentaci\u00f3n detallada de subprogramas, incluyendo su funcionamiento, par\u00e1metros y efectos secundarios. Adem\u00e1s, se destacan los objetivos de las pruebas, que incluyen la identificaci\u00f3n de defectos y la garant\u00eda de que el sistema cumple con los requisitos establecidos, lo que es esencial para la seguridad del paciente y la calidad del producto.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\nLa secci\u00f3n 9.6.4.5 del documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos se centra en el dise\u00f1o de software, estableciendo directrices espec\u00edficas para asegurar que el software se desarrolle de acuerdo con est\u00e1ndares reconocidos. A continuaci\u00f3n se presentan los temas clave y entidades mencionadas:\n\n1. **Especificaciones de Dise\u00f1o de Software**:\n   - **Aplicaciones Personalizadas**: Se requieren especificaciones de dise\u00f1o detalladas.\n   - **Sistemas Configurables**: No se requieren especificaciones, ya que el proyecto se eval\u00faa como parte de la evaluaci\u00f3n del proveedor.\n\n2. **Descripci\u00f3n del Software**:\n   - **M\u00f3dulos del Sistema**: Cada m\u00f3dulo debe ser descrito con su prop\u00f3sito y las interfaces entre ellos, as\u00ed como con sistemas externos. Se recomienda incluir un diagrama del sistema.\n\n3. **Datos del Sistema**:\n   - **Definici\u00f3n de Datos**: Los datos deben caracterizarse de manera jer\u00e1rquica, con objetos complejos derivados de objetos m\u00e1s simples.\n   - **Elementos de Datos**: Incluyen bases de datos, archivos y registros.\n   - **Descripci\u00f3n de Objetos de Datos**: Debe incluir tipos de datos, formatos, precisi\u00f3n y una identificaci\u00f3n \u00fanica para cada archivo y estructura de datos. Se sugiere el uso de modelos como el \"Modelo de Relaci\u00f3n de Entidades\".\n\n4. **Descripci\u00f3n de M\u00f3dulos**:\n   - **Operaci\u00f3n del M\u00f3dulo**: Puede describirse mediante pseudoc\u00f3digo o diagramas de flujo.\n   - **Interfaces con Otros M\u00f3dulos**: Se debe hacer referencia a los diagramas del sistema si est\u00e1n disponibles.\n\n### Entidades Clave\n- **Software**: Aplicaciones personalizadas y sistemas configurables.\n- **M\u00f3dulos**: Componentes del sistema que deben ser descritos y documentados.\n- **Datos**: Objetos de datos que deben ser definidos y caracterizados.\n- **Interfaces**: Conexiones entre m\u00f3dulos y sistemas externos.\n- **Diagramas**: Representaciones visuales recomendadas para la descripci\u00f3n del sistema y sus m\u00f3dulos.\n\nEste resumen proporciona una visi\u00f3n general de los requisitos y directrices para el dise\u00f1o de software en el contexto de la validaci\u00f3n de sistemas inform\u00e1ticos seg\u00fan ANVISA.", "excerpt_keywords": "Keywords: validation, software documentation, testing plan, parameters, regulatory compliance"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "2be94c47-30fd-4311-937b-2227a8d6e06f", "node_type": "4", "metadata": {"page_label": "44", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "- Error handling and data verification;\n- Data mapping for each module;\n- Software module data.\n\nFor each subprogram of the software module, the following points must be covered:\n\n- Subprogram operation: the description can take the form of a pseudocode;\n- The steps involved in each process to be performed and the inputs and outputs of each step;\n- Parameters: each parameter must be identified as one of the examples below:\n- \u2713 Input parameter;\n- \u2713 Output parameter;\n- \u2713 Input and output parameters.\n- Algorithms;\n- It must be identified how each parameter passes the test, either by value or by reference;\n- Any side effects of the subprogram;\n- Language type, including the \u201ccore\u201d and platform version;\n- Reference to any programming standards;\n- Description or examples of all display screens;\n- Subprogram data.\n- Description or examples of all reports implemented, their meaning and manipulation and when were generated.\n\nThe level of detail can be provided in separate specifications.\n\n### 9.6.4.6 Glossary\n\nDefinitions of any little-known terms should be provided.\n\n### 9.7 TESTING PLAN FOR COMPUTERIZED SYSTEMS\n\n#### 9.7.1 Introduction\n\nThe performance of tests in the system meets the following objectives:\n\n- Identification of defects that can be corrected or removed before use;\n- Failure prevention that can affect patient safety, product quality or integrity of the data;\n- Provision of documented evidence that the system performs its functions as specified;\n- Demonstration that the system meets the intended requirements;\n- Providing confidence that the system is suitable for its intended use;\n- Provision of the basis for user acceptance;\n- Meeting a key regulatory requirement, where appropriate.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "c628c44ed5d2117f0155a9381f43b917f5a1e422ce5c03bf01f850f6c0291698", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "- Error handling and data verification;\n- Data mapping for each module;\n- Software module data.\n\nFor each subprogram of the software module, the following points must be covered:\n\n- Subprogram operation: the description can take the form of a pseudocode;\n- The steps involved in each process to be performed and the inputs and outputs of each step;\n- Parameters: each parameter must be identified as one of the examples below:\n- \u2713 Input parameter;\n- \u2713 Output parameter;\n- \u2713 Input and output parameters.\n- Algorithms;\n- It must be identified how each parameter passes the test, either by value or by reference;\n- Any side effects of the subprogram;\n- Language type, including the \u201ccore\u201d and platform version;\n- Reference to any programming standards;\n- Description or examples of all display screens;\n- Subprogram data.\n- Description or examples of all reports implemented, their meaning and manipulation and when were generated.\n\nThe level of detail can be provided in separate specifications.\n\n### 9.6.4.6 Glossary\n\nDefinitions of any little-known terms should be provided.\n\n### 9.7 TESTING PLAN FOR COMPUTERIZED SYSTEMS\n\n#### 9.7.1 Introduction\n\nThe performance of tests in the system meets the following objectives:\n\n- Identification of defects that can be corrected or removed before use;\n- Failure prevention that can affect patient safety, product quality or integrity of the data;\n- Provision of documented evidence that the system performs its functions as specified;\n- Demonstration that the system meets the intended requirements;\n- Providing confidence that the system is suitable for its intended use;\n- Provision of the basis for user acceptance;\n- Meeting a key regulatory requirement, where appropriate.", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 1718, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "e67d1aa3-cf60-4b55-83f7-2a71e02dc2dc": {"__data__": {"id_": "e67d1aa3-cf60-4b55-83f7-2a71e02dc2dc", "embedding": null, "metadata": {"page_label": "45", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 9.7.2 Roles and Responsibilities\n\nThe regulated company must define the roles and responsibilities related to the performance of tests in the system.\n\nThese roles and responsibilities may include:\n\n- User - responsible for the system in question and for the approval of test documents;\n- Subject Specialist (SME) - can act as a test manager, executor, reviewer or authorizer;\n\n----\n\n- Test manager - test planning and test plan writing;\n- Test Analyst - responsible for developing test cases and test scripts;\n- Test runner - this role should be as independent as possible. You must not be the author of the software or test scripts, if possible;\n- Test reviewer - responsible for reviewing test cases, test scripts and test results tests - it should not be the same person who performed the tests;\n- Quality Unit - role defined by the GMP;\n- Supplier - can act as a test planner, performer, reviewer or authorizer for some of the tests.\n\n# 9.7.3 Testing Strategies\n\n## 9.7.3.1 Introduction\n\nThe testing strategy, also known as the test plan, should define an appropriate approach to the testing on a specific computerized system.\n\nThe testing strategy is based on the following points:\n\n- Results of risk assessments;\n- An understanding of the system components (GAMP categories), the complexity and innovation of the system;\n- Results of supplier evaluations, if applicable.\n\nThe testing strategy varies according to the category of the system, ranging from a simple system of the category 3 to a complex category 5 system. The testing strategy must be reviewed and approved by the Specialist on the subject.\n\nThe testing strategy should define:\n\n- What kind of tests are needed;\n- The number and purpose of the test specifications;\n- The use of the supplier's existing documentation according to the assessment carried out in the provider;\n- The testing phases:\n- \u2713 Location and duration of each test phase;\n- \u2713 Resources required for each testing phase;\n- \u2713 Responsibilities for each testing phase.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos establece directrices sobre las roles y responsabilidades en la realizaci\u00f3n de pruebas de sistemas regulados. Se enfatiza la importancia de definir claramente qui\u00e9n es responsable de cada aspecto del proceso de prueba, desde la planificaci\u00f3n hasta la ejecuci\u00f3n y revisi\u00f3n. Adem\u00e1s, se describe la estrategia de pruebas, que debe basarse en evaluaciones de riesgo y en la comprensi\u00f3n de los componentes del sistema, y debe ser revisada y aprobada por un especialista en la materia.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfCu\u00e1les son las responsabilidades espec\u00edficas del \"Test runner\" seg\u00fan el documento de ANVISA?**\n   - El \"Test runner\" debe ser lo m\u00e1s independiente posible y no debe ser el autor del software o de los scripts de prueba, si es posible.\n\n2. **\u00bfQu\u00e9 factores se deben considerar al definir la estrategia de pruebas para un sistema inform\u00e1tico?**\n   - La estrategia de pruebas debe basarse en los resultados de las evaluaciones de riesgo, la comprensi\u00f3n de los componentes del sistema (categor\u00edas GAMP), la complejidad e innovaci\u00f3n del sistema, y los resultados de las evaluaciones de proveedores, si corresponde.\n\n3. **\u00bfQu\u00e9 rol desempe\u00f1a el \"Subject Specialist (SME)\" en el proceso de pruebas seg\u00fan el documento?**\n   - El \"Subject Specialist (SME)\" puede actuar como gerente de pruebas, ejecutor, revisor o autorizador, lo que implica que tiene un papel clave en la supervisi\u00f3n y validaci\u00f3n del proceso de pruebas.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Manejo de Errores y Verificaci\u00f3n de Datos**: Se enfatiza la importancia de implementar mecanismos para manejar errores y verificar la integridad de los datos en los sistemas inform\u00e1ticos.\n\n2. **Documentaci\u00f3n de Subprogramas**: \n   - **Descripci\u00f3n del Funcionamiento**: Se requiere que cada subprograma sea documentado, preferiblemente en forma de pseudoc\u00f3digo.\n   - **Pasos del Proceso**: Detallar los pasos involucrados, as\u00ed como los inputs y outputs de cada uno.\n   - **Identificaci\u00f3n de Par\u00e1metros**: Los par\u00e1metros deben clasificarse como de entrada, salida, o ambos.\n   - **Algoritmos y Efectos Secundarios**: Se debe identificar c\u00f3mo se pasan los par\u00e1metros (por valor o referencia) y cualquier efecto secundario del subprograma.\n   - **Lenguaje y Est\u00e1ndares de Programaci\u00f3n**: Especificar el tipo de lenguaje utilizado y cualquier est\u00e1ndar de programaci\u00f3n relevante.\n   - **Pantallas y Reportes**: Incluir descripciones o ejemplos de las pantallas de visualizaci\u00f3n y los reportes generados por el sistema.\n\n3. **Glosario**: Se debe incluir un glosario que defina t\u00e9rminos poco conocidos para asegurar la comprensi\u00f3n de la documentaci\u00f3n por parte de todos los involucrados.\n\n4. **Plan de Pruebas para Sistemas Inform\u00e1ticos**:\n   - **Objetivos de las Pruebas**: \n     - Identificaci\u00f3n de defectos antes de la implementaci\u00f3n.\n     - Prevenci\u00f3n de fallos que puedan comprometer la seguridad del paciente o la calidad del producto.\n     - Provisi\u00f3n de evidencia documentada de que el sistema cumple con sus funciones especificadas.\n     - Demostraci\u00f3n de que el sistema satisface los requisitos previstos.\n     - Generaci\u00f3n de confianza en la idoneidad del sistema para su uso previsto.\n     - Base para la aceptaci\u00f3n del usuario.\n     - Cumplimiento de requisitos regulatorios clave.\n\n### Entidades Clave\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil, responsable de la regulaci\u00f3n de sistemas inform\u00e1ticos en el \u00e1mbito de la salud.\n- **Subprogramas**: Componentes del software que deben ser documentados y validados.\n- **Par\u00e1metros**: Elementos que se utilizan en los subprogramas, clasificados como de entrada, salida o ambos.\n- **Pruebas**: Actividades realizadas para asegurar la calidad y funcionalidad del sistema inform\u00e1tico.\n\nEste resumen destaca la importancia de la documentaci\u00f3n y las pruebas en la validaci\u00f3n de sistemas inform\u00e1ticos, as\u00ed como la necesidad de claridad en la terminolog\u00eda utilizada.", "excerpt_keywords": "Keywords: validation, testing strategy, roles and responsibilities, risk assessment, computerized systems"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "6985d1eb-6ef0-41dc-91a0-a1b91c1be8cf", "node_type": "4", "metadata": {"page_label": "45", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 9.7.2 Roles and Responsibilities\n\nThe regulated company must define the roles and responsibilities related to the performance of tests in the system.\n\nThese roles and responsibilities may include:\n\n- User - responsible for the system in question and for the approval of test documents;\n- Subject Specialist (SME) - can act as a test manager, executor, reviewer or authorizer;\n\n----\n\n- Test manager - test planning and test plan writing;\n- Test Analyst - responsible for developing test cases and test scripts;\n- Test runner - this role should be as independent as possible. You must not be the author of the software or test scripts, if possible;\n- Test reviewer - responsible for reviewing test cases, test scripts and test results tests - it should not be the same person who performed the tests;\n- Quality Unit - role defined by the GMP;\n- Supplier - can act as a test planner, performer, reviewer or authorizer for some of the tests.\n\n# 9.7.3 Testing Strategies\n\n## 9.7.3.1 Introduction\n\nThe testing strategy, also known as the test plan, should define an appropriate approach to the testing on a specific computerized system.\n\nThe testing strategy is based on the following points:\n\n- Results of risk assessments;\n- An understanding of the system components (GAMP categories), the complexity and innovation of the system;\n- Results of supplier evaluations, if applicable.\n\nThe testing strategy varies according to the category of the system, ranging from a simple system of the category 3 to a complex category 5 system. The testing strategy must be reviewed and approved by the Specialist on the subject.\n\nThe testing strategy should define:\n\n- What kind of tests are needed;\n- The number and purpose of the test specifications;\n- The use of the supplier's existing documentation according to the assessment carried out in the provider;\n- The testing phases:\n- \u2713 Location and duration of each test phase;\n- \u2713 Resources required for each testing phase;\n- \u2713 Responsibilities for each testing phase.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "3c0abd38eaadd68718ab0d91bebe65e35784d21b273f6fd320d855159a660d47", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "# 9.7.2 Roles and Responsibilities\n\nThe regulated company must define the roles and responsibilities related to the performance of tests in the system.\n\nThese roles and responsibilities may include:\n\n- User - responsible for the system in question and for the approval of test documents;\n- Subject Specialist (SME) - can act as a test manager, executor, reviewer or authorizer;\n\n----\n\n- Test manager - test planning and test plan writing;\n- Test Analyst - responsible for developing test cases and test scripts;\n- Test runner - this role should be as independent as possible. You must not be the author of the software or test scripts, if possible;\n- Test reviewer - responsible for reviewing test cases, test scripts and test results tests - it should not be the same person who performed the tests;\n- Quality Unit - role defined by the GMP;\n- Supplier - can act as a test planner, performer, reviewer or authorizer for some of the tests.\n\n# 9.7.3 Testing Strategies\n\n## 9.7.3.1 Introduction\n\nThe testing strategy, also known as the test plan, should define an appropriate approach to the testing on a specific computerized system.\n\nThe testing strategy is based on the following points:\n\n- Results of risk assessments;\n- An understanding of the system components (GAMP categories), the complexity and innovation of the system;\n- Results of supplier evaluations, if applicable.\n\nThe testing strategy varies according to the category of the system, ranging from a simple system of the category 3 to a complex category 5 system. The testing strategy must be reviewed and approved by the Specialist on the subject.\n\nThe testing strategy should define:\n\n- What kind of tests are needed;\n- The number and purpose of the test specifications;\n- The use of the supplier's existing documentation according to the assessment carried out in the provider;\n- The testing phases:\n- \u2713 Location and duration of each test phase;\n- \u2713 Resources required for each testing phase;\n- \u2713 Responsibilities for each testing phase.", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 2004, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "7b4a6013-aee5-4027-aacd-ed113f9dc1df": {"__data__": {"id_": "7b4a6013-aee5-4027-aacd-ed113f9dc1df", "embedding": null, "metadata": {"page_label": "46", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "- The approach used to provide evidence of testing (eg, impressions);\n- Procedures for managing test failures;\n- Test documentation format;\n- The use of test metrics;\n- Use of visual testimony of the tests.\n\n## 9.7.3.2 Test Documentation\n\nFigure 5 below shows a typical structure for testing documentation.\n\n----\n\n**Figure 5. Typical structure for testing documentation.**\nSource: GAMP5\n\nThe use of *templates* to carry out test documentation, such as test specifications, records test results and test reports, helps with consistency, facilitates review and avoids errors in documents.\n\nIn this section, each type of document presented in figure 5 is described.\n\n### 9.7.3.2.1 Testing Strategy\n\nDescribed in item 9.7.3.1.\n\n### 9.7.3.2.2 Test Specifications\n\nThey are a set of test scripts that are suitable for a specific purpose for a specific phase of a project.\n\nThe test specifications should cover the following points, where applicable:", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos establece directrices sobre la documentaci\u00f3n de pruebas en proyectos. Se enfatiza la importancia de utilizar plantillas para asegurar la consistencia y evitar errores. Se describen varios tipos de documentos necesarios para la documentaci\u00f3n de pruebas, incluyendo la estrategia de pruebas y las especificaciones de pruebas, que deben abordar aspectos clave como la evidencia de pruebas, la gesti\u00f3n de fallos y el uso de m\u00e9tricas.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfCu\u00e1l es la importancia de utilizar plantillas en la documentaci\u00f3n de pruebas seg\u00fan el documento de ANVISA?**\n   - Respuesta: El uso de plantillas en la documentaci\u00f3n de pruebas ayuda a garantizar la consistencia, facilita la revisi\u00f3n y evita errores en los documentos.\n\n2. **\u00bfQu\u00e9 aspectos deben cubrir las especificaciones de pruebas seg\u00fan el contexto proporcionado?**\n   - Respuesta: Las especificaciones de pruebas deben cubrir un conjunto de puntos relevantes para un prop\u00f3sito espec\u00edfico en una fase del proyecto, aunque el contexto no detalla cu\u00e1les son esos puntos espec\u00edficos.\n\n3. **\u00bfQu\u00e9 se menciona sobre la gesti\u00f3n de fallos en las pruebas dentro del documento?**\n   - Respuesta: Se menciona que deben existir procedimientos para gestionar las fallas en las pruebas, aunque el contexto no proporciona detalles espec\u00edficos sobre esos procedimientos.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n#### Temas Clave\n1. **Roles y Responsabilidades**: Se establece la necesidad de definir claramente los roles y responsabilidades en el proceso de pruebas de sistemas regulados. Esto incluye diversas funciones como:\n   - **Usuario**: Responsable del sistema y aprobaci\u00f3n de documentos de prueba.\n   - **Especialista en la materia (SME)**: Puede actuar como gerente, ejecutor, revisor o autorizador de pruebas.\n   - **Gerente de Pruebas**: Encargado de la planificaci\u00f3n y redacci\u00f3n del plan de pruebas.\n   - **Analista de Pruebas**: Desarrolla casos y scripts de prueba.\n   - **Ejecutor de Pruebas (Test Runner)**: Debe ser independiente y no autor de software o scripts de prueba.\n   - **Revisor de Pruebas**: Revisa casos, scripts y resultados de pruebas, sin ser la misma persona que realiz\u00f3 las pruebas.\n   - **Unidad de Calidad**: Rol definido por las Buenas Pr\u00e1cticas de Manufactura (GMP).\n   - **Proveedor**: Puede actuar en varias capacidades en el proceso de pruebas.\n\n2. **Estrategias de Pruebas**: La estrategia de pruebas debe ser un enfoque adecuado para el sistema inform\u00e1tico espec\u00edfico y debe basarse en:\n   - Resultados de evaluaciones de riesgo.\n   - Comprensi\u00f3n de los componentes del sistema (categor\u00edas GAMP).\n   - Complejidad e innovaci\u00f3n del sistema.\n   - Resultados de evaluaciones de proveedores, si aplica.\n\n3. **Revisi\u00f3n y Aprobaci\u00f3n**: La estrategia de pruebas debe ser revisada y aprobada por un especialista en la materia.\n\n4. **Definici\u00f3n de la Estrategia de Pruebas**: Debe incluir:\n   - Tipos de pruebas necesarias.\n   - N\u00famero y prop\u00f3sito de las especificaciones de prueba.\n   - Uso de la documentaci\u00f3n existente del proveedor.\n   - Fases de prueba, incluyendo ubicaci\u00f3n, duraci\u00f3n, recursos y responsabilidades.\n\n#### Entidades\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil.\n- **GAMP**: Buenas Pr\u00e1cticas de Manufactura (Good Automated Manufacturing Practice).\n- **Roles**: Usuario, SME, Gerente de Pruebas, Analista de Pruebas, Ejecutor de Pruebas, Revisor de Pruebas, Unidad de Calidad, Proveedor.\n- **Documentaci\u00f3n**: Plan de pruebas, casos de prueba, scripts de prueba, resultados de pruebas.\n\nEste resumen destaca la importancia de la claridad en roles y responsabilidades, as\u00ed como la necesidad de una estrategia de pruebas bien definida y revisada para asegurar la validaci\u00f3n efectiva de sistemas inform\u00e1ticos regulados.", "excerpt_keywords": "Keywords: ANVISA, Computer Systems Validation, Test Documentation, Testing Strategy, GAMP"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "c8573085-049f-4f3c-8628-6902ca8dc188", "node_type": "4", "metadata": {"page_label": "46", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "- The approach used to provide evidence of testing (eg, impressions);\n- Procedures for managing test failures;\n- Test documentation format;\n- The use of test metrics;\n- Use of visual testimony of the tests.\n\n## 9.7.3.2 Test Documentation\n\nFigure 5 below shows a typical structure for testing documentation.\n\n----\n\n**Figure 5. Typical structure for testing documentation.**\nSource: GAMP5\n\nThe use of *templates* to carry out test documentation, such as test specifications, records test results and test reports, helps with consistency, facilitates review and avoids errors in documents.\n\nIn this section, each type of document presented in figure 5 is described.\n\n### 9.7.3.2.1 Testing Strategy\n\nDescribed in item 9.7.3.1.\n\n### 9.7.3.2.2 Test Specifications\n\nThey are a set of test scripts that are suitable for a specific purpose for a specific phase of a project.\n\nThe test specifications should cover the following points, where applicable:", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "7886dc1998135f756096b597bff814cafe5aa77291423a6a6bae59055946e353", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "- The approach used to provide evidence of testing (eg, impressions);\n- Procedures for managing test failures;\n- Test documentation format;\n- The use of test metrics;\n- Use of visual testimony of the tests.\n\n## 9.7.3.2 Test Documentation\n\nFigure 5 below shows a typical structure for testing documentation.\n\n----\n\n**Figure 5. Typical structure for testing documentation.**\nSource: GAMP5\n\nThe use of *templates* to carry out test documentation, such as test specifications, records test results and test reports, helps with consistency, facilitates review and avoids errors in documents.\n\nIn this section, each type of document presented in figure 5 is described.\n\n### 9.7.3.2.1 Testing Strategy\n\nDescribed in item 9.7.3.1.\n\n### 9.7.3.2.2 Test Specifications\n\nThey are a set of test scripts that are suitable for a specific purpose for a specific phase of a project.\n\nThe test specifications should cover the following points, where applicable:", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 943, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "f14eb3ea-a08c-4175-9c15-09bbd1610b5d": {"__data__": {"id_": "f14eb3ea-a08c-4175-9c15-09bbd1610b5d", "embedding": null, "metadata": {"page_label": "47", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# Guide for Computer Systems Validation\n\n- Introduction;\n- Who produced the document, under what authority and for what purpose;\n- The contractual status of the defined document;\n- Relationship to other documents;\n- Scope - must state where the test specification fits into the overall testing strategy;\n- The test scripts / cases to be executed;\n- Software version or configuration under test;\n- Purpose;\n- Resources;\n- Personnel required to carry out each test or group of tests;\n- Methods used;\n- Any grouping or logical ordering of the tests;\n- Prerequisites;\n- Environment;\n- Tools, including automated testing tools;\n- Reference to specifications;\n- Necessary documentation;\n- Necessary reviews and approvals.\n\n## 9.7.3.2.3 Test Cases / Itineraries\n\nThe test cases / roadmaps must contain the details of the tests. The test script should be described in detail enough to allow consistent repeat testing.\n\nEach test script should, where possible, include the following points:\n- Unique test reference;\n- Cross reference to control the specification;\n- Test title;\n- Description of the test, including the purpose of the test;\n- Test steps - a step-by-step description of the actions to be taken by the performers, together with the expected results;\n- Acceptance criteria - Expected result(s) that must be met in order for the parameter specific challenge is considered pass or has passed the test;\n- Pre-test steps - including any test or preparation prerequisites;\n- Data to be recorded - description of the data to be collected and recorded;\n- Post-test actions - optional section that details the actions required to return the system to the state original.\n\n## 9.7.3.2.4 Test Results\n\nThe test results must be available for subsequent review and inspection. The information to be retained should include tests that have passed, those that have failed, records of test failures, test reports and", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento \"Gu\u00eda para la Validaci\u00f3n de Sistemas Inform\u00e1ticos\" de ANVISA establece directrices sobre c\u00f3mo llevar a cabo pruebas de validaci\u00f3n de sistemas inform\u00e1ticos en el \u00e1mbito regulatorio. Incluye secciones sobre la introducci\u00f3n, la producci\u00f3n del documento, su relaci\u00f3n con otros documentos, el alcance de las pruebas, los scripts de prueba, los resultados de las pruebas y los requisitos necesarios para llevar a cabo estas pruebas de manera efectiva. Se enfatiza la importancia de documentar cada paso del proceso de prueba, as\u00ed como los resultados obtenidos.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfQu\u00e9 elementos deben incluirse en un script de prueba seg\u00fan la gu\u00eda de ANVISA?**\n   - La gu\u00eda especifica que un script de prueba debe incluir un identificador \u00fanico, referencia cruzada a la especificaci\u00f3n de control, t\u00edtulo de la prueba, descripci\u00f3n del prop\u00f3sito de la prueba, pasos de prueba detallados, criterios de aceptaci\u00f3n, pasos previos a la prueba, datos a registrar y acciones posteriores a la prueba.\n\n2. **\u00bfCu\u00e1l es la importancia de los resultados de las pruebas y qu\u00e9 informaci\u00f3n debe ser retenida seg\u00fan el documento?**\n   - Los resultados de las pruebas son cruciales para la revisi\u00f3n y la inspecci\u00f3n posterior. La informaci\u00f3n que debe ser retenida incluye los tests que han pasado, aquellos que han fallado, registros de fallos de prueba y los informes de prueba.\n\n3. **\u00bfQu\u00e9 aspectos se deben considerar al definir el alcance de las pruebas en el contexto de la validaci\u00f3n de sistemas inform\u00e1ticos?**\n   - El alcance debe indicar c\u00f3mo la especificaci\u00f3n de prueba se integra en la estrategia general de pruebas, asegurando que se aborden todos los aspectos relevantes del sistema y que se cumplan los requisitos regulatorios establecidos.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos aborda varios aspectos fundamentales relacionados con la documentaci\u00f3n de pruebas en proyectos. A continuaci\u00f3n se presentan los temas clave y las entidades mencionadas en la secci\u00f3n:\n\n#### Temas Clave:\n1. **Evidencia de Pruebas**: Se discute la importancia de proporcionar evidencia de las pruebas realizadas, incluyendo enfoques como impresiones.\n2. **Gesti\u00f3n de Fallos**: Se establecen procedimientos necesarios para manejar las fallas que puedan surgir durante las pruebas.\n3. **Formato de Documentaci\u00f3n de Pruebas**: Se enfatiza la necesidad de un formato estandarizado para la documentaci\u00f3n de pruebas.\n4. **M\u00e9tricas de Pruebas**: Se menciona el uso de m\u00e9tricas para evaluar y reportar los resultados de las pruebas.\n5. **Testimonios Visuales**: Se sugiere el uso de testimonios visuales como parte de la documentaci\u00f3n de pruebas.\n6. **Plantillas para Documentaci\u00f3n**: Se destaca la importancia de utilizar plantillas para asegurar la consistencia y evitar errores en la documentaci\u00f3n de pruebas.\n\n#### Entidades:\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil, responsable de regular la validaci\u00f3n de sistemas inform\u00e1ticos en el \u00e1mbito de la salud.\n- **GAMP5**: Buenas Pr\u00e1cticas de Automatizaci\u00f3n y Validaci\u00f3n de Sistemas, que sirve como referencia para la estructura de la documentaci\u00f3n de pruebas.\n- **Documentos de Pruebas**: Incluyen especificaciones de pruebas, registros de resultados y reportes de pruebas.\n\n### Conclusi\u00f3n\nEl documento proporciona directrices claras sobre c\u00f3mo llevar a cabo la documentaci\u00f3n de pruebas de manera efectiva, resaltando la importancia de la estandarizaci\u00f3n y la gesti\u00f3n adecuada de los procesos de prueba en proyectos de sistemas inform\u00e1ticos.", "excerpt_keywords": "Keywords: validation, testing, documentation, ANVISA, software"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "b603c7f1-0d4d-490a-8ef6-6fd3e8e3b8fb", "node_type": "4", "metadata": {"page_label": "47", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# Guide for Computer Systems Validation\n\n- Introduction;\n- Who produced the document, under what authority and for what purpose;\n- The contractual status of the defined document;\n- Relationship to other documents;\n- Scope - must state where the test specification fits into the overall testing strategy;\n- The test scripts / cases to be executed;\n- Software version or configuration under test;\n- Purpose;\n- Resources;\n- Personnel required to carry out each test or group of tests;\n- Methods used;\n- Any grouping or logical ordering of the tests;\n- Prerequisites;\n- Environment;\n- Tools, including automated testing tools;\n- Reference to specifications;\n- Necessary documentation;\n- Necessary reviews and approvals.\n\n## 9.7.3.2.3 Test Cases / Itineraries\n\nThe test cases / roadmaps must contain the details of the tests. The test script should be described in detail enough to allow consistent repeat testing.\n\nEach test script should, where possible, include the following points:\n- Unique test reference;\n- Cross reference to control the specification;\n- Test title;\n- Description of the test, including the purpose of the test;\n- Test steps - a step-by-step description of the actions to be taken by the performers, together with the expected results;\n- Acceptance criteria - Expected result(s) that must be met in order for the parameter specific challenge is considered pass or has passed the test;\n- Pre-test steps - including any test or preparation prerequisites;\n- Data to be recorded - description of the data to be collected and recorded;\n- Post-test actions - optional section that details the actions required to return the system to the state original.\n\n## 9.7.3.2.4 Test Results\n\nThe test results must be available for subsequent review and inspection. The information to be retained should include tests that have passed, those that have failed, records of test failures, test reports and", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "f349dee3c648bd83cde993e138f0031e728aaf289bca437b75a487f55e95f20d", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "# Guide for Computer Systems Validation\n\n- Introduction;\n- Who produced the document, under what authority and for what purpose;\n- The contractual status of the defined document;\n- Relationship to other documents;\n- Scope - must state where the test specification fits into the overall testing strategy;\n- The test scripts / cases to be executed;\n- Software version or configuration under test;\n- Purpose;\n- Resources;\n- Personnel required to carry out each test or group of tests;\n- Methods used;\n- Any grouping or logical ordering of the tests;\n- Prerequisites;\n- Environment;\n- Tools, including automated testing tools;\n- Reference to specifications;\n- Necessary documentation;\n- Necessary reviews and approvals.\n\n## 9.7.3.2.3 Test Cases / Itineraries\n\nThe test cases / roadmaps must contain the details of the tests. The test script should be described in detail enough to allow consistent repeat testing.\n\nEach test script should, where possible, include the following points:\n- Unique test reference;\n- Cross reference to control the specification;\n- Test title;\n- Description of the test, including the purpose of the test;\n- Test steps - a step-by-step description of the actions to be taken by the performers, together with the expected results;\n- Acceptance criteria - Expected result(s) that must be met in order for the parameter specific challenge is considered pass or has passed the test;\n- Pre-test steps - including any test or preparation prerequisites;\n- Data to be recorded - description of the data to be collected and recorded;\n- Post-test actions - optional section that details the actions required to return the system to the state original.\n\n## 9.7.3.2.4 Test Results\n\nThe test results must be available for subsequent review and inspection. The information to be retained should include tests that have passed, those that have failed, records of test failures, test reports and", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 1904, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "2c4bc896-70b7-40a2-8fb4-c51363ebebbd": {"__data__": {"id_": "2c4bc896-70b7-40a2-8fb4-c51363ebebbd", "embedding": null, "metadata": {"page_label": "48", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "## 9.7.3.2.5 Test Report and Summary Test Report\n\nTest reports must contain:\n\n- Introduction;\n- Scope of tests;\n- Testing organization;\n- Who performed and who reviewed the tests;\n- Summary of test results in tabular form;\n- Summary of test failures;\n- Conclusions;\n- For large or complex projects that have multiple test reports the general conclusions can be documented in a summary test report.\n\n## 9.7.3.3 Components of the Test Strategy\n\nThe following points should be taken into account when developing the testing strategy:\n\n- Company policies and procedures;\n- Results of risk assessments;\n- Results of supplier assessment;\n- GAMP system categories;\n- Other documents, such as: requirements specifications; initial risk assessment; specification functional; configuration specification; design documents; results of other activities carried out in the different stages of software development and traceability matrix.\n\n## 9.7.3.4 Types of Tests\n\nThere are basically two types of testing activities:\n\n- **White Box Testing (White Box Testing)** - also known as a test based on the code or structural tests, where tests are identified based on source code, knowledge of detailed design specifications and other development documents;\n- **Black Box Testing (Black Box Testing)** - testing based on functional specifications, hence known as functional tests.\n\nBlack box tests may be sufficient as long as the supplier's assessment has found adequate evidence of white box testing.\n\nSpecific types of tests should be considered, depending on the complexity and innovation of the system, the associated risk and the assessment of the system supplier to be tested, including:\n\n- Normal Case Tests (Positive Case or Capability Tests) - system skill challenges", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior que puede ayudar a formularlas:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos establece directrices sobre la elaboraci\u00f3n de informes de pruebas, componentes de la estrategia de pruebas y tipos de pruebas que deben realizarse. Se enfatiza la importancia de incluir informaci\u00f3n detallada en los informes de pruebas, as\u00ed como considerar diversos factores al desarrollar una estrategia de pruebas. Adem\u00e1s, se describen dos enfoques principales para las pruebas: pruebas de caja blanca y pruebas de caja negra, junto con ejemplos de pruebas espec\u00edficas que deben realizarse.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfQu\u00e9 elementos son esenciales para incluir en un informe de pruebas seg\u00fan la gu\u00eda de ANVISA?**\n   - La gu\u00eda especifica que un informe de pruebas debe contener una introducci\u00f3n, el alcance de las pruebas, la organizaci\u00f3n de pruebas, qui\u00e9n realiz\u00f3 y revis\u00f3 las pruebas, un resumen de los resultados en forma tabular, un resumen de las fallas en las pruebas y conclusiones. Para proyectos grandes o complejos, se puede documentar un informe de resumen de pruebas.\n\n2. **\u00bfCu\u00e1les son los factores clave que deben considerarse al desarrollar una estrategia de pruebas seg\u00fan ANVISA?**\n   - Al desarrollar una estrategia de pruebas, se deben tener en cuenta las pol\u00edticas y procedimientos de la empresa, los resultados de las evaluaciones de riesgos y de proveedores, las categor\u00edas de sistemas GAMP, y otros documentos relevantes como especificaciones de requisitos, evaluaciones de riesgos iniciales, especificaciones funcionales y matrices de trazabilidad.\n\n3. **\u00bfQu\u00e9 diferencia hay entre las pruebas de caja blanca y las pruebas de caja negra, y cu\u00e1ndo se puede considerar suficiente una prueba de caja negra?**\n   - Las pruebas de caja blanca se basan en el c\u00f3digo y las especificaciones de dise\u00f1o detalladas, mientras que las pruebas de caja negra se basan en las especificaciones funcionales. Las pruebas de caja negra pueden ser suficientes si la evaluaci\u00f3n del proveedor ha encontrado evidencia adecuada de que se han realizado pruebas de caja blanca.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\nEl documento \"Gu\u00eda para la Validaci\u00f3n de Sistemas Inform\u00e1ticos\" de ANVISA aborda varios aspectos fundamentales relacionados con la validaci\u00f3n de sistemas inform\u00e1ticos en un contexto regulatorio. A continuaci\u00f3n se presentan los temas clave y entidades mencionadas en la secci\u00f3n:\n\n#### Temas Clave\n\n1. **Introducci\u00f3n y Prop\u00f3sito**: Se establece el contexto y la finalidad del documento, as\u00ed como la autoridad que lo produce.\n   \n2. **Documentaci\u00f3n y Contratos**: Se discute el estatus contractual del documento y su relaci\u00f3n con otros documentos relevantes.\n\n3. **Alcance de las Pruebas**: Se define c\u00f3mo la especificaci\u00f3n de prueba se integra en la estrategia general de pruebas.\n\n4. **Scripts y Casos de Prueba**: Se detallan los elementos que deben incluirse en los scripts de prueba, asegurando que sean lo suficientemente claros para permitir pruebas repetibles.\n\n5. **Resultados de las Pruebas**: Se enfatiza la importancia de documentar los resultados de las pruebas, incluyendo tanto las pruebas exitosas como las fallidas.\n\n6. **Requisitos de Recursos y Personal**: Se especifican los recursos y el personal necesarios para llevar a cabo las pruebas.\n\n7. **M\u00e9todos y Herramientas**: Se mencionan los m\u00e9todos utilizados en las pruebas y las herramientas, incluidas las herramientas de prueba automatizadas.\n\n8. **Documentaci\u00f3n Necesaria**: Se requiere la documentaci\u00f3n adecuada y las revisiones y aprobaciones necesarias para validar el proceso de prueba.\n\n#### Entidades\n\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil, responsable de la regulaci\u00f3n y supervisi\u00f3n de sistemas inform\u00e1ticos en el \u00e1mbito de la salud.\n- **Documentos Relacionados**: Otros documentos que pueden influir o estar relacionados con la validaci\u00f3n de sistemas inform\u00e1ticos.\n- **Recursos y Personal**: Entidades involucradas en la ejecuci\u00f3n de las pruebas, incluyendo personal t\u00e9cnico y herramientas necesarias.\n- **Especificaciones de Control**: Documentos que sirven como referencia para asegurar que las pruebas se alineen con los requisitos establecidos.\n\nEste resumen proporciona una visi\u00f3n general de los elementos esenciales que se deben considerar al llevar a cabo la validaci\u00f3n de sistemas inform\u00e1ticos, seg\u00fan las directrices de ANVISA.", "excerpt_keywords": "Keywords: validation, testing strategy, test report, white box testing, black box testing"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "afad6838-9e2b-4d9d-a713-7a39b0e64bb4", "node_type": "4", "metadata": {"page_label": "48", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "## 9.7.3.2.5 Test Report and Summary Test Report\n\nTest reports must contain:\n\n- Introduction;\n- Scope of tests;\n- Testing organization;\n- Who performed and who reviewed the tests;\n- Summary of test results in tabular form;\n- Summary of test failures;\n- Conclusions;\n- For large or complex projects that have multiple test reports the general conclusions can be documented in a summary test report.\n\n## 9.7.3.3 Components of the Test Strategy\n\nThe following points should be taken into account when developing the testing strategy:\n\n- Company policies and procedures;\n- Results of risk assessments;\n- Results of supplier assessment;\n- GAMP system categories;\n- Other documents, such as: requirements specifications; initial risk assessment; specification functional; configuration specification; design documents; results of other activities carried out in the different stages of software development and traceability matrix.\n\n## 9.7.3.4 Types of Tests\n\nThere are basically two types of testing activities:\n\n- **White Box Testing (White Box Testing)** - also known as a test based on the code or structural tests, where tests are identified based on source code, knowledge of detailed design specifications and other development documents;\n- **Black Box Testing (Black Box Testing)** - testing based on functional specifications, hence known as functional tests.\n\nBlack box tests may be sufficient as long as the supplier's assessment has found adequate evidence of white box testing.\n\nSpecific types of tests should be considered, depending on the complexity and innovation of the system, the associated risk and the assessment of the system supplier to be tested, including:\n\n- Normal Case Tests (Positive Case or Capability Tests) - system skill challenges", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "f3fa1bb2891c011cfd38634d4c054b9ffc43e8deea84659a02097385442f471d", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "## 9.7.3.2.5 Test Report and Summary Test Report\n\nTest reports must contain:\n\n- Introduction;\n- Scope of tests;\n- Testing organization;\n- Who performed and who reviewed the tests;\n- Summary of test results in tabular form;\n- Summary of test failures;\n- Conclusions;\n- For large or complex projects that have multiple test reports the general conclusions can be documented in a summary test report.\n\n## 9.7.3.3 Components of the Test Strategy\n\nThe following points should be taken into account when developing the testing strategy:\n\n- Company policies and procedures;\n- Results of risk assessments;\n- Results of supplier assessment;\n- GAMP system categories;\n- Other documents, such as: requirements specifications; initial risk assessment; specification functional; configuration specification; design documents; results of other activities carried out in the different stages of software development and traceability matrix.\n\n## 9.7.3.4 Types of Tests\n\nThere are basically two types of testing activities:\n\n- **White Box Testing (White Box Testing)** - also known as a test based on the code or structural tests, where tests are identified based on source code, knowledge of detailed design specifications and other development documents;\n- **Black Box Testing (Black Box Testing)** - testing based on functional specifications, hence known as functional tests.\n\nBlack box tests may be sufficient as long as the supplier's assessment has found adequate evidence of white box testing.\n\nSpecific types of tests should be considered, depending on the complexity and innovation of the system, the associated risk and the assessment of the system supplier to be tested, including:\n\n- Normal Case Tests (Positive Case or Capability Tests) - system skill challenges", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 1759, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "62d167be-3328-49ef-a411-cc7d810784d9": {"__data__": {"id_": "62d167be-3328-49ef-a411-cc7d810784d9", "embedding": null, "metadata": {"page_label": "49", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# Guide for Computer Systems Validation\n\nto do what it was supposed to do, including triggering error and alarm messages, according to specifications:\n\n- **Tests of Invalid Cases (Negative or Resistance Case)** - challenges to the system's ability to not do what you shouldn't do, according to specifications;\n- **Repeatability Tests** - challenges to the system's ability to repeatedly do what it should do or continuously, if associated with real-time control algorithms;\n- **Performance Testing** - challenges to the system's ability to do what it should do as quickly and effectively possible, according to the specifications;\n- **Volume / Load Testing** - challenges the system's ability to manage high loads as it should. Volume/load tests are required when system resources are critical;\n- **Regression Testing** - challenges to the system's ability to:\n1. Maintain functionality after being modified according to specified requirements;\n2. Ensure that software modules not involved in the modifications are not affected adversely.\n- **Structure / Path Tests** - challenges to the program's internal structure to challenge routines/algorithms, variable values, function return values, etc.\n\nThe tests must challenge the system. So, for example, if the system is designed or intended to record the values of the parameters monitored or controlled in a database at an established frequency (e.g., every second, minute, etc.), that condition or worst case should be tested to ensure that data generated during the routine will be recorded correctly.\n\n----\n\n# 9.7.3.5 Test Environments\n\nThe test strategy must consider and define the environments necessary for carrying out the tests. For typical category 3 systems there will be only one environment. For more complex systems, the performance of Testing can take place in different environments during the design phase, which may include:\n\n- **Development environment**, where prototype production or programming takes place;\n- **Test environment**, where tests are formally performed;\n- **Operating environment** where the system is installed in its target environment.\n\nFormal tests, as far as possible, should be performed in an operational environment. To this end, the records must be clearly distinguished from production records or test records can be filed before beginning of the operation. Tests can also be performed in a separate test environment or in two environments.\n\nThe test documents must specify which environment will be used. When using a the test strategy chosen must justify the equivalence of the test results to the results that would be obtained in the operational environment.\n\nFormal tests should only be performed in environments under configuration management.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos detalla los tipos de pruebas que deben realizarse para asegurar que un sistema funcione seg\u00fan las especificaciones. Estas pruebas incluyen casos negativos, pruebas de repetibilidad, rendimiento, carga, regresi\u00f3n y estructura. Adem\u00e1s, se discuten los entornos de prueba necesarios, que pueden incluir entornos de desarrollo, prueba y operaci\u00f3n, y se enfatiza la importancia de realizar pruebas formales en un entorno operativo y bajo gesti\u00f3n de configuraci\u00f3n.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfQu\u00e9 tipo de pruebas se deben realizar para asegurar que un sistema inform\u00e1tico no ejecute acciones no permitidas seg\u00fan las especificaciones?**\n   - Respuesta: Se deben realizar **Tests de Casos Inv\u00e1lidos (Casos Negativos o de Resistencia)**, que desaf\u00edan la capacidad del sistema para no realizar acciones que no deber\u00eda hacer, de acuerdo con las especificaciones.\n\n2. **\u00bfCu\u00e1l es la importancia de realizar pruebas en un entorno operativo en lugar de solo en un entorno de prueba?**\n   - Respuesta: Las pruebas formales deben realizarse en un entorno operativo para asegurar que los resultados sean representativos de c\u00f3mo funcionar\u00e1 el sistema en condiciones reales. Esto ayuda a distinguir claramente entre registros de producci\u00f3n y registros de prueba, garantizando la validez de los resultados obtenidos.\n\n3. **\u00bfQu\u00e9 justificaci\u00f3n se requiere al elegir una estrategia de prueba en relaci\u00f3n con los resultados obtenidos en el entorno operativo?**\n   - Respuesta: La estrategia de prueba elegida debe justificar la equivalencia de los resultados de las pruebas con los resultados que se obtendr\u00edan en el entorno operativo, asegurando que las pruebas realizadas en otros entornos sean relevantes y aplicables a la operaci\u00f3n real del sistema.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Informe de Pruebas**:\n   - Elementos esenciales que deben incluirse:\n     - Introducci\u00f3n\n     - Alcance de las pruebas\n     - Organizaci\u00f3n de pruebas\n     - Identificaci\u00f3n de quienes realizaron y revisaron las pruebas\n     - Resumen de resultados en forma tabular\n     - Resumen de fallas en las pruebas\n     - Conclusiones\n     - Informe de resumen para proyectos grandes o complejos\n\n2. **Estrategia de Pruebas**:\n   - Factores a considerar al desarrollar la estrategia:\n     - Pol\u00edticas y procedimientos de la empresa\n     - Resultados de evaluaciones de riesgos\n     - Resultados de evaluaciones de proveedores\n     - Categor\u00edas de sistemas GAMP\n     - Documentos relevantes (especificaciones de requisitos, evaluaciones de riesgos, especificaciones funcionales, etc.)\n\n3. **Tipos de Pruebas**:\n   - **Pruebas de Caja Blanca**:\n     - Basadas en el c\u00f3digo y especificaciones de dise\u00f1o detalladas.\n   - **Pruebas de Caja Negra**:\n     - Basadas en especificaciones funcionales.\n     - Pueden ser suficientes si hay evidencia adecuada de pruebas de caja blanca.\n\n4. **Tipos Espec\u00edficos de Pruebas**:\n   - Pruebas de Casos Normales (Pruebas Positivas o de Capacidad) que eval\u00faan las habilidades del sistema.\n\n### Entidades Clave\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil.\n- **GAMP**: Buenas Pr\u00e1cticas de Automatizaci\u00f3n de Sistemas.\n- **Documentos de Referencia**: Especificaciones de requisitos, evaluaciones de riesgos, especificaciones funcionales, etc.\n\nEste resumen destaca los elementos esenciales y las consideraciones clave para la validaci\u00f3n de sistemas inform\u00e1ticos seg\u00fan la gu\u00eda de ANVISA.", "excerpt_keywords": "Keywords: validation, testing, environments, specifications, ANVISA"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "060263e9-c831-41cd-81ef-1f5bc32356a7", "node_type": "4", "metadata": {"page_label": "49", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# Guide for Computer Systems Validation\n\nto do what it was supposed to do, including triggering error and alarm messages, according to specifications:\n\n- **Tests of Invalid Cases (Negative or Resistance Case)** - challenges to the system's ability to not do what you shouldn't do, according to specifications;\n- **Repeatability Tests** - challenges to the system's ability to repeatedly do what it should do or continuously, if associated with real-time control algorithms;\n- **Performance Testing** - challenges to the system's ability to do what it should do as quickly and effectively possible, according to the specifications;\n- **Volume / Load Testing** - challenges the system's ability to manage high loads as it should. Volume/load tests are required when system resources are critical;\n- **Regression Testing** - challenges to the system's ability to:\n1. Maintain functionality after being modified according to specified requirements;\n2. Ensure that software modules not involved in the modifications are not affected adversely.\n- **Structure / Path Tests** - challenges to the program's internal structure to challenge routines/algorithms, variable values, function return values, etc.\n\nThe tests must challenge the system. So, for example, if the system is designed or intended to record the values of the parameters monitored or controlled in a database at an established frequency (e.g., every second, minute, etc.), that condition or worst case should be tested to ensure that data generated during the routine will be recorded correctly.\n\n----\n\n# 9.7.3.5 Test Environments\n\nThe test strategy must consider and define the environments necessary for carrying out the tests. For typical category 3 systems there will be only one environment. For more complex systems, the performance of Testing can take place in different environments during the design phase, which may include:\n\n- **Development environment**, where prototype production or programming takes place;\n- **Test environment**, where tests are formally performed;\n- **Operating environment** where the system is installed in its target environment.\n\nFormal tests, as far as possible, should be performed in an operational environment. To this end, the records must be clearly distinguished from production records or test records can be filed before beginning of the operation. Tests can also be performed in a separate test environment or in two environments.\n\nThe test documents must specify which environment will be used. When using a the test strategy chosen must justify the equivalence of the test results to the results that would be obtained in the operational environment.\n\nFormal tests should only be performed in environments under configuration management.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "f1fd04b90d25f85fdcdcb5a7bfdb92af76bd28d9dcfcc9d3725f06663ec283f1", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "# Guide for Computer Systems Validation\n\nto do what it was supposed to do, including triggering error and alarm messages, according to specifications:\n\n- **Tests of Invalid Cases (Negative or Resistance Case)** - challenges to the system's ability to not do what you shouldn't do, according to specifications;\n- **Repeatability Tests** - challenges to the system's ability to repeatedly do what it should do or continuously, if associated with real-time control algorithms;\n- **Performance Testing** - challenges to the system's ability to do what it should do as quickly and effectively possible, according to the specifications;\n- **Volume / Load Testing** - challenges the system's ability to manage high loads as it should. Volume/load tests are required when system resources are critical;\n- **Regression Testing** - challenges to the system's ability to:\n1. Maintain functionality after being modified according to specified requirements;\n2. Ensure that software modules not involved in the modifications are not affected adversely.\n- **Structure / Path Tests** - challenges to the program's internal structure to challenge routines/algorithms, variable values, function return values, etc.\n\nThe tests must challenge the system. So, for example, if the system is designed or intended to record the values of the parameters monitored or controlled in a database at an established frequency (e.g., every second, minute, etc.), that condition or worst case should be tested to ensure that data generated during the routine will be recorded correctly.\n\n----\n\n# 9.7.3.5 Test Environments\n\nThe test strategy must consider and define the environments necessary for carrying out the tests. For typical category 3 systems there will be only one environment. For more complex systems, the performance of Testing can take place in different environments during the design phase, which may include:\n\n- **Development environment**, where prototype production or programming takes place;\n- **Test environment**, where tests are formally performed;\n- **Operating environment** where the system is installed in its target environment.\n\nFormal tests, as far as possible, should be performed in an operational environment. To this end, the records must be clearly distinguished from production records or test records can be filed before beginning of the operation. Tests can also be performed in a separate test environment or in two environments.\n\nThe test documents must specify which environment will be used. When using a the test strategy chosen must justify the equivalence of the test results to the results that would be obtained in the operational environment.\n\nFormal tests should only be performed in environments under configuration management.", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 2745, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "08884b1a-dd94-4fcb-87e9-bb37bbee213f": {"__data__": {"id_": "08884b1a-dd94-4fcb-87e9-bb37bbee213f", "embedding": null, "metadata": {"page_label": "50", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 9.7.3.6 Acceptance Tests\n\nAcceptance tests are specific tests performed to meet some contractual needs. These tests are usually part of a predefined group of functional tests performed to demonstrate the adequacy of the system to the intended use and compliance with user requirements. In such situations, take advantage of test results already carried out, thus avoiding duplication of tests.\n\nAcceptance can be carried out in two stages, Acceptance at the Factory (Factory) or the Plant (Site), namely:\n\n- **Acceptance Testing Factory (Factory Acceptance Tests - FAT)** - are performed on the premises of before delivery, to show that the system is working well enough to be installed and tested at the user's premises;\n- **Acceptance Tests in Plant (Site Acceptance Tests - SAT)** - run on the company premises regulated to show that the system is working in its operating environment and that its interface with other systems and peripherals and is working properly.\n\nThis approach is often used for automated equipment and control systems.\n\nThe environment for conducting the acceptance test (test or operational) must be defined.\n\n# 9.7.4 Execution of Tests\n\nAll tests are performed according to specifications and scripts pre-defined and approved and maintained under version control.\n\n----\n\n# 9.7.4.1 Prerequisites\n\nThe following general requirements must be met before formal testing begins:\n\n- Formal configuration management must exist before formal testing begins. All items to be tested (Firmware/software/hardware) that are within the scope of the testing phase specific, should be considered as a baseline and be under change control before execution of tests;\n- All necessary documentation must be available as described in the test specifications;\n- All prerequisites must be available;\n- If there is a need to calibrate any equipment, this must be done and documented. THE calibration equipment must be certified, traceable to national standards and referenced according to customer procedures;\n- All personnel responsible for carrying out the tests, including end users, must be trained in the test procedures and must be able to demonstrate sufficient confidence to operate the system in test. Training must be documented.\n- All employees involved must be trained in Good Documentation Practices.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos establece directrices para la realizaci\u00f3n de pruebas de aceptaci\u00f3n, que son esenciales para garantizar que un sistema cumple con los requisitos del usuario y es adecuado para su uso previsto. Estas pruebas se dividen en dos etapas: las pruebas de aceptaci\u00f3n en f\u00e1brica (FAT) y las pruebas de aceptaci\u00f3n en planta (SAT). Adem\u00e1s, se detallan los requisitos previos que deben cumplirse antes de iniciar las pruebas formales, incluyendo la gesti\u00f3n de configuraci\u00f3n, la disponibilidad de documentaci\u00f3n y la capacitaci\u00f3n del personal involucrado.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfCu\u00e1les son las diferencias clave entre las pruebas de aceptaci\u00f3n en f\u00e1brica (FAT) y las pruebas de aceptaci\u00f3n en planta (SAT)?**\n   - Esta pregunta busca una comparaci\u00f3n directa entre los dos tipos de pruebas de aceptaci\u00f3n mencionadas en el documento, lo que no se encuentra f\u00e1cilmente en otros contextos.\n\n2. **\u00bfQu\u00e9 requisitos de gesti\u00f3n de configuraci\u00f3n deben cumplirse antes de comenzar las pruebas formales?**\n   - Esta pregunta se centra en los aspectos espec\u00edficos de la gesti\u00f3n de configuraci\u00f3n que son cruciales para el proceso de validaci\u00f3n, lo que puede no estar claramente definido en otras gu\u00edas o documentos.\n\n3. **\u00bfQu\u00e9 tipo de capacitaci\u00f3n es necesaria para el personal que realiza las pruebas, y por qu\u00e9 es importante documentarla?**\n   - Esta pregunta aborda la importancia de la capacitaci\u00f3n del personal y la documentaci\u00f3n de la misma, aspectos que son fundamentales para asegurar la calidad y la conformidad en el proceso de pruebas, pero que pueden no ser tratados en detalle en otros contextos.", "prev_section_summary": "### Temas Clave\n\n1. **Tipos de Pruebas**: El documento detalla varios tipos de pruebas que deben realizarse para validar sistemas inform\u00e1ticos, incluyendo:\n   - **Tests de Casos Inv\u00e1lidos**: Verifican que el sistema no realice acciones no permitidas.\n   - **Pruebas de Repetibilidad**: Aseguran que el sistema pueda realizar las mismas acciones de manera consistente.\n   - **Pruebas de Rendimiento**: Eval\u00faan la rapidez y efectividad del sistema.\n   - **Pruebas de Carga/Volumen**: Determinan la capacidad del sistema para manejar altas cargas de trabajo.\n   - **Pruebas de Regresi\u00f3n**: Aseguran que las modificaciones no afecten negativamente la funcionalidad existente.\n   - **Pruebas de Estructura/Camino**: Analizan la estructura interna del programa.\n\n2. **Entornos de Prueba**: Se discuten los diferentes entornos necesarios para realizar pruebas, que incluyen:\n   - **Entorno de Desarrollo**: Para la producci\u00f3n de prototipos y programaci\u00f3n.\n   - **Entorno de Prueba**: Donde se realizan las pruebas formales.\n   - **Entorno Operativo**: Donde el sistema se instala en su entorno objetivo.\n\n3. **Importancia de las Pruebas Formales**: Se enfatiza que las pruebas deben realizarse en un entorno operativo para asegurar la validez de los resultados y la correcta distinci\u00f3n entre registros de producci\u00f3n y de prueba.\n\n4. **Gesti\u00f3n de Configuraci\u00f3n**: Las pruebas formales deben llevarse a cabo en entornos que est\u00e9n bajo gesti\u00f3n de configuraci\u00f3n para asegurar la integridad y trazabilidad de los resultados.\n\n### Entidades\n\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil, responsable de la regulaci\u00f3n de sistemas inform\u00e1ticos en el \u00e1mbito de la salud.\n- **Sistemas Inform\u00e1ticos**: Sistemas que requieren validaci\u00f3n para asegurar su correcto funcionamiento seg\u00fan especificaciones.\n- **Entornos de Prueba**: Incluyen desarrollo, prueba y operaci\u00f3n, cada uno con un prop\u00f3sito espec\u00edfico en el proceso de validaci\u00f3n.\n- **Documentos de Prueba**: Documentaci\u00f3n que especifica las estrategias y entornos utilizados para las pruebas.\n\n### Resumen\n\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos establece la necesidad de realizar diversas pruebas para garantizar que los sistemas funcionen seg\u00fan las especificaciones. Se destacan los tipos de pruebas, la importancia de realizar pruebas en entornos operativos y la necesidad de gesti\u00f3n de configuraci\u00f3n para asegurar la validez de los resultados.", "excerpt_keywords": "Keywords: Acceptance Tests, Factory Acceptance Tests, Site Acceptance Tests, Configuration Management, Good Documentation Practices"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "cec2f0ca-65ca-434a-b41c-d23642da723e", "node_type": "4", "metadata": {"page_label": "50", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 9.7.3.6 Acceptance Tests\n\nAcceptance tests are specific tests performed to meet some contractual needs. These tests are usually part of a predefined group of functional tests performed to demonstrate the adequacy of the system to the intended use and compliance with user requirements. In such situations, take advantage of test results already carried out, thus avoiding duplication of tests.\n\nAcceptance can be carried out in two stages, Acceptance at the Factory (Factory) or the Plant (Site), namely:\n\n- **Acceptance Testing Factory (Factory Acceptance Tests - FAT)** - are performed on the premises of before delivery, to show that the system is working well enough to be installed and tested at the user's premises;\n- **Acceptance Tests in Plant (Site Acceptance Tests - SAT)** - run on the company premises regulated to show that the system is working in its operating environment and that its interface with other systems and peripherals and is working properly.\n\nThis approach is often used for automated equipment and control systems.\n\nThe environment for conducting the acceptance test (test or operational) must be defined.\n\n# 9.7.4 Execution of Tests\n\nAll tests are performed according to specifications and scripts pre-defined and approved and maintained under version control.\n\n----\n\n# 9.7.4.1 Prerequisites\n\nThe following general requirements must be met before formal testing begins:\n\n- Formal configuration management must exist before formal testing begins. All items to be tested (Firmware/software/hardware) that are within the scope of the testing phase specific, should be considered as a baseline and be under change control before execution of tests;\n- All necessary documentation must be available as described in the test specifications;\n- All prerequisites must be available;\n- If there is a need to calibrate any equipment, this must be done and documented. THE calibration equipment must be certified, traceable to national standards and referenced according to customer procedures;\n- All personnel responsible for carrying out the tests, including end users, must be trained in the test procedures and must be able to demonstrate sufficient confidence to operate the system in test. Training must be documented.\n- All employees involved must be trained in Good Documentation Practices.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "af33b422a6c4654b54e5798bda3cfb5cf536f33d4af5159bf30471233efb4f61", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "# 9.7.3.6 Acceptance Tests\n\nAcceptance tests are specific tests performed to meet some contractual needs. These tests are usually part of a predefined group of functional tests performed to demonstrate the adequacy of the system to the intended use and compliance with user requirements. In such situations, take advantage of test results already carried out, thus avoiding duplication of tests.\n\nAcceptance can be carried out in two stages, Acceptance at the Factory (Factory) or the Plant (Site), namely:\n\n- **Acceptance Testing Factory (Factory Acceptance Tests - FAT)** - are performed on the premises of before delivery, to show that the system is working well enough to be installed and tested at the user's premises;\n- **Acceptance Tests in Plant (Site Acceptance Tests - SAT)** - run on the company premises regulated to show that the system is working in its operating environment and that its interface with other systems and peripherals and is working properly.\n\nThis approach is often used for automated equipment and control systems.\n\nThe environment for conducting the acceptance test (test or operational) must be defined.\n\n# 9.7.4 Execution of Tests\n\nAll tests are performed according to specifications and scripts pre-defined and approved and maintained under version control.\n\n----\n\n# 9.7.4.1 Prerequisites\n\nThe following general requirements must be met before formal testing begins:\n\n- Formal configuration management must exist before formal testing begins. All items to be tested (Firmware/software/hardware) that are within the scope of the testing phase specific, should be considered as a baseline and be under change control before execution of tests;\n- All necessary documentation must be available as described in the test specifications;\n- All prerequisites must be available;\n- If there is a need to calibrate any equipment, this must be done and documented. THE calibration equipment must be certified, traceable to national standards and referenced according to customer procedures;\n- All personnel responsible for carrying out the tests, including end users, must be trained in the test procedures and must be able to demonstrate sufficient confidence to operate the system in test. Training must be documented.\n- All employees involved must be trained in Good Documentation Practices.", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 2318, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "1df903e2-7973-4824-a948-3ef861d97f52": {"__data__": {"id_": "1df903e2-7973-4824-a948-3ef861d97f52", "embedding": null, "metadata": {"page_label": "51", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "## 9.7.4.2 Execution\n\nTests should be performed as follows:\n\n- According to a pre-defined and pre-approved specification.\n- Each test must be performed according to the test script and the results must be recorded;\n- Each test must be performed by an appropriately trained person, including Good Practice Practices. Documentation;\n- The results of the tests must be documented directly at the time of their execution and must be maintained;\n- All test results must be recorded immediately and accurately;\n- The identity of the tester must be recorded;\n- Test records made manually must be readable. Shorthand annotations should be avoided and real values should be recorded whenever possible;\n- The test runner must decide whether the acceptance criterion is met and whether the test has passed or not. THE test script must declare whether the test PASSED or FAILED;\n- In the event of a FAIL in the test, the executor must decide whether to continue testing, abort tests or refers to item 9.7.4.4 (Test Review), in accordance with approved testing procedures. All tests that fail must be recorded;\n- Testing procedures must be flexible enough to allow the tester to be able to decide whether to continue testing when you encounter situations such as when the system is found to work correctly, but the test script is incorrect;\n- All tests that fail must be traceable during correction until final closure. At corrections of failed tests may require regression tests to verify that corrections do not introduced new problems in other modules or routines of the system.\n\nThe execution of the tests must be audited periodically, by sampling, by the Quality Unit of the regulated company.\n\n## 9.7.4.3 Test Support Documentation\n\nDocumentation, such as prints, screen prints, notes, photos, etc., are required to give support test results.\n\nMore complex systems require more extensive and complete support documentation than more complex systems simple.\n\nUnnecessary supporting documentation, which does not add any value to the test results, should be avoided.\n\n## 9.7.4.4 Review of Tests\n\nAfter completing the tests, the results should be reviewed to verify:", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas basadas en el contexto proporcionado, junto con sus respuestas:\n\n### Preguntas y Respuestas\n\n1. **\u00bfQu\u00e9 criterios deben cumplirse para que un test se considere aprobado seg\u00fan el documento de ANVISA?**\n   - Un test se considera aprobado si se realiza de acuerdo con una especificaci\u00f3n predefinida y preaprobada, se ejecuta seg\u00fan el script de prueba, y el resultado se documenta de manera inmediata y precisa. Adem\u00e1s, el script de prueba debe declarar expl\u00edcitamente si el test ha PASADO o FALLADO, y el criterio de aceptaci\u00f3n debe ser cumplido.\n\n2. **\u00bfQu\u00e9 debe hacerse en caso de que un test falle durante su ejecuci\u00f3n?**\n   - Si un test falla, el ejecutor debe decidir si continuar con las pruebas, abortarlas o referirse al procedimiento de revisi\u00f3n de pruebas. Todos los fallos deben ser registrados, y es importante que las pruebas fallidas sean trazables hasta su correcci\u00f3n final. Adem\u00e1s, puede ser necesario realizar pruebas de regresi\u00f3n para asegurar que las correcciones no introduzcan nuevos problemas.\n\n3. **\u00bfCu\u00e1l es la importancia de la documentaci\u00f3n de soporte en las pruebas y c\u00f3mo debe ser manejada?**\n   - La documentaci\u00f3n de soporte, como capturas de pantalla, notas y fotos, es crucial para respaldar los resultados de las pruebas. En sistemas m\u00e1s complejos, se requiere una documentaci\u00f3n m\u00e1s extensa y completa. Sin embargo, se debe evitar la documentaci\u00f3n innecesaria que no aporte valor a los resultados de las pruebas, asegurando as\u00ed que la informaci\u00f3n sea relevante y \u00fatil.\n\n### Resumen de Nivel Superior\n\nEl documento de ANVISA establece directrices claras para la ejecuci\u00f3n de pruebas en sistemas inform\u00e1ticos, enfatizando la importancia de seguir especificaciones predefinidas, documentar resultados de manera precisa y mantener la trazabilidad de las pruebas fallidas. Tambi\u00e9n se destaca la necesidad de una documentaci\u00f3n de soporte adecuada y la flexibilidad en los procedimientos de prueba para adaptarse a situaciones imprevistas. La revisi\u00f3n de los resultados de las pruebas es esencial para garantizar la calidad y la conformidad con los est\u00e1ndares establecidos.\n\n### Preguntas Generadas a partir del Resumen\n\n1. **\u00bfPor qu\u00e9 es crucial seguir especificaciones predefinidas en la ejecuci\u00f3n de pruebas seg\u00fan ANVISA?**\n2. **\u00bfQu\u00e9 papel juega la documentaci\u00f3n de soporte en la validaci\u00f3n de sistemas inform\u00e1ticos y c\u00f3mo se debe gestionar?**\n3. **\u00bfC\u00f3mo se debe manejar la trazabilidad de las pruebas fallidas y qu\u00e9 implicaciones tiene para el proceso de correcci\u00f3n?**", "prev_section_summary": "### Temas Clave\n\n1. **Pruebas de Aceptaci\u00f3n**: Se definen como pruebas espec\u00edficas realizadas para cumplir con necesidades contractuales y demostrar la adecuaci\u00f3n del sistema a su uso previsto y el cumplimiento de los requisitos del usuario.\n\n2. **Tipos de Pruebas de Aceptaci\u00f3n**:\n   - **Pruebas de Aceptaci\u00f3n en F\u00e1brica (FAT)**: Realizadas antes de la entrega para asegurar que el sistema funcione adecuadamente antes de ser instalado en las instalaciones del usuario.\n   - **Pruebas de Aceptaci\u00f3n en Planta (SAT)**: Ejecutadas en las instalaciones del cliente para verificar que el sistema opera correctamente en su entorno y se integra adecuadamente con otros sistemas y perif\u00e9ricos.\n\n3. **Ejecuci\u00f3n de Pruebas**: Todas las pruebas deben realizarse de acuerdo con especificaciones y scripts predefinidos, que deben estar aprobados y bajo control de versiones.\n\n4. **Requisitos Previos para las Pruebas**:\n   - Gesti\u00f3n de configuraci\u00f3n formal.\n   - Disponibilidad de documentaci\u00f3n necesaria.\n   - Cumplimiento de todos los requisitos previos.\n   - Calibraci\u00f3n y documentaci\u00f3n de equipos, si es necesario.\n   - Capacitaci\u00f3n del personal involucrado en las pruebas, con documentaci\u00f3n de la misma.\n   - Capacitaci\u00f3n en Buenas Pr\u00e1cticas de Documentaci\u00f3n para todos los empleados implicados.\n\n### Entidades\n\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria en Brasil, responsable de la regulaci\u00f3n de sistemas inform\u00e1ticos en el \u00e1mbito de la salud.\n- **FAT (Factory Acceptance Tests)**: Pruebas de aceptaci\u00f3n en f\u00e1brica.\n- **SAT (Site Acceptance Tests)**: Pruebas de aceptaci\u00f3n en planta.\n- **Firmware, Software, Hardware**: Elementos que deben ser gestionados bajo control de cambios antes de las pruebas.\n- **Calibraci\u00f3n**: Proceso necesario para asegurar que los equipos utilizados en las pruebas est\u00e9n en condiciones adecuadas de funcionamiento.\n- **Capacitaci\u00f3n**: Formaci\u00f3n necesaria para el personal que realiza las pruebas, asegurando que est\u00e9n preparados y documentados.\n\nEste resumen destaca los aspectos fundamentales y las entidades relevantes en la secci\u00f3n sobre pruebas de aceptaci\u00f3n del documento de ANVISA.", "excerpt_keywords": "Keywords: validation, testing, documentation, ANVISA, quality assurance"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "1c54d830-e6ca-4bbb-beaf-cfc2ec0f71b7", "node_type": "4", "metadata": {"page_label": "51", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "## 9.7.4.2 Execution\n\nTests should be performed as follows:\n\n- According to a pre-defined and pre-approved specification.\n- Each test must be performed according to the test script and the results must be recorded;\n- Each test must be performed by an appropriately trained person, including Good Practice Practices. Documentation;\n- The results of the tests must be documented directly at the time of their execution and must be maintained;\n- All test results must be recorded immediately and accurately;\n- The identity of the tester must be recorded;\n- Test records made manually must be readable. Shorthand annotations should be avoided and real values should be recorded whenever possible;\n- The test runner must decide whether the acceptance criterion is met and whether the test has passed or not. THE test script must declare whether the test PASSED or FAILED;\n- In the event of a FAIL in the test, the executor must decide whether to continue testing, abort tests or refers to item 9.7.4.4 (Test Review), in accordance with approved testing procedures. All tests that fail must be recorded;\n- Testing procedures must be flexible enough to allow the tester to be able to decide whether to continue testing when you encounter situations such as when the system is found to work correctly, but the test script is incorrect;\n- All tests that fail must be traceable during correction until final closure. At corrections of failed tests may require regression tests to verify that corrections do not introduced new problems in other modules or routines of the system.\n\nThe execution of the tests must be audited periodically, by sampling, by the Quality Unit of the regulated company.\n\n## 9.7.4.3 Test Support Documentation\n\nDocumentation, such as prints, screen prints, notes, photos, etc., are required to give support test results.\n\nMore complex systems require more extensive and complete support documentation than more complex systems simple.\n\nUnnecessary supporting documentation, which does not add any value to the test results, should be avoided.\n\n## 9.7.4.4 Review of Tests\n\nAfter completing the tests, the results should be reviewed to verify:", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "b5f8ce7187487edaf78529bb284ad68d079b94a759a61345584e228b630ae643", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "## 9.7.4.2 Execution\n\nTests should be performed as follows:\n\n- According to a pre-defined and pre-approved specification.\n- Each test must be performed according to the test script and the results must be recorded;\n- Each test must be performed by an appropriately trained person, including Good Practice Practices. Documentation;\n- The results of the tests must be documented directly at the time of their execution and must be maintained;\n- All test results must be recorded immediately and accurately;\n- The identity of the tester must be recorded;\n- Test records made manually must be readable. Shorthand annotations should be avoided and real values should be recorded whenever possible;\n- The test runner must decide whether the acceptance criterion is met and whether the test has passed or not. THE test script must declare whether the test PASSED or FAILED;\n- In the event of a FAIL in the test, the executor must decide whether to continue testing, abort tests or refers to item 9.7.4.4 (Test Review), in accordance with approved testing procedures. All tests that fail must be recorded;\n- Testing procedures must be flexible enough to allow the tester to be able to decide whether to continue testing when you encounter situations such as when the system is found to work correctly, but the test script is incorrect;\n- All tests that fail must be traceable during correction until final closure. At corrections of failed tests may require regression tests to verify that corrections do not introduced new problems in other modules or routines of the system.\n\nThe execution of the tests must be audited periodically, by sampling, by the Quality Unit of the regulated company.\n\n## 9.7.4.3 Test Support Documentation\n\nDocumentation, such as prints, screen prints, notes, photos, etc., are required to give support test results.\n\nMore complex systems require more extensive and complete support documentation than more complex systems simple.\n\nUnnecessary supporting documentation, which does not add any value to the test results, should be avoided.\n\n## 9.7.4.4 Review of Tests\n\nAfter completing the tests, the results should be reviewed to verify:", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 2156, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "12317370-c0fe-4965-a79e-3e14ea4656c2": {"__data__": {"id_": "12317370-c0fe-4965-a79e-3e14ea4656c2", "embedding": null, "metadata": {"page_label": "52", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "- That all tests have been covered;\n- The legibility, accuracy and completeness of the tests;\n- That all relevant documents have been included and that the documentation is complete and correctly filled;\n- That the acceptance criteria have been met;\n- That all records of failed tests have been included;\n- Compliance with procedures.\n\nAlternatively, the tester may request a review of the tests when a failure occurs, in order to decide what actions will be taken and what will be the next steps.\n\nReviews must be performed and documented by a person other than the test runner, such as a test reviewer or a group, or the subject matter expert.\n\nIn the event of test failures, the test reviewer must decide what action to take and what type of retest to take. These decisions must be documented.\n\nTesting failures can result from:\n\n- Error in the way the script was written. Corrective action: update, followed by script approval corrected tests and consider the need for retesting;\n- Error in how the requirement was defined. Corrective action: update the requirement, with possible execution of retest and explanation in the test report;\n- Error in the way the test was performed by the tester. Corrective action: repetition of the test;\n- System error. Corrective action: application of a change control and repetition of the test.\n\n## 9.7.5 Testing Activities Performed by the Supplier\n\nThere are different models of *software* development, including:\n\n- Waterfall;\n- Spiral;\n- Prototyping;\n- V model.\n\nWhichever model is used, the supplier must define the implementation of the model, including the necessary quality controls and describe the method used to demonstrate that the system computerized is suitable for the intended use.\n\nTesting strategies must be properly established, implemented and documented.\n\nThe *hardware* and *software* configuration used in the tests must be documented. This includes: systems underlying systems such as operating system, database and network; *hardware* for networks; servers and clients, when appropriate.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos establece directrices sobre la realizaci\u00f3n de pruebas en software, incluyendo la necesidad de cubrir todas las pruebas, la legibilidad y precisi\u00f3n de los resultados, y la documentaci\u00f3n adecuada de los procesos. Se enfatiza la importancia de que las revisiones de pruebas sean realizadas por personas distintas a quienes ejecutaron las pruebas, y se describen las acciones correctivas a tomar en caso de fallos en las pruebas. Adem\u00e1s, se mencionan diferentes modelos de desarrollo de software y la necesidad de documentar la configuraci\u00f3n de hardware y software utilizada en las pruebas.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfQu\u00e9 acciones correctivas se deben tomar si se identifica un error en la forma en que se escribi\u00f3 el script de prueba?**\n   - La acci\u00f3n correctiva consiste en actualizar el script, seguido de la aprobaci\u00f3n del script corregido y considerar la necesidad de realizar un retest.\n\n2. **\u00bfQui\u00e9n debe realizar y documentar las revisiones de las pruebas en caso de fallos, y por qu\u00e9 es importante esta separaci\u00f3n de funciones?**\n   - Las revisiones deben ser realizadas y documentadas por una persona distinta al ejecutor de la prueba, como un revisor de pruebas o un experto en la materia. Esta separaci\u00f3n es importante para garantizar la objetividad y la imparcialidad en la evaluaci\u00f3n de los resultados de las pruebas.\n\n3. **\u00bfQu\u00e9 aspectos deben ser documentados en relaci\u00f3n con la configuraci\u00f3n de hardware y software utilizada durante las pruebas?**\n   - Debe documentarse la configuraci\u00f3n de hardware y software utilizada, incluyendo los sistemas subyacentes como el sistema operativo, la base de datos y la red, as\u00ed como el hardware para redes, servidores y clientes, cuando sea apropiado.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n#### Temas Clave:\n\n1. **Ejecuci\u00f3n de Pruebas**:\n   - Las pruebas deben realizarse seg\u00fan especificaciones predefinidas y aprobadas.\n   - Es esencial seguir un script de prueba y documentar los resultados de manera inmediata y precisa.\n   - La identidad del probador debe ser registrada y los registros deben ser legibles.\n   - En caso de fallos, se debe decidir si continuar, abortar o revisar las pruebas, y todos los fallos deben ser documentados y trazables.\n\n2. **Documentaci\u00f3n de Soporte**:\n   - Se requiere documentaci\u00f3n adicional (capturas de pantalla, notas, fotos) para respaldar los resultados de las pruebas.\n   - La cantidad y complejidad de la documentaci\u00f3n de soporte deben ser proporcionales a la complejidad del sistema.\n   - Se debe evitar la documentaci\u00f3n innecesaria que no aporte valor.\n\n3. **Revisi\u00f3n de Pruebas**:\n   - Los resultados de las pruebas deben ser revisados tras su finalizaci\u00f3n para verificar su validez y conformidad con los criterios establecidos.\n\n4. **Auditor\u00eda**:\n   - La ejecuci\u00f3n de las pruebas debe ser auditada peri\u00f3dicamente por la Unidad de Calidad de la empresa regulada.\n\n#### Entidades:\n\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil, responsable de regular y supervisar la validaci\u00f3n de sistemas inform\u00e1ticos.\n- **Unidad de Calidad**: Entidad dentro de la empresa regulada encargada de auditar y asegurar la calidad de los procesos de prueba.\n- **Probador**: Persona responsable de ejecutar las pruebas, que debe estar adecuadamente entrenada.\n- **Sistema Inform\u00e1tico**: El objeto de validaci\u00f3n que est\u00e1 siendo probado.\n\nEste resumen destaca la importancia de seguir procedimientos rigurosos en la ejecuci\u00f3n de pruebas, la necesidad de documentaci\u00f3n adecuada y la revisi\u00f3n de resultados para garantizar la calidad y conformidad en la validaci\u00f3n de sistemas inform\u00e1ticos.", "excerpt_keywords": "Keywords: validation, testing, documentation, software development, corrective actions"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "f180220c-af47-4d63-b9a2-c94e0f93c150", "node_type": "4", "metadata": {"page_label": "52", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "- That all tests have been covered;\n- The legibility, accuracy and completeness of the tests;\n- That all relevant documents have been included and that the documentation is complete and correctly filled;\n- That the acceptance criteria have been met;\n- That all records of failed tests have been included;\n- Compliance with procedures.\n\nAlternatively, the tester may request a review of the tests when a failure occurs, in order to decide what actions will be taken and what will be the next steps.\n\nReviews must be performed and documented by a person other than the test runner, such as a test reviewer or a group, or the subject matter expert.\n\nIn the event of test failures, the test reviewer must decide what action to take and what type of retest to take. These decisions must be documented.\n\nTesting failures can result from:\n\n- Error in the way the script was written. Corrective action: update, followed by script approval corrected tests and consider the need for retesting;\n- Error in how the requirement was defined. Corrective action: update the requirement, with possible execution of retest and explanation in the test report;\n- Error in the way the test was performed by the tester. Corrective action: repetition of the test;\n- System error. Corrective action: application of a change control and repetition of the test.\n\n## 9.7.5 Testing Activities Performed by the Supplier\n\nThere are different models of *software* development, including:\n\n- Waterfall;\n- Spiral;\n- Prototyping;\n- V model.\n\nWhichever model is used, the supplier must define the implementation of the model, including the necessary quality controls and describe the method used to demonstrate that the system computerized is suitable for the intended use.\n\nTesting strategies must be properly established, implemented and documented.\n\nThe *hardware* and *software* configuration used in the tests must be documented. This includes: systems underlying systems such as operating system, database and network; *hardware* for networks; servers and clients, when appropriate.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "0d1850d4a1c0a2e9976f0a002c7c42ffe955319ff976332dc512ddbd71334b29", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "- That all tests have been covered;\n- The legibility, accuracy and completeness of the tests;\n- That all relevant documents have been included and that the documentation is complete and correctly filled;\n- That the acceptance criteria have been met;\n- That all records of failed tests have been included;\n- Compliance with procedures.\n\nAlternatively, the tester may request a review of the tests when a failure occurs, in order to decide what actions will be taken and what will be the next steps.\n\nReviews must be performed and documented by a person other than the test runner, such as a test reviewer or a group, or the subject matter expert.\n\nIn the event of test failures, the test reviewer must decide what action to take and what type of retest to take. These decisions must be documented.\n\nTesting failures can result from:\n\n- Error in the way the script was written. Corrective action: update, followed by script approval corrected tests and consider the need for retesting;\n- Error in how the requirement was defined. Corrective action: update the requirement, with possible execution of retest and explanation in the test report;\n- Error in the way the test was performed by the tester. Corrective action: repetition of the test;\n- System error. Corrective action: application of a change control and repetition of the test.\n\n## 9.7.5 Testing Activities Performed by the Supplier\n\nThere are different models of *software* development, including:\n\n- Waterfall;\n- Spiral;\n- Prototyping;\n- V model.\n\nWhichever model is used, the supplier must define the implementation of the model, including the necessary quality controls and describe the method used to demonstrate that the system computerized is suitable for the intended use.\n\nTesting strategies must be properly established, implemented and documented.\n\nThe *hardware* and *software* configuration used in the tests must be documented. This includes: systems underlying systems such as operating system, database and network; *hardware* for networks; servers and clients, when appropriate.", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 2053, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "da55b95f-68a7-4b81-bb5a-a1c22c7b4318": {"__data__": {"id_": "da55b95f-68a7-4b81-bb5a-a1c22c7b4318", "embedding": null, "metadata": {"page_label": "53", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "## 9.7.5.1 Tests Performed During Development\n\nInternal tests performed by the supplier must be performed according to test specifications defined and approved. Types of tests most commonly performed are:\n\n- **Acceptance testing for hardware and software purchased** - hardware and software purchased must be subjected to acceptance tests before being used for system development;\n- **Module / unit tests** - individual tests on software components, ensuring readiness for later insertion into an integrated system;\n- **Integration and System Tests** - tests of the integrated components of the system, subsystems and the complete system.\n\n## 9.7.5.2 Contractual Tests\n\nTesting and verification activities should be defined for business purposes, between the computerized system supplier and the regulated company.\n\n## 9.7.6 Automated Tests\n\nAutomated verification testing tools can be used to improve effectiveness and efficiency of test execution. They can be used both for the execution of cash tests, black and white box tests.\n\nAny use of these tools must be defined in the testing strategy.\n\nThese tools must be used in accordance with instructions and manuals defined and maintained under Configuration Management. They usually belong to GAMP category 1.\n\nIt is important that responsibilities are defined in relation to the following aspects:\n\n- Ownership (Who owns it), administration and maintenance of the test tool;\n- Maintenance of test data;\n- Maintenance of test documents (including test specifications, test scripts and test results);\n- Instructions and manuals for use.\n\nPreferably, these testing tools should have the capabilities of electronic signatures and electronic records that meet regulatory requirements.\n\n## 9.7.6.1 Examples of Automated Test Execution Tools\n\nBelow are some examples of tools for automated execution (source code debugging and testing tools) for testing the source code:\n\n- Automated test drivers (automatic test execution);\n- Test data generators;", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "### Resumen del Contexto\n\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos detalla los tipos de pruebas que deben realizarse durante el desarrollo de software y hardware, as\u00ed como la importancia de las pruebas automatizadas. Se enfatiza la necesidad de que las pruebas sean definidas y aprobadas, y se menciona la responsabilidad en la administraci\u00f3n de herramientas de prueba. Tambi\u00e9n se destacan ejemplos de herramientas de ejecuci\u00f3n de pruebas automatizadas.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfCu\u00e1les son los tipos de pruebas que deben realizarse antes de utilizar hardware y software en el desarrollo de sistemas, seg\u00fan el documento de ANVISA?**\n   - Respuesta: Los tipos de pruebas incluyen pruebas de aceptaci\u00f3n para hardware y software adquiridos, pruebas de m\u00f3dulo/unidad, y pruebas de integraci\u00f3n y del sistema.\n\n2. **\u00bfQu\u00e9 aspectos deben definirse en relaci\u00f3n con las herramientas de prueba automatizadas seg\u00fan la gu\u00eda de ANVISA?**\n   - Respuesta: Deben definirse aspectos como la propiedad y administraci\u00f3n de la herramienta de prueba, el mantenimiento de los datos de prueba, el mantenimiento de documentos de prueba (especificaciones, scripts y resultados), y las instrucciones y manuales para su uso.\n\n3. **\u00bfQu\u00e9 caracter\u00edsticas deben tener preferiblemente las herramientas de prueba automatizadas para cumplir con los requisitos regulatorios?**\n   - Respuesta: Las herramientas de prueba automatizadas deben tener capacidades de firmas electr\u00f3nicas y registros electr\u00f3nicos que cumplan con los requisitos regulatorios.\n\n### Resumen de Nivel Superior\n\nEl documento de ANVISA establece directrices claras sobre la validaci\u00f3n de sistemas inform\u00e1ticos, enfatizando la importancia de realizar pruebas adecuadas durante el desarrollo y el uso de herramientas automatizadas para mejorar la eficiencia. Se requiere que las pruebas sean definidas y aprobadas, y que se mantenga una gesti\u00f3n adecuada de las herramientas y documentos relacionados.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Pruebas de Software**: Se enfatiza la importancia de cubrir todas las pruebas, asegurando su legibilidad, precisi\u00f3n y completitud. Tambi\u00e9n se requiere que toda la documentaci\u00f3n relevante est\u00e9 completa y correctamente llenada.\n\n2. **Revisi\u00f3n de Pruebas**: Las revisiones deben ser realizadas por personas distintas a quienes ejecutaron las pruebas, como revisores de pruebas o expertos en la materia. Esto es crucial para mantener la objetividad en la evaluaci\u00f3n de los resultados.\n\n3. **Acciones Correctivas ante Fallos**: Se describen las acciones correctivas a tomar en caso de fallos en las pruebas, que pueden incluir:\n   - Actualizaci\u00f3n del script de prueba.\n   - Actualizaci\u00f3n de los requisitos.\n   - Repetici\u00f3n de la prueba.\n   - Aplicaci\u00f3n de control de cambios y repetici\u00f3n de la prueba en caso de errores del sistema.\n\n4. **Modelos de Desarrollo de Software**: Se mencionan diferentes modelos de desarrollo, como Waterfall, Spiral, Prototyping y V model. El proveedor debe definir c\u00f3mo se implementar\u00e1 el modelo elegido y los controles de calidad necesarios.\n\n5. **Documentaci\u00f3n de Configuraci\u00f3n**: Es esencial documentar la configuraci\u00f3n de hardware y software utilizada en las pruebas, incluyendo sistemas operativos, bases de datos, redes, servidores y clientes.\n\n### Entidades Clave\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil, responsable de la regulaci\u00f3n de la validaci\u00f3n de sistemas inform\u00e1ticos.\n- **Modelos de Desarrollo de Software**: Waterfall, Spiral, Prototyping, V model.\n- **Roles**: Tester, Revisor de Pruebas, Experto en la Materia.\n- **Elementos de Documentaci\u00f3n**: Resultados de pruebas, requisitos, configuraciones de hardware y software. \n\nEste resumen destaca la importancia de la validaci\u00f3n y documentaci\u00f3n en el proceso de pruebas de software, as\u00ed como la necesidad de mantener la calidad y la objetividad en las evaluaciones.", "excerpt_keywords": "Keywords: ANVISA, computer systems validation, automated testing, acceptance testing, software development"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "0e5a5b83-4c39-45ed-a018-143cfa8d9c89", "node_type": "4", "metadata": {"page_label": "53", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "## 9.7.5.1 Tests Performed During Development\n\nInternal tests performed by the supplier must be performed according to test specifications defined and approved. Types of tests most commonly performed are:\n\n- **Acceptance testing for hardware and software purchased** - hardware and software purchased must be subjected to acceptance tests before being used for system development;\n- **Module / unit tests** - individual tests on software components, ensuring readiness for later insertion into an integrated system;\n- **Integration and System Tests** - tests of the integrated components of the system, subsystems and the complete system.\n\n## 9.7.5.2 Contractual Tests\n\nTesting and verification activities should be defined for business purposes, between the computerized system supplier and the regulated company.\n\n## 9.7.6 Automated Tests\n\nAutomated verification testing tools can be used to improve effectiveness and efficiency of test execution. They can be used both for the execution of cash tests, black and white box tests.\n\nAny use of these tools must be defined in the testing strategy.\n\nThese tools must be used in accordance with instructions and manuals defined and maintained under Configuration Management. They usually belong to GAMP category 1.\n\nIt is important that responsibilities are defined in relation to the following aspects:\n\n- Ownership (Who owns it), administration and maintenance of the test tool;\n- Maintenance of test data;\n- Maintenance of test documents (including test specifications, test scripts and test results);\n- Instructions and manuals for use.\n\nPreferably, these testing tools should have the capabilities of electronic signatures and electronic records that meet regulatory requirements.\n\n## 9.7.6.1 Examples of Automated Test Execution Tools\n\nBelow are some examples of tools for automated execution (source code debugging and testing tools) for testing the source code:\n\n- Automated test drivers (automatic test execution);\n- Test data generators;", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "823055defd91f836cb583e7e02669e1a651adf92b6070c3d0a1b6c65f55e6991", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "## 9.7.5.1 Tests Performed During Development\n\nInternal tests performed by the supplier must be performed according to test specifications defined and approved. Types of tests most commonly performed are:\n\n- **Acceptance testing for hardware and software purchased** - hardware and software purchased must be subjected to acceptance tests before being used for system development;\n- **Module / unit tests** - individual tests on software components, ensuring readiness for later insertion into an integrated system;\n- **Integration and System Tests** - tests of the integrated components of the system, subsystems and the complete system.\n\n## 9.7.5.2 Contractual Tests\n\nTesting and verification activities should be defined for business purposes, between the computerized system supplier and the regulated company.\n\n## 9.7.6 Automated Tests\n\nAutomated verification testing tools can be used to improve effectiveness and efficiency of test execution. They can be used both for the execution of cash tests, black and white box tests.\n\nAny use of these tools must be defined in the testing strategy.\n\nThese tools must be used in accordance with instructions and manuals defined and maintained under Configuration Management. They usually belong to GAMP category 1.\n\nIt is important that responsibilities are defined in relation to the following aspects:\n\n- Ownership (Who owns it), administration and maintenance of the test tool;\n- Maintenance of test data;\n- Maintenance of test documents (including test specifications, test scripts and test results);\n- Instructions and manuals for use.\n\nPreferably, these testing tools should have the capabilities of electronic signatures and electronic records that meet regulatory requirements.\n\n## 9.7.6.1 Examples of Automated Test Execution Tools\n\nBelow are some examples of tools for automated execution (source code debugging and testing tools) for testing the source code:\n\n- Automated test drivers (automatic test execution);\n- Test data generators;", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 1994, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "f4e36642-eb32-4bb2-b93e-65aa3fbdf0f9": {"__data__": {"id_": "f4e36642-eb32-4bb2-b93e-65aa3fbdf0f9", "embedding": null, "metadata": {"page_label": "54", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "- Environment simulators;\n- Static analyzers;\n- Dynamic performers;\n- Symbolic performers;\n- Volume / load drivers.\n\n## 9.7.6.2 Automated Testing Documentation\n\nThe automated test scripts must be controlled according to approved procedures.\n\nThe records (logs) generated by the computer resulting from the execution of the automated test scripts are normally generated automatically from the execution of the scripts.\n\nThe header record (log) must provide the following information:\n\n- Record identification;\n- Date and time of execution;\n- Test script name and version;\n- Test runner's identity and the name of the test environment.\n\nThe record cannot be edited or deleted. They must be read-only files, and should be maintained for future reviews or audits.\n\nThe automated test documentation must be kept for a minimum for the same period as the records tests performed on paper.\n\nThe use and management of automated testing documentation must be approved in advance by the Quality Unit as part of the development of the testing strategy.\n\n## 9.7.7 Tests Applied to Different Categories of Systems\n\nThis section presents the practical considerations for planning the tests to be performed on the systems belonging to categories 3, 4 and 5.\n\nFor those computerized systems that comprise equipment managed by an application (software), there is a need to also carry out the qualification of this equipment, whose methodology is described in international guides and specific legislation and is not the scope of this guide.\n\nHardware/software IQ and OQ activities are often performed by the supplier of the software, but such activities must have an active participation in the realization and approval by the company regulated.\n\n## 9.7.7.1 Aspects Applicable to All System Categories\n### 9.7.7.1.1 Hardware/Software Installation (IQ) Tests", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas basadas en el contexto proporcionado, junto con un resumen de nivel superior que puede ayudar a formularlas:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos establece directrices para la documentaci\u00f3n y ejecuci\u00f3n de pruebas automatizadas, as\u00ed como para la calificaci\u00f3n de sistemas y equipos. Se enfatiza la importancia de mantener registros inalterables de las pruebas automatizadas y la necesidad de la aprobaci\u00f3n de la Unidad de Calidad para la gesti\u00f3n de dicha documentaci\u00f3n. Adem\u00e1s, se menciona que las actividades de Calificaci\u00f3n de Instalaci\u00f3n (IQ) y Calificaci\u00f3n de Operaci\u00f3n (OQ) son com\u00fanmente realizadas por los proveedores de software, pero requieren la participaci\u00f3n activa de la empresa regulada.\n\n### Preguntas Espec\u00edficas\n1. **\u00bfQu\u00e9 informaci\u00f3n debe incluirse en el registro (log) de las pruebas automatizadas seg\u00fan el documento de ANVISA?**\n   - Esta pregunta busca detalles espec\u00edficos sobre los requisitos de documentaci\u00f3n que no se encuentran f\u00e1cilmente en otras fuentes.\n\n2. **\u00bfCu\u00e1l es el per\u00edodo m\u00ednimo de conservaci\u00f3n de la documentaci\u00f3n de pruebas automatizadas y c\u00f3mo se compara con los registros de pruebas realizadas en papel?**\n   - Esta pregunta se centra en las pol\u00edticas de conservaci\u00f3n de documentos, que pueden ser \u00fanicas para este contexto.\n\n3. **\u00bfQu\u00e9 rol juega la Unidad de Calidad en la gesti\u00f3n de la documentaci\u00f3n de pruebas automatizadas seg\u00fan las directrices de ANVISA?**\n   - Esta pregunta explora el proceso de aprobaci\u00f3n y la importancia de la Unidad de Calidad, un aspecto que puede no estar claramente definido en otras gu\u00edas o documentos.", "prev_section_summary": "### Temas Clave\n\n1. **Tipos de Pruebas Durante el Desarrollo**:\n   - Pruebas de aceptaci\u00f3n para hardware y software adquiridos.\n   - Pruebas de m\u00f3dulo/unidad para componentes de software.\n   - Pruebas de integraci\u00f3n y del sistema para componentes integrados.\n\n2. **Pruebas Contractuales**:\n   - Definici\u00f3n de actividades de prueba y verificaci\u00f3n entre el proveedor del sistema y la empresa regulada.\n\n3. **Pruebas Automatizadas**:\n   - Uso de herramientas de verificaci\u00f3n automatizadas para mejorar la efectividad y eficiencia de la ejecuci\u00f3n de pruebas.\n   - Importancia de definir el uso de estas herramientas en la estrategia de pruebas.\n   - Necesidad de seguir instrucciones y manuales bajo Gesti\u00f3n de Configuraci\u00f3n.\n\n4. **Responsabilidades en el Uso de Herramientas de Prueba**:\n   - Propiedad, administraci\u00f3n y mantenimiento de la herramienta de prueba.\n   - Mantenimiento de datos y documentos de prueba.\n   - Instrucciones y manuales para el uso de las herramientas.\n\n5. **Requisitos Regulatorios**:\n   - Preferencia por herramientas que incluyan capacidades de firmas electr\u00f3nicas y registros electr\u00f3nicos.\n\n6. **Ejemplos de Herramientas de Ejecuci\u00f3n de Pruebas Automatizadas**:\n   - Controladores de prueba automatizados.\n   - Generadores de datos de prueba.\n\n### Entidades\n\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil.\n- **GAMP**: Buenas Pr\u00e1cticas de Automatizaci\u00f3n de Sistemas.\n- **Herramientas de Prueba**: Software utilizado para la ejecuci\u00f3n y gesti\u00f3n de pruebas automatizadas.\n- **Proveedores de Sistemas**: Entidades que suministran software y hardware para el desarrollo de sistemas inform\u00e1ticos.\n- **Empresas Reguladas**: Organizaciones que deben cumplir con normativas espec\u00edficas en el uso de sistemas inform\u00e1ticos. \n\n### Resumen\n\nLa secci\u00f3n del documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos aborda la importancia de realizar pruebas adecuadas durante el desarrollo de software y hardware. Se destacan los tipos de pruebas que deben llevarse a cabo, la necesidad de definir actividades de prueba contractuales, y el uso de herramientas automatizadas para mejorar la eficiencia. Tambi\u00e9n se enfatiza la importancia de la gesti\u00f3n adecuada de estas herramientas y documentos relacionados, as\u00ed como el cumplimiento de requisitos regulatorios.", "excerpt_keywords": "Keywords: validation, automated testing, documentation, quality unit, hardware/software qualification"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "9cf4ba71-d35f-43f9-aec0-5645c4c8b8b2", "node_type": "4", "metadata": {"page_label": "54", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "- Environment simulators;\n- Static analyzers;\n- Dynamic performers;\n- Symbolic performers;\n- Volume / load drivers.\n\n## 9.7.6.2 Automated Testing Documentation\n\nThe automated test scripts must be controlled according to approved procedures.\n\nThe records (logs) generated by the computer resulting from the execution of the automated test scripts are normally generated automatically from the execution of the scripts.\n\nThe header record (log) must provide the following information:\n\n- Record identification;\n- Date and time of execution;\n- Test script name and version;\n- Test runner's identity and the name of the test environment.\n\nThe record cannot be edited or deleted. They must be read-only files, and should be maintained for future reviews or audits.\n\nThe automated test documentation must be kept for a minimum for the same period as the records tests performed on paper.\n\nThe use and management of automated testing documentation must be approved in advance by the Quality Unit as part of the development of the testing strategy.\n\n## 9.7.7 Tests Applied to Different Categories of Systems\n\nThis section presents the practical considerations for planning the tests to be performed on the systems belonging to categories 3, 4 and 5.\n\nFor those computerized systems that comprise equipment managed by an application (software), there is a need to also carry out the qualification of this equipment, whose methodology is described in international guides and specific legislation and is not the scope of this guide.\n\nHardware/software IQ and OQ activities are often performed by the supplier of the software, but such activities must have an active participation in the realization and approval by the company regulated.\n\n## 9.7.7.1 Aspects Applicable to All System Categories\n### 9.7.7.1.1 Hardware/Software Installation (IQ) Tests", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "a2aadc009777dbb58544f6e0d10b605d3fc203b03ffe5e52a6fead18837c6b35", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "- Environment simulators;\n- Static analyzers;\n- Dynamic performers;\n- Symbolic performers;\n- Volume / load drivers.\n\n## 9.7.6.2 Automated Testing Documentation\n\nThe automated test scripts must be controlled according to approved procedures.\n\nThe records (logs) generated by the computer resulting from the execution of the automated test scripts are normally generated automatically from the execution of the scripts.\n\nThe header record (log) must provide the following information:\n\n- Record identification;\n- Date and time of execution;\n- Test script name and version;\n- Test runner's identity and the name of the test environment.\n\nThe record cannot be edited or deleted. They must be read-only files, and should be maintained for future reviews or audits.\n\nThe automated test documentation must be kept for a minimum for the same period as the records tests performed on paper.\n\nThe use and management of automated testing documentation must be approved in advance by the Quality Unit as part of the development of the testing strategy.\n\n## 9.7.7 Tests Applied to Different Categories of Systems\n\nThis section presents the practical considerations for planning the tests to be performed on the systems belonging to categories 3, 4 and 5.\n\nFor those computerized systems that comprise equipment managed by an application (software), there is a need to also carry out the qualification of this equipment, whose methodology is described in international guides and specific legislation and is not the scope of this guide.\n\nHardware/software IQ and OQ activities are often performed by the supplier of the software, but such activities must have an active participation in the realization and approval by the company regulated.\n\n## 9.7.7.1 Aspects Applicable to All System Categories\n### 9.7.7.1.1 Hardware/Software Installation (IQ) Tests", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 1839, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "3bf391c2-cf68-4bbc-afc4-73188a85c64a": {"__data__": {"id_": "3bf391c2-cf68-4bbc-afc4-73188a85c64a", "embedding": null, "metadata": {"page_label": "55", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "Many companies call this Installation Qualification (IQ) activity. The purpose is to verify and document that the system components are installed according to specifications, documentation supplier and local and global requirements.\n\nIt must be evidenced that the documentation together with the system is complete and that the installation requirements and for local and global use are in accordance with specifications.\n\nInstallation tests provide a configuration baseline for subsequent installation activities, verification and validation, allowing to verify the installation methods, the testing tools and/or scripts used. This forms the basis for managing the configuration of the installed system.\n\nInstallation tests should verify that the following documents are available, when appropriate:\n\n- Technical and user guides;\n- Standard operating procedures;\n- Training schedules;\n- Service Level Agreements;\n- Security procedures;\n- Record books;\n- *Hardware* inventory;\n- List of instruments;\n- Spec sheets;\n- Calibration certificates and procedures;\n- Piping/process and instrumentation diagrams (P&ID);\n- Equipment list and specification sheets;\n- *Software* inventory (including installation procedure, system *software* list, application *software*, data list, initial data settings for initialization);\n- Program source code (category 5);\n- Preventive maintenance program;\n- List of critical spare parts.\n\n## 9.7.7.1.2 *Hardware*/*Software* Operations (OQ) Tests\n\nBelow is a general list, applicable to all systems. It should be used to assist in the verification of installed system:\n\n- Power outage test (prevention of loss of critical data or loss of control action; control reset facility);\n- Access to the system and system resources;\n- Audit trails and record of critical actions, including manual interactions;\n- Manual data entry and input validation features;\n- Electronic signature features;\n- Error and alarm messages;\n- Critical calculations;", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos establece que la Calificaci\u00f3n de Instalaci\u00f3n (IQ) es un proceso crucial para verificar que los componentes del sistema se instalan de acuerdo con las especificaciones y requisitos locales y globales. Este proceso implica la revisi\u00f3n de documentaci\u00f3n y la realizaci\u00f3n de pruebas de instalaci\u00f3n que aseguran que todos los documentos necesarios est\u00e9n disponibles y que el sistema est\u00e9 configurado correctamente. Adem\u00e1s, se mencionan pruebas de Operaciones de Hardware/Software (OQ) que ayudan a verificar el funcionamiento del sistema instalado.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfQu\u00e9 tipo de documentaci\u00f3n debe estar disponible y verificada durante la Calificaci\u00f3n de Instalaci\u00f3n (IQ)?**\n   - La documentaci\u00f3n que debe estar disponible incluye gu\u00edas t\u00e9cnicas y de usuario, procedimientos operativos est\u00e1ndar, horarios de capacitaci\u00f3n, acuerdos de nivel de servicio, procedimientos de seguridad, libros de registro, inventarios de hardware y software, certificados de calibraci\u00f3n, diagramas de tuber\u00edas y equipos, y listas de piezas de repuesto cr\u00edticas, entre otros.\n\n2. **\u00bfCu\u00e1les son algunos ejemplos de pruebas que se deben realizar durante la fase de Operaciones de Hardware/Software (OQ)?**\n   - Ejemplos de pruebas OQ incluyen la prueba de corte de energ\u00eda para prevenir la p\u00e9rdida de datos cr\u00edticos, la verificaci\u00f3n del acceso al sistema y recursos, la revisi\u00f3n de auditor\u00edas y registros de acciones cr\u00edticas, la validaci\u00f3n de entrada de datos manual, y la verificaci\u00f3n de caracter\u00edsticas de firma electr\u00f3nica y mensajes de error.\n\n3. **\u00bfCu\u00e1l es el prop\u00f3sito de realizar pruebas de instalaci\u00f3n y c\u00f3mo contribuyen a la gesti\u00f3n del sistema instalado?**\n   - El prop\u00f3sito de las pruebas de instalaci\u00f3n es establecer una l\u00ednea base de configuraci\u00f3n para actividades posteriores de instalaci\u00f3n, verificaci\u00f3n y validaci\u00f3n. Estas pruebas permiten verificar los m\u00e9todos de instalaci\u00f3n y las herramientas o scripts utilizados, lo que es fundamental para la gesti\u00f3n de la configuraci\u00f3n del sistema instalado y asegura que se cumplan los requisitos de instalaci\u00f3n.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Pruebas Automatizadas**:\n   - Se requiere que los scripts de prueba automatizados sean controlados seg\u00fan procedimientos aprobados.\n   - Los registros generados durante la ejecuci\u00f3n de las pruebas deben incluir informaci\u00f3n espec\u00edfica como identificaci\u00f3n del registro, fecha y hora de ejecuci\u00f3n, nombre y versi\u00f3n del script de prueba, identidad del ejecutor y nombre del entorno de prueba.\n   - Los registros deben ser archivos de solo lectura y no pueden ser editados o eliminados, manteni\u00e9ndose para futuras revisiones o auditor\u00edas.\n\n2. **Documentaci\u00f3n de Pruebas Automatizadas**:\n   - La documentaci\u00f3n de pruebas automatizadas debe conservarse por un per\u00edodo m\u00ednimo equivalente al de los registros de pruebas realizadas en papel.\n   - La gesti\u00f3n de esta documentaci\u00f3n debe ser aprobada por la Unidad de Calidad como parte de la estrategia de pruebas.\n\n3. **Calificaci\u00f3n de Sistemas**:\n   - Se presentan consideraciones pr\u00e1cticas para la planificaci\u00f3n de pruebas en sistemas de categor\u00edas 3, 4 y 5.\n   - La calificaci\u00f3n de equipos gestionados por aplicaciones de software es necesaria y debe seguir metodolog\u00edas descritas en gu\u00edas internacionales y legislaci\u00f3n espec\u00edfica.\n   - Las actividades de Calificaci\u00f3n de Instalaci\u00f3n (IQ) y Calificaci\u00f3n de Operaci\u00f3n (OQ) son com\u00fanmente realizadas por el proveedor de software, pero requieren la participaci\u00f3n activa de la empresa regulada.\n\n### Entidades Clave\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil, responsable de la regulaci\u00f3n de sistemas inform\u00e1ticos en el \u00e1mbito de la salud.\n- **Unidad de Calidad**: Entidad responsable de aprobar la gesti\u00f3n de la documentaci\u00f3n de pruebas automatizadas.\n- **Categor\u00edas de Sistemas**: Clasificaci\u00f3n de sistemas que requieren diferentes enfoques de prueba y calificaci\u00f3n (categor\u00edas 3, 4 y 5).\n- **Hardware/Software**: Elementos que requieren calificaci\u00f3n y validaci\u00f3n en el contexto de sistemas inform\u00e1ticos. \n\nEste resumen destaca la importancia de la documentaci\u00f3n y el control en las pruebas automatizadas, as\u00ed como la necesidad de colaboraci\u00f3n entre proveedores y empresas reguladas en la calificaci\u00f3n de sistemas.", "excerpt_keywords": "Keywords: Installation Qualification, system validation, documentation, hardware/software operations, compliance"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "28faf88e-7303-49c9-9516-7da7a1273085", "node_type": "4", "metadata": {"page_label": "55", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "Many companies call this Installation Qualification (IQ) activity. The purpose is to verify and document that the system components are installed according to specifications, documentation supplier and local and global requirements.\n\nIt must be evidenced that the documentation together with the system is complete and that the installation requirements and for local and global use are in accordance with specifications.\n\nInstallation tests provide a configuration baseline for subsequent installation activities, verification and validation, allowing to verify the installation methods, the testing tools and/or scripts used. This forms the basis for managing the configuration of the installed system.\n\nInstallation tests should verify that the following documents are available, when appropriate:\n\n- Technical and user guides;\n- Standard operating procedures;\n- Training schedules;\n- Service Level Agreements;\n- Security procedures;\n- Record books;\n- *Hardware* inventory;\n- List of instruments;\n- Spec sheets;\n- Calibration certificates and procedures;\n- Piping/process and instrumentation diagrams (P&ID);\n- Equipment list and specification sheets;\n- *Software* inventory (including installation procedure, system *software* list, application *software*, data list, initial data settings for initialization);\n- Program source code (category 5);\n- Preventive maintenance program;\n- List of critical spare parts.\n\n## 9.7.7.1.2 *Hardware*/*Software* Operations (OQ) Tests\n\nBelow is a general list, applicable to all systems. It should be used to assist in the verification of installed system:\n\n- Power outage test (prevention of loss of critical data or loss of control action; control reset facility);\n- Access to the system and system resources;\n- Audit trails and record of critical actions, including manual interactions;\n- Manual data entry and input validation features;\n- Electronic signature features;\n- Error and alarm messages;\n- Critical calculations;", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "c85e344a17d757ff2e5d2bb276b6207172e2bb19f369542a5935e046cb84a077", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "Many companies call this Installation Qualification (IQ) activity. The purpose is to verify and document that the system components are installed according to specifications, documentation supplier and local and global requirements.\n\nIt must be evidenced that the documentation together with the system is complete and that the installation requirements and for local and global use are in accordance with specifications.\n\nInstallation tests provide a configuration baseline for subsequent installation activities, verification and validation, allowing to verify the installation methods, the testing tools and/or scripts used. This forms the basis for managing the configuration of the installed system.\n\nInstallation tests should verify that the following documents are available, when appropriate:\n\n- Technical and user guides;\n- Standard operating procedures;\n- Training schedules;\n- Service Level Agreements;\n- Security procedures;\n- Record books;\n- *Hardware* inventory;\n- List of instruments;\n- Spec sheets;\n- Calibration certificates and procedures;\n- Piping/process and instrumentation diagrams (P&ID);\n- Equipment list and specification sheets;\n- *Software* inventory (including installation procedure, system *software* list, application *software*, data list, initial data settings for initialization);\n- Program source code (category 5);\n- Preventive maintenance program;\n- List of critical spare parts.\n\n## 9.7.7.1.2 *Hardware*/*Software* Operations (OQ) Tests\n\nBelow is a general list, applicable to all systems. It should be used to assist in the verification of installed system:\n\n- Power outage test (prevention of loss of critical data or loss of control action; control reset facility);\n- Access to the system and system resources;\n- Audit trails and record of critical actions, including manual interactions;\n- Manual data entry and input validation features;\n- Electronic signature features;\n- Error and alarm messages;\n- Critical calculations;", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 1966, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "fcc219dd-636a-4d0b-91f2-991df927a3d3": {"__data__": {"id_": "fcc219dd-636a-4d0b-91f2-991df927a3d3", "embedding": null, "metadata": {"page_label": "56", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "- Critical transactions;\n- Transfer of critical data to other packages or systems for further processing;\n- Interfaces and data transfer;\n- Backup and restore;\n- Data archiving and recovery;\n- Ability to handle high volume loads, particularly if the system is accessed by many users or need to register many values of the controlled / monitored parameters at the same time, as part of a networked application, for example.\n\n## 9.7.7.2 Test Activities for an Unconfigured Product\n\nThese computerized systems are those called \u201coff-the-shelf\u201d systems, meaning they are not configured for a specific business process or are used with your default setting (default). They are classified as category 3 of the GAMP.\n\nThe regulated company may decide to make a supplier assessment to verify the quality of the product, depending on the risk. Based on the satisfactory outcome of this assessment and the risks involved, an approach simple consisting of only one level of specification and verification can be applied.\n\nTests should focus on the following points:\n\n- Those related to the installation of the system, described in item 9.7.7.1.1;\n- User Requirements Tests that demonstrate the suitability for the intended use, which may include the conducting system functionality tests against pre-established requirements, depending on the risk involved;\n- User Requirements Tests must also include delivery and acceptance of documentation complete sent by the supplier, including specifications, manuals and drawings, if not yet done;\n- Any subsequent or more rigorous tests depending on the risk and supplier assessments;\n- Any other relevant aspects listed in item 9.7.7.1.2.\n\n## 9.7.7.3 Test Activities for a Configured Product\n\nA configured product involves configuring commercially available software that runs on standard hardware components. These systems that are configured for a specific business process are classified as category 4 of the GAMP.\n\nIn such a situation, based on the satisfactory result of the supplier's assessment and the risks involved, the testing strategy using the three-level approach (configuration, functionality and requirements) is the recommended. The number of test documents needed to cover these three levels will depend on the complexity and impact of the system.\n\nTests should focus on the following points:\n\n- Those related to the installation of the system, described above in item 9.7.7.1.1;\n- Configuration Tests - for each Configuration Specification there must be a Configuration Specification Associated Configuration Test. Tests should verify that the system has been installed according to specifications. Tests can be performed through inspection or verification the supplier's documentation;", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con sus respuestas:\n\n1. **\u00bfQu\u00e9 tipo de sistemas se consideran \"off-the-shelf\" y c\u00f3mo se clasifican seg\u00fan el GAMP?**\n   - Los sistemas \"off-the-shelf\" son aquellos que no est\u00e1n configurados para un proceso de negocio espec\u00edfico y se utilizan con la configuraci\u00f3n predeterminada. Estos sistemas se clasifican como categor\u00eda 3 del GAMP (Good Automated Manufacturing Practice).\n\n2. **\u00bfCu\u00e1les son los enfoques de prueba recomendados para un producto configurado seg\u00fan el GAMP?**\n   - Para un producto configurado, se recomienda una estrategia de prueba que utilice un enfoque de tres niveles: configuraci\u00f3n, funcionalidad y requisitos. La cantidad de documentos de prueba necesarios depender\u00e1 de la complejidad y el impacto del sistema. Las pruebas deben centrarse en la instalaci\u00f3n del sistema, las pruebas de configuraci\u00f3n y la verificaci\u00f3n de que el sistema se ha instalado de acuerdo con las especificaciones.\n\n3. **\u00bfQu\u00e9 aspectos deben considerarse en las pruebas de requisitos del usuario para un sistema no configurado?**\n   - Las pruebas de requisitos del usuario para un sistema no configurado deben demostrar la idoneidad para el uso previsto, lo que puede incluir pruebas de funcionalidad del sistema contra requisitos preestablecidos. Adem\u00e1s, deben incluir la entrega y aceptaci\u00f3n de la documentaci\u00f3n completa enviada por el proveedor, como especificaciones, manuales y dibujos, y cualquier prueba adicional que dependa del riesgo y las evaluaciones del proveedor.\n\n### Resumen de nivel superior del contexto:\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos establece directrices para la prueba de sistemas no configurados (categor\u00eda 3 del GAMP) y configurados (categor\u00eda 4 del GAMP). Para los sistemas no configurados, se sugiere un enfoque simple de especificaci\u00f3n y verificaci\u00f3n, mientras que para los configurados se recomienda un enfoque m\u00e1s detallado que incluye pruebas de configuraci\u00f3n, funcionalidad y requisitos. Las pruebas deben centrarse en aspectos cr\u00edticos como la instalaci\u00f3n del sistema, la transferencia de datos y la capacidad de manejar cargas de alto volumen.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Calificaci\u00f3n de Instalaci\u00f3n (IQ)**:\n   - Proceso para verificar y documentar que los componentes del sistema est\u00e1n instalados seg\u00fan especificaciones y requisitos locales y globales.\n   - Importancia de la documentaci\u00f3n completa y cumplimiento de requisitos de instalaci\u00f3n.\n\n2. **Documentaci\u00f3n Requerida**:\n   - Gu\u00edas t\u00e9cnicas y de usuario.\n   - Procedimientos operativos est\u00e1ndar.\n   - Horarios de capacitaci\u00f3n.\n   - Acuerdos de nivel de servicio.\n   - Procedimientos de seguridad.\n   - Libros de registro.\n   - Inventarios de hardware y software.\n   - Certificados de calibraci\u00f3n.\n   - Diagramas de tuber\u00edas y equipos (P&ID).\n   - Listas de piezas de repuesto cr\u00edticas.\n\n3. **Pruebas de Instalaci\u00f3n**:\n   - Establecen una l\u00ednea base de configuraci\u00f3n para actividades posteriores de verificaci\u00f3n y validaci\u00f3n.\n   - Verifican m\u00e9todos de instalaci\u00f3n y herramientas utilizadas.\n\n4. **Operaciones de Hardware/Software (OQ)**:\n   - Pruebas para verificar el funcionamiento del sistema instalado.\n   - Ejemplos de pruebas incluyen:\n     - Prueba de corte de energ\u00eda.\n     - Verificaci\u00f3n de acceso al sistema.\n     - Auditor\u00edas y registros de acciones cr\u00edticas.\n     - Validaci\u00f3n de entrada de datos manual.\n     - Verificaci\u00f3n de caracter\u00edsticas de firma electr\u00f3nica y mensajes de error.\n\n### Entidades Clave\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria en Brasil.\n- **Documentaci\u00f3n**: Incluye gu\u00edas, procedimientos, acuerdos, certificados, etc.\n- **Sistema**: Se refiere a los componentes de hardware y software que est\u00e1n siendo instalados y validados.\n- **Pruebas**: Actividades realizadas para asegurar que el sistema cumple con los requisitos establecidos. \n\nEste resumen destaca la importancia de la validaci\u00f3n de sistemas inform\u00e1ticos en el contexto regulatorio y los elementos necesarios para asegurar la correcta instalaci\u00f3n y operaci\u00f3n de dichos sistemas.", "excerpt_keywords": "Keywords: validation, GAMP, testing, configuration, documentation"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "4507c7cc-82d3-46d4-ab98-219da0bad8a9", "node_type": "4", "metadata": {"page_label": "56", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "- Critical transactions;\n- Transfer of critical data to other packages or systems for further processing;\n- Interfaces and data transfer;\n- Backup and restore;\n- Data archiving and recovery;\n- Ability to handle high volume loads, particularly if the system is accessed by many users or need to register many values of the controlled / monitored parameters at the same time, as part of a networked application, for example.\n\n## 9.7.7.2 Test Activities for an Unconfigured Product\n\nThese computerized systems are those called \u201coff-the-shelf\u201d systems, meaning they are not configured for a specific business process or are used with your default setting (default). They are classified as category 3 of the GAMP.\n\nThe regulated company may decide to make a supplier assessment to verify the quality of the product, depending on the risk. Based on the satisfactory outcome of this assessment and the risks involved, an approach simple consisting of only one level of specification and verification can be applied.\n\nTests should focus on the following points:\n\n- Those related to the installation of the system, described in item 9.7.7.1.1;\n- User Requirements Tests that demonstrate the suitability for the intended use, which may include the conducting system functionality tests against pre-established requirements, depending on the risk involved;\n- User Requirements Tests must also include delivery and acceptance of documentation complete sent by the supplier, including specifications, manuals and drawings, if not yet done;\n- Any subsequent or more rigorous tests depending on the risk and supplier assessments;\n- Any other relevant aspects listed in item 9.7.7.1.2.\n\n## 9.7.7.3 Test Activities for a Configured Product\n\nA configured product involves configuring commercially available software that runs on standard hardware components. These systems that are configured for a specific business process are classified as category 4 of the GAMP.\n\nIn such a situation, based on the satisfactory result of the supplier's assessment and the risks involved, the testing strategy using the three-level approach (configuration, functionality and requirements) is the recommended. The number of test documents needed to cover these three levels will depend on the complexity and impact of the system.\n\nTests should focus on the following points:\n\n- Those related to the installation of the system, described above in item 9.7.7.1.1;\n- Configuration Tests - for each Configuration Specification there must be a Configuration Specification Associated Configuration Test. Tests should verify that the system has been installed according to specifications. Tests can be performed through inspection or verification the supplier's documentation;", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "14e84c407303bb51f0d2e7cd610b2b6559ae847c4a172c737f6176501bf02e02", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "- Critical transactions;\n- Transfer of critical data to other packages or systems for further processing;\n- Interfaces and data transfer;\n- Backup and restore;\n- Data archiving and recovery;\n- Ability to handle high volume loads, particularly if the system is accessed by many users or need to register many values of the controlled / monitored parameters at the same time, as part of a networked application, for example.\n\n## 9.7.7.2 Test Activities for an Unconfigured Product\n\nThese computerized systems are those called \u201coff-the-shelf\u201d systems, meaning they are not configured for a specific business process or are used with your default setting (default). They are classified as category 3 of the GAMP.\n\nThe regulated company may decide to make a supplier assessment to verify the quality of the product, depending on the risk. Based on the satisfactory outcome of this assessment and the risks involved, an approach simple consisting of only one level of specification and verification can be applied.\n\nTests should focus on the following points:\n\n- Those related to the installation of the system, described in item 9.7.7.1.1;\n- User Requirements Tests that demonstrate the suitability for the intended use, which may include the conducting system functionality tests against pre-established requirements, depending on the risk involved;\n- User Requirements Tests must also include delivery and acceptance of documentation complete sent by the supplier, including specifications, manuals and drawings, if not yet done;\n- Any subsequent or more rigorous tests depending on the risk and supplier assessments;\n- Any other relevant aspects listed in item 9.7.7.1.2.\n\n## 9.7.7.3 Test Activities for a Configured Product\n\nA configured product involves configuring commercially available software that runs on standard hardware components. These systems that are configured for a specific business process are classified as category 4 of the GAMP.\n\nIn such a situation, based on the satisfactory result of the supplier's assessment and the risks involved, the testing strategy using the three-level approach (configuration, functionality and requirements) is the recommended. The number of test documents needed to cover these three levels will depend on the complexity and impact of the system.\n\nTests should focus on the following points:\n\n- Those related to the installation of the system, described above in item 9.7.7.1.1;\n- Configuration Tests - for each Configuration Specification there must be a Configuration Specification Associated Configuration Test. Tests should verify that the system has been installed according to specifications. Tests can be performed through inspection or verification the supplier's documentation;", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 2736, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "c3b3ebc5-bceb-47af-84ff-c25f6959c958": {"__data__": {"id_": "c3b3ebc5-bceb-47af-84ff-c25f6959c958", "embedding": null, "metadata": {"page_label": "57", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# Functional Tests\n\n- Functionality that supports the specific business process. In this activity, the vendor documentation can be leveraged. Possible types of functional tests: normal case (positive); invalid case (negative); repeatability; performance; volume / charge; regression; structural tests;\n- User Requirements Tests that demonstrate the suitability for the intended use, which may include the conducting system functionality tests against pre-established requirements, depending on the risk involved;\n- The requirements tests must also include the delivery and acceptance of the complete documentation sent by the supplier, including specifications, manuals and drawings, if not yet done;\n- Any subsequent or more stringent tests carried out as a result of risk assessments and provider;\n- Any other relevant aspects listed in item 9.7.7.1.2.\n\n## 9.7.7.4 Testing Activities for a Custom Application\n\nSome computerized systems are developed to meet specific user requirements when there are no commercially available solutions. The *software* developed for such systems is classified as category 5 of the GAMP.\n\nIn such cases and based on the satisfactory assessment of the supplier and the risks involved, a testing based on the four levels (module design (unit); integration; functionality and requirements) is applicable.\n\nThe number of test documents needed to cover these four levels will depend on the complexity and system impact.\n\nTests should focus on the following points:\n\n- Those related to the installation of the system, described in item 9.7.7.1.1;\n- Revision of the new code, required as a result of the risk assessment;\n- Tests of *software* modules to verify that they conform to your design specifications - for each *Software* Module Design Specification, a *Software* Module Test Specification associated product must be produced. The *software* module tests to be performed must ensure that the software module meets specifications;\n- Software integration tests to test whether the modules work correctly when operating together - the Software Integration Test Specification defines those tests that demonstrate that all software modules communicate with each other correctly and that the software system meets the project specification. A Software Integration Test Specification must be produced when more than one software module composes the final system;\n- Configuration test (if applicable) - for each Configuration Specification, a Configuration Specification Associated Configuration test must be produced. Tests should verify that the system has been configured according to specification. Tests can take the form of inspections or verification of the provider;\n- Functional Tests - functionality that supports the specific business process based on risk and supplier assessments (This is an area where supplier documentation can be harnessed);\n- Requirements Tests (URS) - demonstrate that the system is suitable for the intended use; this can include carrying out tests of the system\u2019s functionality against predefined requirements, based on risk;", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas que se pueden formular a partir del contexto proporcionado, junto con respuestas espec\u00edficas que probablemente no se encuentren en otro lugar:\n\n1. **\u00bfQu\u00e9 tipos de pruebas funcionales se mencionan en la gu\u00eda de ANVISA y cu\u00e1l es su prop\u00f3sito?**\n   - La gu\u00eda de ANVISA menciona varios tipos de pruebas funcionales, que incluyen: pruebas de caso normal (positivo), pruebas de caso inv\u00e1lido (negativo), pruebas de repetibilidad, pruebas de rendimiento, pruebas de volumen/carga, pruebas de regresi\u00f3n y pruebas estructurales. El prop\u00f3sito de estas pruebas es asegurar que la funcionalidad del sistema soporte adecuadamente los procesos de negocio espec\u00edficos y que cumpla con los requisitos establecidos.\n\n2. **\u00bfQu\u00e9 se debe incluir en las pruebas de requisitos (URS) seg\u00fan la gu\u00eda?**\n   - Las pruebas de requisitos (URS) deben demostrar que el sistema es adecuado para el uso previsto. Esto incluye la realizaci\u00f3n de pruebas de funcionalidad del sistema contra requisitos preestablecidos, dependiendo del riesgo involucrado. Adem\u00e1s, deben incluir la entrega y aceptaci\u00f3n de la documentaci\u00f3n completa proporcionada por el proveedor, que incluye especificaciones, manuales y dibujos, si no se ha hecho previamente.\n\n3. **\u00bfCu\u00e1les son los niveles de prueba aplicables a una aplicaci\u00f3n personalizada seg\u00fan la gu\u00eda de ANVISA?**\n   - Para aplicaciones personalizadas, la gu\u00eda establece que se aplican pruebas basadas en cuatro niveles: dise\u00f1o del m\u00f3dulo (unidad), integraci\u00f3n, funcionalidad y requisitos. La cantidad de documentos de prueba necesarios para cubrir estos niveles depender\u00e1 de la complejidad y el impacto del sistema. Cada nivel tiene un enfoque espec\u00edfico, como la verificaci\u00f3n de que los m\u00f3dulos de software cumplen con las especificaciones de dise\u00f1o y que se comunican correctamente entre s\u00ed.\n\n### Resumen de nivel superior del contexto:\nLa gu\u00eda de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos establece directrices para realizar pruebas funcionales y de requisitos en sistemas que apoyan procesos de negocio espec\u00edficos. Se enfatiza la importancia de documentar y aceptar la documentaci\u00f3n del proveedor, as\u00ed como la necesidad de realizar pruebas en diferentes niveles para aplicaciones personalizadas. La gu\u00eda tambi\u00e9n destaca la importancia de realizar pruebas basadas en la evaluaci\u00f3n de riesgos y la complejidad del sistema.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Tipos de Sistemas**:\n   - **Sistemas \"off-the-shelf\"**: No configurados para un proceso espec\u00edfico, utilizados con configuraci\u00f3n predeterminada. Clasificados como **categor\u00eda 3 del GAMP**.\n   - **Sistemas Configurados**: Software comercial configurado para un proceso espec\u00edfico. Clasificados como **categor\u00eda 4 del GAMP**.\n\n2. **Actividades de Prueba**:\n   - **Para Productos No Configurados**:\n     - Evaluaci\u00f3n del proveedor para verificar la calidad del producto.\n     - Pruebas de instalaci\u00f3n del sistema.\n     - Pruebas de requisitos del usuario para demostrar la idoneidad para el uso previsto.\n     - Aceptaci\u00f3n de documentaci\u00f3n completa del proveedor (especificaciones, manuales, dibujos).\n     - Pruebas adicionales seg\u00fan el riesgo y evaluaciones del proveedor.\n\n   - **Para Productos Configurados**:\n     - Estrategia de prueba recomendada de tres niveles: **configuraci\u00f3n, funcionalidad y requisitos**.\n     - Pruebas de instalaci\u00f3n del sistema.\n     - Pruebas de configuraci\u00f3n asociadas a cada especificaci\u00f3n de configuraci\u00f3n.\n     - Verificaci\u00f3n de que el sistema se ha instalado de acuerdo con las especificaciones.\n\n3. **Aspectos Cr\u00edticos a Considerar**:\n   - Transacciones cr\u00edticas.\n   - Transferencia de datos cr\u00edticos.\n   - Interfaces y transferencia de datos.\n   - Copia de seguridad y restauraci\u00f3n.\n   - Archivado y recuperaci\u00f3n de datos.\n   - Capacidad para manejar cargas de alto volumen, especialmente en aplicaciones en red.\n\n### Entidades Clave:\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil.\n- **GAMP**: Buenas Pr\u00e1cticas de Automatizaci\u00f3n de Manufactura.\n- **Categor\u00edas de GAMP**: Clasificaci\u00f3n de sistemas seg\u00fan su configuraci\u00f3n y uso.\n\nEste resumen destaca los elementos esenciales sobre la validaci\u00f3n de sistemas inform\u00e1ticos seg\u00fan las directrices de ANVISA, enfoc\u00e1ndose en las diferencias entre sistemas no configurados y configurados, as\u00ed como en las actividades de prueba recomendadas para cada tipo.", "excerpt_keywords": "Keywords: ANVISA, Computer Systems Validation, Functional Tests, User Requirements, GAMP"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "72821ccf-6662-475b-82db-f8b108bdd182", "node_type": "4", "metadata": {"page_label": "57", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# Functional Tests\n\n- Functionality that supports the specific business process. In this activity, the vendor documentation can be leveraged. Possible types of functional tests: normal case (positive); invalid case (negative); repeatability; performance; volume / charge; regression; structural tests;\n- User Requirements Tests that demonstrate the suitability for the intended use, which may include the conducting system functionality tests against pre-established requirements, depending on the risk involved;\n- The requirements tests must also include the delivery and acceptance of the complete documentation sent by the supplier, including specifications, manuals and drawings, if not yet done;\n- Any subsequent or more stringent tests carried out as a result of risk assessments and provider;\n- Any other relevant aspects listed in item 9.7.7.1.2.\n\n## 9.7.7.4 Testing Activities for a Custom Application\n\nSome computerized systems are developed to meet specific user requirements when there are no commercially available solutions. The *software* developed for such systems is classified as category 5 of the GAMP.\n\nIn such cases and based on the satisfactory assessment of the supplier and the risks involved, a testing based on the four levels (module design (unit); integration; functionality and requirements) is applicable.\n\nThe number of test documents needed to cover these four levels will depend on the complexity and system impact.\n\nTests should focus on the following points:\n\n- Those related to the installation of the system, described in item 9.7.7.1.1;\n- Revision of the new code, required as a result of the risk assessment;\n- Tests of *software* modules to verify that they conform to your design specifications - for each *Software* Module Design Specification, a *Software* Module Test Specification associated product must be produced. The *software* module tests to be performed must ensure that the software module meets specifications;\n- Software integration tests to test whether the modules work correctly when operating together - the Software Integration Test Specification defines those tests that demonstrate that all software modules communicate with each other correctly and that the software system meets the project specification. A Software Integration Test Specification must be produced when more than one software module composes the final system;\n- Configuration test (if applicable) - for each Configuration Specification, a Configuration Specification Associated Configuration test must be produced. Tests should verify that the system has been configured according to specification. Tests can take the form of inspections or verification of the provider;\n- Functional Tests - functionality that supports the specific business process based on risk and supplier assessments (This is an area where supplier documentation can be harnessed);\n- Requirements Tests (URS) - demonstrate that the system is suitable for the intended use; this can include carrying out tests of the system\u2019s functionality against predefined requirements, based on risk;", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "aa5a8c57eefdeb974af4a62a5d1ad4b55f60cf5190f379611e99cc8d485e0824", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "# Functional Tests\n\n- Functionality that supports the specific business process. In this activity, the vendor documentation can be leveraged. Possible types of functional tests: normal case (positive); invalid case (negative); repeatability; performance; volume / charge; regression; structural tests;\n- User Requirements Tests that demonstrate the suitability for the intended use, which may include the conducting system functionality tests against pre-established requirements, depending on the risk involved;\n- The requirements tests must also include the delivery and acceptance of the complete documentation sent by the supplier, including specifications, manuals and drawings, if not yet done;\n- Any subsequent or more stringent tests carried out as a result of risk assessments and provider;\n- Any other relevant aspects listed in item 9.7.7.1.2.\n\n## 9.7.7.4 Testing Activities for a Custom Application\n\nSome computerized systems are developed to meet specific user requirements when there are no commercially available solutions. The *software* developed for such systems is classified as category 5 of the GAMP.\n\nIn such cases and based on the satisfactory assessment of the supplier and the risks involved, a testing based on the four levels (module design (unit); integration; functionality and requirements) is applicable.\n\nThe number of test documents needed to cover these four levels will depend on the complexity and system impact.\n\nTests should focus on the following points:\n\n- Those related to the installation of the system, described in item 9.7.7.1.1;\n- Revision of the new code, required as a result of the risk assessment;\n- Tests of *software* modules to verify that they conform to your design specifications - for each *Software* Module Design Specification, a *Software* Module Test Specification associated product must be produced. The *software* module tests to be performed must ensure that the software module meets specifications;\n- Software integration tests to test whether the modules work correctly when operating together - the Software Integration Test Specification defines those tests that demonstrate that all software modules communicate with each other correctly and that the software system meets the project specification. A Software Integration Test Specification must be produced when more than one software module composes the final system;\n- Configuration test (if applicable) - for each Configuration Specification, a Configuration Specification Associated Configuration test must be produced. Tests should verify that the system has been configured according to specification. Tests can take the form of inspections or verification of the provider;\n- Functional Tests - functionality that supports the specific business process based on risk and supplier assessments (This is an area where supplier documentation can be harnessed);\n- Requirements Tests (URS) - demonstrate that the system is suitable for the intended use; this can include carrying out tests of the system\u2019s functionality against predefined requirements, based on risk;", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 3090, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "df98e9a8-f727-4c83-9093-87e3f855b23e": {"__data__": {"id_": "df98e9a8-f727-4c83-9093-87e3f855b23e", "embedding": null, "metadata": {"page_label": "58", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 9.7.8 Test Report\n\nA test report must be generated that summarizes the activities carried out and the results obtained and that contains the final conclusions.\n\nThe approval of the test report constitutes the formal release of the system to perform the steps subsequent life cycle.\n\nTest reports must meet the requirements of the corresponding test specifications or in the case of a test summary report, must meet the requirements of the test strategy.\n\n# 9.8 COMPLEMENTARY ACTIVITIES\n\n## 9.8.1 System Description\n\n### 9.8.1.1 Introduction\n\nThis section seeks to meet a recurring regulatory requirement:\n\n\"There should be an updated and detailed description of the system, containing the principles, objectives, security, range of the system and its main characteristics of use, and the interface with other systems and procedures.\"\n\nThe need for a system description can be covered by one or more existing specifications or other documents or a separate document can be produced.\n\nThe main use of such a document is to help new users and regulators understand what the system does and how this is written in a non-technical language as far as possible.\n\n### 9.8.1.2 General Considerations\n\nThe System Description must be maintained for the life of the system.\n\nFor complex systems that are used by different departments or plants / sites (e.g., ERU) a separate document may be the most appropriate. For simpler systems it is common practice to include the description of the system in another specification or other document.\n\nA complete description of the system, which meets regulatory expectations, must be established before the system be released for operational use.\n\nThe system description should be subject to change control and periodic review.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos establece directrices sobre la generaci\u00f3n de informes de prueba y la descripci\u00f3n del sistema. Un informe de prueba debe resumir las actividades y resultados, y su aprobaci\u00f3n es necesaria para liberar formalmente el sistema. Adem\u00e1s, se requiere una descripci\u00f3n detallada y actualizada del sistema que cumpla con las expectativas regulatorias, la cual debe mantenerse durante toda la vida del sistema y estar sujeta a control de cambios y revisiones peri\u00f3dicas.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfQu\u00e9 elementos deben incluirse en un informe de prueba seg\u00fan las directrices de ANVISA?**\n   - Un informe de prueba debe resumir las actividades realizadas, los resultados obtenidos y las conclusiones finales. Adem\u00e1s, debe cumplir con los requisitos de las especificaciones de prueba correspondientes o, en el caso de un informe resumen de prueba, con los requisitos de la estrategia de prueba.\n\n2. **\u00bfCu\u00e1l es la importancia de la descripci\u00f3n del sistema en el contexto de la validaci\u00f3n de sistemas inform\u00e1ticos?**\n   - La descripci\u00f3n del sistema es crucial para ayudar a nuevos usuarios y reguladores a entender el funcionamiento del sistema. Debe ser escrita en un lenguaje no t\u00e9cnico y debe contener principios, objetivos, seguridad, alcance y caracter\u00edsticas principales del sistema, as\u00ed como su interfaz con otros sistemas y procedimientos.\n\n3. **\u00bfC\u00f3mo debe ser gestionada la descripci\u00f3n del sistema a lo largo de su ciclo de vida?**\n   - La descripci\u00f3n del sistema debe mantenerse actualizada durante toda la vida del sistema, estar sujeta a control de cambios y ser revisada peri\u00f3dicamente. Para sistemas complejos, puede ser m\u00e1s apropiado tener un documento separado, mientras que para sistemas m\u00e1s simples, es com\u00fan incluir la descripci\u00f3n en otra especificaci\u00f3n o documento.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Pruebas Funcionales**:\n   - Se enfocan en la funcionalidad que respalda procesos de negocio espec\u00edficos.\n   - Tipos de pruebas funcionales: \n     - Pruebas de caso normal (positivo)\n     - Pruebas de caso inv\u00e1lido (negativo)\n     - Pruebas de repetibilidad\n     - Pruebas de rendimiento\n     - Pruebas de volumen/carga\n     - Pruebas de regresi\u00f3n\n     - Pruebas estructurales\n\n2. **Pruebas de Requisitos del Usuario (URS)**:\n   - Demuestran la idoneidad del sistema para el uso previsto.\n   - Incluyen pruebas de funcionalidad contra requisitos preestablecidos, dependiendo del riesgo.\n   - Requieren la entrega y aceptaci\u00f3n de documentaci\u00f3n completa del proveedor (especificaciones, manuales, dibujos).\n\n3. **Actividades de Pruebas para Aplicaciones Personalizadas**:\n   - Aplican a sistemas desarrollados para satisfacer requisitos espec\u00edficos de usuarios.\n   - Clasificaci\u00f3n del software como categor\u00eda 5 de GAMP.\n   - Pruebas basadas en cuatro niveles:\n     - Dise\u00f1o del m\u00f3dulo (unidad)\n     - Integraci\u00f3n\n     - Funcionalidad\n     - Requisitos\n   - La cantidad de documentos de prueba depende de la complejidad y el impacto del sistema.\n\n4. **Enfoque de Pruebas**:\n   - Instalaci\u00f3n del sistema.\n   - Revisi\u00f3n de nuevo c\u00f3digo seg\u00fan evaluaci\u00f3n de riesgos.\n   - Verificaci\u00f3n de m\u00f3dulos de software contra especificaciones de dise\u00f1o.\n   - Pruebas de integraci\u00f3n de software para asegurar la comunicaci\u00f3n correcta entre m\u00f3dulos.\n   - Pruebas de configuraci\u00f3n, si son aplicables.\n   - Pruebas funcionales y de requisitos basadas en evaluaciones de riesgo.\n\n### Entidades Clave:\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria en Brasil.\n- **GAMP**: Buenas Pr\u00e1cticas de Automatizaci\u00f3n de Sistemas.\n- **Documentaci\u00f3n del Proveedor**: Especificaciones, manuales y dibujos necesarios para la validaci\u00f3n.\n- **Sistema Inform\u00e1tico**: Software desarrollado para procesos de negocio espec\u00edficos.\n\nEste resumen destaca los aspectos fundamentales de la gu\u00eda de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos, enfatizando la importancia de las pruebas funcionales y de requisitos, as\u00ed como la documentaci\u00f3n y evaluaci\u00f3n de riesgos en el proceso de validaci\u00f3n.", "excerpt_keywords": "Keywords: test report, system description, validation, regulatory requirements, change control"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "2b801409-2af4-46dc-9dce-d78d0eb2d3b7", "node_type": "4", "metadata": {"page_label": "58", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 9.7.8 Test Report\n\nA test report must be generated that summarizes the activities carried out and the results obtained and that contains the final conclusions.\n\nThe approval of the test report constitutes the formal release of the system to perform the steps subsequent life cycle.\n\nTest reports must meet the requirements of the corresponding test specifications or in the case of a test summary report, must meet the requirements of the test strategy.\n\n# 9.8 COMPLEMENTARY ACTIVITIES\n\n## 9.8.1 System Description\n\n### 9.8.1.1 Introduction\n\nThis section seeks to meet a recurring regulatory requirement:\n\n\"There should be an updated and detailed description of the system, containing the principles, objectives, security, range of the system and its main characteristics of use, and the interface with other systems and procedures.\"\n\nThe need for a system description can be covered by one or more existing specifications or other documents or a separate document can be produced.\n\nThe main use of such a document is to help new users and regulators understand what the system does and how this is written in a non-technical language as far as possible.\n\n### 9.8.1.2 General Considerations\n\nThe System Description must be maintained for the life of the system.\n\nFor complex systems that are used by different departments or plants / sites (e.g., ERU) a separate document may be the most appropriate. For simpler systems it is common practice to include the description of the system in another specification or other document.\n\nA complete description of the system, which meets regulatory expectations, must be established before the system be released for operational use.\n\nThe system description should be subject to change control and periodic review.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "9536fc7514f4c37c74c25a7e8df4efd654237add195f80a08b04b2c9a2f1a578", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "# 9.7.8 Test Report\n\nA test report must be generated that summarizes the activities carried out and the results obtained and that contains the final conclusions.\n\nThe approval of the test report constitutes the formal release of the system to perform the steps subsequent life cycle.\n\nTest reports must meet the requirements of the corresponding test specifications or in the case of a test summary report, must meet the requirements of the test strategy.\n\n# 9.8 COMPLEMENTARY ACTIVITIES\n\n## 9.8.1 System Description\n\n### 9.8.1.1 Introduction\n\nThis section seeks to meet a recurring regulatory requirement:\n\n\"There should be an updated and detailed description of the system, containing the principles, objectives, security, range of the system and its main characteristics of use, and the interface with other systems and procedures.\"\n\nThe need for a system description can be covered by one or more existing specifications or other documents or a separate document can be produced.\n\nThe main use of such a document is to help new users and regulators understand what the system does and how this is written in a non-technical language as far as possible.\n\n### 9.8.1.2 General Considerations\n\nThe System Description must be maintained for the life of the system.\n\nFor complex systems that are used by different departments or plants / sites (e.g., ERU) a separate document may be the most appropriate. For simpler systems it is common practice to include the description of the system in another specification or other document.\n\nA complete description of the system, which meets regulatory expectations, must be established before the system be released for operational use.\n\nThe system description should be subject to change control and periodic review.", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 1757, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "0b0e083f-c19a-4c70-83ca-95b9ce9f4c7d": {"__data__": {"id_": "0b0e083f-c19a-4c70-83ca-95b9ce9f4c7d", "embedding": null, "metadata": {"page_label": "59", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 9.8.1.3 Document Content\n\nThe description should cover only the main characteristics of the system. Detailed topic information must be included in other specifications and not repeated.\n\n## 9.8.1.3.1 Introduction\n\nThis part should explain the context of the system within the business process and the regulated company in general. This should be considered from the following perspectives:\n\n- Departmental;\n- Within the plant / site;\n- Within the division;\n- From a global point of view.\n\n## 9.8.1.3.2 Main System Functionality\n\nThis part includes the description of the key functions of the system, both in relation to BPx and non-BPx, many of which can be critical to the business.\n\nThe functions can be grouped to keep the description at a high level. The use of diagrams is encouraged to explain relationships between key functions.\n\n## 9.8.1.3.4 Computational Environment\n\nThis part should be covered by a high level diagram showing the architecture that supports the system, covering, where appropriate:\n\n- The infrastructure that supports the system (e.g., server configurations, storage arrangements etc.);\n- *Interfaces* for users;\n- *Interfaces* for equipment;\n- *Interfaces* for other systems;\n- *Interfaces* outside the company;\n- The flow of data through the *interfaces*;\n- Security features such as *firewalls*.\n\n## 9.8.1.3.5 System Components\n\nAn indication of the main *hardware* and *software components* must be provided. Must include information about servers and storage equipment, as well as operating systems, types of database and applications. You should refer to any configuration documentation relevant to the system.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas que pueden proporcionar respuestas espec\u00edficas basadas en el contexto proporcionado, as\u00ed como un resumen de nivel superior del contenido:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos establece directrices sobre c\u00f3mo describir las caracter\u00edsticas principales de un sistema dentro de un entorno regulado. Se enfatiza la importancia de contextualizar el sistema en el proceso empresarial, describir su funcionalidad clave, detallar el entorno computacional y enumerar los componentes del sistema, tanto de hardware como de software. Se sugiere el uso de diagramas para ilustrar relaciones y flujos de datos, as\u00ed como la inclusi\u00f3n de caracter\u00edsticas de seguridad.\n\n### Preguntas\n\n1. **\u00bfCu\u00e1les son las perspectivas espec\u00edficas desde las cuales se debe considerar el contexto del sistema dentro de la empresa regulada?**\n   - Respuesta: El contexto del sistema debe ser considerado desde las perspectivas departamental, dentro de la planta/sitio, dentro de la divisi\u00f3n y desde un punto de vista global.\n\n2. **\u00bfQu\u00e9 tipo de diagramas se recomienda utilizar para describir la funcionalidad del sistema y por qu\u00e9 son importantes?**\n   - Respuesta: Se recomienda el uso de diagramas para explicar las relaciones entre las funciones clave del sistema. Estos diagramas son importantes porque ayudan a mantener la descripci\u00f3n a un nivel alto y facilitan la comprensi\u00f3n de c\u00f3mo interact\u00faan las diferentes funciones.\n\n3. **\u00bfQu\u00e9 informaci\u00f3n debe incluirse al describir el entorno computacional del sistema y por qu\u00e9 es relevante?**\n   - Respuesta: El entorno computacional debe incluir un diagrama de alto nivel que muestre la arquitectura del sistema, incluyendo la infraestructura que lo soporta, las interfaces para usuarios y equipos, las interfaces con otros sistemas y la seguridad (como firewalls). Esta informaci\u00f3n es relevante porque proporciona una visi\u00f3n clara de c\u00f3mo se estructura el sistema y c\u00f3mo se gestionan los datos y la seguridad.", "prev_section_summary": "### Temas Clave\n\n1. **Informe de Prueba**:\n   - Debe resumir las actividades realizadas, los resultados obtenidos y las conclusiones finales.\n   - La aprobaci\u00f3n del informe es necesaria para la liberaci\u00f3n formal del sistema.\n   - Debe cumplir con los requisitos de las especificaciones de prueba o de la estrategia de prueba.\n\n2. **Descripci\u00f3n del Sistema**:\n   - Se requiere una descripci\u00f3n actualizada y detallada del sistema que incluya principios, objetivos, seguridad, alcance y caracter\u00edsticas principales, as\u00ed como la interfaz con otros sistemas.\n   - La descripci\u00f3n debe ser comprensible para nuevos usuarios y reguladores, utilizando un lenguaje no t\u00e9cnico.\n   - Debe mantenerse durante toda la vida del sistema, estar sujeta a control de cambios y revisiones peri\u00f3dicas.\n\n3. **Consideraciones Generales**:\n   - Para sistemas complejos, puede ser m\u00e1s adecuado tener un documento separado; para sistemas m\u00e1s simples, es com\u00fan incluir la descripci\u00f3n en otra especificaci\u00f3n.\n   - La descripci\u00f3n completa debe establecerse antes de que el sistema se libere para uso operativo.\n\n### Entidades\n\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil.\n- **Informe de Prueba**: Documento que resume las pruebas realizadas en el sistema.\n- **Descripci\u00f3n del Sistema**: Documento que detalla el funcionamiento y caracter\u00edsticas del sistema.\n- **Especificaciones de Prueba**: Requisitos que gu\u00edan la creaci\u00f3n del informe de prueba.\n- **Estrategia de Prueba**: Plan que define c\u00f3mo se llevar\u00e1n a cabo las pruebas del sistema.\n- **Control de Cambios**: Proceso para gestionar modificaciones en la documentaci\u00f3n del sistema.\n- **Revisi\u00f3n Peri\u00f3dica**: Evaluaci\u00f3n regular de la documentaci\u00f3n para asegurar su actualizaci\u00f3n y relevancia.", "excerpt_keywords": "Keywords: validation, system functionality, computational environment, hardware components, regulatory compliance"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "b4014e3b-c980-4a13-accb-cfe14b4ac16e", "node_type": "4", "metadata": {"page_label": "59", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 9.8.1.3 Document Content\n\nThe description should cover only the main characteristics of the system. Detailed topic information must be included in other specifications and not repeated.\n\n## 9.8.1.3.1 Introduction\n\nThis part should explain the context of the system within the business process and the regulated company in general. This should be considered from the following perspectives:\n\n- Departmental;\n- Within the plant / site;\n- Within the division;\n- From a global point of view.\n\n## 9.8.1.3.2 Main System Functionality\n\nThis part includes the description of the key functions of the system, both in relation to BPx and non-BPx, many of which can be critical to the business.\n\nThe functions can be grouped to keep the description at a high level. The use of diagrams is encouraged to explain relationships between key functions.\n\n## 9.8.1.3.4 Computational Environment\n\nThis part should be covered by a high level diagram showing the architecture that supports the system, covering, where appropriate:\n\n- The infrastructure that supports the system (e.g., server configurations, storage arrangements etc.);\n- *Interfaces* for users;\n- *Interfaces* for equipment;\n- *Interfaces* for other systems;\n- *Interfaces* outside the company;\n- The flow of data through the *interfaces*;\n- Security features such as *firewalls*.\n\n## 9.8.1.3.5 System Components\n\nAn indication of the main *hardware* and *software components* must be provided. Must include information about servers and storage equipment, as well as operating systems, types of database and applications. You should refer to any configuration documentation relevant to the system.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "2a0dcfdc18ec882506f72ac4ffa22a0f4d63ec38d52cad47f6c0010ca1dda638", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "# 9.8.1.3 Document Content\n\nThe description should cover only the main characteristics of the system. Detailed topic information must be included in other specifications and not repeated.\n\n## 9.8.1.3.1 Introduction\n\nThis part should explain the context of the system within the business process and the regulated company in general. This should be considered from the following perspectives:\n\n- Departmental;\n- Within the plant / site;\n- Within the division;\n- From a global point of view.\n\n## 9.8.1.3.2 Main System Functionality\n\nThis part includes the description of the key functions of the system, both in relation to BPx and non-BPx, many of which can be critical to the business.\n\nThe functions can be grouped to keep the description at a high level. The use of diagrams is encouraged to explain relationships between key functions.\n\n## 9.8.1.3.4 Computational Environment\n\nThis part should be covered by a high level diagram showing the architecture that supports the system, covering, where appropriate:\n\n- The infrastructure that supports the system (e.g., server configurations, storage arrangements etc.);\n- *Interfaces* for users;\n- *Interfaces* for equipment;\n- *Interfaces* for other systems;\n- *Interfaces* outside the company;\n- The flow of data through the *interfaces*;\n- Security features such as *firewalls*.\n\n## 9.8.1.3.5 System Components\n\nAn indication of the main *hardware* and *software components* must be provided. Must include information about servers and storage equipment, as well as operating systems, types of database and applications. You should refer to any configuration documentation relevant to the system.", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 1646, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "d5ede07b-fd19-4ec4-b750-b1139c2bf665": {"__data__": {"id_": "d5ede07b-fd19-4ec4-b750-b1139c2bf665", "embedding": null, "metadata": {"page_label": "60", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# Guide for Computer Systems Validation\n\n## 9.8.1.3.6 System Interfaces\n\nThis part should include an overview of the **key interfaces** for other systems and equipment, as well as the flow of data between the systems involved.\n\n## 9.8.1.3.7 Access Control\n\nThis part should include an overview of the characteristics of access control to the system, both physical (if relevant) and logical.\n\n## 9.8.1.3.8 Security Controls\n\nThis part should include an overview of the established security controls, both physical and logical. These should include **software** to protect data and records, such as, for example, antivirus and anti-malware.\n\n## 9.8.1.3.9 Electronic records and signatures\n\nA description of the types of electronic records created and managed by the system and the types of electronic signatures used, if relevant.\n\n## 9.8.1.3.10 Glossaries\n\nDefinitions of any terms that are unfamiliar must be provided.\n\n## 9.8.2 Configuration and Change Management\n\nProcesses for configuration management must be established so that the system computerized and all its components can be identified and defined at any time.\n\nChange management procedures should also be established. The point or phase at which change management has been introduced must be defined. This management must be applied both for the design phase as well as for the operational phase.\n\nAny involvement of the supplier in these managements must be defined and agreed.\n\n## 9.8.3 Project Review", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "### Resumen del Contexto\n\nEl documento es una gu\u00eda de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos, que incluye secciones espec\u00edficas sobre interfaces del sistema, control de acceso, controles de seguridad, registros y firmas electr\u00f3nicas, gesti\u00f3n de configuraci\u00f3n y cambios, y revisi\u00f3n de proyectos. Cada secci\u00f3n aborda aspectos clave que deben considerarse para garantizar que los sistemas inform\u00e1ticos cumplan con los requisitos regulatorios y de seguridad.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfQu\u00e9 aspectos deben considerarse al describir las interfaces del sistema en el contexto de la validaci\u00f3n de sistemas inform\u00e1ticos?**\n   - La gu\u00eda sugiere que se debe proporcionar una visi\u00f3n general de las interfaces clave con otros sistemas y equipos, as\u00ed como el flujo de datos entre los sistemas involucrados.\n\n2. **\u00bfCu\u00e1les son los elementos esenciales que deben incluirse en los procedimientos de gesti\u00f3n de cambios seg\u00fan la gu\u00eda de ANVISA?**\n   - Los procedimientos de gesti\u00f3n de cambios deben establecerse y definir el punto o fase en la que se introduce la gesti\u00f3n de cambios, aplic\u00e1ndose tanto en la fase de dise\u00f1o como en la fase operativa. Tambi\u00e9n se debe acordar cualquier participaci\u00f3n del proveedor en estas gestiones.\n\n3. **\u00bfQu\u00e9 tipo de software se menciona en la gu\u00eda para proteger los datos y registros dentro de los controles de seguridad?**\n   - La gu\u00eda menciona que los controles de seguridad deben incluir software para proteger datos y registros, como antivirus y anti-malware.\n\n### Resumen de Nivel Superior\n\nLa gu\u00eda de ANVISA para la validaci\u00f3n de sistemas inform\u00e1ticos proporciona directrices sobre c\u00f3mo gestionar y validar sistemas que manejan datos electr\u00f3nicos, asegurando que se cumplan los est\u00e1ndares de seguridad y regulaci\u00f3n. Se enfoca en aspectos como la gesti\u00f3n de interfaces, control de acceso, seguridad de datos, y la importancia de la gesti\u00f3n de cambios y configuraciones en el ciclo de vida del sistema.", "prev_section_summary": "### Resumen de Temas Clave y Entidades de la Secci\u00f3n\n\n1. **Descripci\u00f3n General del Sistema**:\n   - Se debe proporcionar una descripci\u00f3n que abarque solo las caracter\u00edsticas principales del sistema, evitando la repetici\u00f3n de informaci\u00f3n detallada que debe incluirse en otras especificaciones.\n\n2. **Contexto del Sistema**:\n   - La introducci\u00f3n debe explicar el contexto del sistema dentro del proceso empresarial y la empresa regulada, considerando las siguientes perspectivas:\n     - Departamental\n     - Dentro de la planta/sitio\n     - Dentro de la divisi\u00f3n\n     - Desde un punto de vista global\n\n3. **Funcionalidad Principal del Sistema**:\n   - Se debe describir las funciones clave del sistema, tanto en relaci\u00f3n con BPx como con no-BPx, muchas de las cuales son cr\u00edticas para el negocio.\n   - Se sugiere agrupar las funciones para mantener una descripci\u00f3n de alto nivel y utilizar diagramas para ilustrar las relaciones entre las funciones clave.\n\n4. **Entorno Computacional**:\n   - Se debe incluir un diagrama de alto nivel que muestre la arquitectura del sistema, abarcando:\n     - Infraestructura que soporta el sistema (configuraciones de servidores, arreglos de almacenamiento, etc.)\n     - Interfaces para usuarios, equipos, otros sistemas y externas a la empresa\n     - Flujo de datos a trav\u00e9s de las interfaces\n     - Caracter\u00edsticas de seguridad, como firewalls\n\n5. **Componentes del Sistema**:\n   - Se debe proporcionar informaci\u00f3n sobre los principales componentes de hardware y software, incluyendo servidores, equipos de almacenamiento, sistemas operativos, tipos de bases de datos y aplicaciones.\n   - Se debe hacer referencia a cualquier documentaci\u00f3n de configuraci\u00f3n relevante para el sistema.\n\n### Entidades Clave\n- **Sistema**: Entidad central que se describe en t\u00e9rminos de sus caracter\u00edsticas y funcionalidades.\n- **Perspectivas**: Diferentes \u00e1ngulos desde los cuales se analiza el sistema (departamental, planta, divisi\u00f3n, global).\n- **Funciones**: Actividades clave que realiza el sistema, agrupadas para facilitar la comprensi\u00f3n.\n- **Entorno Computacional**: Arquitectura y componentes que soportan el sistema, incluyendo infraestructura y seguridad.\n- **Componentes**: Hardware y software que conforman el sistema, esenciales para su operaci\u00f3n.", "excerpt_keywords": "Keywords: validation, access control, security controls, electronic records, change management"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "2e8ba283-1d95-4faa-ac5f-ed1096860f77", "node_type": "4", "metadata": {"page_label": "60", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# Guide for Computer Systems Validation\n\n## 9.8.1.3.6 System Interfaces\n\nThis part should include an overview of the **key interfaces** for other systems and equipment, as well as the flow of data between the systems involved.\n\n## 9.8.1.3.7 Access Control\n\nThis part should include an overview of the characteristics of access control to the system, both physical (if relevant) and logical.\n\n## 9.8.1.3.8 Security Controls\n\nThis part should include an overview of the established security controls, both physical and logical. These should include **software** to protect data and records, such as, for example, antivirus and anti-malware.\n\n## 9.8.1.3.9 Electronic records and signatures\n\nA description of the types of electronic records created and managed by the system and the types of electronic signatures used, if relevant.\n\n## 9.8.1.3.10 Glossaries\n\nDefinitions of any terms that are unfamiliar must be provided.\n\n## 9.8.2 Configuration and Change Management\n\nProcesses for configuration management must be established so that the system computerized and all its components can be identified and defined at any time.\n\nChange management procedures should also be established. The point or phase at which change management has been introduced must be defined. This management must be applied both for the design phase as well as for the operational phase.\n\nAny involvement of the supplier in these managements must be defined and agreed.\n\n## 9.8.3 Project Review", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "5ebf242f40498282afe739623e8ba20f6bb7567f42a2057f8abe5dbb6912f1d9", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "# Guide for Computer Systems Validation\n\n## 9.8.1.3.6 System Interfaces\n\nThis part should include an overview of the **key interfaces** for other systems and equipment, as well as the flow of data between the systems involved.\n\n## 9.8.1.3.7 Access Control\n\nThis part should include an overview of the characteristics of access control to the system, both physical (if relevant) and logical.\n\n## 9.8.1.3.8 Security Controls\n\nThis part should include an overview of the established security controls, both physical and logical. These should include **software** to protect data and records, such as, for example, antivirus and anti-malware.\n\n## 9.8.1.3.9 Electronic records and signatures\n\nA description of the types of electronic records created and managed by the system and the types of electronic signatures used, if relevant.\n\n## 9.8.1.3.10 Glossaries\n\nDefinitions of any terms that are unfamiliar must be provided.\n\n## 9.8.2 Configuration and Change Management\n\nProcesses for configuration management must be established so that the system computerized and all its components can be identified and defined at any time.\n\nChange management procedures should also be established. The point or phase at which change management has been introduced must be defined. This management must be applied both for the design phase as well as for the operational phase.\n\nAny involvement of the supplier in these managements must be defined and agreed.\n\n## 9.8.3 Project Review", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 1466, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "089d5a2e-c302-430d-b7ea-a78a03b66994": {"__data__": {"id_": "089d5a2e-c302-430d-b7ea-a78a03b66994", "embedding": null, "metadata": {"page_label": "61", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "At appropriate stages of the life cycle, planned and systematic design reviews of the project specifications design and development must be carried out. This project review should assess the results to be obtained to ensure that they meet the specified requirements. Corrective actions must be defined and developed.\n\nThe rigor of the execution of the design review and the extension of the documentation must be based on risk, complexity and innovation.\n\n## 9.8.4 Documentation Management\n\nDocumentation management includes preparing, reviewing, approving, issuing, changing, withdrawing and archiving.\n\n----\n\n## 9.8.5 Traceability Matrix\n\nTraceability is a process for:\n\n- The requirements are addressed and traceable to the respective design and functional specifications.\n- The requirements are traceable to the respective checks.\n\nIn addition to demonstrating project and verification coverage, traceability helps with assessment and change management.\n\nTraceability should focus on aspects critical to patient safety, product quality and data integrity and is known as the Requirements Traceability Matrix.\n\nFor non-configured products, traceability between user requirements and the verification performed can be enough.\n\nFor configured products, the design specification column (Design Specification - DS) can be replaced by a connection to the configuration items, providing traceability between system requirements user, configuration and verification.\n\nFor customized applications, traceability must be presented from the project specification level, from functional specifications to verification of user requirements.\n\nFigure 6 shows an example of a traceability matrix, where AR stands for Risk Analysis.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos establece la importancia de realizar revisiones de dise\u00f1o sistem\u00e1ticas y planificadas a lo largo del ciclo de vida del proyecto. Estas revisiones deben evaluar si los resultados cumplen con los requisitos especificados y definir acciones correctivas cuando sea necesario. Adem\u00e1s, se aborda la gesti\u00f3n de la documentaci\u00f3n y la importancia de la trazabilidad, que asegura que los requisitos est\u00e9n claramente vinculados a las especificaciones de dise\u00f1o y a las verificaciones realizadas, con un enfoque en la seguridad del paciente, la calidad del producto y la integridad de los datos.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfQu\u00e9 criterios deben considerarse al determinar el rigor de la ejecuci\u00f3n de una revisi\u00f3n de dise\u00f1o seg\u00fan el documento de ANVISA?**\n   - El rigor de la ejecuci\u00f3n de la revisi\u00f3n de dise\u00f1o y la extensi\u00f3n de la documentaci\u00f3n deben basarse en el riesgo, la complejidad y la innovaci\u00f3n del proyecto.\n\n2. **\u00bfCu\u00e1l es la funci\u00f3n principal de la Matriz de Trazabilidad seg\u00fan el contexto del documento?**\n   - La Matriz de Trazabilidad tiene como funci\u00f3n principal asegurar que los requisitos est\u00e9n abordados y sean trazables a las especificaciones de dise\u00f1o y funcionales correspondientes, as\u00ed como a las verificaciones realizadas, lo que ayuda en la gesti\u00f3n de cambios y evaluaci\u00f3n del proyecto.\n\n3. **\u00bfC\u00f3mo se debe presentar la trazabilidad para aplicaciones personalizadas seg\u00fan el documento?**\n   - Para aplicaciones personalizadas, la trazabilidad debe presentarse desde el nivel de especificaci\u00f3n del proyecto, abarcando desde las especificaciones funcionales hasta la verificaci\u00f3n de los requisitos del usuario.", "prev_section_summary": "La secci\u00f3n del documento \"Gu\u00eda para la Validaci\u00f3n de Sistemas Inform\u00e1ticos\" de ANVISA aborda varios temas clave relacionados con la validaci\u00f3n y gesti\u00f3n de sistemas que manejan datos electr\u00f3nicos. A continuaci\u00f3n se resumen los puntos m\u00e1s importantes:\n\n### Temas Clave\n\n1. **Interfaces del Sistema**:\n   - Importancia de describir las interfaces clave con otros sistemas y equipos.\n   - Necesidad de detallar el flujo de datos entre los sistemas involucrados.\n\n2. **Control de Acceso**:\n   - Revisi\u00f3n de las caracter\u00edsticas del control de acceso al sistema, tanto f\u00edsico como l\u00f3gico.\n\n3. **Controles de Seguridad**:\n   - Descripci\u00f3n de los controles de seguridad establecidos, incluyendo software para la protecci\u00f3n de datos y registros, como antivirus y anti-malware.\n\n4. **Registros y Firmas Electr\u00f3nicas**:\n   - Identificaci\u00f3n de los tipos de registros electr\u00f3nicos creados y gestionados por el sistema, as\u00ed como los tipos de firmas electr\u00f3nicas utilizadas.\n\n5. **Glosarios**:\n   - Inclusi\u00f3n de definiciones para t\u00e9rminos que puedan ser desconocidos.\n\n6. **Gesti\u00f3n de Configuraci\u00f3n y Cambios**:\n   - Establecimiento de procesos para la gesti\u00f3n de configuraci\u00f3n, asegurando que todos los componentes del sistema puedan ser identificados y definidos.\n   - Procedimientos de gesti\u00f3n de cambios que deben aplicarse en las fases de dise\u00f1o y operativa, incluyendo la participaci\u00f3n del proveedor.\n\n7. **Revisi\u00f3n de Proyectos**:\n   - Aunque no se detalla en el extracto, se menciona que debe haber un proceso de revisi\u00f3n de proyectos.\n\n### Entidades\n\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil, responsable de la regulaci\u00f3n de sistemas inform\u00e1ticos en el \u00e1mbito de la salud.\n- **Sistemas Inform\u00e1ticos**: Sistemas que manejan datos electr\u00f3nicos y requieren validaci\u00f3n para cumplir con est\u00e1ndares regulatorios.\n- **Controles de Seguridad**: Medidas implementadas para proteger la integridad y confidencialidad de los datos.\n- **Registros Electr\u00f3nicos**: Documentos digitales que son creados y gestionados por el sistema.\n- **Firmas Electr\u00f3nicas**: M\u00e9todos utilizados para autenticar la identidad de los firmantes en documentos electr\u00f3nicos.\n\nEste resumen proporciona una visi\u00f3n general de los aspectos cr\u00edticos que deben considerarse para garantizar la validaci\u00f3n adecuada de los sistemas inform\u00e1ticos seg\u00fan las directrices de ANVISA.", "excerpt_keywords": "Keywords: validation, traceability, documentation management, design review, patient safety"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "3cdf8fcf-2031-486b-b62f-ccea0c169673", "node_type": "4", "metadata": {"page_label": "61", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "At appropriate stages of the life cycle, planned and systematic design reviews of the project specifications design and development must be carried out. This project review should assess the results to be obtained to ensure that they meet the specified requirements. Corrective actions must be defined and developed.\n\nThe rigor of the execution of the design review and the extension of the documentation must be based on risk, complexity and innovation.\n\n## 9.8.4 Documentation Management\n\nDocumentation management includes preparing, reviewing, approving, issuing, changing, withdrawing and archiving.\n\n----\n\n## 9.8.5 Traceability Matrix\n\nTraceability is a process for:\n\n- The requirements are addressed and traceable to the respective design and functional specifications.\n- The requirements are traceable to the respective checks.\n\nIn addition to demonstrating project and verification coverage, traceability helps with assessment and change management.\n\nTraceability should focus on aspects critical to patient safety, product quality and data integrity and is known as the Requirements Traceability Matrix.\n\nFor non-configured products, traceability between user requirements and the verification performed can be enough.\n\nFor configured products, the design specification column (Design Specification - DS) can be replaced by a connection to the configuration items, providing traceability between system requirements user, configuration and verification.\n\nFor customized applications, traceability must be presented from the project specification level, from functional specifications to verification of user requirements.\n\nFigure 6 shows an example of a traceability matrix, where AR stands for Risk Analysis.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "9e73a37226b8402690ea3206a03744bdb0413939fe009cb3b7ba10984e7d0a73", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "At appropriate stages of the life cycle, planned and systematic design reviews of the project specifications design and development must be carried out. This project review should assess the results to be obtained to ensure that they meet the specified requirements. Corrective actions must be defined and developed.\n\nThe rigor of the execution of the design review and the extension of the documentation must be based on risk, complexity and innovation.\n\n## 9.8.4 Documentation Management\n\nDocumentation management includes preparing, reviewing, approving, issuing, changing, withdrawing and archiving.\n\n----\n\n## 9.8.5 Traceability Matrix\n\nTraceability is a process for:\n\n- The requirements are addressed and traceable to the respective design and functional specifications.\n- The requirements are traceable to the respective checks.\n\nIn addition to demonstrating project and verification coverage, traceability helps with assessment and change management.\n\nTraceability should focus on aspects critical to patient safety, product quality and data integrity and is known as the Requirements Traceability Matrix.\n\nFor non-configured products, traceability between user requirements and the verification performed can be enough.\n\nFor configured products, the design specification column (Design Specification - DS) can be replaced by a connection to the configuration items, providing traceability between system requirements user, configuration and verification.\n\nFor customized applications, traceability must be presented from the project specification level, from functional specifications to verification of user requirements.\n\nFigure 6 shows an example of a traceability matrix, where AR stands for Risk Analysis.", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 1718, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "bef21dec-6bab-4dae-93a1-1eeebec9f706": {"__data__": {"id_": "bef21dec-6bab-4dae-93a1-1eeebec9f706", "embedding": null, "metadata": {"page_label": "62", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 9.9 VALIDATION REPORT\n\n## 9.9.1 Introduction\n\nA validation report with a focus on aspects related to patient safety, product quality and data integrity. It should summarize the activities performed, any deviations occurred in relation to what was planned, the most important corrective actions and a statement about the service of the system to the intended use.\n\nThe level of detail in the report should reflect the risk, complexity and innovation of the system.\n\nThe structure of the report should reflect the structure of the corresponding plan.\n\nThe report must be approved by at least the process owner and the Quality Unit. May also it is appropriate that other approvers of the corresponding plan also approve the report, such as the owner of the system.\n\nIt is common to produce a final report. However, there may be other reports (partial or phases of the validation) that feed into this final report or that is created later to supplement it.\n\n## 9.9.2 Contents of the Computerized System Validation Report\n\n### 9.9.2.1 Introduction and Scope\n\nThe introduction should reflect the corresponding plan and highlight what differences may have arisen since the plan was issued. It should contain the following information:\n\n- Purpose and scope of the report;\n- Who drafted the report and under what authority;\n- Summary of the approach used;\n- Cross-reference to the plans, procedures and policies that guided the report.\n\n### 9.9.2.2 Scope Changes\n\nIt may be necessary to change the initial approach. The report must highlight and justify such changes in scope.\n\n### 9.9.2.3 Supplier Evaluation\n\n----\n\n*Figure 6. Example of a Traceability Matrix.*\n*Source: GAMP5*\n\n*Guide for Computer Systems Validation*\n*Guide n\u00b0 33/2020 - version 1, of 03/26/2020*", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas computacionales establece directrices para la elaboraci\u00f3n de un informe de validaci\u00f3n. Este informe debe centrarse en la seguridad del paciente, la calidad del producto y la integridad de los datos. Debe resumir las actividades realizadas, las desviaciones respecto al plan inicial, las acciones correctivas m\u00e1s importantes y una declaraci\u00f3n sobre el uso del sistema. La estructura del informe debe reflejar la del plan correspondiente y debe ser aprobado por el propietario del proceso y la Unidad de Calidad, entre otros.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfQu\u00e9 aspectos deben ser considerados al redactar la introducci\u00f3n del informe de validaci\u00f3n?**\n   - La introducci\u00f3n debe reflejar el plan correspondiente y destacar las diferencias que hayan surgido desde su emisi\u00f3n. Debe incluir el prop\u00f3sito y alcance del informe, qui\u00e9n lo redact\u00f3 y bajo qu\u00e9 autoridad, un resumen del enfoque utilizado y referencias cruzadas a los planes, procedimientos y pol\u00edticas que guiaron el informe.\n\n2. **\u00bfQu\u00e9 se debe hacer si hay cambios en el alcance del informe de validaci\u00f3n?**\n   - Si es necesario cambiar el enfoque inicial, el informe debe resaltar y justificar dichos cambios en el alcance.\n\n3. **\u00bfQui\u00e9nes deben aprobar el informe de validaci\u00f3n y por qu\u00e9 es importante esta aprobaci\u00f3n?**\n   - El informe debe ser aprobado por al menos el propietario del proceso y la Unidad de Calidad. Tambi\u00e9n puede ser apropiado que otros aprobadores del plan correspondiente lo firmen, como el propietario del sistema. Esta aprobaci\u00f3n es importante para garantizar que el informe cumpla con los est\u00e1ndares de calidad y seguridad requeridos.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Revisiones de Dise\u00f1o**: \n   - Importancia de realizar revisiones sistem\u00e1ticas y planificadas a lo largo del ciclo de vida del proyecto.\n   - Evaluaci\u00f3n de resultados para asegurar el cumplimiento de requisitos especificados.\n   - Definici\u00f3n y desarrollo de acciones correctivas.\n\n2. **Criterios para la Ejecuci\u00f3n de Revisiones**:\n   - El rigor y la extensi\u00f3n de la documentaci\u00f3n deben basarse en:\n     - **Riesgo**\n     - **Complejidad**\n     - **Innovaci\u00f3n**\n\n3. **Gesti\u00f3n de Documentaci\u00f3n**:\n   - Incluye procesos de preparaci\u00f3n, revisi\u00f3n, aprobaci\u00f3n, emisi\u00f3n, cambio, retiro y archivo de documentos.\n\n4. **Matriz de Trazabilidad**:\n   - Asegura que los requisitos est\u00e9n vinculados a las especificaciones de dise\u00f1o y funcionales, as\u00ed como a las verificaciones realizadas.\n   - Facilita la gesti\u00f3n de cambios y la evaluaci\u00f3n del proyecto.\n   - Enfoque en aspectos cr\u00edticos como:\n     - **Seguridad del paciente**\n     - **Calidad del producto**\n     - **Integridad de los datos**\n\n5. **Tipos de Productos y Trazabilidad**:\n   - **Productos no configurados**: Trazabilidad entre requisitos del usuario y verificaciones puede ser suficiente.\n   - **Productos configurados**: La columna de especificaci\u00f3n de dise\u00f1o puede conectarse a los elementos de configuraci\u00f3n.\n   - **Aplicaciones personalizadas**: Trazabilidad desde el nivel de especificaci\u00f3n del proyecto hasta la verificaci\u00f3n de requisitos del usuario.\n\n### Entidades Clave\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil.\n- **Matriz de Trazabilidad**: Herramienta para asegurar la conexi\u00f3n entre requisitos y verificaciones.\n- **Documentaci\u00f3n**: Conjunto de documentos que deben ser gestionados a lo largo del ciclo de vida del proyecto.\n- **Riesgo, Complejidad e Innovaci\u00f3n**: Criterios que influyen en la ejecuci\u00f3n de revisiones de dise\u00f1o.\n\nEste resumen destaca la importancia de la planificaci\u00f3n y la sistematizaci\u00f3n en la validaci\u00f3n de sistemas inform\u00e1ticos, as\u00ed como la necesidad de una gesti\u00f3n adecuada de la documentaci\u00f3n y la trazabilidad para garantizar la calidad y seguridad en el desarrollo de productos.", "excerpt_keywords": "Keywords: validation report, patient safety, data integrity, quality assurance, computerized systems"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "5e8d9b11-53e2-4e2b-878b-6bf424bf98da", "node_type": "4", "metadata": {"page_label": "62", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 9.9 VALIDATION REPORT\n\n## 9.9.1 Introduction\n\nA validation report with a focus on aspects related to patient safety, product quality and data integrity. It should summarize the activities performed, any deviations occurred in relation to what was planned, the most important corrective actions and a statement about the service of the system to the intended use.\n\nThe level of detail in the report should reflect the risk, complexity and innovation of the system.\n\nThe structure of the report should reflect the structure of the corresponding plan.\n\nThe report must be approved by at least the process owner and the Quality Unit. May also it is appropriate that other approvers of the corresponding plan also approve the report, such as the owner of the system.\n\nIt is common to produce a final report. However, there may be other reports (partial or phases of the validation) that feed into this final report or that is created later to supplement it.\n\n## 9.9.2 Contents of the Computerized System Validation Report\n\n### 9.9.2.1 Introduction and Scope\n\nThe introduction should reflect the corresponding plan and highlight what differences may have arisen since the plan was issued. It should contain the following information:\n\n- Purpose and scope of the report;\n- Who drafted the report and under what authority;\n- Summary of the approach used;\n- Cross-reference to the plans, procedures and policies that guided the report.\n\n### 9.9.2.2 Scope Changes\n\nIt may be necessary to change the initial approach. The report must highlight and justify such changes in scope.\n\n### 9.9.2.3 Supplier Evaluation\n\n----\n\n*Figure 6. Example of a Traceability Matrix.*\n*Source: GAMP5*\n\n*Guide for Computer Systems Validation*\n*Guide n\u00b0 33/2020 - version 1, of 03/26/2020*", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "f2ad875b4340962310fb8355f9c393570f55d0abfc225eeb47ac6566a24caf45", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "# 9.9 VALIDATION REPORT\n\n## 9.9.1 Introduction\n\nA validation report with a focus on aspects related to patient safety, product quality and data integrity. It should summarize the activities performed, any deviations occurred in relation to what was planned, the most important corrective actions and a statement about the service of the system to the intended use.\n\nThe level of detail in the report should reflect the risk, complexity and innovation of the system.\n\nThe structure of the report should reflect the structure of the corresponding plan.\n\nThe report must be approved by at least the process owner and the Quality Unit. May also it is appropriate that other approvers of the corresponding plan also approve the report, such as the owner of the system.\n\nIt is common to produce a final report. However, there may be other reports (partial or phases of the validation) that feed into this final report or that is created later to supplement it.\n\n## 9.9.2 Contents of the Computerized System Validation Report\n\n### 9.9.2.1 Introduction and Scope\n\nThe introduction should reflect the corresponding plan and highlight what differences may have arisen since the plan was issued. It should contain the following information:\n\n- Purpose and scope of the report;\n- Who drafted the report and under what authority;\n- Summary of the approach used;\n- Cross-reference to the plans, procedures and policies that guided the report.\n\n### 9.9.2.2 Scope Changes\n\nIt may be necessary to change the initial approach. The report must highlight and justify such changes in scope.\n\n### 9.9.2.3 Supplier Evaluation\n\n----\n\n*Figure 6. Example of a Traceability Matrix.*\n*Source: GAMP5*\n\n*Guide for Computer Systems Validation*\n*Guide n\u00b0 33/2020 - version 1, of 03/26/2020*", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 1758, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "4cdb5f35-36f8-4bf1-86ed-8c4c4244da9f": {"__data__": {"id_": "4cdb5f35-36f8-4bf1-86ed-8c4c4244da9f", "embedding": null, "metadata": {"page_label": "63", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "Supplier assessment activities should be summarized or referenced to other source documents, such as a Supplier Assessment or Audit Report.\n\nIf the supplier's documentation has been used / used, there should be a discussion about the measures taken to ensure their suitability.\n\nInformation already available in other documents should not be repeated.\n\nContent of audit reports at the supplier should not be included in the validation report.\n\n## 9.9.2.4 Summary of Activities\n\nThe summary must refer to the existing documentation and there should be no duplication of information.\n\nThis section can include subsections relevant to each phase.\n\n## 9.9.2.5 Summary of Results Obtained\n\nThe report must verify that all the results expected in the corresponding validation plan have been obtained and approved. This includes the system development documentation and Operating Procedures Standard (POP) required for operational support.\n\n----\n\n## 9.9.2.6 Summary of Deviations and Corrective Actions\n\nThe report should describe any activities and results that did not meet the specified expectations in the plan and explain its impact and the respective corrective actions. The most important corrective actions should be highlighted and appropriate next steps identified or referenced.\n\n## 9.9.2.7 Declaration of Suitability for Intended Use\n\nThere must be a clear statement about the status of the system and whether it is suitable for its intended use, taking mind any major deviations or corrective actions.\n\n## 9.9.2.8 Training\n\nThe report must verify that the personnel involved with the new processes, equipment or systems have been trained and that this training has been documented.\n\n## 9.9.2.9 Maintenance of Service and Adequacy to the Intended Use\n\nThe report should outline how the system's service situation will be maintained. This can be efficiently achieved by referencing the relevant policies and procedures. See the documents.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas que se pueden formular a partir del contexto proporcionado, junto con sus respuestas espec\u00edficas:\n\n### Preguntas y Respuestas\n\n1. **\u00bfQu\u00e9 debe incluirse en la secci\u00f3n de \"Resumen de Resultados Obtenidos\" del informe de validaci\u00f3n?**\n   - La secci\u00f3n de \"Resumen de Resultados Obtenidos\" debe verificar que todos los resultados esperados en el plan de validaci\u00f3n correspondiente han sido obtenidos y aprobados. Esto incluye la documentaci\u00f3n de desarrollo del sistema y los Procedimientos Operativos Est\u00e1ndar (POP) necesarios para el soporte operativo.\n\n2. **\u00bfC\u00f3mo debe abordarse la capacitaci\u00f3n del personal en el informe de validaci\u00f3n?**\n   - El informe debe verificar que el personal involucrado con los nuevos procesos, equipos o sistemas ha recibido capacitaci\u00f3n y que esta capacitaci\u00f3n ha sido documentada adecuadamente.\n\n3. **\u00bfQu\u00e9 se debe hacer si hay desviaciones en los resultados esperados seg\u00fan el plan de validaci\u00f3n?**\n   - Si hay desviaciones en los resultados esperados, el informe debe describir las actividades y resultados que no cumplieron con las expectativas especificadas en el plan, explicar su impacto y detallar las acciones correctivas correspondientes. Las acciones correctivas m\u00e1s importantes deben ser destacadas y se deben identificar o referenciar los pasos siguientes apropiados.\n\n### Resumen de Nivel Superior\n\nEl contexto se centra en las directrices de ANVISA para la validaci\u00f3n de sistemas inform\u00e1ticos, destacando la importancia de la documentaci\u00f3n y la capacitaci\u00f3n en el proceso de validaci\u00f3n. Se enfatiza que la informaci\u00f3n no debe duplicarse y que los informes deben ser claros sobre la adecuaci\u00f3n del sistema para su uso previsto, as\u00ed como sobre cualquier desviaci\u00f3n y las acciones correctivas tomadas. Adem\u00e1s, se menciona la necesidad de mantener la situaci\u00f3n del servicio del sistema y documentar la capacitaci\u00f3n del personal involucrado.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n**Temas Clave:**\n\n1. **Informe de Validaci\u00f3n:**\n   - Enfocado en la seguridad del paciente, calidad del producto e integridad de los datos.\n   - Debe resumir actividades realizadas, desviaciones del plan, acciones correctivas y declaraci\u00f3n sobre el uso del sistema.\n\n2. **Estructura del Informe:**\n   - Debe reflejar la estructura del plan correspondiente.\n   - Aprobaci\u00f3n requerida por el propietario del proceso y la Unidad de Calidad, con posibilidad de incluir otros aprobadores.\n\n3. **Contenido del Informe:**\n   - Introducci\u00f3n y alcance que refleje el plan y diferencias desde su emisi\u00f3n.\n   - Justificaci\u00f3n de cambios en el alcance si es necesario.\n   - Evaluaci\u00f3n de proveedores como parte del proceso.\n\n4. **Aprobaci\u00f3n del Informe:**\n   - Importancia de la aprobaci\u00f3n para asegurar el cumplimiento de est\u00e1ndares de calidad y seguridad.\n\n**Entidades:**\n\n- **ANVISA:** Agencia Nacional de Vigilancia Sanitaria de Brasil, responsable de la regulaci\u00f3n.\n- **Proceso Owner:** Propietario del proceso que debe aprobar el informe.\n- **Quality Unit:** Unidad de Calidad que tambi\u00e9n debe aprobar el informe.\n- **Sistema Computacional:** El sistema que est\u00e1 siendo validado y evaluado en el informe.\n- **GAMP5:** Referencia a las buenas pr\u00e1cticas en la validaci\u00f3n de sistemas computacionales.\n\nEste resumen destaca los elementos esenciales que deben considerarse al elaborar un informe de validaci\u00f3n de sistemas computacionales seg\u00fan las directrices de ANVISA.", "excerpt_keywords": "Keywords: validation report, supplier assessment, corrective actions, training documentation, system suitability"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "cde9d584-3ead-480f-9958-8d1ab94189de", "node_type": "4", "metadata": {"page_label": "63", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "Supplier assessment activities should be summarized or referenced to other source documents, such as a Supplier Assessment or Audit Report.\n\nIf the supplier's documentation has been used / used, there should be a discussion about the measures taken to ensure their suitability.\n\nInformation already available in other documents should not be repeated.\n\nContent of audit reports at the supplier should not be included in the validation report.\n\n## 9.9.2.4 Summary of Activities\n\nThe summary must refer to the existing documentation and there should be no duplication of information.\n\nThis section can include subsections relevant to each phase.\n\n## 9.9.2.5 Summary of Results Obtained\n\nThe report must verify that all the results expected in the corresponding validation plan have been obtained and approved. This includes the system development documentation and Operating Procedures Standard (POP) required for operational support.\n\n----\n\n## 9.9.2.6 Summary of Deviations and Corrective Actions\n\nThe report should describe any activities and results that did not meet the specified expectations in the plan and explain its impact and the respective corrective actions. The most important corrective actions should be highlighted and appropriate next steps identified or referenced.\n\n## 9.9.2.7 Declaration of Suitability for Intended Use\n\nThere must be a clear statement about the status of the system and whether it is suitable for its intended use, taking mind any major deviations or corrective actions.\n\n## 9.9.2.8 Training\n\nThe report must verify that the personnel involved with the new processes, equipment or systems have been trained and that this training has been documented.\n\n## 9.9.2.9 Maintenance of Service and Adequacy to the Intended Use\n\nThe report should outline how the system's service situation will be maintained. This can be efficiently achieved by referencing the relevant policies and procedures. See the documents.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "e2e01e214475b3e7068a19b9aa045cd61ef677a055b842a7b428f47bb45d2d63", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "Supplier assessment activities should be summarized or referenced to other source documents, such as a Supplier Assessment or Audit Report.\n\nIf the supplier's documentation has been used / used, there should be a discussion about the measures taken to ensure their suitability.\n\nInformation already available in other documents should not be repeated.\n\nContent of audit reports at the supplier should not be included in the validation report.\n\n## 9.9.2.4 Summary of Activities\n\nThe summary must refer to the existing documentation and there should be no duplication of information.\n\nThis section can include subsections relevant to each phase.\n\n## 9.9.2.5 Summary of Results Obtained\n\nThe report must verify that all the results expected in the corresponding validation plan have been obtained and approved. This includes the system development documentation and Operating Procedures Standard (POP) required for operational support.\n\n----\n\n## 9.9.2.6 Summary of Deviations and Corrective Actions\n\nThe report should describe any activities and results that did not meet the specified expectations in the plan and explain its impact and the respective corrective actions. The most important corrective actions should be highlighted and appropriate next steps identified or referenced.\n\n## 9.9.2.7 Declaration of Suitability for Intended Use\n\nThere must be a clear statement about the status of the system and whether it is suitable for its intended use, taking mind any major deviations or corrective actions.\n\n## 9.9.2.8 Training\n\nThe report must verify that the personnel involved with the new processes, equipment or systems have been trained and that this training has been documented.\n\n## 9.9.2.9 Maintenance of Service and Adequacy to the Intended Use\n\nThe report should outline how the system's service situation will be maintained. This can be efficiently achieved by referencing the relevant policies and procedures. See the documents.", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 1942, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "82e2cd1a-7363-451b-87ef-6d62ff681e10": {"__data__": {"id_": "82e2cd1a-7363-451b-87ef-6d62ff681e10", "embedding": null, "metadata": {"page_label": "64", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "9.9.2.10 Glossary\n\nDefinitions of any little-known terms should be provided.\n\n9.9.2.11 Appendices\n\nThere may be a need for the existence of appendices, depending on the purpose, size and complexity of the report, the corporate style of the regulated company and its policies adopted for the preparation of reports.\n\n# 10. INVENTORY LIST\n\nRegulated companies must maintain an inventory of computer systems.\n\nThe inventory must present summary information about each system, describing: name of the system; associated equipment or application; impact / criticality in relation to BPx; GAMP category; ownership (sector, system owner, process owner); current version; provider; validation situation.\n\nAutomated equipment can be listed separately and duplication must be avoided.\n\nThe inventory should cover the level of systems that support business processes and not items individual *hardware* (components) that must be covered by local industry procedures information technology.\n\nThis inventory can be used for planning periodic reviews.\n\n# 11. OPERATIONAL PHASE OF COMPUTERIZED SYSTEMS\n\n## 11.1 INTRODUCTION\n\nThis section deals with the phase of the system's life cycle subsequent to its validation, in which the system validated computer is released for use by the end user.\n\nThe operational phase can take many years and can include changing *software*, *hardware*, business and regulatory requirements. The integrity of the system and its data must be maintained throughout period of use, including when retired, and must be verified when periodic review.\n\nAs experience is gained with the computerized system, improvement opportunities for the process and system, based on periodic review, evaluation of operational and performance data, in the analysis of the root causes of the failures that occurred. Information obtained incident management processes and CAPA's can provide relevant data for the system evaluation.\n\nChange management should provide a mechanism for the immediate adoption of improvements.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas que se pueden responder espec\u00edficamente con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos establece directrices para la gesti\u00f3n y mantenimiento de sistemas inform\u00e1ticos en empresas reguladas. Se enfatiza la importancia de mantener un inventario detallado de los sistemas, que incluya informaci\u00f3n cr\u00edtica como el nombre del sistema, su impacto, la categor\u00eda GAMP, y la situaci\u00f3n de validaci\u00f3n. Adem\u00e1s, se aborda la fase operativa de los sistemas, que sigue a su validaci\u00f3n, destacando la necesidad de mantener la integridad del sistema y sus datos a lo largo de su ciclo de vida, as\u00ed como la importancia de la gesti\u00f3n de cambios y la mejora continua basada en la revisi\u00f3n peri\u00f3dica y el an\u00e1lisis de datos operativos.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfQu\u00e9 informaci\u00f3n debe incluirse en el inventario de sistemas inform\u00e1ticos seg\u00fan la gu\u00eda de ANVISA?**\n   - La gu\u00eda establece que el inventario debe incluir el nombre del sistema, el equipo o aplicaci\u00f3n asociada, el impacto/cr\u00edtica en relaci\u00f3n con BPx, la categor\u00eda GAMP, la propiedad (sector, propietario del sistema, propietario del proceso), la versi\u00f3n actual, el proveedor y la situaci\u00f3n de validaci\u00f3n.\n\n2. **\u00bfC\u00f3mo se debe manejar la integridad de los sistemas inform\u00e1ticos durante su fase operativa?**\n   - La integridad del sistema y sus datos debe mantenerse durante todo el per\u00edodo de uso, incluso cuando el sistema es retirado. Esto incluye la verificaci\u00f3n de la integridad durante las revisiones peri\u00f3dicas y la implementaci\u00f3n de mejoras basadas en la experiencia adquirida y el an\u00e1lisis de datos operativos.\n\n3. **\u00bfCu\u00e1l es el prop\u00f3sito de la gesti\u00f3n de cambios en el contexto de los sistemas inform\u00e1ticos validados?**\n   - La gesti\u00f3n de cambios debe proporcionar un mecanismo para la adopci\u00f3n inmediata de mejoras en el sistema, asegurando que cualquier cambio necesario se implemente de manera eficiente y que se mantenga la conformidad con los requisitos regulatorios y de negocio.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Actividades de Evaluaci\u00f3n de Proveedores**:\n   - Resumen o referencia a documentos de evaluaci\u00f3n o auditor\u00eda de proveedores.\n   - Discusi\u00f3n sobre la idoneidad de la documentaci\u00f3n del proveedor utilizada.\n\n2. **Resumen de Actividades**:\n   - Debe referirse a la documentaci\u00f3n existente sin duplicar informaci\u00f3n.\n   - Puede incluir subsecciones relevantes a cada fase del proceso.\n\n3. **Resumen de Resultados Obtenidos**:\n   - Verificaci\u00f3n de que se han obtenido y aprobado todos los resultados esperados seg\u00fan el plan de validaci\u00f3n.\n   - Incluye documentaci\u00f3n de desarrollo del sistema y Procedimientos Operativos Est\u00e1ndar (POP).\n\n4. **Resumen de Desviaciones y Acciones Correctivas**:\n   - Descripci\u00f3n de actividades y resultados que no cumplieron con las expectativas.\n   - Explicaci\u00f3n del impacto y acciones correctivas, destacando las m\u00e1s importantes.\n\n5. **Declaraci\u00f3n de Idoneidad para el Uso Previsto**:\n   - Declaraci\u00f3n clara sobre el estado del sistema y su idoneidad para el uso previsto, considerando desviaciones y acciones correctivas.\n\n6. **Capacitaci\u00f3n**:\n   - Verificaci\u00f3n de que el personal ha sido capacitado en nuevos procesos, equipos o sistemas, y que esta capacitaci\u00f3n est\u00e1 documentada.\n\n7. **Mantenimiento del Servicio y Adecuaci\u00f3n al Uso Previsto**:\n   - Descripci\u00f3n de c\u00f3mo se mantendr\u00e1 la situaci\u00f3n del servicio del sistema, referenciando pol\u00edticas y procedimientos relevantes.\n\n### Entidades Clave\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil.\n- **Proveedores**: Entidades que suministran productos o servicios.\n- **Documentaci\u00f3n**: Informes, procedimientos y registros relacionados con la validaci\u00f3n.\n- **Personal**: Empleados involucrados en los nuevos procesos o sistemas.\n- **Sistema**: Software o hardware que se est\u00e1 validando para su uso en operaciones. \n\nEste resumen destaca la importancia de la documentaci\u00f3n, la capacitaci\u00f3n y la gesti\u00f3n de desviaciones en el proceso de validaci\u00f3n de sistemas inform\u00e1ticos seg\u00fan las directrices de ANVISA.", "excerpt_keywords": "Keywords: validation, inventory, operational phase, change management, regulatory compliance"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "bd3d8e62-05ce-492b-9ca6-df5e7f6ba34a", "node_type": "4", "metadata": {"page_label": "64", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "9.9.2.10 Glossary\n\nDefinitions of any little-known terms should be provided.\n\n9.9.2.11 Appendices\n\nThere may be a need for the existence of appendices, depending on the purpose, size and complexity of the report, the corporate style of the regulated company and its policies adopted for the preparation of reports.\n\n# 10. INVENTORY LIST\n\nRegulated companies must maintain an inventory of computer systems.\n\nThe inventory must present summary information about each system, describing: name of the system; associated equipment or application; impact / criticality in relation to BPx; GAMP category; ownership (sector, system owner, process owner); current version; provider; validation situation.\n\nAutomated equipment can be listed separately and duplication must be avoided.\n\nThe inventory should cover the level of systems that support business processes and not items individual *hardware* (components) that must be covered by local industry procedures information technology.\n\nThis inventory can be used for planning periodic reviews.\n\n# 11. OPERATIONAL PHASE OF COMPUTERIZED SYSTEMS\n\n## 11.1 INTRODUCTION\n\nThis section deals with the phase of the system's life cycle subsequent to its validation, in which the system validated computer is released for use by the end user.\n\nThe operational phase can take many years and can include changing *software*, *hardware*, business and regulatory requirements. The integrity of the system and its data must be maintained throughout period of use, including when retired, and must be verified when periodic review.\n\nAs experience is gained with the computerized system, improvement opportunities for the process and system, based on periodic review, evaluation of operational and performance data, in the analysis of the root causes of the failures that occurred. Information obtained incident management processes and CAPA's can provide relevant data for the system evaluation.\n\nChange management should provide a mechanism for the immediate adoption of improvements.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "de03154b3a31d3a9fe3f1ab2c3579f1447aafe50bb0ad605fccd7365fab36be8", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "9.9.2.10 Glossary\n\nDefinitions of any little-known terms should be provided.\n\n9.9.2.11 Appendices\n\nThere may be a need for the existence of appendices, depending on the purpose, size and complexity of the report, the corporate style of the regulated company and its policies adopted for the preparation of reports.\n\n# 10. INVENTORY LIST\n\nRegulated companies must maintain an inventory of computer systems.\n\nThe inventory must present summary information about each system, describing: name of the system; associated equipment or application; impact / criticality in relation to BPx; GAMP category; ownership (sector, system owner, process owner); current version; provider; validation situation.\n\nAutomated equipment can be listed separately and duplication must be avoided.\n\nThe inventory should cover the level of systems that support business processes and not items individual *hardware* (components) that must be covered by local industry procedures information technology.\n\nThis inventory can be used for planning periodic reviews.\n\n# 11. OPERATIONAL PHASE OF COMPUTERIZED SYSTEMS\n\n## 11.1 INTRODUCTION\n\nThis section deals with the phase of the system's life cycle subsequent to its validation, in which the system validated computer is released for use by the end user.\n\nThe operational phase can take many years and can include changing *software*, *hardware*, business and regulatory requirements. The integrity of the system and its data must be maintained throughout period of use, including when retired, and must be verified when periodic review.\n\nAs experience is gained with the computerized system, improvement opportunities for the process and system, based on periodic review, evaluation of operational and performance data, in the analysis of the root causes of the failures that occurred. Information obtained incident management processes and CAPA's can provide relevant data for the system evaluation.\n\nChange management should provide a mechanism for the immediate adoption of improvements.", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 2013, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "cb8b5958-df63-4c4e-b8cc-5740f607474b": {"__data__": {"id_": "cb8b5958-df63-4c4e-b8cc-5740f607474b", "embedding": null, "metadata": {"page_label": "65", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "Table 3 presents the necessary procedures for the smooth running of the operational phase of the system computerized.\n\n### Table 3. Operating Procedures Associated with the Operating Phase of the System.\n\n| Process Groups                        | Procedures                                                                 | Section |\n|---------------------------------------|----------------------------------------------------------------------------|---------|\n| Delivery                              | \u2022 Delivery Process                                                         | 11.2    |\n| Management of Service and Performance | \u2022 Establishment and Management Services Support                            | 11.3    |\n| of performance                        | \u2022 Monitoring in Performance                                                | 11.4    |\n| Management of Incidents and CAPA      | \u2022 Management in Incidents                                                  | 11.5    |\n|                                       | \u2022 COVER                                                                    | 11.6    |\n| Management of Changes                 | \u2022 Management in Changes and Configuration System                           | 11.7    |\n| Audits and Review                     | \u2022 Repair Activities                                                        | 11.8    |\n|                                       | \u2022 Periodic Review                                                          | 11.9    |\n|                                       | \u2022 Internal Audits                                                          | 11.10   |\n| Management Continuity                 | \u2022 Backup and Restore                                                       |         |\n|                                       | \u2022 Business Continuity and Disaster Recovery                                | 11.11   |\n|                                       | \u2022 Management gives Safety                                                  | 11.12   |\n| Security and Administration of System | \u2022 Administration of System                                                 | 11.13   |\n| Management of Records                 | \u2022 Retention, Archiving and Recovery                                        | 11.14   |\n\n----\n\n### 11.2 SYSTEM DELIVERY\n\n#### 11.2.1 Introduction\n\nSystem delivery is the process of transferring responsibility from the system, the project team or a service group for the end user. It is an important process, as achieving compliance and suitability for the intended use alone are not sufficient to ensure a successful transfer to the operational phase.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos detalla los procedimientos necesarios para garantizar el funcionamiento adecuado de la fase operativa de un sistema. En la Tabla 3, se enumeran diferentes grupos de procesos y procedimientos asociados, que incluyen la entrega del sistema, la gesti\u00f3n del servicio y el rendimiento, la gesti\u00f3n de incidentes, cambios, auditor\u00edas, continuidad del negocio, seguridad y administraci\u00f3n del sistema, as\u00ed como la gesti\u00f3n de registros. Cada uno de estos grupos de procesos tiene secciones espec\u00edficas que abordan aspectos cr\u00edticos para el mantenimiento y la operaci\u00f3n efectiva del sistema.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfCu\u00e1les son los procedimientos asociados con la gesti\u00f3n de incidentes y CAPA seg\u00fan la Tabla 3?**\n   - Respuesta: Los procedimientos asociados con la gesti\u00f3n de incidentes y CAPA son: \"Gesti\u00f3n en Incidentes\" (11.5) y \"COVER\" (11.6).\n\n2. **\u00bfQu\u00e9 se entiende por el proceso de entrega del sistema y por qu\u00e9 es importante?**\n   - Respuesta: El proceso de entrega del sistema es la transferencia de responsabilidad del sistema, el equipo del proyecto o un grupo de servicio al usuario final. Es importante porque, aunque se logre la conformidad y la idoneidad para el uso previsto, esto no es suficiente para garantizar una transferencia exitosa a la fase operativa.\n\n3. **\u00bfQu\u00e9 procedimientos se mencionan en relaci\u00f3n con la continuidad del negocio y la recuperaci\u00f3n ante desastres?**\n   - Respuesta: Los procedimientos mencionados en relaci\u00f3n con la continuidad del negocio y la recuperaci\u00f3n ante desastres son: \"Business Continuity and Disaster Recovery\" (11.11) y \"Backup and Restore\" (sin secci\u00f3n especificada).", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Inventario de Sistemas Inform\u00e1ticos**:\n   - **Requisito**: Las empresas reguladas deben mantener un inventario de sistemas inform\u00e1ticos.\n   - **Contenido del Inventario**: \n     - Nombre del sistema\n     - Equipos o aplicaciones asociadas\n     - Impacto/cr\u00edtica en relaci\u00f3n con BPx\n     - Categor\u00eda GAMP\n     - Propiedad (sector, propietario del sistema, propietario del proceso)\n     - Versi\u00f3n actual\n     - Proveedor\n     - Situaci\u00f3n de validaci\u00f3n\n   - **Objetivo**: Facilitar la planificaci\u00f3n de revisiones peri\u00f3dicas y evitar duplicaciones.\n\n2. **Fase Operativa de Sistemas Inform\u00e1ticos**:\n   - **Definici\u00f3n**: Se refiere a la etapa del ciclo de vida del sistema que sigue a su validaci\u00f3n, donde el sistema se libera para uso por parte del usuario final.\n   - **Duraci\u00f3n**: Puede extenderse por muchos a\u00f1os e incluir cambios en software, hardware, y requisitos de negocio y regulatorios.\n   - **Mantenimiento de la Integridad**: Es crucial mantener la integridad del sistema y sus datos durante todo el per\u00edodo de uso, incluyendo su retiro.\n   - **Revisi\u00f3n Peri\u00f3dica**: Se debe verificar la integridad del sistema durante las revisiones peri\u00f3dicas.\n   - **Mejora Continua**: Se deben identificar oportunidades de mejora basadas en la revisi\u00f3n peri\u00f3dica y el an\u00e1lisis de datos operativos.\n   - **Gesti\u00f3n de Cambios**: Debe facilitar la adopci\u00f3n inmediata de mejoras en el sistema.\n\n### Entidades Clave\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil, responsable de la regulaci\u00f3n.\n- **BPx**: Referencia a un contexto espec\u00edfico de impacto o criticidad en el \u00e1mbito regulatorio.\n- **GAMP**: Buenas Pr\u00e1cticas de Automatizaci\u00f3n y Validaci\u00f3n de Sistemas.\n- **CAPA**: Acciones Correctivas y Preventivas, utilizadas para la gesti\u00f3n de incidentes y mejoras.\n\nEste resumen destaca la importancia de un inventario detallado y la gesti\u00f3n adecuada de la fase operativa para asegurar la conformidad y la mejora continua en los sistemas inform\u00e1ticos regulados.", "excerpt_keywords": "Keywords: ANVISA, Computer Systems Validation, Operational Phase, Management Procedures, System Delivery"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "82e0a5f5-c0c5-40f8-bf7a-8087c49d713f", "node_type": "4", "metadata": {"page_label": "65", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "Table 3 presents the necessary procedures for the smooth running of the operational phase of the system computerized.\n\n### Table 3. Operating Procedures Associated with the Operating Phase of the System.\n\n| Process Groups                        | Procedures                                                                 | Section |\n|---------------------------------------|----------------------------------------------------------------------------|---------|\n| Delivery                              | \u2022 Delivery Process                                                         | 11.2    |\n| Management of Service and Performance | \u2022 Establishment and Management Services Support                            | 11.3    |\n| of performance                        | \u2022 Monitoring in Performance                                                | 11.4    |\n| Management of Incidents and CAPA      | \u2022 Management in Incidents                                                  | 11.5    |\n|                                       | \u2022 COVER                                                                    | 11.6    |\n| Management of Changes                 | \u2022 Management in Changes and Configuration System                           | 11.7    |\n| Audits and Review                     | \u2022 Repair Activities                                                        | 11.8    |\n|                                       | \u2022 Periodic Review                                                          | 11.9    |\n|                                       | \u2022 Internal Audits                                                          | 11.10   |\n| Management Continuity                 | \u2022 Backup and Restore                                                       |         |\n|                                       | \u2022 Business Continuity and Disaster Recovery                                | 11.11   |\n|                                       | \u2022 Management gives Safety                                                  | 11.12   |\n| Security and Administration of System | \u2022 Administration of System                                                 | 11.13   |\n| Management of Records                 | \u2022 Retention, Archiving and Recovery                                        | 11.14   |\n\n----\n\n### 11.2 SYSTEM DELIVERY\n\n#### 11.2.1 Introduction\n\nSystem delivery is the process of transferring responsibility from the system, the project team or a service group for the end user. It is an important process, as achieving compliance and suitability for the intended use alone are not sufficient to ensure a successful transfer to the operational phase.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "2dc55445071c15e481b2bab724bde649d5e764b24a0fb2c47f5c0cd7d2931054", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "Table 3 presents the necessary procedures for the smooth running of the operational phase of the system computerized.\n\n### Table 3. Operating Procedures Associated with the Operating Phase of the System.\n\n| Process Groups                        | Procedures                                                                 | Section |\n|---------------------------------------|----------------------------------------------------------------------------|---------|\n| Delivery                              | \u2022 Delivery Process                                                         | 11.2    |\n| Management of Service and Performance | \u2022 Establishment and Management Services Support                            | 11.3    |\n| of performance                        | \u2022 Monitoring in Performance                                                | 11.4    |\n| Management of Incidents and CAPA      | \u2022 Management in Incidents                                                  | 11.5    |\n|                                       | \u2022 COVER                                                                    | 11.6    |\n| Management of Changes                 | \u2022 Management in Changes and Configuration System                           | 11.7    |\n| Audits and Review                     | \u2022 Repair Activities                                                        | 11.8    |\n|                                       | \u2022 Periodic Review                                                          | 11.9    |\n|                                       | \u2022 Internal Audits                                                          | 11.10   |\n| Management Continuity                 | \u2022 Backup and Restore                                                       |         |\n|                                       | \u2022 Business Continuity and Disaster Recovery                                | 11.11   |\n|                                       | \u2022 Management gives Safety                                                  | 11.12   |\n| Security and Administration of System | \u2022 Administration of System                                                 | 11.13   |\n| Management of Records                 | \u2022 Retention, Archiving and Recovery                                        | 11.14   |\n\n----\n\n### 11.2 SYSTEM DELIVERY\n\n#### 11.2.1 Introduction\n\nSystem delivery is the process of transferring responsibility from the system, the project team or a service group for the end user. It is an important process, as achieving compliance and suitability for the intended use alone are not sufficient to ensure a successful transfer to the operational phase.", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 2632, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "f056e0a6-30d6-4501-9f61-5ee7bb05c9f4": {"__data__": {"id_": "f056e0a6-30d6-4501-9f61-5ee7bb05c9f4", "embedding": null, "metadata": {"page_label": "66", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "The delivery process usually involves the project team (development group and/or supplier), the owner of the process, owner of the system and the quality unit.\n\n## 11.2.2 Key requirements\n\nThe regulated company must be able to demonstrate formal acceptance of the system after testing and controlled transfer to the operating environment of the work routine. This activity should be documented.\n\n## 11.2.3 Responsibilities\n\nThe project manager is responsible for preparing the system for delivery. The owner of the process and the owner of the system are responsible for accepting the system for operational use.\n\nResponsibility for completing any exceptional actions at the time of delivery should be agreed between the parts.\n\nConsideration should be given to defining a period for monitoring the system after its delivery and a reversal/return strategy in the event of a significant problem occurring during the monitoring period.\n\n## 11.2.4 Execution of the Delivery Activity\n\nThe company should define the scope, including configuration items, the period for delivery to occur and the acceptance criteria.\n\nThen you must establish a plan for delivery, which can be a separate document or be part of the Validation Plan. A checklist can be used to ensure acceptance and transfer of responsibilities.\n\nThe next step is to carry out the activities to deliver the system to the receiving group.\n\nAn agreement must be established between the parties for the conclusion (justified) or transfer of any open questions and incomplete activities or documentation from the design environment to the environment operational. For the delivery to be successful, critical deviations cannot persist.\n\nA report must be prepared, signed by the transferring group and the receiving group. This document may be part of the System Validation Report.\n\n## 11.3 SUPPORT SERVICE MANAGEMENT\n\n### 11.3.1 Introduction\n\nSupport Services Establishment and Management activities ensure that", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la Validaci\u00f3n de Sistemas Inform\u00e1ticos establece un proceso de entrega que involucra a varios actores, incluyendo el equipo del proyecto, el propietario del proceso, el propietario del sistema y la unidad de calidad. Se enfatiza la importancia de la aceptaci\u00f3n formal del sistema despu\u00e9s de las pruebas y la transferencia controlada al entorno operativo. Tambi\u00e9n se detallan las responsabilidades de los involucrados, la ejecuci\u00f3n de la actividad de entrega y la necesidad de documentaci\u00f3n adecuada para asegurar que no persistan desviaciones cr\u00edticas.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfCu\u00e1les son los pasos clave que deben seguirse para garantizar una entrega exitosa del sistema?**\n   - La entrega exitosa del sistema requiere definir el alcance, establecer un plan de entrega, realizar actividades de entrega, acordar la conclusi\u00f3n de preguntas abiertas y preparar un informe firmado por ambas partes.\n\n2. **\u00bfQu\u00e9 documentaci\u00f3n es necesaria para formalizar la aceptaci\u00f3n del sistema despu\u00e9s de la entrega?**\n   - Es necesario documentar la aceptaci\u00f3n formal del sistema, que puede incluir un informe que sea parte del Sistema de Validaci\u00f3n, as\u00ed como un plan de entrega que contenga criterios de aceptaci\u00f3n y un checklist para asegurar la transferencia de responsabilidades.\n\n3. **\u00bfQu\u00e9 consideraciones deben tenerse en cuenta para el monitoreo del sistema despu\u00e9s de su entrega?**\n   - Se debe definir un per\u00edodo de monitoreo post-entrega y establecer una estrategia de reversi\u00f3n en caso de que surjan problemas significativos durante este per\u00edodo. Adem\u00e1s, es importante acordar la responsabilidad de cualquier acci\u00f3n excepcional que deba completarse en el momento de la entrega.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos aborda procedimientos esenciales para asegurar el funcionamiento efectivo de la fase operativa de un sistema. A continuaci\u00f3n se presentan los temas clave y entidades relevantes:\n\n1. **Procedimientos Operativos**: La Tabla 3 enumera los grupos de procesos y sus procedimientos asociados, que son fundamentales para la operaci\u00f3n del sistema. Los grupos incluyen:\n   - **Entrega**: Proceso de entrega del sistema (Secci\u00f3n 11.2).\n   - **Gesti\u00f3n de Servicio y Rendimiento**: Establecimiento y gesti\u00f3n del soporte de servicios (Secci\u00f3n 11.3) y monitoreo del rendimiento (Secci\u00f3n 11.4).\n   - **Gesti\u00f3n de Incidentes y CAPA**: Manejo de incidentes (Secci\u00f3n 11.5) y procedimientos de \"COVER\" (Secci\u00f3n 11.6).\n   - **Gesti\u00f3n de Cambios**: Manejo de cambios y configuraci\u00f3n del sistema (Secci\u00f3n 11.7).\n   - **Auditor\u00edas y Revisi\u00f3n**: Actividades de reparaci\u00f3n (Secci\u00f3n 11.8), revisi\u00f3n peri\u00f3dica (Secci\u00f3n 11.9) e auditor\u00edas internas (Secci\u00f3n 11.10).\n   - **Continuidad del Negocio**: Procedimientos de respaldo y restauraci\u00f3n, continuidad del negocio y recuperaci\u00f3n ante desastres (Secci\u00f3n 11.11).\n   - **Seguridad y Administraci\u00f3n del Sistema**: Administraci\u00f3n del sistema (Secci\u00f3n 11.13).\n   - **Gesti\u00f3n de Registros**: Retenci\u00f3n, archivo y recuperaci\u00f3n de registros (Secci\u00f3n 11.14).\n\n2. **Proceso de Entrega del Sistema**: Se define como la transferencia de responsabilidad del sistema al usuario final, destacando su importancia para asegurar una transici\u00f3n exitosa a la fase operativa, m\u00e1s all\u00e1 de la conformidad y la idoneidad del uso.\n\n3. **Importancia de la Gesti\u00f3n de Incidentes y Continuidad**: Se enfatiza la necesidad de gestionar incidentes y tener planes de continuidad del negocio para mantener la operatividad del sistema en situaciones adversas.\n\nEste resumen destaca la estructura y los procedimientos necesarios para la validaci\u00f3n y operaci\u00f3n de sistemas inform\u00e1ticos seg\u00fan las directrices de ANVISA.", "excerpt_keywords": "Keywords: delivery process, system validation, formal acceptance, project responsibilities, support service management"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "01f24c7d-c222-482c-b65d-76cdf7b38555", "node_type": "4", "metadata": {"page_label": "66", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "The delivery process usually involves the project team (development group and/or supplier), the owner of the process, owner of the system and the quality unit.\n\n## 11.2.2 Key requirements\n\nThe regulated company must be able to demonstrate formal acceptance of the system after testing and controlled transfer to the operating environment of the work routine. This activity should be documented.\n\n## 11.2.3 Responsibilities\n\nThe project manager is responsible for preparing the system for delivery. The owner of the process and the owner of the system are responsible for accepting the system for operational use.\n\nResponsibility for completing any exceptional actions at the time of delivery should be agreed between the parts.\n\nConsideration should be given to defining a period for monitoring the system after its delivery and a reversal/return strategy in the event of a significant problem occurring during the monitoring period.\n\n## 11.2.4 Execution of the Delivery Activity\n\nThe company should define the scope, including configuration items, the period for delivery to occur and the acceptance criteria.\n\nThen you must establish a plan for delivery, which can be a separate document or be part of the Validation Plan. A checklist can be used to ensure acceptance and transfer of responsibilities.\n\nThe next step is to carry out the activities to deliver the system to the receiving group.\n\nAn agreement must be established between the parties for the conclusion (justified) or transfer of any open questions and incomplete activities or documentation from the design environment to the environment operational. For the delivery to be successful, critical deviations cannot persist.\n\nA report must be prepared, signed by the transferring group and the receiving group. This document may be part of the System Validation Report.\n\n## 11.3 SUPPORT SERVICE MANAGEMENT\n\n### 11.3.1 Introduction\n\nSupport Services Establishment and Management activities ensure that", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "7fb1712e6395770cc790ef4e4093e253fcdb7f65edb8fcaff87cfa682f83327b", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "The delivery process usually involves the project team (development group and/or supplier), the owner of the process, owner of the system and the quality unit.\n\n## 11.2.2 Key requirements\n\nThe regulated company must be able to demonstrate formal acceptance of the system after testing and controlled transfer to the operating environment of the work routine. This activity should be documented.\n\n## 11.2.3 Responsibilities\n\nThe project manager is responsible for preparing the system for delivery. The owner of the process and the owner of the system are responsible for accepting the system for operational use.\n\nResponsibility for completing any exceptional actions at the time of delivery should be agreed between the parts.\n\nConsideration should be given to defining a period for monitoring the system after its delivery and a reversal/return strategy in the event of a significant problem occurring during the monitoring period.\n\n## 11.2.4 Execution of the Delivery Activity\n\nThe company should define the scope, including configuration items, the period for delivery to occur and the acceptance criteria.\n\nThen you must establish a plan for delivery, which can be a separate document or be part of the Validation Plan. A checklist can be used to ensure acceptance and transfer of responsibilities.\n\nThe next step is to carry out the activities to deliver the system to the receiving group.\n\nAn agreement must be established between the parties for the conclusion (justified) or transfer of any open questions and incomplete activities or documentation from the design environment to the environment operational. For the delivery to be successful, critical deviations cannot persist.\n\nA report must be prepared, signed by the transferring group and the receiving group. This document may be part of the System Validation Report.\n\n## 11.3 SUPPORT SERVICE MANAGEMENT\n\n### 11.3.1 Introduction\n\nSupport Services Establishment and Management activities ensure that", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 1964, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "ce9faee6-937c-4f6c-817e-a14f4a1cfa9d": {"__data__": {"id_": "ce9faee6-937c-4f6c-817e-a14f4a1cfa9d", "embedding": null, "metadata": {"page_label": "67", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "support, whether internal or external, are properly specified and managed. This process is often managed through the use of **Service Level Agreements** - SLA.\n\nService management and system performance monitoring are related to managing generated records to evidence the proper operation and performance of the system. Additionally, there are potential interactions with incident management, CAPA's and change management when the results of the service or monitoring indicate that there are problems that need to be corrected.\n\nThe necessary support for each system and how it will be provided must be formally established. THE support can be provided by internal and external resources. This process should ensure that agreements for support, maintenance plans and standard operating procedures are established.\n\nService Level Agreements can be established separately for individual systems or to cover groups of similar systems (e.g., equipment in a single laboratory).\n\nIt may be useful to have a standard format for Service Level Agreements and regulated companies, in addition to a standard operating procedure to describe how to prepare an Agreement. An approach based on risk for defining content and details must be considered.\n\nService Level Agreements must be agreed, understood and approved by both the system owner and by the service provider. These agreements must unambiguously define the system whose support will be provided, defining how the service will be provided and the responsibilities of the service provider, service and the system owner.\n\nThe qualification of the service provider must be ensured and monitored through appropriate assessments, there may even be audits at the service provider.\n\n## 11.3.2 Key requirements\n\nThere must be a formal agreement with suppliers, including a clear statement of responsibilities. In this context, it is understood that suppliers, both external outsourced and other departments of the company, belong to other management structures of the company.\n\n## 11.3.3 Responsibilities\n\nIt is the responsibility of the system owner to ensure that the necessary support is identified and that the Agreement Service Level is established, followed, monitored and reported.\n\n----\n\nGuide for Computer Systems Validation\nGuide n\u00b0 33/2020 - version 1, of 03/26/2020\n\nPage 63\n\nIt is the responsibility of the system owner to ensure that the service provider is subject to the assessment of appropriate supplier.\n\nIt is the responsibility of the service provider to ensure the competence of the support staff and that they are properly trained and work in accordance with agreed procedures and the Service Level Agreement Service.\n\nIt is the responsibility of the organization providing the support service, identified in the Service Level Agreement", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos enfatiza la importancia de establecer Acuerdos de Nivel de Servicio (SLA) para la gesti\u00f3n del soporte y el rendimiento de los sistemas. Se destaca la necesidad de formalizar el soporte necesario, ya sea interno o externo, y de definir claramente las responsabilidades de los propietarios del sistema y los proveedores de servicios. Adem\u00e1s, se menciona la importancia de la evaluaci\u00f3n y auditor\u00eda de los proveedores de servicios para asegurar su competencia y el cumplimiento de los procedimientos acordados.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfQu\u00e9 elementos deben incluirse en un Acuerdo de Nivel de Servicio (SLA) para garantizar su efectividad?**\n   - El SLA debe incluir una definici\u00f3n clara del sistema que se va a soportar, c\u00f3mo se proporcionar\u00e1 el servicio, y las responsabilidades tanto del proveedor de servicios como del propietario del sistema.\n\n2. **\u00bfCu\u00e1les son las responsabilidades espec\u00edficas del propietario del sistema en relaci\u00f3n con el soporte y la gesti\u00f3n del SLA?**\n   - El propietario del sistema es responsable de identificar el soporte necesario, establecer el SLA, asegurarse de que se siga, monitorear su cumplimiento y reportar cualquier incidencia relacionada.\n\n3. **\u00bfQu\u00e9 procesos deben implementarse para evaluar la competencia de un proveedor de servicios?**\n   - Se deben llevar a cabo evaluaciones adecuadas del proveedor de servicios, que pueden incluir auditor\u00edas, para garantizar que el personal de soporte est\u00e9 capacitado y trabaje de acuerdo con los procedimientos y el SLA acordados.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\nEl documento de ANVISA sobre la Validaci\u00f3n de Sistemas Inform\u00e1ticos aborda varios aspectos cruciales del proceso de entrega de sistemas. A continuaci\u00f3n se presentan los temas clave y las entidades involucradas:\n\n#### Temas Clave\n\n1. **Proceso de Entrega**: Involucra al equipo del proyecto, el propietario del proceso, el propietario del sistema y la unidad de calidad.\n   \n2. **Requisitos Clave**: La empresa regulada debe demostrar la aceptaci\u00f3n formal del sistema tras las pruebas y la transferencia controlada al entorno operativo, lo cual debe ser documentado.\n\n3. **Responsabilidades**:\n   - **Gerente de Proyecto**: Responsable de preparar el sistema para la entrega.\n   - **Propietario del Proceso y del Sistema**: Responsables de aceptar el sistema para su uso operativo.\n   - Acuerdo sobre acciones excepcionales que deban completarse durante la entrega.\n\n4. **Monitoreo Post-Entrega**: Se debe definir un per\u00edodo de monitoreo y una estrategia de reversi\u00f3n en caso de problemas significativos.\n\n5. **Ejecuci\u00f3n de la Actividad de Entrega**:\n   - Definici\u00f3n del alcance, criterios de aceptaci\u00f3n y un plan de entrega.\n   - Uso de un checklist para asegurar la aceptaci\u00f3n y transferencia de responsabilidades.\n   - Preparaci\u00f3n de un informe firmado por ambas partes, que puede formar parte del Informe de Validaci\u00f3n del Sistema.\n\n#### Entidades Involucradas\n\n- **Equipo del Proyecto**: Grupo de desarrollo y/o proveedor.\n- **Propietario del Proceso**: Persona o entidad responsable del proceso que utiliza el sistema.\n- **Propietario del Sistema**: Persona o entidad responsable del sistema en s\u00ed.\n- **Unidad de Calidad**: Entidad encargada de asegurar la calidad del sistema y del proceso de entrega.\n\nEste resumen destaca la importancia de la documentaci\u00f3n, la claridad en las responsabilidades y la planificaci\u00f3n adecuada para asegurar una entrega exitosa y el funcionamiento del sistema en el entorno operativo.", "excerpt_keywords": "Keywords: Service Level Agreements, system support, performance monitoring, supplier assessment, responsibilities"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "b9331827-a872-41b0-9d25-cb87dbb5570c", "node_type": "4", "metadata": {"page_label": "67", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "support, whether internal or external, are properly specified and managed. This process is often managed through the use of **Service Level Agreements** - SLA.\n\nService management and system performance monitoring are related to managing generated records to evidence the proper operation and performance of the system. Additionally, there are potential interactions with incident management, CAPA's and change management when the results of the service or monitoring indicate that there are problems that need to be corrected.\n\nThe necessary support for each system and how it will be provided must be formally established. THE support can be provided by internal and external resources. This process should ensure that agreements for support, maintenance plans and standard operating procedures are established.\n\nService Level Agreements can be established separately for individual systems or to cover groups of similar systems (e.g., equipment in a single laboratory).\n\nIt may be useful to have a standard format for Service Level Agreements and regulated companies, in addition to a standard operating procedure to describe how to prepare an Agreement. An approach based on risk for defining content and details must be considered.\n\nService Level Agreements must be agreed, understood and approved by both the system owner and by the service provider. These agreements must unambiguously define the system whose support will be provided, defining how the service will be provided and the responsibilities of the service provider, service and the system owner.\n\nThe qualification of the service provider must be ensured and monitored through appropriate assessments, there may even be audits at the service provider.\n\n## 11.3.2 Key requirements\n\nThere must be a formal agreement with suppliers, including a clear statement of responsibilities. In this context, it is understood that suppliers, both external outsourced and other departments of the company, belong to other management structures of the company.\n\n## 11.3.3 Responsibilities\n\nIt is the responsibility of the system owner to ensure that the necessary support is identified and that the Agreement Service Level is established, followed, monitored and reported.\n\n----\n\nGuide for Computer Systems Validation\nGuide n\u00b0 33/2020 - version 1, of 03/26/2020\n\nPage 63\n\nIt is the responsibility of the system owner to ensure that the service provider is subject to the assessment of appropriate supplier.\n\nIt is the responsibility of the service provider to ensure the competence of the support staff and that they are properly trained and work in accordance with agreed procedures and the Service Level Agreement Service.\n\nIt is the responsibility of the organization providing the support service, identified in the Service Level Agreement", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "869ec5974787f19c6c122483c97c8013714df87281993d28e4d71917a9c8113d", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "support, whether internal or external, are properly specified and managed. This process is often managed through the use of **Service Level Agreements** - SLA.\n\nService management and system performance monitoring are related to managing generated records to evidence the proper operation and performance of the system. Additionally, there are potential interactions with incident management, CAPA's and change management when the results of the service or monitoring indicate that there are problems that need to be corrected.\n\nThe necessary support for each system and how it will be provided must be formally established. THE support can be provided by internal and external resources. This process should ensure that agreements for support, maintenance plans and standard operating procedures are established.\n\nService Level Agreements can be established separately for individual systems or to cover groups of similar systems (e.g., equipment in a single laboratory).\n\nIt may be useful to have a standard format for Service Level Agreements and regulated companies, in addition to a standard operating procedure to describe how to prepare an Agreement. An approach based on risk for defining content and details must be considered.\n\nService Level Agreements must be agreed, understood and approved by both the system owner and by the service provider. These agreements must unambiguously define the system whose support will be provided, defining how the service will be provided and the responsibilities of the service provider, service and the system owner.\n\nThe qualification of the service provider must be ensured and monitored through appropriate assessments, there may even be audits at the service provider.\n\n## 11.3.2 Key requirements\n\nThere must be a formal agreement with suppliers, including a clear statement of responsibilities. In this context, it is understood that suppliers, both external outsourced and other departments of the company, belong to other management structures of the company.\n\n## 11.3.3 Responsibilities\n\nIt is the responsibility of the system owner to ensure that the necessary support is identified and that the Agreement Service Level is established, followed, monitored and reported.\n\n----\n\nGuide for Computer Systems Validation\nGuide n\u00b0 33/2020 - version 1, of 03/26/2020\n\nPage 63\n\nIt is the responsibility of the system owner to ensure that the service provider is subject to the assessment of appropriate supplier.\n\nIt is the responsibility of the service provider to ensure the competence of the support staff and that they are properly trained and work in accordance with agreed procedures and the Service Level Agreement Service.\n\nIt is the responsibility of the organization providing the support service, identified in the Service Level Agreement", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 2797, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "69ed7cb5-c79a-4cae-843d-85114f0db572": {"__data__": {"id_": "69ed7cb5-c79a-4cae-843d-85114f0db572", "embedding": null, "metadata": {"page_label": "68", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 11.3.4 Execution of Activities\n\nThe support service management activity involves performing the following actions, in this order:\n\n- First, support needs are identified.\n- Following is the evaluation and selection of the support service provider(s).\n- The next step is the establishment of the Service Level Agreement.\n- The next step involves establishing the standard operating procedures to support the system.\n- From then on, the Quality and Performance of the system are monitored, through audits or performance checks.\n\nIf the support contract does not meet expectations, it must be terminated.\n\n# 11.4 MONITORING SYSTEM PERFORMANCE\n\n## 11.4.1 Introduction\n\nThe impact of a computer system failure will vary depending on its criticality. When appropriate, system performance must be monitored so that problems can be detected timely. This activity allows the user to anticipate the occurrence of failures, through the use of monitoring tools and techniques.\n\nPerformance monitoring is part of a general preventive maintenance program that aims to purpose of acquiring performance data that is useful for diagnosing system problems. THE monitoring can indicate trends that can indicate performance problems and that can be used as part of corrective and preventive actions (CAPA) to reduce application downtime or system.\n\nPerformance Monitoring Plans are system specific. However, it may be practical to develop a Standard Operating Procedure on how to prepare these plans and develop some parameters generic monitoring.\n\nThe level of detail of the monitoring plan will depend on the associated risk, the complexity and the system innovation. It may not be necessary to develop monitoring plans for simple and low risk, which may be covered by some other document.\n\nPerformance Monitoring Plans can be integrated with the Service Level Agreements discussed in section 11.3.1.\n\nPerformance monitoring can be an automatic or manual process, or even a combination of both.\n\nPerformance monitoring records should be subject to periodic internal audit.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos detalla los procedimientos para la gesti\u00f3n de servicios de soporte y la monitorizaci\u00f3n del rendimiento del sistema. Se enfatiza la importancia de identificar necesidades de soporte, seleccionar proveedores adecuados, establecer acuerdos de nivel de servicio y desarrollar procedimientos operativos est\u00e1ndar. Adem\u00e1s, se aborda la monitorizaci\u00f3n del rendimiento del sistema como parte de un programa de mantenimiento preventivo, destacando la necesidad de planes de monitorizaci\u00f3n espec\u00edficos y su integraci\u00f3n con los acuerdos de nivel de servicio.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfCu\u00e1les son los pasos espec\u00edficos que se deben seguir para gestionar un servicio de soporte seg\u00fan el documento de ANVISA?**\n   - El documento detalla cinco pasos: identificaci\u00f3n de necesidades de soporte, evaluaci\u00f3n y selecci\u00f3n de proveedores, establecimiento de un Acuerdo de Nivel de Servicio, desarrollo de procedimientos operativos est\u00e1ndar y monitoreo de la calidad y rendimiento del sistema.\n\n2. **\u00bfQu\u00e9 factores determinan el nivel de detalle que debe tener un Plan de Monitoreo del Rendimiento?**\n   - El nivel de detalle del Plan de Monitoreo depende del riesgo asociado, la complejidad del sistema y la innovaci\u00f3n del mismo. Para sistemas simples y de bajo riesgo, puede no ser necesario desarrollar un plan de monitoreo detallado.\n\n3. **\u00bfC\u00f3mo se integran los Planes de Monitoreo del Rendimiento con los Acuerdos de Nivel de Servicio?**\n   - Los Planes de Monitoreo del Rendimiento pueden ser integrados con los Acuerdos de Nivel de Servicio, lo que permite una evaluaci\u00f3n m\u00e1s efectiva del rendimiento del sistema en relaci\u00f3n con las expectativas establecidas en el acuerdo.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Acuerdos de Nivel de Servicio (SLA)**:\n   - Importancia de establecer SLA para la gesti\u00f3n del soporte y rendimiento de sistemas inform\u00e1ticos.\n   - Los SLA deben definir claramente el sistema a soportar, c\u00f3mo se proporcionar\u00e1 el servicio y las responsabilidades de las partes involucradas.\n\n2. **Soporte y Recursos**:\n   - El soporte puede ser interno o externo y debe ser formalmente establecido.\n   - Es necesario contar con planes de mantenimiento y procedimientos operativos est\u00e1ndar.\n\n3. **Responsabilidades**:\n   - **Propietario del Sistema**: Identificar el soporte necesario, establecer y monitorear el SLA, y asegurar que se sigan los procedimientos acordados.\n   - **Proveedor de Servicios**: Asegurar la competencia del personal de soporte y que trabajen conforme a los procedimientos y SLA establecidos.\n\n4. **Evaluaci\u00f3n de Proveedores**:\n   - Se deben realizar evaluaciones y auditor\u00edas para garantizar la competencia del proveedor de servicios.\n\n5. **Interacciones con Otros Procesos**:\n   - Los SLA pueden interactuar con la gesti\u00f3n de incidentes, CAPA (Acciones Correctivas y Preventivas) y gesti\u00f3n de cambios.\n\n### Entidades Clave\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil, responsable de la regulaci\u00f3n.\n- **SLA (Service Level Agreement)**: Acuerdo formal que define el nivel de servicio esperado.\n- **Propietario del Sistema**: Persona o entidad responsable del sistema inform\u00e1tico.\n- **Proveedor de Servicios**: Entidad que proporciona soporte y mantenimiento al sistema.\n- **Auditor\u00edas**: Proceso de evaluaci\u00f3n para asegurar el cumplimiento y competencia del proveedor.\n\nEste resumen destaca la importancia de la formalizaci\u00f3n y gesti\u00f3n de los SLA en el contexto de la validaci\u00f3n de sistemas inform\u00e1ticos, as\u00ed como las responsabilidades y procesos necesarios para asegurar un soporte efectivo.", "excerpt_keywords": "Keywords: ANVISA, Computer Systems Validation, Service Level Agreement, Performance Monitoring, Support Service Management"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "66204439-cfae-441a-bd32-67eb98c3eb93", "node_type": "4", "metadata": {"page_label": "68", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 11.3.4 Execution of Activities\n\nThe support service management activity involves performing the following actions, in this order:\n\n- First, support needs are identified.\n- Following is the evaluation and selection of the support service provider(s).\n- The next step is the establishment of the Service Level Agreement.\n- The next step involves establishing the standard operating procedures to support the system.\n- From then on, the Quality and Performance of the system are monitored, through audits or performance checks.\n\nIf the support contract does not meet expectations, it must be terminated.\n\n# 11.4 MONITORING SYSTEM PERFORMANCE\n\n## 11.4.1 Introduction\n\nThe impact of a computer system failure will vary depending on its criticality. When appropriate, system performance must be monitored so that problems can be detected timely. This activity allows the user to anticipate the occurrence of failures, through the use of monitoring tools and techniques.\n\nPerformance monitoring is part of a general preventive maintenance program that aims to purpose of acquiring performance data that is useful for diagnosing system problems. THE monitoring can indicate trends that can indicate performance problems and that can be used as part of corrective and preventive actions (CAPA) to reduce application downtime or system.\n\nPerformance Monitoring Plans are system specific. However, it may be practical to develop a Standard Operating Procedure on how to prepare these plans and develop some parameters generic monitoring.\n\nThe level of detail of the monitoring plan will depend on the associated risk, the complexity and the system innovation. It may not be necessary to develop monitoring plans for simple and low risk, which may be covered by some other document.\n\nPerformance Monitoring Plans can be integrated with the Service Level Agreements discussed in section 11.3.1.\n\nPerformance monitoring can be an automatic or manual process, or even a combination of both.\n\nPerformance monitoring records should be subject to periodic internal audit.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "379fe6e4daa1d599831c4d8640d564a9329b8115917951f7121191a167fce031", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "# 11.3.4 Execution of Activities\n\nThe support service management activity involves performing the following actions, in this order:\n\n- First, support needs are identified.\n- Following is the evaluation and selection of the support service provider(s).\n- The next step is the establishment of the Service Level Agreement.\n- The next step involves establishing the standard operating procedures to support the system.\n- From then on, the Quality and Performance of the system are monitored, through audits or performance checks.\n\nIf the support contract does not meet expectations, it must be terminated.\n\n# 11.4 MONITORING SYSTEM PERFORMANCE\n\n## 11.4.1 Introduction\n\nThe impact of a computer system failure will vary depending on its criticality. When appropriate, system performance must be monitored so that problems can be detected timely. This activity allows the user to anticipate the occurrence of failures, through the use of monitoring tools and techniques.\n\nPerformance monitoring is part of a general preventive maintenance program that aims to purpose of acquiring performance data that is useful for diagnosing system problems. THE monitoring can indicate trends that can indicate performance problems and that can be used as part of corrective and preventive actions (CAPA) to reduce application downtime or system.\n\nPerformance Monitoring Plans are system specific. However, it may be practical to develop a Standard Operating Procedure on how to prepare these plans and develop some parameters generic monitoring.\n\nThe level of detail of the monitoring plan will depend on the associated risk, the complexity and the system innovation. It may not be necessary to develop monitoring plans for simple and low risk, which may be covered by some other document.\n\nPerformance Monitoring Plans can be integrated with the Service Level Agreements discussed in section 11.3.1.\n\nPerformance monitoring can be an automatic or manual process, or even a combination of both.\n\nPerformance monitoring records should be subject to periodic internal audit.", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 2055, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "238b9f03-05bb-4db8-a2e5-c6a0d548f413": {"__data__": {"id_": "238b9f03-05bb-4db8-a2e5-c6a0d548f413", "embedding": null, "metadata": {"page_label": "69", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 11.4.2 Key requirements\n\nThe need and extent of monitoring activities should be based on the system's risk to patient safety, product quality and data integrity.\n\nThe appropriate performance parameters should be defined based on the identified risks.\n\n# 11.4.3 Responsibilities\n\nIt is the responsibility of the system owner to ensure that the performance of the system is monitored and that appropriate actions are taken when necessary.\n\nIt is the responsibility of the system owner to inform the process owner and the Quality Unit about any performance issues that may impact patient safety, product and data integrity, and must also invoke Incident Management.\n\n# 11.4.4 Execution of Activities\n\nThe performance monitoring activity involves performing the following actions, in this order:\n\n- Conduct risk assessment;\n- Define the monitoring plan;\n- Start monitoring system performance, change control activities, incident and maintenance management;\n- Conduct periodic reviews and evaluations as a source of data for the Periodic Review of the system.\n\n# 11.4.5 Monitored parameters\n\nDepending on the risks to BPx of installed applications / systems and the type of computerized equipment involved, the following conditions should be checked with appropriate tools at appropriate intervals:\n\n- Servers / workstations / PCs / control systems;\n- CPU usage;\n- Use of the cache;\n- Interactive response time;\n- Number of transactions per unit of time;\n- Average waiting time at work;\n- Disk capacity utilization;\n- I / O load (Input / Output);\n- System error messages, including operating system failures and warning messages;\n- Hardware situation;\n- Existence of critical batch jobs;", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos establece directrices sobre la necesidad de monitoreo de sistemas en funci\u00f3n de los riesgos asociados a la seguridad del paciente, la calidad del producto y la integridad de los datos. Se asignan responsabilidades al propietario del sistema para garantizar el monitoreo del rendimiento y la gesti\u00f3n de incidentes. Adem\u00e1s, se detallan las actividades a realizar para el monitoreo y los par\u00e1metros que deben ser verificados en funci\u00f3n de los riesgos identificados.\n\n### Preguntas\n1. **\u00bfCu\u00e1les son las responsabilidades espec\u00edficas del propietario del sistema en relaci\u00f3n con el monitoreo del rendimiento?**\n   - El propietario del sistema es responsable de asegurar que el rendimiento del sistema sea monitoreado y de tomar acciones apropiadas cuando sea necesario. Tambi\u00e9n debe informar al propietario del proceso y a la Unidad de Calidad sobre cualquier problema de rendimiento que pueda afectar la seguridad del paciente, la calidad del producto y la integridad de los datos, adem\u00e1s de invocar la gesti\u00f3n de incidentes.\n\n2. **\u00bfQu\u00e9 pasos deben seguirse en el proceso de monitoreo del rendimiento del sistema?**\n   - El proceso de monitoreo del rendimiento del sistema debe seguir estos pasos: realizar una evaluaci\u00f3n de riesgos, definir un plan de monitoreo, comenzar a monitorear el rendimiento del sistema y las actividades de control de cambios, gestionar incidentes y mantenimiento, y realizar revisiones y evaluaciones peri\u00f3dicas como fuente de datos para la revisi\u00f3n peri\u00f3dica del sistema.\n\n3. **\u00bfQu\u00e9 par\u00e1metros espec\u00edficos deben ser monitoreados y por qu\u00e9 son importantes?**\n   - Los par\u00e1metros que deben ser monitoreados incluyen el uso de CPU, el tiempo de respuesta interactivo, el n\u00famero de transacciones por unidad de tiempo, la utilizaci\u00f3n de la capacidad del disco, y los mensajes de error del sistema, entre otros. Estos par\u00e1metros son importantes porque ayudan a identificar problemas que pueden afectar la seguridad del paciente, la calidad del producto y la integridad de los datos, permitiendo as\u00ed tomar acciones correctivas a tiempo.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n#### Temas Clave\n\n1. **Gesti\u00f3n de Servicios de Soporte**:\n   - Identificaci\u00f3n de necesidades de soporte.\n   - Evaluaci\u00f3n y selecci\u00f3n de proveedores de servicios de soporte.\n   - Establecimiento de Acuerdos de Nivel de Servicio (SLA).\n   - Desarrollo de procedimientos operativos est\u00e1ndar.\n   - Monitoreo de la calidad y rendimiento del sistema.\n\n2. **Monitoreo del Rendimiento del Sistema**:\n   - Importancia de la monitorizaci\u00f3n para detectar problemas a tiempo.\n   - Integraci\u00f3n de la monitorizaci\u00f3n en un programa de mantenimiento preventivo.\n   - Desarrollo de Planes de Monitoreo del Rendimiento espec\u00edficos para cada sistema.\n   - Dependencia del nivel de detalle del plan en el riesgo, complejidad e innovaci\u00f3n del sistema.\n   - Posibilidad de que la monitorizaci\u00f3n sea autom\u00e1tica, manual o una combinaci\u00f3n de ambas.\n   - Sujeci\u00f3n de los registros de monitoreo a auditor\u00edas internas peri\u00f3dicas.\n\n#### Entidades\n\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil, responsable de la regulaci\u00f3n y supervisi\u00f3n de la salud p\u00fablica.\n- **Acuerdo de Nivel de Servicio (SLA)**: Contrato que define el nivel esperado de servicio entre el proveedor y el cliente.\n- **Planes de Monitoreo del Rendimiento**: Documentos que establecen c\u00f3mo se llevar\u00e1 a cabo la monitorizaci\u00f3n del rendimiento del sistema.\n- **CAPA (Corrective and Preventive Actions)**: Acciones correctivas y preventivas para abordar problemas identificados en el rendimiento del sistema.\n\nEste resumen destaca la importancia de una gesti\u00f3n adecuada de los servicios de soporte y la monitorizaci\u00f3n del rendimiento del sistema para garantizar la eficacia y la continuidad operativa en el contexto de la validaci\u00f3n de sistemas inform\u00e1ticos.", "excerpt_keywords": "Keywords: monitoring, system performance, patient safety, data integrity, risk assessment"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "7cfc95ef-0d04-4e28-b51e-9bf255e21649", "node_type": "4", "metadata": {"page_label": "69", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 11.4.2 Key requirements\n\nThe need and extent of monitoring activities should be based on the system's risk to patient safety, product quality and data integrity.\n\nThe appropriate performance parameters should be defined based on the identified risks.\n\n# 11.4.3 Responsibilities\n\nIt is the responsibility of the system owner to ensure that the performance of the system is monitored and that appropriate actions are taken when necessary.\n\nIt is the responsibility of the system owner to inform the process owner and the Quality Unit about any performance issues that may impact patient safety, product and data integrity, and must also invoke Incident Management.\n\n# 11.4.4 Execution of Activities\n\nThe performance monitoring activity involves performing the following actions, in this order:\n\n- Conduct risk assessment;\n- Define the monitoring plan;\n- Start monitoring system performance, change control activities, incident and maintenance management;\n- Conduct periodic reviews and evaluations as a source of data for the Periodic Review of the system.\n\n# 11.4.5 Monitored parameters\n\nDepending on the risks to BPx of installed applications / systems and the type of computerized equipment involved, the following conditions should be checked with appropriate tools at appropriate intervals:\n\n- Servers / workstations / PCs / control systems;\n- CPU usage;\n- Use of the cache;\n- Interactive response time;\n- Number of transactions per unit of time;\n- Average waiting time at work;\n- Disk capacity utilization;\n- I / O load (Input / Output);\n- System error messages, including operating system failures and warning messages;\n- Hardware situation;\n- Existence of critical batch jobs;", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "abd58a8503312ea50917a15734d6917afec58b96e02806a7847c4eae578e7f36", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "# 11.4.2 Key requirements\n\nThe need and extent of monitoring activities should be based on the system's risk to patient safety, product quality and data integrity.\n\nThe appropriate performance parameters should be defined based on the identified risks.\n\n# 11.4.3 Responsibilities\n\nIt is the responsibility of the system owner to ensure that the performance of the system is monitored and that appropriate actions are taken when necessary.\n\nIt is the responsibility of the system owner to inform the process owner and the Quality Unit about any performance issues that may impact patient safety, product and data integrity, and must also invoke Incident Management.\n\n# 11.4.4 Execution of Activities\n\nThe performance monitoring activity involves performing the following actions, in this order:\n\n- Conduct risk assessment;\n- Define the monitoring plan;\n- Start monitoring system performance, change control activities, incident and maintenance management;\n- Conduct periodic reviews and evaluations as a source of data for the Periodic Review of the system.\n\n# 11.4.5 Monitored parameters\n\nDepending on the risks to BPx of installed applications / systems and the type of computerized equipment involved, the following conditions should be checked with appropriate tools at appropriate intervals:\n\n- Servers / workstations / PCs / control systems;\n- CPU usage;\n- Use of the cache;\n- Interactive response time;\n- Number of transactions per unit of time;\n- Average waiting time at work;\n- Disk capacity utilization;\n- I / O load (Input / Output);\n- System error messages, including operating system failures and warning messages;\n- Hardware situation;\n- Existence of critical batch jobs;", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 1684, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "2eed0715-580b-4181-a143-00769b3b5d95": {"__data__": {"id_": "2eed0715-580b-4181-a143-00769b3b5d95", "embedding": null, "metadata": {"page_label": "70", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "- Existence of critical processes;\n- Availability of printer queues;\n- Alarms;\n- Networks;\n- Component availability (server, router, etc.);\n- Network load (eg, number of collisions);\n- Transmissions;\n- Applications;\n- Monitoring of error messages;\n- Response times;\n- Number of concurrent users;\n- General system availability for users.\n\n**NOTE:** The parameters mentioned above are only examples and not a complete list.\n\n## 11.4.6 Notification Mechanisms\n\nDepending on the risk associated with the monitored parameter, mechanisms such as one or more described below must be used to notify the main stakeholders about the exception conditions that have occurred:\n\n- System console message;\n- E-mail to the system operator;\n- E-mail to external service providers;\n- Printed lists or records;\n- Visual or audible alarms.\n\n## 11.4.7 Structure of the Monitoring Plan\n\nThe monitoring plan should cover the following areas:\n\n- Monitored parameters;\n- Alert limits;\n- Observation frequency;\n- Monitoring tool;\n- Notification mechanism and person / system to be informed;\n- Documentation of monitoring results;\n- Results storage / retention period;\n\nIt is recommended to use a tabular format for plan documentation.\n\n## 11.4.8 Review of the Monitoring Plan\n\nThe following items should be checked during the review of the monitoring plan:\n\n- Whether the appropriate parameters and components are monitored;\n- Whether the risks determined in the risk analysis are adequately addressed;", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos establece directrices para el monitoreo de par\u00e1metros cr\u00edticos en sistemas. Se detallan los mecanismos de notificaci\u00f3n que deben implementarse en funci\u00f3n del riesgo asociado a los par\u00e1metros monitoreados. Adem\u00e1s, se sugiere una estructura para el plan de monitoreo y se indican los elementos que deben revisarse durante su evaluaci\u00f3n.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfCu\u00e1les son algunos ejemplos de par\u00e1metros que deben ser monitoreados seg\u00fan el documento de ANVISA?**\n   - El documento menciona par\u00e1metros como la existencia de procesos cr\u00edticos, disponibilidad de colas de impresi\u00f3n, carga de red, tiempos de respuesta y n\u00famero de usuarios concurrentes, entre otros.\n\n2. **\u00bfQu\u00e9 mecanismos de notificaci\u00f3n se recomiendan para informar a las partes interesadas sobre condiciones excepcionales?**\n   - Se sugieren mecanismos como mensajes en la consola del sistema, correos electr\u00f3nicos al operador del sistema y proveedores de servicios externos, listas impresas, y alarmas visuales o audibles.\n\n3. **\u00bfQu\u00e9 elementos deben ser revisados durante la evaluaci\u00f3n del plan de monitoreo?**\n   - Durante la revisi\u00f3n del plan, se debe verificar si se est\u00e1n monitoreando los par\u00e1metros y componentes adecuados y si los riesgos identificados en el an\u00e1lisis de riesgos est\u00e1n siendo abordados de manera adecuada.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Monitoreo de Sistemas**: La necesidad y el alcance de las actividades de monitoreo deben basarse en los riesgos que el sistema representa para la seguridad del paciente, la calidad del producto y la integridad de los datos.\n\n2. **Responsabilidades del Propietario del Sistema**: \n   - Asegurar el monitoreo del rendimiento del sistema.\n   - Informar sobre problemas de rendimiento que puedan afectar la seguridad del paciente y la calidad del producto.\n   - Invocar la gesti\u00f3n de incidentes cuando sea necesario.\n\n3. **Actividades de Ejecuci\u00f3n**: El monitoreo del rendimiento del sistema implica:\n   - Realizar una evaluaci\u00f3n de riesgos.\n   - Definir un plan de monitoreo.\n   - Iniciar el monitoreo del rendimiento del sistema y gestionar incidentes y mantenimiento.\n   - Realizar revisiones y evaluaciones peri\u00f3dicas.\n\n4. **Par\u00e1metros a Monitorear**: Los par\u00e1metros que deben ser verificados incluyen:\n   - Uso de CPU.\n   - Tiempo de respuesta interactivo.\n   - N\u00famero de transacciones por unidad de tiempo.\n   - Utilizaci\u00f3n de la capacidad del disco.\n   - Mensajes de error del sistema, entre otros.\n\n### Entidades Clave\n- **Sistema**: Se refiere a los sistemas inform\u00e1ticos que requieren monitoreo.\n- **Propietario del Sistema**: La persona o entidad responsable del sistema.\n- **Unidad de Calidad**: Entidad que debe ser informada sobre problemas de rendimiento.\n- **Gesti\u00f3n de Incidentes**: Proceso que debe ser invocado ante problemas de rendimiento.\n- **Par\u00e1metros de Rendimiento**: Indicadores que se deben monitorear para asegurar la integridad y calidad del sistema.\n\nEste resumen destaca la importancia del monitoreo sistem\u00e1tico y la asignaci\u00f3n de responsabilidades para garantizar la seguridad y calidad en el uso de sistemas inform\u00e1ticos en el contexto de la salud y la industria.", "excerpt_keywords": "Keywords: monitoring, notification mechanisms, risk analysis, system validation, performance parameters"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "6b0aca27-3ab2-41f1-8fe6-2b87e39665db", "node_type": "4", "metadata": {"page_label": "70", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "- Existence of critical processes;\n- Availability of printer queues;\n- Alarms;\n- Networks;\n- Component availability (server, router, etc.);\n- Network load (eg, number of collisions);\n- Transmissions;\n- Applications;\n- Monitoring of error messages;\n- Response times;\n- Number of concurrent users;\n- General system availability for users.\n\n**NOTE:** The parameters mentioned above are only examples and not a complete list.\n\n## 11.4.6 Notification Mechanisms\n\nDepending on the risk associated with the monitored parameter, mechanisms such as one or more described below must be used to notify the main stakeholders about the exception conditions that have occurred:\n\n- System console message;\n- E-mail to the system operator;\n- E-mail to external service providers;\n- Printed lists or records;\n- Visual or audible alarms.\n\n## 11.4.7 Structure of the Monitoring Plan\n\nThe monitoring plan should cover the following areas:\n\n- Monitored parameters;\n- Alert limits;\n- Observation frequency;\n- Monitoring tool;\n- Notification mechanism and person / system to be informed;\n- Documentation of monitoring results;\n- Results storage / retention period;\n\nIt is recommended to use a tabular format for plan documentation.\n\n## 11.4.8 Review of the Monitoring Plan\n\nThe following items should be checked during the review of the monitoring plan:\n\n- Whether the appropriate parameters and components are monitored;\n- Whether the risks determined in the risk analysis are adequately addressed;", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "4e92afa602e666c9ef8cb787d47f1043e9211e48f5be48642fcd37f8a2550d31", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "- Existence of critical processes;\n- Availability of printer queues;\n- Alarms;\n- Networks;\n- Component availability (server, router, etc.);\n- Network load (eg, number of collisions);\n- Transmissions;\n- Applications;\n- Monitoring of error messages;\n- Response times;\n- Number of concurrent users;\n- General system availability for users.\n\n**NOTE:** The parameters mentioned above are only examples and not a complete list.\n\n## 11.4.6 Notification Mechanisms\n\nDepending on the risk associated with the monitored parameter, mechanisms such as one or more described below must be used to notify the main stakeholders about the exception conditions that have occurred:\n\n- System console message;\n- E-mail to the system operator;\n- E-mail to external service providers;\n- Printed lists or records;\n- Visual or audible alarms.\n\n## 11.4.7 Structure of the Monitoring Plan\n\nThe monitoring plan should cover the following areas:\n\n- Monitored parameters;\n- Alert limits;\n- Observation frequency;\n- Monitoring tool;\n- Notification mechanism and person / system to be informed;\n- Documentation of monitoring results;\n- Results storage / retention period;\n\nIt is recommended to use a tabular format for plan documentation.\n\n## 11.4.8 Review of the Monitoring Plan\n\nThe following items should be checked during the review of the monitoring plan:\n\n- Whether the appropriate parameters and components are monitored;\n- Whether the risks determined in the risk analysis are adequately addressed;", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 1476, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "47e1db0f-5738-4dc3-82fe-5f9ae6ab018e": {"__data__": {"id_": "47e1db0f-5738-4dc3-82fe-5f9ae6ab018e", "embedding": null, "metadata": {"page_label": "71", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "- Whether the time intervals and alert limits for the monitored parameters are adequate;\n- Whether notification methods are used and allow for timely alerting;\n- Whether the results of monitoring are safely retained.\n\n## 11.5 INCIDENT MANAGEMENT\n\n### 11.5.1 Introduction\n\nThe incident management process aims to categorize incidents in order to target them for a timely resolution.\n\nThere should be a procedure defining how problems related to *software*, *hardware* and Operational procedures will be captured, reviewed, prioritized, rolled out, sized and completed.\n\nThe primary objective of Incident Management is to ensure that any unplanned deviations that impact on patient safety, product quality or data integrity resolved before causing damage.\n\nIncident Management must be designed so that the system / application / service is returned to the user as quickly as possible. This process / procedure is usually somewhat generic and can be applied to all systems.\n\nIncidents should be assessed taking into account any impact on patient safety, product quality and data integrity. The Quality Unit should be consulted to assist in the definition of the acceptance criteria to be used in this assessment and to assist in the assessment of the incident.\n\n### 11.5.2 Key requirements\n\nThe incident management process should ensure that operational events that are not part of the standard operations (eg, deviations, problems and errors) are identified, evaluated, resolved and completed in a timely manner. These activities must be documented.\n\n### 11.5.3 Responsibilities\n\nIt is the responsibility of the process owner to ensure that the incident management process and the procedure are established to support the system.\n\nIt is the responsibility of the subject matter specialist (SME) to assess incidents and consult the Quality on those that impact patient safety, product quality or data integrity and take appropriate corrective actions.\n\nIt is the responsibility of the system owner to ensure that incidents are resolved and completed when applicable.\n\nIt is the responsibility of the Quality Unit to ensure that the procedures associated with management incidents are followed and that appropriate actions have been taken and documented.\n\n### 11.5.4 Execution of Activities", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas que se pueden responder espec\u00edficamente con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos establece un proceso de gesti\u00f3n de incidentes que tiene como objetivo categorizar y resolver incidentes relacionados con software, hardware y procedimientos operativos. Este proceso es crucial para garantizar la seguridad del paciente, la calidad del producto y la integridad de los datos. Se definen responsabilidades claras para los propietarios de procesos, especialistas en la materia y unidades de calidad, y se enfatiza la necesidad de documentar todas las actividades relacionadas con la gesti\u00f3n de incidentes.\n\n### Preguntas\n1. **\u00bfCu\u00e1les son los criterios de aceptaci\u00f3n que deben considerarse al evaluar un incidente relacionado con la seguridad del paciente?**\n   - El contexto menciona que la Unidad de Calidad debe ser consultada para ayudar en la definici\u00f3n de los criterios de aceptaci\u00f3n utilizados en la evaluaci\u00f3n de incidentes que impactan la seguridad del paciente, la calidad del producto o la integridad de los datos.\n\n2. **\u00bfQu\u00e9 pasos deben seguirse para documentar un incidente en el proceso de gesti\u00f3n de incidentes?**\n   - El documento establece que las actividades relacionadas con la identificaci\u00f3n, evaluaci\u00f3n, resoluci\u00f3n y finalizaci\u00f3n de eventos operativos no est\u00e1ndar deben ser documentadas, aunque no se detallan los pasos espec\u00edficos en el texto proporcionado.\n\n3. **\u00bfQu\u00e9 papel juega la Unidad de Calidad en el proceso de gesti\u00f3n de incidentes?**\n   - La Unidad de Calidad es responsable de asegurar que se sigan los procedimientos asociados con la gesti\u00f3n de incidentes y que se tomen y documenten las acciones apropiadas, lo que resalta su importancia en el proceso de gesti\u00f3n de incidentes.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos aborda varios aspectos cr\u00edticos relacionados con el monitoreo de sistemas. A continuaci\u00f3n se presentan los temas clave y las entidades mencionadas en la secci\u00f3n:\n\n1. **Par\u00e1metros a Monitorear**:\n   - Procesos cr\u00edticos\n   - Disponibilidad de colas de impresi\u00f3n\n   - Alarmas\n   - Redes\n   - Disponibilidad de componentes (servidores, routers, etc.)\n   - Carga de red (n\u00famero de colisiones)\n   - Transmisiones\n   - Aplicaciones\n   - Monitoreo de mensajes de error\n   - Tiempos de respuesta\n   - N\u00famero de usuarios concurrentes\n   - Disponibilidad general del sistema para los usuarios\n\n2. **Mecanismos de Notificaci\u00f3n**:\n   - Mensajes en la consola del sistema\n   - Correos electr\u00f3nicos al operador del sistema\n   - Correos electr\u00f3nicos a proveedores de servicios externos\n   - Listas o registros impresos\n   - Alarmas visuales o audibles\n\n3. **Estructura del Plan de Monitoreo**:\n   - Par\u00e1metros monitoreados\n   - L\u00edmites de alerta\n   - Frecuencia de observaci\u00f3n\n   - Herramienta de monitoreo\n   - Mecanismo de notificaci\u00f3n y personas/sistemas a informar\n   - Documentaci\u00f3n de resultados de monitoreo\n   - Almacenamiento de resultados/per\u00edodo de retenci\u00f3n\n\n4. **Revisi\u00f3n del Plan de Monitoreo**:\n   - Verificaci\u00f3n de par\u00e1metros y componentes adecuados\n   - Evaluaci\u00f3n de si los riesgos identificados en el an\u00e1lisis de riesgos est\u00e1n siendo abordados adecuadamente\n\n### Conclusi\u00f3n\nEl documento establece directrices claras para el monitoreo efectivo de sistemas inform\u00e1ticos, enfatizando la importancia de los par\u00e1metros cr\u00edticos, los mecanismos de notificaci\u00f3n y la estructura del plan de monitoreo, as\u00ed como la necesidad de revisiones peri\u00f3dicas para asegurar la efectividad del sistema.", "excerpt_keywords": "Keywords: incident management, patient safety, data integrity, quality unit, software validation"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "2719f7a0-e9c3-45cc-a0ef-7b3641bc0817", "node_type": "4", "metadata": {"page_label": "71", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "- Whether the time intervals and alert limits for the monitored parameters are adequate;\n- Whether notification methods are used and allow for timely alerting;\n- Whether the results of monitoring are safely retained.\n\n## 11.5 INCIDENT MANAGEMENT\n\n### 11.5.1 Introduction\n\nThe incident management process aims to categorize incidents in order to target them for a timely resolution.\n\nThere should be a procedure defining how problems related to *software*, *hardware* and Operational procedures will be captured, reviewed, prioritized, rolled out, sized and completed.\n\nThe primary objective of Incident Management is to ensure that any unplanned deviations that impact on patient safety, product quality or data integrity resolved before causing damage.\n\nIncident Management must be designed so that the system / application / service is returned to the user as quickly as possible. This process / procedure is usually somewhat generic and can be applied to all systems.\n\nIncidents should be assessed taking into account any impact on patient safety, product quality and data integrity. The Quality Unit should be consulted to assist in the definition of the acceptance criteria to be used in this assessment and to assist in the assessment of the incident.\n\n### 11.5.2 Key requirements\n\nThe incident management process should ensure that operational events that are not part of the standard operations (eg, deviations, problems and errors) are identified, evaluated, resolved and completed in a timely manner. These activities must be documented.\n\n### 11.5.3 Responsibilities\n\nIt is the responsibility of the process owner to ensure that the incident management process and the procedure are established to support the system.\n\nIt is the responsibility of the subject matter specialist (SME) to assess incidents and consult the Quality on those that impact patient safety, product quality or data integrity and take appropriate corrective actions.\n\nIt is the responsibility of the system owner to ensure that incidents are resolved and completed when applicable.\n\nIt is the responsibility of the Quality Unit to ensure that the procedures associated with management incidents are followed and that appropriate actions have been taken and documented.\n\n### 11.5.4 Execution of Activities", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "08ec82c893a53a4c9ab420979ffae68e2ed913d08fe2f25407788f2cd9145a7a", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "- Whether the time intervals and alert limits for the monitored parameters are adequate;\n- Whether notification methods are used and allow for timely alerting;\n- Whether the results of monitoring are safely retained.\n\n## 11.5 INCIDENT MANAGEMENT\n\n### 11.5.1 Introduction\n\nThe incident management process aims to categorize incidents in order to target them for a timely resolution.\n\nThere should be a procedure defining how problems related to *software*, *hardware* and Operational procedures will be captured, reviewed, prioritized, rolled out, sized and completed.\n\nThe primary objective of Incident Management is to ensure that any unplanned deviations that impact on patient safety, product quality or data integrity resolved before causing damage.\n\nIncident Management must be designed so that the system / application / service is returned to the user as quickly as possible. This process / procedure is usually somewhat generic and can be applied to all systems.\n\nIncidents should be assessed taking into account any impact on patient safety, product quality and data integrity. The Quality Unit should be consulted to assist in the definition of the acceptance criteria to be used in this assessment and to assist in the assessment of the incident.\n\n### 11.5.2 Key requirements\n\nThe incident management process should ensure that operational events that are not part of the standard operations (eg, deviations, problems and errors) are identified, evaluated, resolved and completed in a timely manner. These activities must be documented.\n\n### 11.5.3 Responsibilities\n\nIt is the responsibility of the process owner to ensure that the incident management process and the procedure are established to support the system.\n\nIt is the responsibility of the subject matter specialist (SME) to assess incidents and consult the Quality on those that impact patient safety, product quality or data integrity and take appropriate corrective actions.\n\nIt is the responsibility of the system owner to ensure that incidents are resolved and completed when applicable.\n\nIt is the responsibility of the Quality Unit to ensure that the procedures associated with management incidents are followed and that appropriate actions have been taken and documented.\n\n### 11.5.4 Execution of Activities", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 2286, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "f1e96510-941a-4a2f-a052-606433f5934d": {"__data__": {"id_": "f1e96510-941a-4a2f-a052-606433f5934d", "embedding": null, "metadata": {"page_label": "72", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# Incident management activities involve performing the following actions:\n\n- Identify and record the incident;\n- Assess the incident. The result of this assessment can be one of the following options: there is no need of taking action; taking action according to a pre-established procedure, forward to superior skills;\n- Problem resolution and incident report preparation;\n- Conclusion / closure of the incident.\n\n## 11.6 CORRECTIVE AND PREVENTIVE ACTIONS (COVER)\n\n### 11.6.1 Introduction\n\nCAPA activities involve the process of investigating, understanding and correcting discrepancies based on the analysis of the root cause, in order to avoid its recurrence.\n\nIn the operational environment, CAPA activities related to computerized systems must be part of CAPA's general system of activities for the other areas. When incidents occur, or when opportunities to reduce system failures are identified by other means, corrective actions and preventive measures must be identified and processes must be established to ensure that CAPA's are effectively deployed.\n\nThe CAPA process is strongly associated with the Incident Management process and the Repair.\n\nThe CAPA process is usually generic, that is, a process can be applied to all systems. THE regulated company should assess whether to maintain a CAPA record for all systems or a record for groups of similar systems or a record for each system.\n\nAny corrective or preventive action taken to eliminate the causes of actual or non-compliance potential must have a degree according to the magnitude of the problems and proportional to the risks found.\n\nCAPA's records must be subject to periodic internal audits.\n\n### 11.6.2 Key requirements\n\nThe CAPA process must cover:\n\n- Corrective actions for an identified problem or a potential problem;\n- Determining the root cause and taking corrective action to potentially prevent recurrence of a similar problem;\n- Preventive action to prevent the recurrence of a similar potential problem, when appropriate;\n- Evaluation of the effectiveness of the actions taken.\n\nA procedure should be established to record and analyze incidents and allow corrective action be taken. These activities must be documented.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas computacionales aborda la gesti\u00f3n de incidentes y el proceso de Acciones Correctivas y Preventivas (CAPA). Se describen las actividades involucradas en la gesti\u00f3n de incidentes, que incluyen la identificaci\u00f3n, evaluaci\u00f3n, resoluci\u00f3n y cierre de incidentes. Adem\u00e1s, se detalla el proceso CAPA, que implica investigar y corregir discrepancias mediante el an\u00e1lisis de la causa ra\u00edz para evitar su recurrencia. Se enfatiza la importancia de documentar estas actividades y de realizar auditor\u00edas internas peri\u00f3dicas.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfQu\u00e9 pasos deben seguirse para evaluar un incidente seg\u00fan el documento de ANVISA?**\n   - El documento establece que la evaluaci\u00f3n de un incidente puede resultar en tres opciones: no se necesita tomar acci\u00f3n, tomar acci\u00f3n de acuerdo con un procedimiento preestablecido, o remitir el incidente a habilidades superiores.\n\n2. **\u00bfC\u00f3mo debe una empresa regulada decidir sobre el mantenimiento de registros de CAPA?**\n   - La empresa regulada debe evaluar si mantener un registro de CAPA para todos los sistemas, para grupos de sistemas similares, o un registro para cada sistema individual, dependiendo de la naturaleza y el riesgo asociado a los problemas identificados.\n\n3. **\u00bfCu\u00e1les son los requisitos clave que debe cubrir el proceso CAPA seg\u00fan el documento?**\n   - El proceso CAPA debe incluir acciones correctivas para problemas identificados o potenciales, determinar la causa ra\u00edz y tomar acciones correctivas, implementar acciones preventivas cuando sea apropiado, y evaluar la efectividad de las acciones tomadas. Adem\u00e1s, se debe establecer un procedimiento para registrar y analizar incidentes.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n**Tema Principal: Gesti\u00f3n de Incidentes**\n- El proceso de gesti\u00f3n de incidentes tiene como objetivo categorizar y resolver incidentes relacionados con software, hardware y procedimientos operativos de manera oportuna.\n- Se busca garantizar la seguridad del paciente, la calidad del producto y la integridad de los datos, resolviendo desviaciones no planificadas antes de que causen da\u00f1os.\n\n**Subtemas Clave:**\n1. **Introducci\u00f3n a la Gesti\u00f3n de Incidentes:**\n   - Definici\u00f3n de procedimientos para capturar, revisar, priorizar y resolver problemas.\n   - Importancia de la r\u00e1pida recuperaci\u00f3n del sistema o servicio para el usuario.\n\n2. **Requisitos Clave:**\n   - Identificaci\u00f3n, evaluaci\u00f3n, resoluci\u00f3n y documentaci\u00f3n de eventos operativos no est\u00e1ndar (desviaciones, problemas y errores).\n\n3. **Responsabilidades:**\n   - **Propietario del Proceso:** Asegurar el establecimiento del proceso de gesti\u00f3n de incidentes.\n   - **Especialista en la Materia (SME):** Evaluar incidentes y consultar a la Unidad de Calidad sobre aquellos que impactan la seguridad del paciente, calidad del producto o integridad de datos.\n   - **Propietario del Sistema:** Asegurar la resoluci\u00f3n y finalizaci\u00f3n de incidentes.\n   - **Unidad de Calidad:** Garantizar el cumplimiento de los procedimientos de gesti\u00f3n de incidentes y la documentaci\u00f3n de acciones apropiadas.\n\n**Entidades Clave:**\n- **Unidad de Calidad:** Juega un papel crucial en la definici\u00f3n de criterios de aceptaci\u00f3n y en la evaluaci\u00f3n de incidentes.\n- **Propietario del Proceso:** Responsable de establecer el proceso de gesti\u00f3n de incidentes.\n- **Especialista en la Materia (SME):** Encargado de la evaluaci\u00f3n t\u00e9cnica de los incidentes.\n\nEste resumen destaca la importancia de un proceso estructurado para la gesti\u00f3n de incidentes en sistemas inform\u00e1ticos, enfatizando la colaboraci\u00f3n entre diferentes roles para asegurar la calidad y seguridad en el entorno operativo.", "excerpt_keywords": "Keywords: incident management, corrective actions, preventive actions, root cause analysis, CAPA process"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "33db9069-74e5-4a9d-9e86-a34c6a3907e4", "node_type": "4", "metadata": {"page_label": "72", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# Incident management activities involve performing the following actions:\n\n- Identify and record the incident;\n- Assess the incident. The result of this assessment can be one of the following options: there is no need of taking action; taking action according to a pre-established procedure, forward to superior skills;\n- Problem resolution and incident report preparation;\n- Conclusion / closure of the incident.\n\n## 11.6 CORRECTIVE AND PREVENTIVE ACTIONS (COVER)\n\n### 11.6.1 Introduction\n\nCAPA activities involve the process of investigating, understanding and correcting discrepancies based on the analysis of the root cause, in order to avoid its recurrence.\n\nIn the operational environment, CAPA activities related to computerized systems must be part of CAPA's general system of activities for the other areas. When incidents occur, or when opportunities to reduce system failures are identified by other means, corrective actions and preventive measures must be identified and processes must be established to ensure that CAPA's are effectively deployed.\n\nThe CAPA process is strongly associated with the Incident Management process and the Repair.\n\nThe CAPA process is usually generic, that is, a process can be applied to all systems. THE regulated company should assess whether to maintain a CAPA record for all systems or a record for groups of similar systems or a record for each system.\n\nAny corrective or preventive action taken to eliminate the causes of actual or non-compliance potential must have a degree according to the magnitude of the problems and proportional to the risks found.\n\nCAPA's records must be subject to periodic internal audits.\n\n### 11.6.2 Key requirements\n\nThe CAPA process must cover:\n\n- Corrective actions for an identified problem or a potential problem;\n- Determining the root cause and taking corrective action to potentially prevent recurrence of a similar problem;\n- Preventive action to prevent the recurrence of a similar potential problem, when appropriate;\n- Evaluation of the effectiveness of the actions taken.\n\nA procedure should be established to record and analyze incidents and allow corrective action be taken. These activities must be documented.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "17d02d314dbe5f498446b787a83ab2d677fb4f69c0c1c9632701f7c50544d17d", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "# Incident management activities involve performing the following actions:\n\n- Identify and record the incident;\n- Assess the incident. The result of this assessment can be one of the following options: there is no need of taking action; taking action according to a pre-established procedure, forward to superior skills;\n- Problem resolution and incident report preparation;\n- Conclusion / closure of the incident.\n\n## 11.6 CORRECTIVE AND PREVENTIVE ACTIONS (COVER)\n\n### 11.6.1 Introduction\n\nCAPA activities involve the process of investigating, understanding and correcting discrepancies based on the analysis of the root cause, in order to avoid its recurrence.\n\nIn the operational environment, CAPA activities related to computerized systems must be part of CAPA's general system of activities for the other areas. When incidents occur, or when opportunities to reduce system failures are identified by other means, corrective actions and preventive measures must be identified and processes must be established to ensure that CAPA's are effectively deployed.\n\nThe CAPA process is strongly associated with the Incident Management process and the Repair.\n\nThe CAPA process is usually generic, that is, a process can be applied to all systems. THE regulated company should assess whether to maintain a CAPA record for all systems or a record for groups of similar systems or a record for each system.\n\nAny corrective or preventive action taken to eliminate the causes of actual or non-compliance potential must have a degree according to the magnitude of the problems and proportional to the risks found.\n\nCAPA's records must be subject to periodic internal audits.\n\n### 11.6.2 Key requirements\n\nThe CAPA process must cover:\n\n- Corrective actions for an identified problem or a potential problem;\n- Determining the root cause and taking corrective action to potentially prevent recurrence of a similar problem;\n- Preventive action to prevent the recurrence of a similar potential problem, when appropriate;\n- Evaluation of the effectiveness of the actions taken.\n\nA procedure should be established to record and analyze incidents and allow corrective action be taken. These activities must be documented.", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 2205, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "aac2e433-6caf-453d-956e-4ae63fd9e42a": {"__data__": {"id_": "aac2e433-6caf-453d-956e-4ae63fd9e42a", "embedding": null, "metadata": {"page_label": "73", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "## 11.6.3 Responsibilities\n\nIt is the responsibility of the process owner to ensure that a CAPA process is implemented for the system computerized and that responsibilities are delegated to the system owner.\n\nIt is the responsibility of the Quality Unit to ensure that CAPA procedures are followed and actions appropriate measures have been taken and documented.\n\nIt is the responsibility of the subject matter specialist (SME) to ensure that the corrective and preventive actions agreed carried out and completed.\n\n## 11.6.4 Execution of Activities\n\nCAPA activities involve the following actions:\n\n1. Problem identification and registration;\n2. Determination of the emergency action to be taken;\n3. Determination of the probable root cause. This activity can start from the immediate correction of the problem. It usually involves a multidisciplinary team;\n4. Determination of Preventive Action. This action may involve Documentation Management, Change Management, Training, Support and Administration;\n5. Record of the result obtained. A rationale should be written if no action is taken.\n6. Assessment of the success of the Corrective Action and/or Preventive Action performed(s).\n\n## 11.7 MANAGING CHANGES AND SYSTEM CONFIGURATION\n\n### 11.7.1 Introduction\n\nChange management is a critical and fundamental activity for maintaining compliance with systems and processes. All changes proposed during the operational phase of the system, be they related to software, hardware, infrastructure or system usage, should be subject to a process formal change control. This process should ensure that the proposed change is adequately revised to assess the impact and risk of its implementation. The process must ensure that changes are properly evaluated, authorized, documented, tested and approved before their implementation and duly completed.\n\nSome activities such as system replacements and administrative tasks must be covered by repair and system administration processes.\n\nChange management should provide a mechanism for prompt implementation of improvements processes and systems based on periodic review and evaluation, operational and performance and analysis of the root causes of failures that occurred.\n\nConfiguration Management includes those activities necessary for the precise definition of the system computerized at any point in its life cycle, from the initial stage of development to its retirement.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos establece directrices sobre la implementaci\u00f3n de procesos de Acci\u00f3n Correctiva y Preventiva (CAPA) y la gesti\u00f3n de cambios y configuraci\u00f3n del sistema. Se detallan las responsabilidades de los propietarios de procesos, la unidad de calidad y los especialistas en la materia en relaci\u00f3n con la ejecuci\u00f3n de actividades CAPA. Adem\u00e1s, se enfatiza la importancia de un control formal de cambios para asegurar que todas las modificaciones en el sistema sean evaluadas, autorizadas y documentadas adecuadamente.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfCu\u00e1les son las responsabilidades espec\u00edficas del propietario del proceso en relaci\u00f3n con el proceso CAPA?**\n   - El propietario del proceso es responsable de asegurar que se implemente un proceso CAPA para el sistema computarizado y de delegar responsabilidades al propietario del sistema.\n\n2. **\u00bfQu\u00e9 pasos se deben seguir para llevar a cabo las actividades de CAPA seg\u00fan el documento?**\n   - Las actividades de CAPA incluyen la identificaci\u00f3n y registro del problema, determinaci\u00f3n de acciones de emergencia, identificaci\u00f3n de la causa ra\u00edz probable, determinaci\u00f3n de acciones preventivas, registro de resultados y evaluaci\u00f3n del \u00e9xito de las acciones correctivas y/o preventivas realizadas.\n\n3. **\u00bfQu\u00e9 aspectos deben considerarse en la gesti\u00f3n de cambios y configuraci\u00f3n del sistema durante su ciclo de vida?**\n   - La gesti\u00f3n de cambios debe incluir la evaluaci\u00f3n del impacto y riesgo de las modificaciones propuestas, asegurando que sean evaluadas, autorizadas, documentadas, probadas y aprobadas antes de su implementaci\u00f3n. La gesti\u00f3n de configuraci\u00f3n implica definir con precisi\u00f3n el sistema en cualquier punto de su ciclo de vida, desde el desarrollo inicial hasta su retiro.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n**1. Gesti\u00f3n de Incidentes:**\n   - **Actividades Clave:**\n     - Identificaci\u00f3n y registro del incidente.\n     - Evaluaci\u00f3n del incidente con posibles resultados: no se necesita acci\u00f3n, acci\u00f3n seg\u00fan procedimiento preestablecido, o remitir a habilidades superiores.\n     - Resoluci\u00f3n del problema y preparaci\u00f3n del informe del incidente.\n     - Cierre del incidente.\n\n**2. Acciones Correctivas y Preventivas (CAPA):**\n   - **Introducci\u00f3n:**\n     - Proceso de investigar, entender y corregir discrepancias mediante el an\u00e1lisis de la causa ra\u00edz para evitar recurrencias.\n     - Las actividades CAPA deben integrarse en el sistema general de actividades de la empresa regulada.\n     - Importancia de identificar acciones correctivas y preventivas cuando ocurren incidentes o se identifican oportunidades de mejora.\n\n   - **Requisitos Clave del Proceso CAPA:**\n     - Acciones correctivas para problemas identificados o potenciales.\n     - Determinaci\u00f3n de la causa ra\u00edz y acciones correctivas para prevenir recurrencias.\n     - Acciones preventivas para evitar la recurrencia de problemas potenciales.\n     - Evaluaci\u00f3n de la efectividad de las acciones tomadas.\n     - Establecimiento de un procedimiento para registrar y analizar incidentes.\n\n**3. Documentaci\u00f3n y Auditor\u00eda:**\n   - La documentaci\u00f3n de las actividades de gesti\u00f3n de incidentes y CAPA es esencial.\n   - Los registros de CAPA deben ser objeto de auditor\u00edas internas peri\u00f3dicas.\n\n### Entidades Clave:\n- **ANVISA:** Agencia Nacional de Vigilancia Sanitaria de Brasil.\n- **CAPA:** Acciones Correctivas y Preventivas.\n- **Incidentes:** Problemas o fallas en sistemas computacionales que requieren gesti\u00f3n y resoluci\u00f3n. \n\nEste resumen destaca la importancia de la gesti\u00f3n de incidentes y el proceso CAPA en el contexto de la validaci\u00f3n de sistemas computacionales, enfatizando la necesidad de documentaci\u00f3n y auditor\u00eda para asegurar la efectividad de las acciones tomadas.", "excerpt_keywords": "Keywords: CAPA, Change Management, System Configuration, Quality Unit, Root Cause Analysis"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "6c2cad81-9f81-4b21-bfa2-f869f258d9c9", "node_type": "4", "metadata": {"page_label": "73", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "## 11.6.3 Responsibilities\n\nIt is the responsibility of the process owner to ensure that a CAPA process is implemented for the system computerized and that responsibilities are delegated to the system owner.\n\nIt is the responsibility of the Quality Unit to ensure that CAPA procedures are followed and actions appropriate measures have been taken and documented.\n\nIt is the responsibility of the subject matter specialist (SME) to ensure that the corrective and preventive actions agreed carried out and completed.\n\n## 11.6.4 Execution of Activities\n\nCAPA activities involve the following actions:\n\n1. Problem identification and registration;\n2. Determination of the emergency action to be taken;\n3. Determination of the probable root cause. This activity can start from the immediate correction of the problem. It usually involves a multidisciplinary team;\n4. Determination of Preventive Action. This action may involve Documentation Management, Change Management, Training, Support and Administration;\n5. Record of the result obtained. A rationale should be written if no action is taken.\n6. Assessment of the success of the Corrective Action and/or Preventive Action performed(s).\n\n## 11.7 MANAGING CHANGES AND SYSTEM CONFIGURATION\n\n### 11.7.1 Introduction\n\nChange management is a critical and fundamental activity for maintaining compliance with systems and processes. All changes proposed during the operational phase of the system, be they related to software, hardware, infrastructure or system usage, should be subject to a process formal change control. This process should ensure that the proposed change is adequately revised to assess the impact and risk of its implementation. The process must ensure that changes are properly evaluated, authorized, documented, tested and approved before their implementation and duly completed.\n\nSome activities such as system replacements and administrative tasks must be covered by repair and system administration processes.\n\nChange management should provide a mechanism for prompt implementation of improvements processes and systems based on periodic review and evaluation, operational and performance and analysis of the root causes of failures that occurred.\n\nConfiguration Management includes those activities necessary for the precise definition of the system computerized at any point in its life cycle, from the initial stage of development to its retirement.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "3c3fcd0df4bd36519da696f80f90d139327c317db9a34f23e222c3017597b6b7", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "## 11.6.3 Responsibilities\n\nIt is the responsibility of the process owner to ensure that a CAPA process is implemented for the system computerized and that responsibilities are delegated to the system owner.\n\nIt is the responsibility of the Quality Unit to ensure that CAPA procedures are followed and actions appropriate measures have been taken and documented.\n\nIt is the responsibility of the subject matter specialist (SME) to ensure that the corrective and preventive actions agreed carried out and completed.\n\n## 11.6.4 Execution of Activities\n\nCAPA activities involve the following actions:\n\n1. Problem identification and registration;\n2. Determination of the emergency action to be taken;\n3. Determination of the probable root cause. This activity can start from the immediate correction of the problem. It usually involves a multidisciplinary team;\n4. Determination of Preventive Action. This action may involve Documentation Management, Change Management, Training, Support and Administration;\n5. Record of the result obtained. A rationale should be written if no action is taken.\n6. Assessment of the success of the Corrective Action and/or Preventive Action performed(s).\n\n## 11.7 MANAGING CHANGES AND SYSTEM CONFIGURATION\n\n### 11.7.1 Introduction\n\nChange management is a critical and fundamental activity for maintaining compliance with systems and processes. All changes proposed during the operational phase of the system, be they related to software, hardware, infrastructure or system usage, should be subject to a process formal change control. This process should ensure that the proposed change is adequately revised to assess the impact and risk of its implementation. The process must ensure that changes are properly evaluated, authorized, documented, tested and approved before their implementation and duly completed.\n\nSome activities such as system replacements and administrative tasks must be covered by repair and system administration processes.\n\nChange management should provide a mechanism for prompt implementation of improvements processes and systems based on periodic review and evaluation, operational and performance and analysis of the root causes of failures that occurred.\n\nConfiguration Management includes those activities necessary for the precise definition of the system computerized at any point in its life cycle, from the initial stage of development to its retirement.", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 2418, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "702231ac-75ce-4e3c-8ae9-03028151ef2e": {"__data__": {"id_": "702231ac-75ce-4e3c-8ae9-03028151ef2e", "embedding": null, "metadata": {"page_label": "74", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "A configuration item is a component of the system that is not changed as a result of an operation normal system. Configuration items can only be changed through a management process of changes. There must be formal procedures in place to identify, define and establish the items of the initial configuration and to track and record changes and releases of configuration items, including updates and packages.\n\n----\n\nGuide for Computer Systems Validation\nGuide n\u00b0 33/2020 - version 1, of 03/26/2020\n\n----\n\n# Configuration Management and Change Management\n\nConfiguration Management and Change Management are closely related. When changes are proposed, both activities need to be dealt with in parallel, particularly during the assessment of the impact of changes.\n\nBoth activities must be applied to the complete scope of the systems including the *hardware* components and *software* and associated documentation and records, particularly those with an impact on BPx.\n\n## 11.7.2 Key requirements\n\nChange management should continue until the system is retired. If the data is kept after the retired system, the management of this data must be subject to change control.\n\nAll changes must be reviewed, assessed for risk and impact, authorized, documented, tested and approved before deployment.\n\nThe *hardware* and *software* configuration must be documented throughout the system's life cycle. The level of detail should be sufficient to allow the system to be rebuilt in the event of total loss of system.\n\nTests to verify changes must be proportionate to the risk to patient safety, quality product integrity and data integrity.\n\n## 11.7.3 Responsibilities\n\nIt is the responsibility of the Process Owner to ensure that a change management and configuration is deployed.\n\nIt is the responsibility of the Quality Unit to ensure that the existing procedures for these activities followed.\n\nIt is the responsibility of each member of the team associated with each change to play their part in the correct way.\n\n## 11.7.4 Change Management\n\nThis activity follows the same guidelines followed by other areas relevant to Good Manufacturing Practices.\n\nHowever, specific processes or variations of the standard process may be necessary for the following types", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento \"Gu\u00eda para la Validaci\u00f3n de Sistemas Inform\u00e1ticos\" de ANVISA establece directrices sobre la gesti\u00f3n de configuraciones y cambios en sistemas inform\u00e1ticos, enfatizando la importancia de un proceso formal para manejar los elementos de configuraci\u00f3n. Se destaca que la gesti\u00f3n de cambios debe ser continua hasta que el sistema sea retirado, y que todos los cambios deben ser revisados, documentados y aprobados antes de su implementaci\u00f3n. Tambi\u00e9n se asignan responsabilidades espec\u00edficas a los propietarios de procesos y a la unidad de calidad para asegurar el cumplimiento de estas directrices.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfQu\u00e9 procedimientos formales deben implementarse para gestionar los elementos de configuraci\u00f3n en un sistema inform\u00e1tico seg\u00fan la gu\u00eda de ANVISA?**\n   - La gu\u00eda establece que deben existir procedimientos formales para identificar, definir y establecer los elementos de la configuraci\u00f3n inicial, as\u00ed como para rastrear y registrar cambios y versiones de los elementos de configuraci\u00f3n, incluyendo actualizaciones y paquetes.\n\n2. **\u00bfCu\u00e1les son las responsabilidades espec\u00edficas del propietario del proceso y de la unidad de calidad en la gesti\u00f3n de cambios seg\u00fan el documento?**\n   - El propietario del proceso es responsable de asegurar que se implemente la gesti\u00f3n de cambios y configuraciones, mientras que la unidad de calidad debe garantizar que se sigan los procedimientos existentes para estas actividades. Cada miembro del equipo tambi\u00e9n tiene la responsabilidad de participar correctamente en el proceso de gesti\u00f3n de cambios.\n\n3. **\u00bfC\u00f3mo se deben documentar las configuraciones de hardware y software a lo largo del ciclo de vida del sistema?**\n   - La gu\u00eda indica que la configuraci\u00f3n de hardware y software debe ser documentada durante todo el ciclo de vida del sistema, con un nivel de detalle suficiente para permitir la reconstrucci\u00f3n del sistema en caso de p\u00e9rdida total. Adem\u00e1s, las pruebas para verificar cambios deben ser proporcionales al riesgo que representan para la seguridad del paciente, la integridad del producto y la integridad de los datos.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n**1. Responsabilidades en el Proceso CAPA:**\n   - **Propietario del Proceso:** Asegura la implementaci\u00f3n del proceso CAPA y delega responsabilidades al propietario del sistema.\n   - **Unidad de Calidad:** Verifica que se sigan los procedimientos CAPA y que se tomen y documenten las medidas adecuadas.\n   - **Especialista en la Materia (SME):** Se asegura de que las acciones correctivas y preventivas acordadas se lleven a cabo y se completen.\n\n**2. Ejecuci\u00f3n de Actividades CAPA:**\n   - **Identificaci\u00f3n y Registro del Problema:** Primer paso en el proceso.\n   - **Determinaci\u00f3n de Acci\u00f3n de Emergencia:** Acciones inmediatas a tomar.\n   - **Determinaci\u00f3n de la Causa Ra\u00edz:** An\u00e1lisis para identificar la causa subyacente del problema.\n   - **Determinaci\u00f3n de Acci\u00f3n Preventiva:** Acciones que pueden incluir gesti\u00f3n de documentaci\u00f3n, gesti\u00f3n de cambios, capacitaci\u00f3n, soporte y administraci\u00f3n.\n   - **Registro de Resultados:** Documentaci\u00f3n de los resultados obtenidos y justificaci\u00f3n si no se toma ninguna acci\u00f3n.\n   - **Evaluaci\u00f3n del \u00c9xito:** An\u00e1lisis de la efectividad de las acciones correctivas y preventivas implementadas.\n\n**3. Gesti\u00f3n de Cambios y Configuraci\u00f3n del Sistema:**\n   - **Importancia de la Gesti\u00f3n de Cambios:** Fundamental para mantener la conformidad de sistemas y procesos. Todos los cambios deben pasar por un control formal.\n   - **Evaluaci\u00f3n de Impacto y Riesgo:** Asegurar que los cambios propuestos sean revisados adecuadamente.\n   - **Documentaci\u00f3n y Pruebas:** Los cambios deben ser documentados, probados y aprobados antes de su implementaci\u00f3n.\n   - **Gesti\u00f3n de Configuraci\u00f3n:** Actividades necesarias para definir con precisi\u00f3n el sistema en cualquier etapa de su ciclo de vida, desde el desarrollo hasta el retiro.\n\n### Entidades Clave\n- **CAPA (Acci\u00f3n Correctiva y Preventiva)**\n- **Propietario del Proceso**\n- **Unidad de Calidad**\n- **Especialista en la Materia (SME)**\n- **Gesti\u00f3n de Cambios**\n- **Gesti\u00f3n de Configuraci\u00f3n**\n- **Causa Ra\u00edz**\n- **Documentaci\u00f3n**\n- **Evaluaci\u00f3n de Impacto y Riesgo** \n\nEste resumen destaca las responsabilidades, procesos y la importancia de la gesti\u00f3n de cambios y configuraci\u00f3n en el contexto de la validaci\u00f3n de sistemas inform\u00e1ticos seg\u00fan las directrices de ANVISA.", "excerpt_keywords": "Keywords: configuration management, change management, validation, risk assessment, documentation"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "385c48b4-1acd-4629-a46a-25fac43ae31f", "node_type": "4", "metadata": {"page_label": "74", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "A configuration item is a component of the system that is not changed as a result of an operation normal system. Configuration items can only be changed through a management process of changes. There must be formal procedures in place to identify, define and establish the items of the initial configuration and to track and record changes and releases of configuration items, including updates and packages.\n\n----\n\nGuide for Computer Systems Validation\nGuide n\u00b0 33/2020 - version 1, of 03/26/2020\n\n----\n\n# Configuration Management and Change Management\n\nConfiguration Management and Change Management are closely related. When changes are proposed, both activities need to be dealt with in parallel, particularly during the assessment of the impact of changes.\n\nBoth activities must be applied to the complete scope of the systems including the *hardware* components and *software* and associated documentation and records, particularly those with an impact on BPx.\n\n## 11.7.2 Key requirements\n\nChange management should continue until the system is retired. If the data is kept after the retired system, the management of this data must be subject to change control.\n\nAll changes must be reviewed, assessed for risk and impact, authorized, documented, tested and approved before deployment.\n\nThe *hardware* and *software* configuration must be documented throughout the system's life cycle. The level of detail should be sufficient to allow the system to be rebuilt in the event of total loss of system.\n\nTests to verify changes must be proportionate to the risk to patient safety, quality product integrity and data integrity.\n\n## 11.7.3 Responsibilities\n\nIt is the responsibility of the Process Owner to ensure that a change management and configuration is deployed.\n\nIt is the responsibility of the Quality Unit to ensure that the existing procedures for these activities followed.\n\nIt is the responsibility of each member of the team associated with each change to play their part in the correct way.\n\n## 11.7.4 Change Management\n\nThis activity follows the same guidelines followed by other areas relevant to Good Manufacturing Practices.\n\nHowever, specific processes or variations of the standard process may be necessary for the following types", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "46c3f0c81e42eb20cc8d672466cf077a13ca1a282cf6366f6cfdbe39ac555f3d", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "A configuration item is a component of the system that is not changed as a result of an operation normal system. Configuration items can only be changed through a management process of changes. There must be formal procedures in place to identify, define and establish the items of the initial configuration and to track and record changes and releases of configuration items, including updates and packages.\n\n----\n\nGuide for Computer Systems Validation\nGuide n\u00b0 33/2020 - version 1, of 03/26/2020\n\n----\n\n# Configuration Management and Change Management\n\nConfiguration Management and Change Management are closely related. When changes are proposed, both activities need to be dealt with in parallel, particularly during the assessment of the impact of changes.\n\nBoth activities must be applied to the complete scope of the systems including the *hardware* components and *software* and associated documentation and records, particularly those with an impact on BPx.\n\n## 11.7.2 Key requirements\n\nChange management should continue until the system is retired. If the data is kept after the retired system, the management of this data must be subject to change control.\n\nAll changes must be reviewed, assessed for risk and impact, authorized, documented, tested and approved before deployment.\n\nThe *hardware* and *software* configuration must be documented throughout the system's life cycle. The level of detail should be sufficient to allow the system to be rebuilt in the event of total loss of system.\n\nTests to verify changes must be proportionate to the risk to patient safety, quality product integrity and data integrity.\n\n## 11.7.3 Responsibilities\n\nIt is the responsibility of the Process Owner to ensure that a change management and configuration is deployed.\n\nIt is the responsibility of the Quality Unit to ensure that the existing procedures for these activities followed.\n\nIt is the responsibility of each member of the team associated with each change to play their part in the correct way.\n\n## 11.7.4 Change Management\n\nThis activity follows the same guidelines followed by other areas relevant to Good Manufacturing Practices.\n\nHowever, specific processes or variations of the standard process may be necessary for the following types", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 2251, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "95d39973-156c-4ab7-a7e4-1ee24e7c4886": {"__data__": {"id_": "95d39973-156c-4ab7-a7e4-1ee24e7c4886", "embedding": null, "metadata": {"page_label": "75", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# Configuration Management\n\nConfiguration management during the operational phase should begin with the configuration called baseline (initial) and associated configuration management records. This information should be part of the system delivery stage by the validation team for the operational environment (routine).\n\nConfiguration Management consists of the following activities:\n\n- Configuration Identification - WHAT must be kept in control;\n- Configuration Control - HOW to perform the control;\n- Configuration Status - HOW to document the control;\n- Configuration Evaluation - HOW to check the control.\n\nThere should be a standard operating procedure involving the activities, responsibilities, procedures and schedules related to configuration management during the operational phase of the system.\n\nConfiguration management and associated records are an essential part of recovery activity disasters, where the system and its components can be correctly reassembled and integrated for the operational reestablishment of the computerized system.\n\n## Configuration Identification\n\nThe components of the systems subject to configuration management must be clearly established. The system must be broken down into configuration items, which must be identified during the definition of specifications and development.\n\nA configuration item is a component of the system that does not change as a result of an operation normal system. Configuration items should be modified only by applying changes. Examples of configuration items are: application software; embedded software, hardware and system documentation.\n\nThe formally established list of configuration items and their versions are referred to as configuration baseline (*Configuration baseline*).", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos establece la importancia de la gesti\u00f3n de la configuraci\u00f3n durante la fase operativa de un sistema. Se define la gesti\u00f3n de la configuraci\u00f3n como un conjunto de actividades que incluyen la identificaci\u00f3n, control, documentaci\u00f3n y evaluaci\u00f3n de la configuraci\u00f3n. Se enfatiza la necesidad de un procedimiento operativo est\u00e1ndar que detalle las responsabilidades y actividades relacionadas con la gesti\u00f3n de la configuraci\u00f3n, as\u00ed como la importancia de mantener registros para facilitar la recuperaci\u00f3n en caso de desastres.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfCu\u00e1les son las cuatro actividades principales que componen la gesti\u00f3n de la configuraci\u00f3n seg\u00fan el documento de ANVISA?**\n   - Respuesta: Las cuatro actividades principales son: Identificaci\u00f3n de Configuraci\u00f3n, Control de Configuraci\u00f3n, Estado de Configuraci\u00f3n y Evaluaci\u00f3n de Configuraci\u00f3n.\n\n2. **\u00bfQu\u00e9 se entiende por 'elemento de configuraci\u00f3n' y c\u00f3mo se relaciona con la gesti\u00f3n de la configuraci\u00f3n?**\n   - Respuesta: Un elemento de configuraci\u00f3n es un componente del sistema que no cambia como resultado de la operaci\u00f3n normal del sistema. Estos elementos deben ser modificados solo mediante la aplicaci\u00f3n de cambios y son fundamentales para la gesti\u00f3n de la configuraci\u00f3n, ya que deben ser claramente identificados y controlados.\n\n3. **\u00bfPor qu\u00e9 es crucial tener registros de gesti\u00f3n de la configuraci\u00f3n en el contexto de la recuperaci\u00f3n de desastres?**\n   - Respuesta: Los registros de gesti\u00f3n de la configuraci\u00f3n son esenciales para las actividades de recuperaci\u00f3n de desastres porque permiten que el sistema y sus componentes sean correctamente reensamblados e integrados para restablecer la operaci\u00f3n del sistema inform\u00e1tico de manera efectiva.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Gesti\u00f3n de Configuraci\u00f3n y Gesti\u00f3n de Cambios**:\n   - Ambas actividades est\u00e1n interrelacionadas y deben manejarse en paralelo, especialmente al evaluar el impacto de los cambios propuestos.\n   - Se aplican a todos los componentes del sistema, incluyendo hardware, software y documentaci\u00f3n asociada.\n\n2. **Requisitos Clave**:\n   - La gesti\u00f3n de cambios debe ser continua hasta que el sistema sea retirado.\n   - Todos los cambios deben ser revisados, evaluados por riesgo e impacto, autorizados, documentados, probados y aprobados antes de su implementaci\u00f3n.\n   - La configuraci\u00f3n de hardware y software debe ser documentada a lo largo del ciclo de vida del sistema, con suficiente detalle para permitir la reconstrucci\u00f3n en caso de p\u00e9rdida total.\n\n3. **Responsabilidades**:\n   - **Propietario del Proceso**: Asegurar la implementaci\u00f3n de la gesti\u00f3n de cambios y configuraciones.\n   - **Unidad de Calidad**: Garantizar que se sigan los procedimientos existentes para la gesti\u00f3n de cambios.\n   - **Miembros del Equipo**: Cada miembro debe participar correctamente en el proceso de gesti\u00f3n de cambios.\n\n4. **Pruebas y Verificaci\u00f3n**:\n   - Las pruebas para verificar cambios deben ser proporcionales al riesgo que representan para la seguridad del paciente, la integridad del producto y la integridad de los datos.\n\n### Entidades Clave\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil.\n- **Gu\u00eda n\u00b0 33/2020**: Documento que establece directrices para la validaci\u00f3n de sistemas inform\u00e1ticos.\n- **Hardware y Software**: Componentes del sistema que deben ser gestionados y documentados.\n- **BPx**: Referencia a procesos o sistemas que impactan en la calidad y seguridad de productos.\n\nEste resumen destaca la importancia de un enfoque estructurado y responsable en la gesti\u00f3n de configuraciones y cambios dentro de los sistemas inform\u00e1ticos, asegurando la calidad y la seguridad en el contexto de las Buenas Pr\u00e1cticas de Manufactura.", "excerpt_keywords": "Keywords: Configuration Management, Baseline, Configuration Items, Disaster Recovery, Standard Operating Procedure"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "f37402a7-6e7b-4fa7-914c-62435d55e6c9", "node_type": "4", "metadata": {"page_label": "75", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# Configuration Management\n\nConfiguration management during the operational phase should begin with the configuration called baseline (initial) and associated configuration management records. This information should be part of the system delivery stage by the validation team for the operational environment (routine).\n\nConfiguration Management consists of the following activities:\n\n- Configuration Identification - WHAT must be kept in control;\n- Configuration Control - HOW to perform the control;\n- Configuration Status - HOW to document the control;\n- Configuration Evaluation - HOW to check the control.\n\nThere should be a standard operating procedure involving the activities, responsibilities, procedures and schedules related to configuration management during the operational phase of the system.\n\nConfiguration management and associated records are an essential part of recovery activity disasters, where the system and its components can be correctly reassembled and integrated for the operational reestablishment of the computerized system.\n\n## Configuration Identification\n\nThe components of the systems subject to configuration management must be clearly established. The system must be broken down into configuration items, which must be identified during the definition of specifications and development.\n\nA configuration item is a component of the system that does not change as a result of an operation normal system. Configuration items should be modified only by applying changes. Examples of configuration items are: application software; embedded software, hardware and system documentation.\n\nThe formally established list of configuration items and their versions are referred to as configuration baseline (*Configuration baseline*).", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "53ba268d175c07486745a7dab515d5f4ebd514f210721ee2f2db28f8d0dc7def", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "# Configuration Management\n\nConfiguration management during the operational phase should begin with the configuration called baseline (initial) and associated configuration management records. This information should be part of the system delivery stage by the validation team for the operational environment (routine).\n\nConfiguration Management consists of the following activities:\n\n- Configuration Identification - WHAT must be kept in control;\n- Configuration Control - HOW to perform the control;\n- Configuration Status - HOW to document the control;\n- Configuration Evaluation - HOW to check the control.\n\nThere should be a standard operating procedure involving the activities, responsibilities, procedures and schedules related to configuration management during the operational phase of the system.\n\nConfiguration management and associated records are an essential part of recovery activity disasters, where the system and its components can be correctly reassembled and integrated for the operational reestablishment of the computerized system.\n\n## Configuration Identification\n\nThe components of the systems subject to configuration management must be clearly established. The system must be broken down into configuration items, which must be identified during the definition of specifications and development.\n\nA configuration item is a component of the system that does not change as a result of an operation normal system. Configuration items should be modified only by applying changes. Examples of configuration items are: application software; embedded software, hardware and system documentation.\n\nThe formally established list of configuration items and their versions are referred to as configuration baseline (*Configuration baseline*).", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 1758, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "0f8e54b1-bae0-416a-9f5b-5424a1e2a12e": {"__data__": {"id_": "0f8e54b1-bae0-416a-9f5b-5424a1e2a12e", "embedding": null, "metadata": {"page_label": "76", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 11.7.7 Configuration Control\n\nChanges to the configuration items must be coordinated and controlled. This includes the following activities:\n\n- Version control;\n- Change control;\n- Configuration item storage;\n- Delivery control.\n\nA unique name and version number must be used to identify each configuration item.\n\nChange control must be applied for each configuration item. Changes in _hardware_, _software_ and configuration must be carried out by authorized persons and controls must be maintained.\n\n# 11.7.8 Configuration Status\n\nThere must be documentation showing the status and history of the configuration items. Such documentation it should include: details of the changes made; latest version numbers and release identifiers. This shows that the system specifications are reviewed, updated and approved.\n\nThis activity can be performed in several ways, including through a document with version controlled by describing the baseline configuration or by using automated tools.\n\n# 11.7.9 Configuration Evaluation\n\nAll documented activities must be subject to management to ensure that the situation of the system is accurate and up-to-date and provides a source for auditing system configuration management.\n\nThe periodic review of systems in operation should include checking that current information about the system configuration is correct and accurate.\n\n# 11.7.19 Execution of Activities\n\nChange and configuration management activities involve performing the following actions, only items 2, 4 and 6 are related to configuration management, specifically:\n\n1. Proposal for change - record the details for the motivation of the change and prepare the requirements from the user to the proposed change;\n2. Assessment of the impact of the change - identification of regulatory and record impacts; identification the configuration items (system components) affected;\n3. Decision on the proposal - accept or reject;\n4. Process development - Includes: _software_, _hardware_ and documentation update;", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos establece directrices para el control de configuraci\u00f3n, el estado de configuraci\u00f3n, la evaluaci\u00f3n de configuraci\u00f3n y la ejecuci\u00f3n de actividades relacionadas con la gesti\u00f3n de cambios y configuraciones. Se enfatiza la importancia de la documentaci\u00f3n, el control de cambios, la identificaci\u00f3n de elementos de configuraci\u00f3n y la evaluaci\u00f3n peri\u00f3dica para asegurar que los sistemas operativos mantengan su integridad y cumplimiento normativo.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfQu\u00e9 elementos deben ser considerados en el control de cambios para los \u00edtems de configuraci\u00f3n seg\u00fan el documento de ANVISA?**\n   - El control de cambios debe incluir la identificaci\u00f3n de los \u00edtems de configuraci\u00f3n afectados, la evaluaci\u00f3n de los impactos regulatorios y de registro, y la autorizaci\u00f3n de las personas que realizan los cambios en hardware, software y configuraci\u00f3n.\n\n2. **\u00bfC\u00f3mo se debe documentar el estado y la historia de los \u00edtems de configuraci\u00f3n?**\n   - La documentaci\u00f3n debe incluir detalles de los cambios realizados, los n\u00fameros de versi\u00f3n m\u00e1s recientes y los identificadores de lanzamiento. Esto puede hacerse a trav\u00e9s de un documento controlado por versiones que describa la configuraci\u00f3n base o mediante herramientas automatizadas.\n\n3. **\u00bfQu\u00e9 acciones espec\u00edficas se deben llevar a cabo en la gesti\u00f3n de cambios y configuraciones seg\u00fan el documento?**\n   - Las acciones incluyen la propuesta de cambio (registrar la motivaci\u00f3n y requisitos del usuario), la evaluaci\u00f3n del impacto del cambio (identificaci\u00f3n de impactos regulatorios y de registro), la decisi\u00f3n sobre la propuesta (aceptar o rechazar) y el desarrollo del proceso (actualizaci\u00f3n de software, hardware y documentaci\u00f3n).", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n**Tema Principal: Gesti\u00f3n de la Configuraci\u00f3n**\n- La gesti\u00f3n de la configuraci\u00f3n es un proceso cr\u00edtico durante la fase operativa de un sistema inform\u00e1tico, comenzando con una configuraci\u00f3n inicial conocida como *baseline*.\n\n**Actividades de Gesti\u00f3n de la Configuraci\u00f3n:**\n1. **Identificaci\u00f3n de Configuraci\u00f3n:** Determinar qu\u00e9 elementos deben ser controlados.\n2. **Control de Configuraci\u00f3n:** Establecer c\u00f3mo se llevar\u00e1 a cabo el control.\n3. **Estado de Configuraci\u00f3n:** Documentar c\u00f3mo se realiza el control.\n4. **Evaluaci\u00f3n de Configuraci\u00f3n:** Verificar c\u00f3mo se revisa el control.\n\n**Importancia de la Gesti\u00f3n de la Configuraci\u00f3n:**\n- Se requiere un procedimiento operativo est\u00e1ndar que defina actividades, responsabilidades y cronogramas relacionados con la gesti\u00f3n de la configuraci\u00f3n.\n- Los registros de gesti\u00f3n de la configuraci\u00f3n son esenciales para la recuperaci\u00f3n ante desastres, permitiendo la correcta reensambladura e integraci\u00f3n del sistema y sus componentes.\n\n**Elementos de Configuraci\u00f3n:**\n- Los componentes del sistema deben ser claramente identificados y desglosados en *elementos de configuraci\u00f3n*, que son partes del sistema que no cambian durante la operaci\u00f3n normal.\n- Ejemplos de elementos de configuraci\u00f3n incluyen software de aplicaci\u00f3n, software embebido, hardware y documentaci\u00f3n del sistema.\n- La lista formal de elementos de configuraci\u00f3n y sus versiones se conoce como *baseline de configuraci\u00f3n*.\n\n### Entidades Clave:\n- **Gesti\u00f3n de la Configuraci\u00f3n**\n- **Baseline (Configuraci\u00f3n Inicial)**\n- **Elementos de Configuraci\u00f3n**\n- **Recuperaci\u00f3n ante Desastres**\n- **Procedimiento Operativo Est\u00e1ndar** \n\nEste resumen destaca la estructura y la importancia de la gesti\u00f3n de la configuraci\u00f3n en el contexto de la validaci\u00f3n de sistemas inform\u00e1ticos seg\u00fan el documento de ANVISA.", "excerpt_keywords": "Keywords: configuration control, change management, version control, documentation, system validation"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "d83e698a-0fdd-43fc-a101-995d50708ee4", "node_type": "4", "metadata": {"page_label": "76", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 11.7.7 Configuration Control\n\nChanges to the configuration items must be coordinated and controlled. This includes the following activities:\n\n- Version control;\n- Change control;\n- Configuration item storage;\n- Delivery control.\n\nA unique name and version number must be used to identify each configuration item.\n\nChange control must be applied for each configuration item. Changes in _hardware_, _software_ and configuration must be carried out by authorized persons and controls must be maintained.\n\n# 11.7.8 Configuration Status\n\nThere must be documentation showing the status and history of the configuration items. Such documentation it should include: details of the changes made; latest version numbers and release identifiers. This shows that the system specifications are reviewed, updated and approved.\n\nThis activity can be performed in several ways, including through a document with version controlled by describing the baseline configuration or by using automated tools.\n\n# 11.7.9 Configuration Evaluation\n\nAll documented activities must be subject to management to ensure that the situation of the system is accurate and up-to-date and provides a source for auditing system configuration management.\n\nThe periodic review of systems in operation should include checking that current information about the system configuration is correct and accurate.\n\n# 11.7.19 Execution of Activities\n\nChange and configuration management activities involve performing the following actions, only items 2, 4 and 6 are related to configuration management, specifically:\n\n1. Proposal for change - record the details for the motivation of the change and prepare the requirements from the user to the proposed change;\n2. Assessment of the impact of the change - identification of regulatory and record impacts; identification the configuration items (system components) affected;\n3. Decision on the proposal - accept or reject;\n4. Process development - Includes: _software_, _hardware_ and documentation update;", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "a9ad8297da7b81c0be46df1e7680374fa925983e4198a079f9f3a32248a829d7", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "# 11.7.7 Configuration Control\n\nChanges to the configuration items must be coordinated and controlled. This includes the following activities:\n\n- Version control;\n- Change control;\n- Configuration item storage;\n- Delivery control.\n\nA unique name and version number must be used to identify each configuration item.\n\nChange control must be applied for each configuration item. Changes in _hardware_, _software_ and configuration must be carried out by authorized persons and controls must be maintained.\n\n# 11.7.8 Configuration Status\n\nThere must be documentation showing the status and history of the configuration items. Such documentation it should include: details of the changes made; latest version numbers and release identifiers. This shows that the system specifications are reviewed, updated and approved.\n\nThis activity can be performed in several ways, including through a document with version controlled by describing the baseline configuration or by using automated tools.\n\n# 11.7.9 Configuration Evaluation\n\nAll documented activities must be subject to management to ensure that the situation of the system is accurate and up-to-date and provides a source for auditing system configuration management.\n\nThe periodic review of systems in operation should include checking that current information about the system configuration is correct and accurate.\n\n# 11.7.19 Execution of Activities\n\nChange and configuration management activities involve performing the following actions, only items 2, 4 and 6 are related to configuration management, specifically:\n\n1. Proposal for change - record the details for the motivation of the change and prepare the requirements from the user to the proposed change;\n2. Assessment of the impact of the change - identification of regulatory and record impacts; identification the configuration items (system components) affected;\n3. Decision on the proposal - accept or reject;\n4. Process development - Includes: _software_, _hardware_ and documentation update;", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 2007, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "743d43df-8b23-430c-89bd-25db18e1189a": {"__data__": {"id_": "743d43df-8b23-430c-89bd-25db18e1189a", "embedding": null, "metadata": {"page_label": "77", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "5. Test of the implanted change;\n6. Approval and implementation - Items to be considered: training; updating processes business and communication;\n7. Closure.\n\nRecords of activities associated with change and configuration management should be subject to periodic internal audits.\n\n## 11.8 SYSTEM REPAIR ACTIVITIES\n\n### 11.8.1 Introduction\n\nSystem Repair is the activity that consists of managing repairs or replacing components failures or defects. The repair object can even be a configuration item. It is a way of change control in which the relevant specifications are not changed.\n\nRepairing or replacing components of computer systems that fail or fail, generally related to *hardware* or infrastructure, must be managed according to a procedure defined. Such activities should be authorized and implemented only within a context of change control management.\n\nMany repair activities are emergency and require quick resolution. Therefore, the incident management and change control should be structured to allow such activities can occur without delay or without increasing the risk to the operational integrity of the system computerized.\n\nThe repair process can be integrated with the change and configuration management process, but it is a more simplified route can be used.\n\nWhen failure (or repair) could impact patient safety, product quality or integrity data, then an incident management process must be initiated.\n\nRepair or replacement records must be subject to periodic internal audits and their review must be form part of the performance management process.\n\n### 11.8.2 Key requirements\n\nThe procedures to be followed in case of system failure or defect must be established, approved and verified.\n\nAny failures and corrective actions taken must be recorded.\n\nA procedure should be established to record and analyze errors and allow corrective actions to be taken. sockets.\n\nThese activities must be documented.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "### Resumen del contexto\n\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos aborda la gesti\u00f3n de cambios y actividades de reparaci\u00f3n de sistemas. Se enfatiza la importancia de seguir procedimientos definidos para la reparaci\u00f3n o reemplazo de componentes defectuosos, asegurando que estas actividades se realicen dentro de un marco de control de cambios. Adem\u00e1s, se menciona que las actividades de reparaci\u00f3n deben ser documentadas y auditadas peri\u00f3dicamente, especialmente si pueden afectar la seguridad del paciente, la calidad del producto o la integridad de los datos.\n\n### Preguntas espec\u00edficas\n\n1. **\u00bfQu\u00e9 procedimientos deben establecerse para gestionar las actividades de reparaci\u00f3n en sistemas inform\u00e1ticos seg\u00fan la gu\u00eda de ANVISA?**\n   - La gu\u00eda establece que deben existir procedimientos aprobados y verificados para manejar fallos o defectos en los sistemas. Estos procedimientos deben incluir la autorizaci\u00f3n de las actividades de reparaci\u00f3n dentro del contexto de gesti\u00f3n de cambios.\n\n2. **\u00bfC\u00f3mo se deben manejar las actividades de reparaci\u00f3n que son consideradas emergencias?**\n   - Las actividades de reparaci\u00f3n de emergencia deben estar estructuradas dentro de la gesti\u00f3n de incidentes y control de cambios para permitir una resoluci\u00f3n r\u00e1pida, sin demoras que puedan comprometer la integridad operativa del sistema.\n\n3. **\u00bfQu\u00e9 tipo de registros deben mantenerse en relaci\u00f3n con las actividades de reparaci\u00f3n y c\u00f3mo deben ser auditados?**\n   - Se deben mantener registros de todas las fallas y las acciones correctivas tomadas. Estos registros deben ser objeto de auditor\u00edas internas peri\u00f3dicas y su revisi\u00f3n debe formar parte del proceso de gesti\u00f3n del rendimiento.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Control de Configuraci\u00f3n**:\n   - Importancia de coordinar y controlar los cambios en los \u00edtems de configuraci\u00f3n.\n   - Actividades clave: control de versiones, control de cambios, almacenamiento de \u00edtems de configuraci\u00f3n y control de entrega.\n   - Identificaci\u00f3n \u00fanica de cada \u00edtem de configuraci\u00f3n mediante un nombre y n\u00famero de versi\u00f3n.\n\n2. **Estado de Configuraci\u00f3n**:\n   - Necesidad de documentaci\u00f3n que muestre el estado y la historia de los \u00edtems de configuraci\u00f3n.\n   - Detalles que deben incluirse: cambios realizados, n\u00fameros de versi\u00f3n m\u00e1s recientes e identificadores de lanzamiento.\n   - M\u00e9todos de documentaci\u00f3n: documentos controlados por versiones o herramientas automatizadas.\n\n3. **Evaluaci\u00f3n de Configuraci\u00f3n**:\n   - Revisi\u00f3n y gesti\u00f3n de todas las actividades documentadas para asegurar la precisi\u00f3n y actualidad de la configuraci\u00f3n del sistema.\n   - Importancia de la revisi\u00f3n peri\u00f3dica de los sistemas en operaci\u00f3n.\n\n4. **Ejecuci\u00f3n de Actividades**:\n   - Acciones espec\u00edficas en la gesti\u00f3n de cambios y configuraciones:\n     - Propuesta de cambio: registro de motivaciones y requisitos del usuario.\n     - Evaluaci\u00f3n del impacto del cambio: identificaci\u00f3n de impactos regulatorios y de registro, as\u00ed como de los \u00edtems de configuraci\u00f3n afectados.\n     - Decisi\u00f3n sobre la propuesta: aceptaci\u00f3n o rechazo.\n     - Desarrollo del proceso: actualizaci\u00f3n de software, hardware y documentaci\u00f3n.\n\n### Entidades Clave\n- **\u00cdtems de Configuraci\u00f3n**: Componentes del sistema que requieren control y gesti\u00f3n.\n- **Documentaci\u00f3n**: Registros que detallan cambios, versiones y estado de los \u00edtems de configuraci\u00f3n.\n- **Autorizaci\u00f3n**: Necesidad de que los cambios sean realizados por personas autorizadas.\n- **Herramientas Automatizadas**: Opciones para facilitar la gesti\u00f3n y documentaci\u00f3n de la configuraci\u00f3n.\n\nEste resumen destaca la importancia de un enfoque sistem\u00e1tico y documentado para la gesti\u00f3n de cambios y configuraciones en sistemas inform\u00e1ticos, asegurando su integridad y cumplimiento normativo.", "excerpt_keywords": "Keywords: validation, change management, system repair, internal audits, incident management"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "1e70b5d9-7d70-4c51-9aab-9f5a1d0efba0", "node_type": "4", "metadata": {"page_label": "77", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "5. Test of the implanted change;\n6. Approval and implementation - Items to be considered: training; updating processes business and communication;\n7. Closure.\n\nRecords of activities associated with change and configuration management should be subject to periodic internal audits.\n\n## 11.8 SYSTEM REPAIR ACTIVITIES\n\n### 11.8.1 Introduction\n\nSystem Repair is the activity that consists of managing repairs or replacing components failures or defects. The repair object can even be a configuration item. It is a way of change control in which the relevant specifications are not changed.\n\nRepairing or replacing components of computer systems that fail or fail, generally related to *hardware* or infrastructure, must be managed according to a procedure defined. Such activities should be authorized and implemented only within a context of change control management.\n\nMany repair activities are emergency and require quick resolution. Therefore, the incident management and change control should be structured to allow such activities can occur without delay or without increasing the risk to the operational integrity of the system computerized.\n\nThe repair process can be integrated with the change and configuration management process, but it is a more simplified route can be used.\n\nWhen failure (or repair) could impact patient safety, product quality or integrity data, then an incident management process must be initiated.\n\nRepair or replacement records must be subject to periodic internal audits and their review must be form part of the performance management process.\n\n### 11.8.2 Key requirements\n\nThe procedures to be followed in case of system failure or defect must be established, approved and verified.\n\nAny failures and corrective actions taken must be recorded.\n\nA procedure should be established to record and analyze errors and allow corrective actions to be taken. sockets.\n\nThese activities must be documented.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "afde5b62169ab977a850daf4852a11c40a45e6fe33d6f433181ae1e886ff4e71", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "5. Test of the implanted change;\n6. Approval and implementation - Items to be considered: training; updating processes business and communication;\n7. Closure.\n\nRecords of activities associated with change and configuration management should be subject to periodic internal audits.\n\n## 11.8 SYSTEM REPAIR ACTIVITIES\n\n### 11.8.1 Introduction\n\nSystem Repair is the activity that consists of managing repairs or replacing components failures or defects. The repair object can even be a configuration item. It is a way of change control in which the relevant specifications are not changed.\n\nRepairing or replacing components of computer systems that fail or fail, generally related to *hardware* or infrastructure, must be managed according to a procedure defined. Such activities should be authorized and implemented only within a context of change control management.\n\nMany repair activities are emergency and require quick resolution. Therefore, the incident management and change control should be structured to allow such activities can occur without delay or without increasing the risk to the operational integrity of the system computerized.\n\nThe repair process can be integrated with the change and configuration management process, but it is a more simplified route can be used.\n\nWhen failure (or repair) could impact patient safety, product quality or integrity data, then an incident management process must be initiated.\n\nRepair or replacement records must be subject to periodic internal audits and their review must be form part of the performance management process.\n\n### 11.8.2 Key requirements\n\nThe procedures to be followed in case of system failure or defect must be established, approved and verified.\n\nAny failures and corrective actions taken must be recorded.\n\nA procedure should be established to record and analyze errors and allow corrective actions to be taken. sockets.\n\nThese activities must be documented.", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 1932, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "0b328365-eae4-4433-aa33-12a9aeba4033": {"__data__": {"id_": "0b328365-eae4-4433-aa33-12a9aeba4033", "embedding": null, "metadata": {"page_label": "78", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "## 11.8.3 Responsibilities\n\nIt is the responsibility of the system owner to identify those components that are eligible for repair or replacement. Relevant information obtained in the design/validation phase may be available before and after delivery of the system, such as a list of spare parts for when the system is to be made operational.\n\nIt is the responsibility of the system owner to ensure that procedures are followed.\n\nIt is the responsibility of the team performing the repair (or replacement) to carry out the procedure complete and accurate, including record updates as needed (e.g., record book).\n\nIt is the responsibility of the Quality Unit to ensure that repair procedures are followed and appropriate actions are taken and documented.\n\n## 11.8.4 Execution of Activities\n\nIncident management activities involve performing the following actions:\n\n1. Fault identification (may be via incident management);\n2. Impact assessment - identification of the impact on regulated processes and records; identification of configuration items (system components) affected; definition of test documents and requirements;\n3. Evaluation and determination of the action to be taken - repair or replacement;\n\n4. Perform repair or replacement - including *hardware* and updating documentation and books of records;\n5. Verification of repair or replacement;\n6. Return to use - communication to users.\n\n**Note:** Items 2 to 6 should include configuration management.\n\n## 11.9 PERIODIC REVIEW\n\n### 11.9.1 Introduction\n\nPeriodic reviews are used throughout the operational life of the computerized system to verify that it remains compatible with regulatory requirements, fit for the intended use and meets the policies and company procedures. Reviews should confirm that, for system components, support necessary and the expected maintenance processes and regulatory controls (plans, procedures and records) are established.\n\nPeriodic reviews should be:\n\n- Scheduled at appropriate intervals consistent with impact and the operational history of the system.\n\nRisk assessments should be used to determine whether systems are in scope and whether the frequency", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos establece responsabilidades claras para los propietarios de sistemas, equipos de reparaci\u00f3n y unidades de calidad en la gesti\u00f3n de incidentes y mantenimiento de sistemas. Se enfatiza la importancia de seguir procedimientos establecidos, realizar evaluaciones de impacto y llevar a cabo revisiones peri\u00f3dicas para asegurar que los sistemas se mantengan en conformidad con los requisitos regulatorios y sean aptos para su uso previsto.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfCu\u00e1les son las responsabilidades espec\u00edficas del propietario del sistema en relaci\u00f3n con la identificaci\u00f3n de componentes elegibles para reparaci\u00f3n o reemplazo?**\n   - El propietario del sistema es responsable de identificar los componentes que pueden ser reparados o reemplazados, asegur\u00e1ndose de que se sigan los procedimientos establecidos y de que se disponga de informaci\u00f3n relevante, como listas de piezas de repuesto.\n\n2. **\u00bfQu\u00e9 pasos deben seguirse en la gesti\u00f3n de incidentes seg\u00fan el documento?**\n   - La gesti\u00f3n de incidentes implica varios pasos: identificaci\u00f3n de fallos, evaluaci\u00f3n del impacto, determinaci\u00f3n de la acci\u00f3n a tomar (reparaci\u00f3n o reemplazo), ejecuci\u00f3n de la reparaci\u00f3n o reemplazo, verificaci\u00f3n de la acci\u00f3n realizada y comunicaci\u00f3n del retorno a uso a los usuarios.\n\n3. **\u00bfC\u00f3mo se deben programar las revisiones peri\u00f3dicas de los sistemas inform\u00e1ticos?**\n   - Las revisiones peri\u00f3dicas deben programarse a intervalos apropiados que sean consistentes con el impacto del sistema y su historial operativo. Adem\u00e1s, se deben utilizar evaluaciones de riesgo para determinar si los sistemas est\u00e1n dentro del alcance y la frecuencia de las revisiones necesarias.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Gesti\u00f3n de Cambios y Reparaciones**:\n   - La secci\u00f3n aborda la importancia de gestionar adecuadamente las actividades de reparaci\u00f3n y reemplazo de componentes defectuosos en sistemas inform\u00e1ticos, dentro de un marco de control de cambios.\n\n2. **Procedimientos Definidos**:\n   - Se deben establecer, aprobar y verificar procedimientos espec\u00edficos para manejar fallos o defectos en los sistemas.\n\n3. **Actividades de Emergencia**:\n   - Las reparaciones de emergencia deben ser gestionadas de manera que se permita una resoluci\u00f3n r\u00e1pida, minimizando el riesgo para la integridad operativa del sistema.\n\n4. **Documentaci\u00f3n y Auditor\u00eda**:\n   - Es esencial mantener registros de todas las fallas y acciones correctivas, los cuales deben ser auditados peri\u00f3dicamente como parte del proceso de gesti\u00f3n del rendimiento.\n\n5. **Impacto en la Seguridad y Calidad**:\n   - Si una falla puede afectar la seguridad del paciente, la calidad del producto o la integridad de los datos, se debe iniciar un proceso de gesti\u00f3n de incidentes.\n\n### Entidades Clave\n\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil, responsable de la regulaci\u00f3n y validaci\u00f3n de sistemas inform\u00e1ticos en el \u00e1mbito de la salud.\n- **Sistema Inform\u00e1tico**: Conjunto de hardware y software que puede requerir reparaciones o cambios.\n- **Control de Cambios**: Proceso que asegura que todas las modificaciones en el sistema se realicen de manera controlada y documentada.\n- **Gesti\u00f3n de Incidentes**: Proceso que permite la r\u00e1pida resoluci\u00f3n de problemas que afectan la operaci\u00f3n del sistema.\n- **Auditor\u00edas Internas**: Evaluaciones peri\u00f3dicas que aseguran el cumplimiento de los procedimientos establecidos y la efectividad de las acciones correctivas. \n\nEste resumen destaca la importancia de la gesti\u00f3n adecuada de cambios y reparaciones en sistemas inform\u00e1ticos, enfatizando la necesidad de procedimientos claros, documentaci\u00f3n y auditor\u00edas para garantizar la seguridad y calidad en el \u00e1mbito de la salud.", "excerpt_keywords": "Keywords: ANVISA, computer systems validation, incident management, repair procedures, periodic review"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "83e36738-a729-4179-b711-b38e7d1e0ee3", "node_type": "4", "metadata": {"page_label": "78", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "## 11.8.3 Responsibilities\n\nIt is the responsibility of the system owner to identify those components that are eligible for repair or replacement. Relevant information obtained in the design/validation phase may be available before and after delivery of the system, such as a list of spare parts for when the system is to be made operational.\n\nIt is the responsibility of the system owner to ensure that procedures are followed.\n\nIt is the responsibility of the team performing the repair (or replacement) to carry out the procedure complete and accurate, including record updates as needed (e.g., record book).\n\nIt is the responsibility of the Quality Unit to ensure that repair procedures are followed and appropriate actions are taken and documented.\n\n## 11.8.4 Execution of Activities\n\nIncident management activities involve performing the following actions:\n\n1. Fault identification (may be via incident management);\n2. Impact assessment - identification of the impact on regulated processes and records; identification of configuration items (system components) affected; definition of test documents and requirements;\n3. Evaluation and determination of the action to be taken - repair or replacement;\n\n4. Perform repair or replacement - including *hardware* and updating documentation and books of records;\n5. Verification of repair or replacement;\n6. Return to use - communication to users.\n\n**Note:** Items 2 to 6 should include configuration management.\n\n## 11.9 PERIODIC REVIEW\n\n### 11.9.1 Introduction\n\nPeriodic reviews are used throughout the operational life of the computerized system to verify that it remains compatible with regulatory requirements, fit for the intended use and meets the policies and company procedures. Reviews should confirm that, for system components, support necessary and the expected maintenance processes and regulatory controls (plans, procedures and records) are established.\n\nPeriodic reviews should be:\n\n- Scheduled at appropriate intervals consistent with impact and the operational history of the system.\n\nRisk assessments should be used to determine whether systems are in scope and whether the frequency", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "cd925563750d68d573e4d8928fab6322743bbcc537c256ce926e594e4c413eb7", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "## 11.8.3 Responsibilities\n\nIt is the responsibility of the system owner to identify those components that are eligible for repair or replacement. Relevant information obtained in the design/validation phase may be available before and after delivery of the system, such as a list of spare parts for when the system is to be made operational.\n\nIt is the responsibility of the system owner to ensure that procedures are followed.\n\nIt is the responsibility of the team performing the repair (or replacement) to carry out the procedure complete and accurate, including record updates as needed (e.g., record book).\n\nIt is the responsibility of the Quality Unit to ensure that repair procedures are followed and appropriate actions are taken and documented.\n\n## 11.8.4 Execution of Activities\n\nIncident management activities involve performing the following actions:\n\n1. Fault identification (may be via incident management);\n2. Impact assessment - identification of the impact on regulated processes and records; identification of configuration items (system components) affected; definition of test documents and requirements;\n3. Evaluation and determination of the action to be taken - repair or replacement;\n\n4. Perform repair or replacement - including *hardware* and updating documentation and books of records;\n5. Verification of repair or replacement;\n6. Return to use - communication to users.\n\n**Note:** Items 2 to 6 should include configuration management.\n\n## 11.9 PERIODIC REVIEW\n\n### 11.9.1 Introduction\n\nPeriodic reviews are used throughout the operational life of the computerized system to verify that it remains compatible with regulatory requirements, fit for the intended use and meets the policies and company procedures. Reviews should confirm that, for system components, support necessary and the expected maintenance processes and regulatory controls (plans, procedures and records) are established.\n\nPeriodic reviews should be:\n\n- Scheduled at appropriate intervals consistent with impact and the operational history of the system.\n\nRisk assessments should be used to determine whether systems are in scope and whether the frequency", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 2154, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "af2d3fdd-876b-413e-bfb6-24a924d0f838": {"__data__": {"id_": "af2d3fdd-876b-413e-bfb6-24a924d0f838", "embedding": null, "metadata": {"page_label": "79", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "to perform the periodic review is adequate;\n- Executed according to a pre-defined procedure;\n- Documented and with traceable corrective actions.\n\nThe periodic review process must be generic and applicable to all systems.\n\nIt may be useful to develop checklists for carrying out reviews.\n\n## 11.9.2 Key requirements\n\nA process for defining the time and scheduling periodic reviews must be defined. The periods for review of systems should be based on the impact of the system, its complexity and innovation. At risk-based decisions must be documented.\n\nProblems encountered during the review should be documented, along with corrective actions sockets. The major implications related to these corrective actions should be assessed.\n\nCorrective actions must be resolved and approved.\n\n## 11.9.3 Responsibilities\n\nIt is the responsibility of the process owner to ensure that periodic reviews are conducted and that appropriate responses to the conclusions of the review were given.\n\nIt is the responsibility of Quality Assurance to ensure that periodic reviews are scheduled, executed and documented.\n\n----\n\nGuide for Computer Systems Validation\nGuide n\u00b0 33/2020 - version 1, of 03/26/2020\n\n----\n\n## Page 74\n\nThe review should be conducted by one or more people depending on the scope of the review. Participants can include: Quality Unit; the Subject Specialist; users; Information technology; Engineering; Regulatory Affairs. The conclusions must be documented.\n\n## 11.9.4 Schedule for Review\n\nFrequencies for periodic reviews should be based on the impact of the system, its complexity and innovation.\n\nAcceptable methods include:\n- By systems, the frequency being defined in the respective system validation reports;\n- Based on regular reviews and analysis of the systems inventory;\n- Based on specific events, whether planned or not;\n- Based on the number and complexity of change requests.\n\n----\n\nhttps://translate.googleusercontent.com/translate_f\n79/112", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "### Resumen del Contexto\n\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos establece directrices para la revisi\u00f3n peri\u00f3dica de estos sistemas. Se enfatiza la importancia de que las revisiones sean ejecutadas de acuerdo a procedimientos predefinidos, documentadas y con acciones correctivas trazables. Se menciona que el proceso de revisi\u00f3n debe ser gen\u00e9rico y aplicable a todos los sistemas, y se sugiere el uso de listas de verificaci\u00f3n. Adem\u00e1s, se detallan las responsabilidades del propietario del proceso y del \u00e1rea de Aseguramiento de Calidad en la programaci\u00f3n y ejecuci\u00f3n de estas revisiones. La frecuencia de las revisiones debe basarse en el impacto, complejidad e innovaci\u00f3n del sistema.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfCu\u00e1les son los criterios espec\u00edficos que se deben considerar al definir la frecuencia de las revisiones peri\u00f3dicas de un sistema inform\u00e1tico seg\u00fan el documento de ANVISA?**\n   - Esta pregunta busca obtener detalles sobre los factores que influyen en la programaci\u00f3n de revisiones, que no se encuentran f\u00e1cilmente en otros documentos.\n\n2. **\u00bfQu\u00e9 tipo de problemas deben ser documentados durante el proceso de revisi\u00f3n y c\u00f3mo se deben evaluar las implicaciones de las acciones correctivas?**\n   - Esta pregunta se centra en el manejo de problemas espec\u00edficos que surgen durante las revisiones, proporcionando informaci\u00f3n que puede no estar disponible en otras gu\u00edas.\n\n3. **\u00bfQu\u00e9 roles y responsabilidades espec\u00edficas tienen los diferentes participantes en el proceso de revisi\u00f3n peri\u00f3dica de sistemas inform\u00e1ticos seg\u00fan el documento?**\n   - Esta pregunta busca aclarar las funciones de cada participante en el proceso de revisi\u00f3n, lo que puede no estar claramente definido en otros contextos.\n\n### Resumen de Nivel Superior\n\nEl documento de ANVISA proporciona un marco para la validaci\u00f3n de sistemas inform\u00e1ticos, destacando la importancia de las revisiones peri\u00f3dicas. Se establece que estas revisiones deben ser sistem\u00e1ticas, documentadas y basadas en un an\u00e1lisis de riesgo. Adem\u00e1s, se asignan responsabilidades claras a los propietarios de procesos y a los equipos de calidad, y se sugieren m\u00e9todos para determinar la frecuencia de las revisiones.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Responsabilidades del Propietario del Sistema**:\n   - Identificaci\u00f3n de componentes elegibles para reparaci\u00f3n o reemplazo.\n   - Asegurarse de que se sigan los procedimientos establecidos.\n   - Disponibilidad de informaci\u00f3n relevante, como listas de piezas de repuesto.\n\n2. **Responsabilidades del Equipo de Reparaci\u00f3n**:\n   - Realizar procedimientos de reparaci\u00f3n o reemplazo de manera completa y precisa.\n   - Actualizaci\u00f3n de registros seg\u00fan sea necesario.\n\n3. **Responsabilidades de la Unidad de Calidad**:\n   - Asegurar que se sigan los procedimientos de reparaci\u00f3n.\n   - Documentar las acciones apropiadas tomadas durante el proceso de reparaci\u00f3n.\n\n4. **Gesti\u00f3n de Incidentes**:\n   - Pasos a seguir: identificaci\u00f3n de fallos, evaluaci\u00f3n del impacto, determinaci\u00f3n de acciones (reparaci\u00f3n o reemplazo), ejecuci\u00f3n de la reparaci\u00f3n o reemplazo, verificaci\u00f3n de la acci\u00f3n realizada y comunicaci\u00f3n del retorno a uso a los usuarios.\n   - Importancia de la gesti\u00f3n de configuraci\u00f3n en los pasos 2 a 6.\n\n5. **Revisiones Peri\u00f3dicas**:\n   - Uso de revisiones a lo largo de la vida operativa del sistema para verificar la conformidad con requisitos regulatorios y pol\u00edticas de la empresa.\n   - Programaci\u00f3n de revisiones a intervalos apropiados basados en el impacto y la historia operativa del sistema.\n   - Uso de evaluaciones de riesgo para determinar el alcance y la frecuencia de las revisiones.\n\n### Entidades Clave\n- **Sistema Inform\u00e1tico**: Objeto de validaci\u00f3n y mantenimiento.\n- **Propietario del Sistema**: Entidad responsable de la gesti\u00f3n y mantenimiento del sistema.\n- **Equipo de Reparaci\u00f3n**: Grupo encargado de realizar reparaciones o reemplazos.\n- **Unidad de Calidad**: Entidad que supervisa el cumplimiento de los procedimientos de calidad.\n- **Incidentes**: Eventos que requieren gesti\u00f3n y resoluci\u00f3n.\n- **Revisiones Peri\u00f3dicas**: Evaluaciones programadas para asegurar la conformidad y funcionalidad del sistema. \n\nEste resumen destaca las responsabilidades y procesos clave relacionados con la gesti\u00f3n y mantenimiento de sistemas inform\u00e1ticos seg\u00fan el documento de ANVISA.", "excerpt_keywords": "Keywords: validation, periodic review, corrective actions, quality assurance, risk-based decisions"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "0ebd4c0c-1965-4833-bef9-675cef79d75d", "node_type": "4", "metadata": {"page_label": "79", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "to perform the periodic review is adequate;\n- Executed according to a pre-defined procedure;\n- Documented and with traceable corrective actions.\n\nThe periodic review process must be generic and applicable to all systems.\n\nIt may be useful to develop checklists for carrying out reviews.\n\n## 11.9.2 Key requirements\n\nA process for defining the time and scheduling periodic reviews must be defined. The periods for review of systems should be based on the impact of the system, its complexity and innovation. At risk-based decisions must be documented.\n\nProblems encountered during the review should be documented, along with corrective actions sockets. The major implications related to these corrective actions should be assessed.\n\nCorrective actions must be resolved and approved.\n\n## 11.9.3 Responsibilities\n\nIt is the responsibility of the process owner to ensure that periodic reviews are conducted and that appropriate responses to the conclusions of the review were given.\n\nIt is the responsibility of Quality Assurance to ensure that periodic reviews are scheduled, executed and documented.\n\n----\n\nGuide for Computer Systems Validation\nGuide n\u00b0 33/2020 - version 1, of 03/26/2020\n\n----\n\n## Page 74\n\nThe review should be conducted by one or more people depending on the scope of the review. Participants can include: Quality Unit; the Subject Specialist; users; Information technology; Engineering; Regulatory Affairs. The conclusions must be documented.\n\n## 11.9.4 Schedule for Review\n\nFrequencies for periodic reviews should be based on the impact of the system, its complexity and innovation.\n\nAcceptable methods include:\n- By systems, the frequency being defined in the respective system validation reports;\n- Based on regular reviews and analysis of the systems inventory;\n- Based on specific events, whether planned or not;\n- Based on the number and complexity of change requests.\n\n----\n\nhttps://translate.googleusercontent.com/translate_f\n79/112", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "cf0733759d421a92e4e4198e8593ea050ce130f1f9420bd6704c70ce9046025c", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "to perform the periodic review is adequate;\n- Executed according to a pre-defined procedure;\n- Documented and with traceable corrective actions.\n\nThe periodic review process must be generic and applicable to all systems.\n\nIt may be useful to develop checklists for carrying out reviews.\n\n## 11.9.2 Key requirements\n\nA process for defining the time and scheduling periodic reviews must be defined. The periods for review of systems should be based on the impact of the system, its complexity and innovation. At risk-based decisions must be documented.\n\nProblems encountered during the review should be documented, along with corrective actions sockets. The major implications related to these corrective actions should be assessed.\n\nCorrective actions must be resolved and approved.\n\n## 11.9.3 Responsibilities\n\nIt is the responsibility of the process owner to ensure that periodic reviews are conducted and that appropriate responses to the conclusions of the review were given.\n\nIt is the responsibility of Quality Assurance to ensure that periodic reviews are scheduled, executed and documented.\n\n----\n\nGuide for Computer Systems Validation\nGuide n\u00b0 33/2020 - version 1, of 03/26/2020\n\n----\n\n## Page 74\n\nThe review should be conducted by one or more people depending on the scope of the review. Participants can include: Quality Unit; the Subject Specialist; users; Information technology; Engineering; Regulatory Affairs. The conclusions must be documented.\n\n## 11.9.4 Schedule for Review\n\nFrequencies for periodic reviews should be based on the impact of the system, its complexity and innovation.\n\nAcceptable methods include:\n- By systems, the frequency being defined in the respective system validation reports;\n- Based on regular reviews and analysis of the systems inventory;\n- Based on specific events, whether planned or not;\n- Based on the number and complexity of change requests.\n\n----\n\nhttps://translate.googleusercontent.com/translate_f\n79/112", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 1958, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "fbdeb945-9a6b-4165-a800-7c6a7438a549": {"__data__": {"id_": "fbdeb945-9a6b-4165-a800-7c6a7438a549", "embedding": null, "metadata": {"page_label": "80", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 11.9.5 Reviewing a System\n\n## 11.9.5.1 Preparation\n\nRelevant information should be available for the review, such as:\n\n- System documentation, including: plans, specifications, tests, reports, traceability, risk management documentation, project reviews, user manuals, training materials and records;\n- Standard Operating Procedures for operation and maintenance;\n- Configuration management information;\n- Change management information;\n- Incident records;\n- Security and access control information;\n- Reports of any previous audits of individual systems;\n- Validation Report.\n\nThe objectives, the team and the agenda for carrying out the review must be defined. The review team must ensure that the necessary reference material and people are available and that the process owner is committed to the results of the review.\n\n## 11.9.5.2 Conducting the Review\n\nProblems encountered during the review should be documented, along with corrective actions recommended. Depending on the management process created by the company, an audit of follow-up can be scheduled.\n\nWhen setting the agenda for the review, the following points should be considered:\n\n- The documentation must be complete, up to date and correct, including:\n- \u2713 Specification and verification;\n- \u2713 Operation and maintenance;\n- \u2713 List of configuration items.\n- Records of any changes made to the system;\n- The level of change made to the system and the nature of the change;\n- Exceptional actions required by a Validation Report;\n- Reports of previous audits and the respective actions taken;\n- Any controls implemented to manage risks that are still in place effective;\n- Evidence of unstable or unreliable operation;\n- Changes in the environment, process or business requirements, legislation or accepted best practices;", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos establece directrices para la revisi\u00f3n de sistemas. Se divide en dos secciones principales: la preparaci\u00f3n para la revisi\u00f3n y la conducci\u00f3n de la misma. En la preparaci\u00f3n, se enfatiza la necesidad de tener documentaci\u00f3n relevante y la definici\u00f3n de objetivos, equipo y agenda. Durante la revisi\u00f3n, se deben documentar problemas y acciones correctivas, y se deben considerar varios aspectos de la documentaci\u00f3n y cambios en el sistema.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfQu\u00e9 tipo de documentaci\u00f3n se considera esencial para la preparaci\u00f3n de la revisi\u00f3n de un sistema seg\u00fan el documento de ANVISA?**\n   - La documentaci\u00f3n esencial incluye planes, especificaciones, pruebas, informes, documentaci\u00f3n de gesti\u00f3n de riesgos, revisiones de proyectos, manuales de usuario, materiales de capacitaci\u00f3n, procedimientos operativos est\u00e1ndar, informaci\u00f3n de gesti\u00f3n de configuraci\u00f3n y registros de incidentes.\n\n2. **\u00bfCu\u00e1les son los puntos clave que deben considerarse al establecer la agenda para la revisi\u00f3n de un sistema?**\n   - Al establecer la agenda, se deben considerar la completitud y actualidad de la documentaci\u00f3n, registros de cambios realizados al sistema, el nivel y naturaleza de los cambios, acciones excepcionales requeridas por un informe de validaci\u00f3n, informes de auditor\u00edas previas y controles implementados para gestionar riesgos.\n\n3. **\u00bfQu\u00e9 acciones deben tomarse si se encuentran problemas durante la revisi\u00f3n de un sistema?**\n   - Los problemas encontrados deben ser documentados junto con las acciones correctivas recomendadas. Dependiendo del proceso de gesti\u00f3n de la empresa, se puede programar una auditor\u00eda de seguimiento para asegurar que se aborden los problemas identificados.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Revisi\u00f3n Peri\u00f3dica de Sistemas Inform\u00e1ticos**:\n   - Importancia de realizar revisiones peri\u00f3dicas de los sistemas inform\u00e1ticos de manera sistem\u00e1tica y documentada.\n   - Las revisiones deben seguir procedimientos predefinidos y contar con acciones correctivas trazables.\n\n2. **Requisitos Clave**:\n   - Definici\u00f3n de un proceso para establecer la frecuencia y programaci\u00f3n de las revisiones, basado en el impacto, complejidad e innovaci\u00f3n del sistema.\n   - Documentaci\u00f3n de problemas encontrados durante las revisiones y evaluaci\u00f3n de las implicaciones de las acciones correctivas.\n\n3. **Responsabilidades**:\n   - **Propietario del Proceso**: Asegurar que las revisiones se realicen y que se respondan adecuadamente a las conclusiones.\n   - **Aseguramiento de Calidad**: Programar, ejecutar y documentar las revisiones peri\u00f3dicas.\n\n4. **Participantes en el Proceso de Revisi\u00f3n**:\n   - La revisi\u00f3n puede incluir a miembros de la Unidad de Calidad, Especialistas en la Materia, usuarios, Tecnolog\u00eda de la Informaci\u00f3n, Ingenier\u00eda y Asuntos Regulatorios.\n\n5. **Programaci\u00f3n de Revisiones**:\n   - La frecuencia de las revisiones debe basarse en:\n     - Informes de validaci\u00f3n de sistemas.\n     - An\u00e1lisis regular del inventario de sistemas.\n     - Eventos espec\u00edficos, planificados o no.\n     - N\u00famero y complejidad de solicitudes de cambio.\n\n### Entidades Clave:\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil.\n- **Sistema Inform\u00e1tico**: Cualquier sistema que requiera validaci\u00f3n y revisi\u00f3n peri\u00f3dica.\n- **Propietario del Proceso**: Persona responsable de la gesti\u00f3n del sistema.\n- **Aseguramiento de Calidad**: \u00c1rea encargada de garantizar la calidad y cumplimiento de los procesos.\n- **Participantes**: Incluyen a miembros de diversas \u00e1reas como Calidad, TI, Ingenier\u00eda, etc. \n\nEste resumen destaca la estructura y los elementos esenciales del proceso de revisi\u00f3n peri\u00f3dica seg\u00fan la gu\u00eda de ANVISA para la validaci\u00f3n de sistemas inform\u00e1ticos.", "excerpt_keywords": "Keywords: validation, review, documentation, corrective actions, risk management"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "7db8007e-74a7-40d3-93b4-1227fc12fc60", "node_type": "4", "metadata": {"page_label": "80", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 11.9.5 Reviewing a System\n\n## 11.9.5.1 Preparation\n\nRelevant information should be available for the review, such as:\n\n- System documentation, including: plans, specifications, tests, reports, traceability, risk management documentation, project reviews, user manuals, training materials and records;\n- Standard Operating Procedures for operation and maintenance;\n- Configuration management information;\n- Change management information;\n- Incident records;\n- Security and access control information;\n- Reports of any previous audits of individual systems;\n- Validation Report.\n\nThe objectives, the team and the agenda for carrying out the review must be defined. The review team must ensure that the necessary reference material and people are available and that the process owner is committed to the results of the review.\n\n## 11.9.5.2 Conducting the Review\n\nProblems encountered during the review should be documented, along with corrective actions recommended. Depending on the management process created by the company, an audit of follow-up can be scheduled.\n\nWhen setting the agenda for the review, the following points should be considered:\n\n- The documentation must be complete, up to date and correct, including:\n- \u2713 Specification and verification;\n- \u2713 Operation and maintenance;\n- \u2713 List of configuration items.\n- Records of any changes made to the system;\n- The level of change made to the system and the nature of the change;\n- Exceptional actions required by a Validation Report;\n- Reports of previous audits and the respective actions taken;\n- Any controls implemented to manage risks that are still in place effective;\n- Evidence of unstable or unreliable operation;\n- Changes in the environment, process or business requirements, legislation or accepted best practices;", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "b10f312a08def271b851c5b287a657ac13e19f3c4daa893e3890c7bbea88df07", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "# 11.9.5 Reviewing a System\n\n## 11.9.5.1 Preparation\n\nRelevant information should be available for the review, such as:\n\n- System documentation, including: plans, specifications, tests, reports, traceability, risk management documentation, project reviews, user manuals, training materials and records;\n- Standard Operating Procedures for operation and maintenance;\n- Configuration management information;\n- Change management information;\n- Incident records;\n- Security and access control information;\n- Reports of any previous audits of individual systems;\n- Validation Report.\n\nThe objectives, the team and the agenda for carrying out the review must be defined. The review team must ensure that the necessary reference material and people are available and that the process owner is committed to the results of the review.\n\n## 11.9.5.2 Conducting the Review\n\nProblems encountered during the review should be documented, along with corrective actions recommended. Depending on the management process created by the company, an audit of follow-up can be scheduled.\n\nWhen setting the agenda for the review, the following points should be considered:\n\n- The documentation must be complete, up to date and correct, including:\n- \u2713 Specification and verification;\n- \u2713 Operation and maintenance;\n- \u2713 List of configuration items.\n- Records of any changes made to the system;\n- The level of change made to the system and the nature of the change;\n- Exceptional actions required by a Validation Report;\n- Reports of previous audits and the respective actions taken;\n- Any controls implemented to manage risks that are still in place effective;\n- Evidence of unstable or unreliable operation;\n- Changes in the environment, process or business requirements, legislation or accepted best practices;", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 1787, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "c716a4f7-919b-4f96-b072-04b27b74bd14": {"__data__": {"id_": "c716a4f7-919b-4f96-b072-04b27b74bd14", "embedding": null, "metadata": {"page_label": "81", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "- Operational procedures;\n- Business Continuity Planning;\n- Personnel (including qualifications, training, experience and continuity);\n- System security and access control;\n- System maintenance and incident records;\n- Backups of software and data.\n\n## 11.9.6 Execution of Activities\n\nReview activities involve the following actions:\n\n1. Definition of the policy and process for establishing time and scheduling reviews periodic - Can be system specific, defined in the respective Inspection Reports; defined in the List Computerized Systems Inventory, based on triggers or events;\n2. Preparation for conducting the review - Evidence may include plans, records of previous incidents / changes, audits or reviews;\n3. Performing the review;\n4. Documentation of the results of the review;\n5. Execution of Corrective Action, if applicable.\n\n## 11.10 BACKUP AND RESTORATION\n\n### 11.10.1 Introduction\n\nBackup is the process of copying records, data and software to protect against loss of integrity or availability of the original. Restoration is the subsequent restoration of records, data or software when requested / required.\n\nBackup and restore should not be confused with archiving and recovery.\n\n----\n\n## 11.10.2 Key requirements\n\nProcedures must be in place to describe and discriminate against backups of records, data and software, carried out routinely, to a safe storage location and adequately separated from the place of primary storage. The frequency of running the backup procedure should be based on a risk assessment.\n\nWritten procedures must be in place to ensure the restoration and maintenance of records and data relevant to GMP, in the event of failure.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos establece procedimientos operativos esenciales para garantizar la integridad y disponibilidad de los datos en entornos regulados. Se enfoca en la planificaci\u00f3n de continuidad del negocio, la capacitaci\u00f3n del personal, la seguridad del sistema, el mantenimiento y la gesti\u00f3n de copias de seguridad. Adem\u00e1s, detalla los pasos necesarios para llevar a cabo revisiones peri\u00f3dicas y los requisitos clave para la realizaci\u00f3n de copias de seguridad y restauraci\u00f3n de datos.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfCu\u00e1les son los pasos espec\u00edficos que deben seguirse para llevar a cabo una revisi\u00f3n peri\u00f3dica de un sistema inform\u00e1tico seg\u00fan el documento de ANVISA?**\n   - Respuesta: Los pasos incluyen la definici\u00f3n de la pol\u00edtica y proceso para establecer el tiempo y la programaci\u00f3n de revisiones, la preparaci\u00f3n para la revisi\u00f3n, la realizaci\u00f3n de la revisi\u00f3n, la documentaci\u00f3n de los resultados y la ejecuci\u00f3n de acciones correctivas si es necesario.\n\n2. **\u00bfQu\u00e9 diferencias existen entre los procesos de copia de seguridad y restauraci\u00f3n en comparaci\u00f3n con el archivo y la recuperaci\u00f3n, seg\u00fan el documento?**\n   - Respuesta: La copia de seguridad es el proceso de copiar registros, datos y software para protegerse contra la p\u00e9rdida de integridad o disponibilidad, mientras que la restauraci\u00f3n es la recuperaci\u00f3n de esos registros o datos cuando se requiere. Esto se diferencia del archivo, que implica almacenar datos de manera que no se utilicen regularmente, y la recuperaci\u00f3n, que se refiere a la restauraci\u00f3n de datos despu\u00e9s de un evento de p\u00e9rdida.\n\n3. **\u00bfQu\u00e9 requisitos clave se deben cumplir para la realizaci\u00f3n de copias de seguridad de registros y datos seg\u00fan el documento de ANVISA?**\n   - Respuesta: Se deben establecer procedimientos que describan las copias de seguridad de registros, datos y software, que se realicen de manera rutinaria en una ubicaci\u00f3n de almacenamiento segura, separada del almacenamiento primario. La frecuencia de las copias de seguridad debe basarse en una evaluaci\u00f3n de riesgos, y deben existir procedimientos escritos para garantizar la restauraci\u00f3n y el mantenimiento de registros y datos relevantes para las Buenas Pr\u00e1cticas de Manufactura (GMP) en caso de fallo.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n#### Temas Clave:\n1. **Preparaci\u00f3n para la Revisi\u00f3n**:\n   - Importancia de la documentaci\u00f3n relevante para la revisi\u00f3n del sistema.\n   - Definici\u00f3n de objetivos, equipo y agenda para la revisi\u00f3n.\n   - Compromiso del propietario del proceso con los resultados de la revisi\u00f3n.\n\n2. **Documentaci\u00f3n Esencial**:\n   - Tipos de documentaci\u00f3n necesarios: planes, especificaciones, pruebas, informes, documentaci\u00f3n de gesti\u00f3n de riesgos, manuales de usuario, procedimientos operativos est\u00e1ndar, informaci\u00f3n de gesti\u00f3n de configuraci\u00f3n, registros de incidentes, y reportes de auditor\u00edas previas.\n\n3. **Conducci\u00f3n de la Revisi\u00f3n**:\n   - Documentaci\u00f3n de problemas encontrados y acciones correctivas recomendadas.\n   - Consideraciones para establecer la agenda de la revisi\u00f3n, incluyendo la completitud y actualidad de la documentaci\u00f3n, registros de cambios, y controles de gesti\u00f3n de riesgos.\n\n4. **Acciones Correctivas**:\n   - Proceso de seguimiento en caso de problemas identificados durante la revisi\u00f3n.\n\n#### Entidades:\n- **Documentaci\u00f3n**: Planes, especificaciones, pruebas, informes, manuales de usuario, etc.\n- **Equipo de Revisi\u00f3n**: Grupo responsable de llevar a cabo la revisi\u00f3n del sistema.\n- **Propietario del Proceso**: Persona o entidad comprometida con los resultados de la revisi\u00f3n.\n- **Auditor\u00eda**: Proceso de seguimiento para asegurar que se aborden los problemas identificados.\n- **Controles de Riesgo**: Medidas implementadas para gestionar riesgos en el sistema.\n\nEste resumen destaca la importancia de la preparaci\u00f3n y la documentaci\u00f3n en el proceso de revisi\u00f3n de sistemas, as\u00ed como la necesidad de un enfoque sistem\u00e1tico para abordar problemas y asegurar la conformidad con las normativas.", "excerpt_keywords": "Keywords: validation, backup, restoration, compliance, operational procedures"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "3dc021b5-fabf-4e32-8fe0-abeeb3fce5ef", "node_type": "4", "metadata": {"page_label": "81", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "- Operational procedures;\n- Business Continuity Planning;\n- Personnel (including qualifications, training, experience and continuity);\n- System security and access control;\n- System maintenance and incident records;\n- Backups of software and data.\n\n## 11.9.6 Execution of Activities\n\nReview activities involve the following actions:\n\n1. Definition of the policy and process for establishing time and scheduling reviews periodic - Can be system specific, defined in the respective Inspection Reports; defined in the List Computerized Systems Inventory, based on triggers or events;\n2. Preparation for conducting the review - Evidence may include plans, records of previous incidents / changes, audits or reviews;\n3. Performing the review;\n4. Documentation of the results of the review;\n5. Execution of Corrective Action, if applicable.\n\n## 11.10 BACKUP AND RESTORATION\n\n### 11.10.1 Introduction\n\nBackup is the process of copying records, data and software to protect against loss of integrity or availability of the original. Restoration is the subsequent restoration of records, data or software when requested / required.\n\nBackup and restore should not be confused with archiving and recovery.\n\n----\n\n## 11.10.2 Key requirements\n\nProcedures must be in place to describe and discriminate against backups of records, data and software, carried out routinely, to a safe storage location and adequately separated from the place of primary storage. The frequency of running the backup procedure should be based on a risk assessment.\n\nWritten procedures must be in place to ensure the restoration and maintenance of records and data relevant to GMP, in the event of failure.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "6afb200fdd7b6568844595f417b440182fad78c955b3c11a5ae3151012611325", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "- Operational procedures;\n- Business Continuity Planning;\n- Personnel (including qualifications, training, experience and continuity);\n- System security and access control;\n- System maintenance and incident records;\n- Backups of software and data.\n\n## 11.9.6 Execution of Activities\n\nReview activities involve the following actions:\n\n1. Definition of the policy and process for establishing time and scheduling reviews periodic - Can be system specific, defined in the respective Inspection Reports; defined in the List Computerized Systems Inventory, based on triggers or events;\n2. Preparation for conducting the review - Evidence may include plans, records of previous incidents / changes, audits or reviews;\n3. Performing the review;\n4. Documentation of the results of the review;\n5. Execution of Corrective Action, if applicable.\n\n## 11.10 BACKUP AND RESTORATION\n\n### 11.10.1 Introduction\n\nBackup is the process of copying records, data and software to protect against loss of integrity or availability of the original. Restoration is the subsequent restoration of records, data or software when requested / required.\n\nBackup and restore should not be confused with archiving and recovery.\n\n----\n\n## 11.10.2 Key requirements\n\nProcedures must be in place to describe and discriminate against backups of records, data and software, carried out routinely, to a safe storage location and adequately separated from the place of primary storage. The frequency of running the backup procedure should be based on a risk assessment.\n\nWritten procedures must be in place to ensure the restoration and maintenance of records and data relevant to GMP, in the event of failure.", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 1669, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "519bc754-1312-4f67-830e-516f302b7c80": {"__data__": {"id_": "519bc754-1312-4f67-830e-516f302b7c80", "embedding": null, "metadata": {"page_label": "82", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "The backup procedure, storage facilities and media used must ensure the integrity of Dice. There should be a record of the backup performed, with references to the media used for storage.\n\nThe storage medium used must be documented and justified as to its reliability.\n\nBackup processes must be verified when they are established. Additionally, there must be procedures and plans for regular testing of the ability to perform backup and restore. These actions must be documented.\n\n## 11.10.3 Responsibilities\n\nThe process owner is responsible for:\n\n- Definition of the data that need backup, including the data relevant to GMP;\n- Definition of availability and access control requirements for GMP-relevant data.\n\nThe system owner is responsible for:\n\n- Ensure that the organization of the backup and restoration of the software for the operating system is defined meet the applicable regulations, in accordance with the Quality Assurance guidelines, when applicable;\n- Ensure proper backup and restore performance of software and data for the system operational;\n- Ensure appropriate access controls.\n\n## 11.10.4 Backup and Restore Process\n\n### 11.10.4.1 Backup Media\n\nThe backup must be performed on suitable media and it must be used according to the recommendation of the manufacturers.\n\nWhen selecting and using storage media, the following points should be considered:\n\n- The average life expectancy;\n- The acceptable environmental conditions for its storage;\n- Requirements for verification, renewal and overwriting.\n\nGuidance on storage, transport and maintenance of various types of media, magnetic and optical, used in data storage are generally available in the documentation provided by the manufacturer of product.\n\n## 11.10.4.2 Backup of the Operating System\n\nThe backups of software are designed to ensure that the latest and correct version of the software is available.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas basadas en el contexto proporcionado, junto con sus respuestas:\n\n### Preguntas y Respuestas\n\n1. **\u00bfCu\u00e1les son las responsabilidades espec\u00edficas del propietario del proceso en relaci\u00f3n con el respaldo de datos relevantes para GMP?**\n   - **Respuesta:** El propietario del proceso es responsable de definir los datos que necesitan respaldo, incluyendo aquellos relevantes para las Buenas Pr\u00e1cticas de Manufactura (GMP), as\u00ed como de establecer los requisitos de disponibilidad y control de acceso para esos datos.\n\n2. **\u00bfQu\u00e9 aspectos deben considerarse al seleccionar y utilizar medios de almacenamiento para respaldos?**\n   - **Respuesta:** Al seleccionar y utilizar medios de almacenamiento para respaldos, se deben considerar la expectativa de vida promedio del medio, las condiciones ambientales aceptables para su almacenamiento, y los requisitos para la verificaci\u00f3n, renovaci\u00f3n y sobrescritura del medio.\n\n3. **\u00bfQu\u00e9 documentaci\u00f3n se requiere para los procesos de respaldo y restauraci\u00f3n?**\n   - **Respuesta:** Se requiere que los procesos de respaldo sean verificados al establecerse, y que existan procedimientos y planes para pruebas regulares de la capacidad de realizar respaldos y restauraciones. Todas estas acciones deben ser documentadas adecuadamente.\n\n### Resumen de Nivel Superior\n\nEl contexto aborda la importancia de los procedimientos de respaldo y restauraci\u00f3n en sistemas inform\u00e1ticos, enfatizando la necesidad de asegurar la integridad de los datos, especialmente aquellos relevantes para las Buenas Pr\u00e1cticas de Manufactura (GMP). Se detallan las responsabilidades de los propietarios de procesos y sistemas, as\u00ed como los criterios para seleccionar medios de almacenamiento adecuados. Adem\u00e1s, se subraya la importancia de la documentaci\u00f3n y verificaci\u00f3n de los procesos de respaldo.\n\n### Preguntas Adicionales Basadas en el Resumen\n\n1. **\u00bfPor qu\u00e9 es crucial documentar los medios de almacenamiento utilizados para los respaldos?**\n   - **Respuesta:** Es crucial documentar los medios de almacenamiento utilizados para los respaldos para justificar su fiabilidad y asegurar que se cumplen los requisitos de calidad y regulaciones aplicables.\n\n2. **\u00bfQu\u00e9 tipo de pruebas deben realizarse regularmente en los procesos de respaldo y restauraci\u00f3n?**\n   - **Respuesta:** Deben realizarse pruebas regulares para verificar la capacidad de realizar respaldos y restauraciones efectivas, asegurando que los datos pueden ser recuperados de manera confiable en caso de p\u00e9rdida.\n\n3. **\u00bfQu\u00e9 se entiende por \"integridad de Dice\" en el contexto de los procedimientos de respaldo?**\n   - **Respuesta:** La \"integridad de Dice\" se refiere a la protecci\u00f3n y conservaci\u00f3n de la informaci\u00f3n y datos almacenados, asegurando que no se pierdan ni se corrompan durante el proceso de respaldo y restauraci\u00f3n.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Procedimientos Operativos**: Se enfatiza la importancia de tener procedimientos operativos bien definidos para garantizar la integridad y disponibilidad de los datos en sistemas inform\u00e1ticos regulados.\n\n2. **Planificaci\u00f3n de Continuidad del Negocio**: Se menciona la necesidad de establecer planes que aseguren la continuidad de las operaciones en caso de incidentes.\n\n3. **Personal**: Se aborda la importancia de contar con personal calificado, capacitado y con experiencia, as\u00ed como la continuidad en su formaci\u00f3n.\n\n4. **Seguridad del Sistema y Control de Acceso**: Se requiere implementar medidas de seguridad para proteger los sistemas y controlar el acceso a los mismos.\n\n5. **Mantenimiento del Sistema y Registros de Incidentes**: Se deben llevar registros de mantenimiento y de incidentes para asegurar la trazabilidad y la mejora continua.\n\n6. **Copias de Seguridad de Software y Datos**: Se establece la necesidad de realizar copias de seguridad de manera rutinaria y en ubicaciones seguras, separadas del almacenamiento primario.\n\n### Ejecuci\u00f3n de Actividades de Revisi\u00f3n\n\n- **Definici\u00f3n de Pol\u00edticas**: Establecer pol\u00edticas y procesos para programar revisiones peri\u00f3dicas.\n- **Preparaci\u00f3n para la Revisi\u00f3n**: Reunir evidencia relevante, como planes y registros de incidentes anteriores.\n- **Realizaci\u00f3n de la Revisi\u00f3n**: Llevar a cabo la revisi\u00f3n seg\u00fan lo planificado.\n- **Documentaci\u00f3n de Resultados**: Registrar los hallazgos de la revisi\u00f3n.\n- **Acciones Correctivas**: Implementar acciones correctivas si se identifican problemas.\n\n### Copias de Seguridad y Restauraci\u00f3n\n\n- **Definici\u00f3n de Copia de Seguridad**: Proceso de copiar datos y software para protegerse contra la p\u00e9rdida de integridad o disponibilidad.\n- **Restauraci\u00f3n**: Proceso de recuperar datos o software cuando sea necesario.\n- **Diferenciaci\u00f3n**: Se aclara que las copias de seguridad y la restauraci\u00f3n no son lo mismo que el archivo y la recuperaci\u00f3n.\n\n### Requisitos Clave para Copias de Seguridad\n\n- **Procedimientos Escritos**: Deben existir procedimientos que describan c\u00f3mo se realizan las copias de seguridad y la restauraci\u00f3n de datos.\n- **Frecuencia Basada en Riesgos**: La frecuencia de las copias de seguridad debe determinarse a partir de una evaluaci\u00f3n de riesgos.\n- **Mantenimiento de Registros**: Asegurar la restauraci\u00f3n y mantenimiento de registros relevantes para las Buenas Pr\u00e1cticas de Manufactura (GMP) en caso de fallos.\n\nEste resumen abarca los aspectos fundamentales del documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos, destacando la importancia de la planificaci\u00f3n, la seguridad y la gesti\u00f3n de datos.", "excerpt_keywords": "Keywords: backup procedure, data integrity, GMP compliance, storage media, system validation"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "812a04f9-69bf-4f1b-91c1-bf1e942e3394", "node_type": "4", "metadata": {"page_label": "82", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "The backup procedure, storage facilities and media used must ensure the integrity of Dice. There should be a record of the backup performed, with references to the media used for storage.\n\nThe storage medium used must be documented and justified as to its reliability.\n\nBackup processes must be verified when they are established. Additionally, there must be procedures and plans for regular testing of the ability to perform backup and restore. These actions must be documented.\n\n## 11.10.3 Responsibilities\n\nThe process owner is responsible for:\n\n- Definition of the data that need backup, including the data relevant to GMP;\n- Definition of availability and access control requirements for GMP-relevant data.\n\nThe system owner is responsible for:\n\n- Ensure that the organization of the backup and restoration of the software for the operating system is defined meet the applicable regulations, in accordance with the Quality Assurance guidelines, when applicable;\n- Ensure proper backup and restore performance of software and data for the system operational;\n- Ensure appropriate access controls.\n\n## 11.10.4 Backup and Restore Process\n\n### 11.10.4.1 Backup Media\n\nThe backup must be performed on suitable media and it must be used according to the recommendation of the manufacturers.\n\nWhen selecting and using storage media, the following points should be considered:\n\n- The average life expectancy;\n- The acceptable environmental conditions for its storage;\n- Requirements for verification, renewal and overwriting.\n\nGuidance on storage, transport and maintenance of various types of media, magnetic and optical, used in data storage are generally available in the documentation provided by the manufacturer of product.\n\n## 11.10.4.2 Backup of the Operating System\n\nThe backups of software are designed to ensure that the latest and correct version of the software is available.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "c244c84e0621f5b2bfa0268c3cb4568387c06c9cbfaad084dc1df1dabcb59f77", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "The backup procedure, storage facilities and media used must ensure the integrity of Dice. There should be a record of the backup performed, with references to the media used for storage.\n\nThe storage medium used must be documented and justified as to its reliability.\n\nBackup processes must be verified when they are established. Additionally, there must be procedures and plans for regular testing of the ability to perform backup and restore. These actions must be documented.\n\n## 11.10.3 Responsibilities\n\nThe process owner is responsible for:\n\n- Definition of the data that need backup, including the data relevant to GMP;\n- Definition of availability and access control requirements for GMP-relevant data.\n\nThe system owner is responsible for:\n\n- Ensure that the organization of the backup and restoration of the software for the operating system is defined meet the applicable regulations, in accordance with the Quality Assurance guidelines, when applicable;\n- Ensure proper backup and restore performance of software and data for the system operational;\n- Ensure appropriate access controls.\n\n## 11.10.4 Backup and Restore Process\n\n### 11.10.4.1 Backup Media\n\nThe backup must be performed on suitable media and it must be used according to the recommendation of the manufacturers.\n\nWhen selecting and using storage media, the following points should be considered:\n\n- The average life expectancy;\n- The acceptable environmental conditions for its storage;\n- Requirements for verification, renewal and overwriting.\n\nGuidance on storage, transport and maintenance of various types of media, magnetic and optical, used in data storage are generally available in the documentation provided by the manufacturer of product.\n\n## 11.10.4.2 Backup of the Operating System\n\nThe backups of software are designed to ensure that the latest and correct version of the software is available.", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 1885, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "8c01c01b-3a92-41b6-9eb8-869049a840c9": {"__data__": {"id_": "8c01c01b-3a92-41b6-9eb8-869049a840c9", "embedding": null, "metadata": {"page_label": "83", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "and can be restored in a short time and without error, in case of failure or after changes made during development.\n\nAll software components required for the operating system must be included in the scope of the backup to ensure that the entire system can be restored.\n\nThe process backup of the software should be defined and documented. This backup can occur:\n\n- After any modification of the software, in which case backing up the components modified software may be sufficient. This activity should be documented as part of the control of changes;\n- At regular intervals (e.g. annually) as a full backup, based on the risk and nature of the business.\n\nBackup copies must be stored in a safe place.\n\nBackup media must be physically safe and protected from fire, water and other hazards. The process of storage, standards and access must be defined and documented.\n\nAt least two generations of backup copies must be stored: the current one and the one before the last change fulfilled. Based on the risk, it may be advisable to keep more generations to avoid the possibility of propagation of errors in all available backup copies.\n\nThe following data must be clearly associated with the backup media, either on the label or in a record, in a traceable manner:\n\n- Creation date;\n- System designation;\n- Software designation;\n- Model and/or software/firmware build number (build number), if applicable;\n- Current number (generation and possible multiple backups);\n- Reason for backing up the software;\n- Backup date;\n- Identity of the person who performed the backup.\n\nBackups of the software should be performed while the system is operating. Backup logs performed must be maintained. Backup and restore instructions should be stored securely together with the backup media.\n\nRisk-based and process backup, the transactions backup should be reviewed periodically and Backup restoration should be periodically performed to verify that it will work correctly when required.\n\n## 11.10.4.3 Backup of Data\n\nElectronic data relevant to GMP must be kept secure for the defined retention time. While data is often kept on a hard disk using redundancy concepts or mirrored disks, additional backups of GMP-relevant data form a key part of preventing", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos establece directrices sobre la importancia de realizar copias de seguridad de software y datos relevantes para las Buenas Pr\u00e1cticas de Manufactura (GMP). Se enfatiza la necesidad de documentar el proceso de copia de seguridad, almacenar las copias en lugares seguros, y mantener registros claros sobre las copias de seguridad realizadas. Adem\u00e1s, se menciona la importancia de realizar copias de seguridad peri\u00f3dicas y de verificar la restauraci\u00f3n de datos para asegurar su integridad y disponibilidad.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfQu\u00e9 informaci\u00f3n debe estar claramente asociada con los medios de copia de seguridad seg\u00fan el documento de ANVISA?**\n   - El documento especifica que deben estar asociadas las siguientes informaciones: fecha de creaci\u00f3n, designaci\u00f3n del sistema, designaci\u00f3n del software, n\u00famero de modelo y/o n\u00famero de compilaci\u00f3n de software/firmware, n\u00famero actual (generaci\u00f3n y posibles copias m\u00faltiples), raz\u00f3n para la copia de seguridad, fecha de copia de seguridad e identidad de la persona que realiz\u00f3 la copia.\n\n2. **\u00bfCu\u00e1les son las recomendaciones sobre la frecuencia de las copias de seguridad de software y en qu\u00e9 situaciones se deben realizar?**\n   - Se recomienda realizar copias de seguridad despu\u00e9s de cualquier modificaci\u00f3n del software y a intervalos regulares (por ejemplo, anualmente) como una copia de seguridad completa, dependiendo del riesgo y la naturaleza del negocio.\n\n3. **\u00bfQu\u00e9 medidas de seguridad se deben tomar para el almacenamiento de las copias de seguridad?**\n   - Las copias de seguridad deben almacenarse en un lugar seguro, y los medios de copia de seguridad deben estar f\u00edsicamente protegidos contra incendios, agua y otros peligros. Adem\u00e1s, el proceso de almacenamiento, est\u00e1ndares y acceso debe estar definido y documentado.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n**Temas Clave:**\n\n1. **Procedimientos de Respaldo:**\n   - Importancia de asegurar la integridad de los datos durante el proceso de respaldo.\n   - Necesidad de documentar y justificar los medios de almacenamiento utilizados.\n\n2. **Responsabilidades:**\n   - **Propietario del Proceso:** Define los datos que necesitan respaldo y los requisitos de disponibilidad y control de acceso para datos relevantes a las Buenas Pr\u00e1cticas de Manufactura (GMP).\n   - **Propietario del Sistema:** Asegura que los procesos de respaldo y restauraci\u00f3n cumplan con las regulaciones aplicables y las directrices de Aseguramiento de Calidad.\n\n3. **Medios de Respaldo:**\n   - Selecci\u00f3n de medios adecuados considerando la expectativa de vida, condiciones ambientales y requisitos de verificaci\u00f3n.\n   - Uso de medios de almacenamiento de acuerdo con las recomendaciones del fabricante.\n\n4. **Verificaci\u00f3n y Documentaci\u00f3n:**\n   - Los procesos de respaldo deben ser verificados al establecerse.\n   - Se deben tener procedimientos y planes para pruebas regulares de respaldo y restauraci\u00f3n, todos documentados adecuadamente.\n\n5. **Respaldo del Sistema Operativo:**\n   - Asegurar que se disponga de la versi\u00f3n m\u00e1s reciente y correcta del software a trav\u00e9s de respaldos.\n\n**Entidades:**\n\n- **GMP (Buenas Pr\u00e1cticas de Manufactura):** Normativas relevantes para la industria que deben ser consideradas en los procesos de respaldo.\n- **Propietario del Proceso:** Persona responsable de la definici\u00f3n de datos y requisitos de acceso.\n- **Propietario del Sistema:** Persona encargada de la organizaci\u00f3n y cumplimiento de los procesos de respaldo y restauraci\u00f3n.\n- **Medios de Almacenamiento:** Dispositivos utilizados para realizar respaldos, que deben ser seleccionados y utilizados adecuadamente.\n- **Documentaci\u00f3n:** Registros que deben mantenerse para verificar y validar los procesos de respaldo y restauraci\u00f3n.\n\nEste resumen destaca la importancia de los procedimientos de respaldo en sistemas inform\u00e1ticos, enfatizando la necesidad de responsabilidades claras, selecci\u00f3n adecuada de medios y documentaci\u00f3n rigurosa para garantizar la integridad y disponibilidad de los datos.", "excerpt_keywords": "Keywords: backup, software validation, GMP, data security, documentation"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "63a2000e-1fd5-4a74-860f-59a3fe0b7e91", "node_type": "4", "metadata": {"page_label": "83", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "and can be restored in a short time and without error, in case of failure or after changes made during development.\n\nAll software components required for the operating system must be included in the scope of the backup to ensure that the entire system can be restored.\n\nThe process backup of the software should be defined and documented. This backup can occur:\n\n- After any modification of the software, in which case backing up the components modified software may be sufficient. This activity should be documented as part of the control of changes;\n- At regular intervals (e.g. annually) as a full backup, based on the risk and nature of the business.\n\nBackup copies must be stored in a safe place.\n\nBackup media must be physically safe and protected from fire, water and other hazards. The process of storage, standards and access must be defined and documented.\n\nAt least two generations of backup copies must be stored: the current one and the one before the last change fulfilled. Based on the risk, it may be advisable to keep more generations to avoid the possibility of propagation of errors in all available backup copies.\n\nThe following data must be clearly associated with the backup media, either on the label or in a record, in a traceable manner:\n\n- Creation date;\n- System designation;\n- Software designation;\n- Model and/or software/firmware build number (build number), if applicable;\n- Current number (generation and possible multiple backups);\n- Reason for backing up the software;\n- Backup date;\n- Identity of the person who performed the backup.\n\nBackups of the software should be performed while the system is operating. Backup logs performed must be maintained. Backup and restore instructions should be stored securely together with the backup media.\n\nRisk-based and process backup, the transactions backup should be reviewed periodically and Backup restoration should be periodically performed to verify that it will work correctly when required.\n\n## 11.10.4.3 Backup of Data\n\nElectronic data relevant to GMP must be kept secure for the defined retention time. While data is often kept on a hard disk using redundancy concepts or mirrored disks, additional backups of GMP-relevant data form a key part of preventing", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "2fa43a245f891c10bf587cedbaa69e4db4630c35a157be13ca2dc72cce0b93eb", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "and can be restored in a short time and without error, in case of failure or after changes made during development.\n\nAll software components required for the operating system must be included in the scope of the backup to ensure that the entire system can be restored.\n\nThe process backup of the software should be defined and documented. This backup can occur:\n\n- After any modification of the software, in which case backing up the components modified software may be sufficient. This activity should be documented as part of the control of changes;\n- At regular intervals (e.g. annually) as a full backup, based on the risk and nature of the business.\n\nBackup copies must be stored in a safe place.\n\nBackup media must be physically safe and protected from fire, water and other hazards. The process of storage, standards and access must be defined and documented.\n\nAt least two generations of backup copies must be stored: the current one and the one before the last change fulfilled. Based on the risk, it may be advisable to keep more generations to avoid the possibility of propagation of errors in all available backup copies.\n\nThe following data must be clearly associated with the backup media, either on the label or in a record, in a traceable manner:\n\n- Creation date;\n- System designation;\n- Software designation;\n- Model and/or software/firmware build number (build number), if applicable;\n- Current number (generation and possible multiple backups);\n- Reason for backing up the software;\n- Backup date;\n- Identity of the person who performed the backup.\n\nBackups of the software should be performed while the system is operating. Backup logs performed must be maintained. Backup and restore instructions should be stored securely together with the backup media.\n\nRisk-based and process backup, the transactions backup should be reviewed periodically and Backup restoration should be periodically performed to verify that it will work correctly when required.\n\n## 11.10.4.3 Backup of Data\n\nElectronic data relevant to GMP must be kept secure for the defined retention time. While data is often kept on a hard disk using redundancy concepts or mirrored disks, additional backups of GMP-relevant data form a key part of preventing", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 2242, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "67088541-d093-471b-a8a6-a237b7cc7f6b": {"__data__": {"id_": "67088541-d093-471b-a8a6-a237b7cc7f6b", "embedding": null, "metadata": {"page_label": "84", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "loss of data in case of system failure. The data must be recoverable in a short time and without error and copies kept remotely to avoid loss due to some common failure in one location (e.g., fire). The type and frequency of the **backup** should be based on risk.\n\nThe data must be periodically saved on the **backup media**. The system owner must establish and document the organization of data **backups**, covering the following aspects:\n\n- **Backup types** (full or incremental);\n- **Interval**: daily, weekly, monthly, quarterly, annual or non-cyclical (permanent retention);\n- **Number of generations**. The number of generations defines the number of identically performed backups that are maintained. Since **backup** media is often reused, after the number of generations has been reached, subsequent **backups** will be overwritten over the oldest **backup**. For example: if the number of generations set to four, the fifth **backup** will overwrite the first, the sixth will overwrite the second and so on;\n- **Backup failure** - Actions to be taken in case of **backup** failure must be established, such as a repeat **backup** during the day. Actions taken in the event of failure should be documented (e.g., logbook) by the person responsible for the computerized system;\n- **Backup Media Labeling**. The following items must appear on the media label, or registered at record book: system designation; **software / data designation**; version and / or build number the **software / firmware** (if applicable); creation date; date of first use; current number (generations, possible multiple backups); **backup** date; reason for **backup** and operator identity;\n- **Duration of use**. The media should only be used for as long as it is guaranteed;\n- The type of media used must be documented;\n- **Storage Location**. Storage locations must be safe and properly identified and traceable;\n- **Data Backup Tools and Corresponding Procedures**. GMP-relevant data should be stored in an appropriate way that allows their restoration. The location and name of the procedure control must be documented. Procedures must cover restoration, verification activities and restart after system failure;\n- **Data Backup Review**. The process owner, or delegated person, is responsible for ensuring successful **backup**. Faults should be investigated and defective storage media potentials must be discarded and replaced. The actions must be documented in a record book.\n\n## 11.10.4.4 Restoration\n\nWritten and tested procedures must be used to perform the restoration. When the restoration is performed manually, this must be registered and signed.\n\nThe process owner, or delegated person, must authorize the restoration of data. These people are the responsible for ensuring that the restoration procedure is in compliance with the regulations of Good habits.\n\nIf the restoration is motivated by technical reasons, the owner of the process and the owner of the system must make a assessment of the process and possible risks. The restoration method used and the control of the restoration must be documented.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos establece directrices claras sobre la gesti\u00f3n de copias de seguridad (backups) y la restauraci\u00f3n de datos en caso de fallos del sistema. Se enfatiza la importancia de la recuperaci\u00f3n de datos de manera r\u00e1pida y sin errores, as\u00ed como la necesidad de mantener copias de seguridad en ubicaciones remotas para evitar p\u00e9rdidas. Se detallan aspectos como los tipos de copias de seguridad, la frecuencia, la gesti\u00f3n de fallos, el etiquetado de medios de copia de seguridad, y la documentaci\u00f3n necesaria para garantizar la integridad y disponibilidad de los datos.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfCu\u00e1les son los criterios que deben considerarse al establecer el intervalo de copias de seguridad seg\u00fan el documento de ANVISA?**\n   - El intervalo de copias de seguridad debe basarse en el riesgo asociado a la p\u00e9rdida de datos, y puede ser diario, semanal, mensual, trimestral, anual o no c\u00edclico (retenci\u00f3n permanente).\n\n2. **\u00bfQu\u00e9 informaci\u00f3n debe incluirse en la etiqueta de los medios de copia de seguridad seg\u00fan las directrices de ANVISA?**\n   - La etiqueta debe incluir: designaci\u00f3n del sistema, designaci\u00f3n del software/datos, versi\u00f3n y/o n\u00famero de compilaci\u00f3n del software/firmware (si aplica), fecha de creaci\u00f3n, fecha de primer uso, n\u00famero actual (generaciones, posibles copias m\u00faltiples), fecha de copia de seguridad, raz\u00f3n de la copia de seguridad e identidad del operador.\n\n3. **\u00bfQu\u00e9 acciones deben tomarse en caso de fallo en la copia de seguridad y c\u00f3mo deben documentarse?**\n   - Se deben establecer acciones a seguir en caso de fallo, como repetir la copia de seguridad durante el d\u00eda. Las acciones tomadas deben ser documentadas en un libro de registro por la persona responsable del sistema computarizado.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\nEl contenido de la secci\u00f3n se centra en las directrices para la copia de seguridad de software y datos en el contexto de la validaci\u00f3n de sistemas inform\u00e1ticos seg\u00fan ANVISA. A continuaci\u00f3n se presentan los temas clave y entidades relevantes:\n\n#### Temas Clave:\n1. **Importancia de las Copias de Seguridad**: Se enfatiza la necesidad de realizar copias de seguridad para asegurar la recuperaci\u00f3n del sistema en caso de fallos o modificaciones.\n2. **Documentaci\u00f3n del Proceso**: El proceso de copia de seguridad debe ser definido y documentado, incluyendo las circunstancias bajo las cuales se realizan las copias.\n3. **Frecuencia de las Copias de Seguridad**: Se recomienda realizar copias de seguridad despu\u00e9s de modificaciones y a intervalos regulares (por ejemplo, anualmente).\n4. **Almacenamiento Seguro**: Las copias de seguridad deben almacenarse en lugares seguros y los medios de copia deben estar protegidos contra riesgos f\u00edsicos como incendios y agua.\n5. **Generaciones de Copias de Seguridad**: Se deben mantener al menos dos generaciones de copias de seguridad para evitar la propagaci\u00f3n de errores.\n6. **Datos Asociados a las Copias de Seguridad**: Se debe registrar informaci\u00f3n clave como la fecha de creaci\u00f3n, designaci\u00f3n del sistema y software, y la identidad de la persona que realiz\u00f3 la copia.\n7. **Mantenimiento de Registros**: Se deben mantener registros de las copias de seguridad y las instrucciones de restauraci\u00f3n deben almacenarse de manera segura.\n8. **Revisi\u00f3n Peri\u00f3dica**: Las copias de seguridad y su restauraci\u00f3n deben ser revisadas peri\u00f3dicamente para asegurar su efectividad.\n\n#### Entidades:\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil, responsable de la regulaci\u00f3n de la salud p\u00fablica.\n- **GMP**: Buenas Pr\u00e1cticas de Manufactura, que se refiere a las pr\u00e1cticas que aseguran que los productos sean producidos y controlados de acuerdo con est\u00e1ndares de calidad.\n- **Software**: Componentes de software que requieren copias de seguridad.\n- **Datos Electr\u00f3nicos**: Informaci\u00f3n relevante para GMP que debe ser protegida y respaldada.\n\nEste resumen destaca la importancia de un enfoque sistem\u00e1tico y documentado para la gesti\u00f3n de copias de seguridad en sistemas inform\u00e1ticos, asegurando la integridad y disponibilidad de los datos cr\u00edticos.", "excerpt_keywords": "Keywords: backups, data recovery, ANVISA, system validation, documentation"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "1ec71e0f-34db-4e11-8e7b-07dd594810ec", "node_type": "4", "metadata": {"page_label": "84", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "loss of data in case of system failure. The data must be recoverable in a short time and without error and copies kept remotely to avoid loss due to some common failure in one location (e.g., fire). The type and frequency of the **backup** should be based on risk.\n\nThe data must be periodically saved on the **backup media**. The system owner must establish and document the organization of data **backups**, covering the following aspects:\n\n- **Backup types** (full or incremental);\n- **Interval**: daily, weekly, monthly, quarterly, annual or non-cyclical (permanent retention);\n- **Number of generations**. The number of generations defines the number of identically performed backups that are maintained. Since **backup** media is often reused, after the number of generations has been reached, subsequent **backups** will be overwritten over the oldest **backup**. For example: if the number of generations set to four, the fifth **backup** will overwrite the first, the sixth will overwrite the second and so on;\n- **Backup failure** - Actions to be taken in case of **backup** failure must be established, such as a repeat **backup** during the day. Actions taken in the event of failure should be documented (e.g., logbook) by the person responsible for the computerized system;\n- **Backup Media Labeling**. The following items must appear on the media label, or registered at record book: system designation; **software / data designation**; version and / or build number the **software / firmware** (if applicable); creation date; date of first use; current number (generations, possible multiple backups); **backup** date; reason for **backup** and operator identity;\n- **Duration of use**. The media should only be used for as long as it is guaranteed;\n- The type of media used must be documented;\n- **Storage Location**. Storage locations must be safe and properly identified and traceable;\n- **Data Backup Tools and Corresponding Procedures**. GMP-relevant data should be stored in an appropriate way that allows their restoration. The location and name of the procedure control must be documented. Procedures must cover restoration, verification activities and restart after system failure;\n- **Data Backup Review**. The process owner, or delegated person, is responsible for ensuring successful **backup**. Faults should be investigated and defective storage media potentials must be discarded and replaced. The actions must be documented in a record book.\n\n## 11.10.4.4 Restoration\n\nWritten and tested procedures must be used to perform the restoration. When the restoration is performed manually, this must be registered and signed.\n\nThe process owner, or delegated person, must authorize the restoration of data. These people are the responsible for ensuring that the restoration procedure is in compliance with the regulations of Good habits.\n\nIf the restoration is motivated by technical reasons, the owner of the process and the owner of the system must make a assessment of the process and possible risks. The restoration method used and the control of the restoration must be documented.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "c5a00832cf7bc63dca0f49e64f3294d70b89ad688e149a7197824302de68edb4", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "loss of data in case of system failure. The data must be recoverable in a short time and without error and copies kept remotely to avoid loss due to some common failure in one location (e.g., fire). The type and frequency of the **backup** should be based on risk.\n\nThe data must be periodically saved on the **backup media**. The system owner must establish and document the organization of data **backups**, covering the following aspects:\n\n- **Backup types** (full or incremental);\n- **Interval**: daily, weekly, monthly, quarterly, annual or non-cyclical (permanent retention);\n- **Number of generations**. The number of generations defines the number of identically performed backups that are maintained. Since **backup** media is often reused, after the number of generations has been reached, subsequent **backups** will be overwritten over the oldest **backup**. For example: if the number of generations set to four, the fifth **backup** will overwrite the first, the sixth will overwrite the second and so on;\n- **Backup failure** - Actions to be taken in case of **backup** failure must be established, such as a repeat **backup** during the day. Actions taken in the event of failure should be documented (e.g., logbook) by the person responsible for the computerized system;\n- **Backup Media Labeling**. The following items must appear on the media label, or registered at record book: system designation; **software / data designation**; version and / or build number the **software / firmware** (if applicable); creation date; date of first use; current number (generations, possible multiple backups); **backup** date; reason for **backup** and operator identity;\n- **Duration of use**. The media should only be used for as long as it is guaranteed;\n- The type of media used must be documented;\n- **Storage Location**. Storage locations must be safe and properly identified and traceable;\n- **Data Backup Tools and Corresponding Procedures**. GMP-relevant data should be stored in an appropriate way that allows their restoration. The location and name of the procedure control must be documented. Procedures must cover restoration, verification activities and restart after system failure;\n- **Data Backup Review**. The process owner, or delegated person, is responsible for ensuring successful **backup**. Faults should be investigated and defective storage media potentials must be discarded and replaced. The actions must be documented in a record book.\n\n## 11.10.4.4 Restoration\n\nWritten and tested procedures must be used to perform the restoration. When the restoration is performed manually, this must be registered and signed.\n\nThe process owner, or delegated person, must authorize the restoration of data. These people are the responsible for ensuring that the restoration procedure is in compliance with the regulations of Good habits.\n\nIf the restoration is motivated by technical reasons, the owner of the process and the owner of the system must make a assessment of the process and possible risks. The restoration method used and the control of the restoration must be documented.", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 3112, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "7c20cbe8-9dd8-4c83-91c5-3ec8e51aa9f9": {"__data__": {"id_": "7c20cbe8-9dd8-4c83-91c5-3ec8e51aa9f9", "embedding": null, "metadata": {"page_label": "85", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 11.10.4.5 Long Term Integrity\n\nElectronic storage media degrades over time, therefore, media reuse must be carried out according to the manufacturer's guidelines regarding its useful life.\n\nIn the unlikely event that a backup copy will be kept for a period approaching the end of its life media, the integrity of the backups contained on the media should be reviewed according to the specifications manufacturer. It is preferable to copy the data onto new media rather than review the old media.\n\nThe procedures for backup and restore must be checked periodically. The frequency should be based on risk. This verification can be performed by means of restoring the backup to a backup system, test and verifying its correct operation.\n\nA common and pragmatic approach is to combine verification of the backup process with testing disaster recovery. The restoration of the backup to the system running in production, with the purpose testing is not recommended, as an error in the procedure can result in data loss.\n\nThe procedures backup and restoration should be checked during the periodic review of the system. At conclusions must be documented.\n\n# 11.10.5 Execution of Activities\n\nThe activities backup and restoration involve performing the following actions:\n\n1. Risk assessment, taking into account the probability and risk of damage occurring;\n2. Definition of the strategy for carrying out backup operations, covering: frequency, location of storage, required response times, retention period and storage media;\n3. Development of written backup and restoration procedures, covering: responsibilities, training and documentation;\n4. Definition of test procedures and plans to verify backup and backup operations restoration;\n5. Execution of tests, documenting the results and actions taken;\n6. Execution of backup operations according to established procedure;\n7. Monitoring the system during its operational life.\n\n# 11.11 BUSINESS CONTINUITY PLANNING / DISASTER RECOVERY\n\n## 11.11.1 Introduction\n\nBusiness Continuity Planning consists of a series of activities and related processes with the guarantee that the regulated company is fully prepared to respond effectively when failure and disturbance.\n\nCritical business processes and systems that support these processes must be identified and their associated risks should be assessed. Plans must be established and exercised to ensure the timely and effective resumption of these processes and critical systems for the business.\n\nThe Business Continuity Plan defines how the business can continue to function and how to deal with data after failures occur. Defines the steps required to restore business processes after the occurrence of a disaster and how the data generated during the occurrence of this event should be", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "### Resumen del Contexto\n\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos aborda la importancia de la integridad a largo plazo de los medios de almacenamiento electr\u00f3nico y la planificaci\u00f3n de la continuidad del negocio. Se enfatiza que los medios de almacenamiento se degradan con el tiempo y que deben seguirse las pautas del fabricante para su reutilizaci\u00f3n. Adem\u00e1s, se describen procedimientos para la realizaci\u00f3n de copias de seguridad y restauraci\u00f3n, as\u00ed como la importancia de evaluar riesgos y establecer estrategias adecuadas. La planificaci\u00f3n de la continuidad del negocio se centra en garantizar que una empresa est\u00e9 preparada para responder a fallos y perturbaciones, identificando procesos cr\u00edticos y evaluando riesgos asociados.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfCu\u00e1les son las recomendaciones espec\u00edficas para la verificaci\u00f3n de la integridad de las copias de seguridad en medios que se acercan al final de su vida \u00fatil?**\n   - El documento sugiere que, en caso de que se mantenga una copia de seguridad en medios que se acercan al final de su vida \u00fatil, se debe revisar la integridad de las copias de seguridad de acuerdo con las especificaciones del fabricante. Sin embargo, se prefiere copiar los datos a nuevos medios en lugar de revisar los antiguos.\n\n2. **\u00bfQu\u00e9 acciones deben llevarse a cabo para asegurar la correcta ejecuci\u00f3n de las operaciones de copia de seguridad y restauraci\u00f3n?**\n   - Las acciones incluyen realizar una evaluaci\u00f3n de riesgos, definir una estrategia para las operaciones de copia de seguridad, desarrollar procedimientos escritos, definir procedimientos de prueba, ejecutar pruebas y documentar los resultados, llevar a cabo las operaciones de copia de seguridad seg\u00fan el procedimiento establecido y monitorear el sistema durante su vida operativa.\n\n3. **\u00bfC\u00f3mo se define un Plan de Continuidad del Negocio y qu\u00e9 aspectos clave debe incluir?**\n   - Un Plan de Continuidad del Negocio define c\u00f3mo la empresa puede seguir funcionando y c\u00f3mo manejar los datos despu\u00e9s de que ocurran fallos. Debe incluir la identificaci\u00f3n de procesos cr\u00edticos, la evaluaci\u00f3n de riesgos asociados, y los pasos necesarios para restaurar los procesos comerciales despu\u00e9s de un desastre, as\u00ed como el manejo de los datos generados durante dicho evento.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Importancia de las Copias de Seguridad**:\n   - Se enfatiza la necesidad de realizar copias de seguridad para garantizar la recuperaci\u00f3n de datos en caso de fallos del sistema. Las copias deben ser recuperables r\u00e1pidamente y sin errores.\n\n2. **Organizaci\u00f3n de las Copias de Seguridad**:\n   - **Tipos de Copias**: Se deben definir si ser\u00e1n completas o incrementales.\n   - **Intervalo de Copias**: Debe basarse en el riesgo y puede ser diario, semanal, mensual, trimestral, anual o no c\u00edclico.\n   - **N\u00famero de Generaciones**: Se establece cu\u00e1ntas copias se mantendr\u00e1n antes de sobrescribir las m\u00e1s antiguas.\n\n3. **Manejo de Fallos en las Copias de Seguridad**:\n   - Se deben establecer acciones a seguir en caso de fallo, como repetir la copia de seguridad, y documentar estas acciones.\n\n4. **Etiquetado de Medios de Copia de Seguridad**:\n   - La etiqueta debe incluir informaci\u00f3n clave como la designaci\u00f3n del sistema, versi\u00f3n del software, fechas relevantes y la identidad del operador.\n\n5. **Duraci\u00f3n y Tipo de Medios**:\n   - Los medios de copia de seguridad deben ser utilizados solo durante el tiempo garantizado y su tipo debe ser documentado.\n\n6. **Ubicaci\u00f3n de Almacenamiento**:\n   - Las ubicaciones de almacenamiento deben ser seguras, identificadas y trazables.\n\n7. **Herramientas y Procedimientos de Copia de Seguridad**:\n   - Se deben documentar las herramientas utilizadas y los procedimientos para la restauraci\u00f3n y verificaci\u00f3n de datos.\n\n8. **Revisi\u00f3n de Copias de Seguridad**:\n   - El propietario del proceso es responsable de asegurar el \u00e9xito de las copias de seguridad y debe documentar cualquier fallo y las acciones tomadas.\n\n9. **Restauraci\u00f3n de Datos**:\n   - Se deben seguir procedimientos escritos y probados para la restauraci\u00f3n, que deben ser autorizados y documentados por el propietario del proceso o una persona delegada.\n\n### Entidades Clave\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil.\n- **Sistema Computarizado**: Referido en el contexto de la gesti\u00f3n de datos y copias de seguridad.\n- **Datos**: Informaci\u00f3n que debe ser respaldada y restaurada.\n- **Medios de Copia de Seguridad**: Dispositivos o soportes donde se almacenan las copias de seguridad.\n- **Procedimientos**: Documentaci\u00f3n que gu\u00eda las acciones de copia y restauraci\u00f3n de datos. \n\nEste resumen proporciona una visi\u00f3n general de los aspectos cr\u00edticos relacionados con la gesti\u00f3n de copias de seguridad y la restauraci\u00f3n de datos seg\u00fan las directrices de ANVISA.", "excerpt_keywords": "Keywords: backup, data integrity, business continuity, disaster recovery, risk assessment"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "46739c31-4f45-4c47-ad64-8f751f42fa94", "node_type": "4", "metadata": {"page_label": "85", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 11.10.4.5 Long Term Integrity\n\nElectronic storage media degrades over time, therefore, media reuse must be carried out according to the manufacturer's guidelines regarding its useful life.\n\nIn the unlikely event that a backup copy will be kept for a period approaching the end of its life media, the integrity of the backups contained on the media should be reviewed according to the specifications manufacturer. It is preferable to copy the data onto new media rather than review the old media.\n\nThe procedures for backup and restore must be checked periodically. The frequency should be based on risk. This verification can be performed by means of restoring the backup to a backup system, test and verifying its correct operation.\n\nA common and pragmatic approach is to combine verification of the backup process with testing disaster recovery. The restoration of the backup to the system running in production, with the purpose testing is not recommended, as an error in the procedure can result in data loss.\n\nThe procedures backup and restoration should be checked during the periodic review of the system. At conclusions must be documented.\n\n# 11.10.5 Execution of Activities\n\nThe activities backup and restoration involve performing the following actions:\n\n1. Risk assessment, taking into account the probability and risk of damage occurring;\n2. Definition of the strategy for carrying out backup operations, covering: frequency, location of storage, required response times, retention period and storage media;\n3. Development of written backup and restoration procedures, covering: responsibilities, training and documentation;\n4. Definition of test procedures and plans to verify backup and backup operations restoration;\n5. Execution of tests, documenting the results and actions taken;\n6. Execution of backup operations according to established procedure;\n7. Monitoring the system during its operational life.\n\n# 11.11 BUSINESS CONTINUITY PLANNING / DISASTER RECOVERY\n\n## 11.11.1 Introduction\n\nBusiness Continuity Planning consists of a series of activities and related processes with the guarantee that the regulated company is fully prepared to respond effectively when failure and disturbance.\n\nCritical business processes and systems that support these processes must be identified and their associated risks should be assessed. Plans must be established and exercised to ensure the timely and effective resumption of these processes and critical systems for the business.\n\nThe Business Continuity Plan defines how the business can continue to function and how to deal with data after failures occur. Defines the steps required to restore business processes after the occurrence of a disaster and how the data generated during the occurrence of this event should be", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "efb462029d004a2b2888322ebc41a103e3f8c05acd110962a2406876acb6b677", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "# 11.10.4.5 Long Term Integrity\n\nElectronic storage media degrades over time, therefore, media reuse must be carried out according to the manufacturer's guidelines regarding its useful life.\n\nIn the unlikely event that a backup copy will be kept for a period approaching the end of its life media, the integrity of the backups contained on the media should be reviewed according to the specifications manufacturer. It is preferable to copy the data onto new media rather than review the old media.\n\nThe procedures for backup and restore must be checked periodically. The frequency should be based on risk. This verification can be performed by means of restoring the backup to a backup system, test and verifying its correct operation.\n\nA common and pragmatic approach is to combine verification of the backup process with testing disaster recovery. The restoration of the backup to the system running in production, with the purpose testing is not recommended, as an error in the procedure can result in data loss.\n\nThe procedures backup and restoration should be checked during the periodic review of the system. At conclusions must be documented.\n\n# 11.10.5 Execution of Activities\n\nThe activities backup and restoration involve performing the following actions:\n\n1. Risk assessment, taking into account the probability and risk of damage occurring;\n2. Definition of the strategy for carrying out backup operations, covering: frequency, location of storage, required response times, retention period and storage media;\n3. Development of written backup and restoration procedures, covering: responsibilities, training and documentation;\n4. Definition of test procedures and plans to verify backup and backup operations restoration;\n5. Execution of tests, documenting the results and actions taken;\n6. Execution of backup operations according to established procedure;\n7. Monitoring the system during its operational life.\n\n# 11.11 BUSINESS CONTINUITY PLANNING / DISASTER RECOVERY\n\n## 11.11.1 Introduction\n\nBusiness Continuity Planning consists of a series of activities and related processes with the guarantee that the regulated company is fully prepared to respond effectively when failure and disturbance.\n\nCritical business processes and systems that support these processes must be identified and their associated risks should be assessed. Plans must be established and exercised to ensure the timely and effective resumption of these processes and critical systems for the business.\n\nThe Business Continuity Plan defines how the business can continue to function and how to deal with data after failures occur. Defines the steps required to restore business processes after the occurrence of a disaster and how the data generated during the occurrence of this event should be", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 2783, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "d39c41e3-0a18-4cb7-901a-d83078ba53c8": {"__data__": {"id_": "d39c41e3-0a18-4cb7-901a-d83078ba53c8", "embedding": null, "metadata": {"page_label": "86", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# Guide for Computer Systems Validation\n\n## 11.11.2 Key requirements\n\nPatient safety, product quality and data integrity cannot be compromised by computer system crashes or crashes.\n\nThe regulated company must carry out business continuity planning to actively protect its ability to supply their products to the public and meet regulatory requirements.\n\nThe Business Continuity Plan must provide alternative procedures or processes to be implemented to replace functionality missing from some system and allow for safe continuity during the failure.\n\nBusiness Continuity Plans should include provision for testing. Alternative processes defined by the Business Continuity Plan must be properly documented and staff involved properly trained.\n\nRegulated companies must be able to demonstrate that they can ensure that critical and processes can continue and that there is a timely resumption of essential business functions.\n\nBusiness Continuity Plans and their tests must be subject to periodic internal audits.\n\n## 11.11.3 Responsibilities\n\nIt is the responsibility of the company's top management, including process owners, system owners and the Quality Unit, ensure that appropriate Business Continuity Plans are in place, periodically tested and once started, be followed, documented and communicated.\n\nIt is the responsibility of the process owner and the system owner to ensure that recovery plans are appropriate disaster systems are in place for the systems to support the Plans for Business Continuity.\n\n## 11.11.4 Execution of Activities\n\nPlanning for Business Continuity and Disaster Recovery activities involve carrying out the following actions:\n\n1. Establishing the need for planning and management for business continuity,", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la Validaci\u00f3n de Sistemas Inform\u00e1ticos establece requisitos clave para garantizar la continuidad del negocio en empresas reguladas. Se enfatiza la importancia de la planificaci\u00f3n de la continuidad del negocio para proteger la seguridad del paciente, la calidad del producto y la integridad de los datos. Se requiere que las empresas desarrollen un Plan de Continuidad del Negocio que incluya procedimientos alternativos, pruebas documentadas y capacitaci\u00f3n del personal. Adem\u00e1s, se asignan responsabilidades a la alta direcci\u00f3n y a los propietarios de procesos y sistemas para asegurar que estos planes sean efectivos y se mantengan actualizados.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfQu\u00e9 elementos deben incluirse en un Plan de Continuidad del Negocio seg\u00fan la gu\u00eda de ANVISA?**\n   - La gu\u00eda establece que el Plan de Continuidad del Negocio debe incluir procedimientos alternativos para reemplazar la funcionalidad perdida, provisiones para pruebas, documentaci\u00f3n adecuada de los procesos alternativos y capacitaci\u00f3n del personal involucrado.\n\n2. **\u00bfQui\u00e9nes son responsables de asegurar la implementaci\u00f3n y el seguimiento de los Planes de Continuidad del Negocio en una empresa regulada?**\n   - La responsabilidad recae en la alta direcci\u00f3n de la empresa, incluidos los propietarios de procesos, los propietarios de sistemas y la Unidad de Calidad, quienes deben asegurarse de que los planes sean apropiados, se prueben peri\u00f3dicamente y se sigan adecuadamente.\n\n3. **\u00bfQu\u00e9 acciones se deben llevar a cabo para planificar la continuidad del negocio y la recuperaci\u00f3n ante desastres?**\n   - Las acciones incluyen establecer la necesidad de planificaci\u00f3n y gesti\u00f3n para la continuidad del negocio, lo que implica identificar riesgos, definir procedimientos alternativos y asegurar que se realicen pruebas y auditor\u00edas internas peri\u00f3dicas.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Integridad a Largo Plazo de Medios de Almacenamiento Electr\u00f3nico**:\n   - La degradaci\u00f3n de los medios de almacenamiento con el tiempo requiere seguir las pautas del fabricante para su reutilizaci\u00f3n.\n   - Se recomienda copiar datos a nuevos medios en lugar de revisar medios antiguos que se acercan al final de su vida \u00fatil.\n\n2. **Procedimientos de Copia de Seguridad y Restauraci\u00f3n**:\n   - Es esencial verificar peri\u00f3dicamente los procedimientos de copia de seguridad y restauraci\u00f3n, bas\u00e1ndose en una evaluaci\u00f3n de riesgos.\n   - La verificaci\u00f3n puede incluir la restauraci\u00f3n de copias de seguridad en un sistema de respaldo para probar su correcto funcionamiento.\n   - No se recomienda restaurar copias de seguridad en sistemas en producci\u00f3n para evitar la p\u00e9rdida de datos.\n\n3. **Ejecuci\u00f3n de Actividades de Copia de Seguridad**:\n   - Las actividades incluyen: evaluaci\u00f3n de riesgos, definici\u00f3n de estrategias de copia de seguridad, desarrollo de procedimientos escritos, definici\u00f3n de procedimientos de prueba, ejecuci\u00f3n de pruebas y monitoreo del sistema.\n   - Documentaci\u00f3n de resultados y acciones tomadas es crucial.\n\n4. **Planificaci\u00f3n de Continuidad del Negocio / Recuperaci\u00f3n ante Desastres**:\n   - La planificaci\u00f3n de continuidad del negocio implica preparar a la empresa para responder a fallos y perturbaciones.\n   - Identificaci\u00f3n de procesos cr\u00edticos y evaluaci\u00f3n de riesgos asociados son fundamentales.\n   - El Plan de Continuidad del Negocio debe detallar c\u00f3mo la empresa puede seguir operando y manejar datos tras un desastre, incluyendo pasos para restaurar procesos comerciales.\n\n### Entidades Clave:\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil.\n- **Medios de Almacenamiento Electr\u00f3nico**: Dispositivos utilizados para almacenar datos.\n- **Copia de Seguridad**: Proceso de crear una copia de los datos para su recuperaci\u00f3n.\n- **Plan de Continuidad del Negocio**: Estrategia para mantener operaciones durante y despu\u00e9s de un desastre.\n- **Evaluaci\u00f3n de Riesgos**: Proceso de identificar y analizar riesgos potenciales.", "excerpt_keywords": "Keywords: Business Continuity, Disaster Recovery, Data Integrity, Regulatory Compliance, ANVISA"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "ff54a2c8-ba1e-4a51-a97c-fb26576f326b", "node_type": "4", "metadata": {"page_label": "86", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# Guide for Computer Systems Validation\n\n## 11.11.2 Key requirements\n\nPatient safety, product quality and data integrity cannot be compromised by computer system crashes or crashes.\n\nThe regulated company must carry out business continuity planning to actively protect its ability to supply their products to the public and meet regulatory requirements.\n\nThe Business Continuity Plan must provide alternative procedures or processes to be implemented to replace functionality missing from some system and allow for safe continuity during the failure.\n\nBusiness Continuity Plans should include provision for testing. Alternative processes defined by the Business Continuity Plan must be properly documented and staff involved properly trained.\n\nRegulated companies must be able to demonstrate that they can ensure that critical and processes can continue and that there is a timely resumption of essential business functions.\n\nBusiness Continuity Plans and their tests must be subject to periodic internal audits.\n\n## 11.11.3 Responsibilities\n\nIt is the responsibility of the company's top management, including process owners, system owners and the Quality Unit, ensure that appropriate Business Continuity Plans are in place, periodically tested and once started, be followed, documented and communicated.\n\nIt is the responsibility of the process owner and the system owner to ensure that recovery plans are appropriate disaster systems are in place for the systems to support the Plans for Business Continuity.\n\n## 11.11.4 Execution of Activities\n\nPlanning for Business Continuity and Disaster Recovery activities involve carrying out the following actions:\n\n1. Establishing the need for planning and management for business continuity,", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "ebcc6cda6f9adea877fc22f9eb972edc194924e4f0faeb1b4d650d636828167e", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "# Guide for Computer Systems Validation\n\n## 11.11.2 Key requirements\n\nPatient safety, product quality and data integrity cannot be compromised by computer system crashes or crashes.\n\nThe regulated company must carry out business continuity planning to actively protect its ability to supply their products to the public and meet regulatory requirements.\n\nThe Business Continuity Plan must provide alternative procedures or processes to be implemented to replace functionality missing from some system and allow for safe continuity during the failure.\n\nBusiness Continuity Plans should include provision for testing. Alternative processes defined by the Business Continuity Plan must be properly documented and staff involved properly trained.\n\nRegulated companies must be able to demonstrate that they can ensure that critical and processes can continue and that there is a timely resumption of essential business functions.\n\nBusiness Continuity Plans and their tests must be subject to periodic internal audits.\n\n## 11.11.3 Responsibilities\n\nIt is the responsibility of the company's top management, including process owners, system owners and the Quality Unit, ensure that appropriate Business Continuity Plans are in place, periodically tested and once started, be followed, documented and communicated.\n\nIt is the responsibility of the process owner and the system owner to ensure that recovery plans are appropriate disaster systems are in place for the systems to support the Plans for Business Continuity.\n\n## 11.11.4 Execution of Activities\n\nPlanning for Business Continuity and Disaster Recovery activities involve carrying out the following actions:\n\n1. Establishing the need for planning and management for business continuity,", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 1738, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "2116a15e-3afe-4c29-b1a4-3cdc56847cd6": {"__data__": {"id_": "2116a15e-3afe-4c29-b1a4-3cdc56847cd6", "embedding": null, "metadata": {"page_label": "87", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# Guide for Computer Systems Validation\n\nincluding Disaster Recovery Planning, identifying key processes and services for the business. Obtaining support from senior management;\n\n## Guide for Computer Systems Validation\n### Guide n\u00b0 33/2020 - version 1, of 03/26/2020\n\n----\n\n2. **Risk assessment and analysis.** Determination of adverse events and damages that may adversely affect the organization. Evaluation of the severity of each event and the probability of its occurrence;\n\n3. **Definition of strategies for Business Continuity.** Selection of alternative strategies for recovery, while maintaining the organization's ability to perform its critical functions;\n\n4. **Development of the Business Continuity Plan.** Identification of roles and responsibilities, organizational resources and the triggers that can cause the use of the Plan and its escalation;\n\n5. **Implementation of the Business Continuity Plan;**\n\n6. **Maintenance and Testing.** Pre-planning and coordination of trials, documenting and evaluating the results of each test, incorporating the lessons learned within the Business Continuity Plan. Maintenance of the Plan's timeliness and its capability according to the company's strategy and requirements regulatory requirements. Publication of test results to key stakeholders.\n\n## 11.12 SYSTEM SECURITY MANAGEMENT\n\n### 11.12.1 Introduction\n\nSystem security management is the process of ensuring reliability, integrity and availability of the regulated company's systems, records and processes.\n\nEffective security management protects the company's computer systems so that minimize business impacts caused by security vulnerabilities and incidents.\n\n### 11.12.2 Key requirements\n\nMeasures must be put in place to ensure that the computerized systems of regulated companies and your data is adequate and protected against accidental or intentional loss, damage or unintended changes authorized.\n\nSuch measures should ensure continuous control, integrity and availability and, where appropriate, confidentiality of regulated data.\n\nThis process should include:\n\n- Establishment and maintenance of roles and responsibilities, policies, standards and procedures security-related;\n- Periodic safety monitoring and testing, for example, manual book verification system access, automated notifications of system access locks, token testing and so on onwards;\n- Implementation of corrective actions for identified weaknesses and security incidents;\n- Ensure that there is a list of people authorized to access the system.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento \"Gu\u00eda para la Validaci\u00f3n de Sistemas Inform\u00e1ticos\" de ANVISA (Gu\u00eda n\u00b0 33/2020) aborda la importancia de la planificaci\u00f3n de la continuidad del negocio y la gesti\u00f3n de la seguridad de los sistemas. Se destacan procesos clave como la evaluaci\u00f3n de riesgos, la definici\u00f3n de estrategias de recuperaci\u00f3n, el desarrollo e implementaci\u00f3n de un Plan de Continuidad del Negocio, y la gesti\u00f3n de la seguridad del sistema para proteger la integridad y disponibilidad de los datos regulados.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfCu\u00e1les son los pasos clave en el desarrollo de un Plan de Continuidad del Negocio seg\u00fan la Gu\u00eda de ANVISA?**\n   - La gu\u00eda detalla varios pasos, incluyendo la identificaci\u00f3n de roles y responsabilidades, la selecci\u00f3n de estrategias de recuperaci\u00f3n, y la coordinaci\u00f3n de pruebas para evaluar la efectividad del plan.\n\n2. **\u00bfQu\u00e9 medidas se deben implementar para garantizar la seguridad de los sistemas inform\u00e1ticos en empresas reguladas?**\n   - Se deben establecer roles y responsabilidades, pol\u00edticas y procedimientos de seguridad, realizar monitoreos y pruebas peri\u00f3dicas, implementar acciones correctivas para debilidades identificadas, y mantener una lista de personas autorizadas para acceder al sistema.\n\n3. **\u00bfC\u00f3mo se eval\u00faa el riesgo en el contexto de la validaci\u00f3n de sistemas inform\u00e1ticos seg\u00fan el documento?**\n   - La evaluaci\u00f3n de riesgos implica determinar eventos adversos y da\u00f1os potenciales que puedan afectar a la organizaci\u00f3n, as\u00ed como evaluar la gravedad de cada evento y la probabilidad de su ocurrencia.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n**Temas Clave:**\n\n1. **Seguridad del Paciente y Calidad del Producto:** La gu\u00eda enfatiza que la seguridad del paciente, la calidad del producto y la integridad de los datos no deben verse comprometidas por fallos en los sistemas inform\u00e1ticos.\n\n2. **Planificaci\u00f3n de la Continuidad del Negocio:** Se requiere que las empresas reguladas desarrollen un Plan de Continuidad del Negocio que incluya procedimientos alternativos para mantener la funcionalidad durante fallos del sistema.\n\n3. **Documentaci\u00f3n y Capacitaci\u00f3n:** Los planes deben estar debidamente documentados y el personal involucrado debe recibir capacitaci\u00f3n adecuada.\n\n4. **Auditor\u00edas Internas:** Los Planes de Continuidad del Negocio y sus pruebas deben ser objeto de auditor\u00edas internas peri\u00f3dicas.\n\n5. **Responsabilidades de la Alta Direcci\u00f3n:** La alta direcci\u00f3n, incluidos los propietarios de procesos y sistemas, es responsable de asegurar la implementaci\u00f3n y el seguimiento de los planes.\n\n6. **Actividades de Ejecuci\u00f3n:** La planificaci\u00f3n para la continuidad del negocio y la recuperaci\u00f3n ante desastres implica establecer la necesidad de gesti\u00f3n y planificaci\u00f3n.\n\n**Entidades:**\n\n- **ANVISA:** Agencia Nacional de Vigilancia Sanitaria de Brasil, responsable de la regulaci\u00f3n.\n- **Alta Direcci\u00f3n:** Incluye a los propietarios de procesos, propietarios de sistemas y la Unidad de Calidad.\n- **Personal Involucrado:** Empleados que deben ser capacitados en los procedimientos del Plan de Continuidad del Negocio.\n\nEste resumen destaca la importancia de la planificaci\u00f3n y gesti\u00f3n de la continuidad del negocio en empresas reguladas, as\u00ed como las responsabilidades y acciones necesarias para garantizar su efectividad.", "excerpt_keywords": "Keywords: validation, business continuity, risk assessment, system security, regulatory compliance"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "8aa247cd-101d-437e-ad40-679a3d96127b", "node_type": "4", "metadata": {"page_label": "87", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# Guide for Computer Systems Validation\n\nincluding Disaster Recovery Planning, identifying key processes and services for the business. Obtaining support from senior management;\n\n## Guide for Computer Systems Validation\n### Guide n\u00b0 33/2020 - version 1, of 03/26/2020\n\n----\n\n2. **Risk assessment and analysis.** Determination of adverse events and damages that may adversely affect the organization. Evaluation of the severity of each event and the probability of its occurrence;\n\n3. **Definition of strategies for Business Continuity.** Selection of alternative strategies for recovery, while maintaining the organization's ability to perform its critical functions;\n\n4. **Development of the Business Continuity Plan.** Identification of roles and responsibilities, organizational resources and the triggers that can cause the use of the Plan and its escalation;\n\n5. **Implementation of the Business Continuity Plan;**\n\n6. **Maintenance and Testing.** Pre-planning and coordination of trials, documenting and evaluating the results of each test, incorporating the lessons learned within the Business Continuity Plan. Maintenance of the Plan's timeliness and its capability according to the company's strategy and requirements regulatory requirements. Publication of test results to key stakeholders.\n\n## 11.12 SYSTEM SECURITY MANAGEMENT\n\n### 11.12.1 Introduction\n\nSystem security management is the process of ensuring reliability, integrity and availability of the regulated company's systems, records and processes.\n\nEffective security management protects the company's computer systems so that minimize business impacts caused by security vulnerabilities and incidents.\n\n### 11.12.2 Key requirements\n\nMeasures must be put in place to ensure that the computerized systems of regulated companies and your data is adequate and protected against accidental or intentional loss, damage or unintended changes authorized.\n\nSuch measures should ensure continuous control, integrity and availability and, where appropriate, confidentiality of regulated data.\n\nThis process should include:\n\n- Establishment and maintenance of roles and responsibilities, policies, standards and procedures security-related;\n- Periodic safety monitoring and testing, for example, manual book verification system access, automated notifications of system access locks, token testing and so on onwards;\n- Implementation of corrective actions for identified weaknesses and security incidents;\n- Ensure that there is a list of people authorized to access the system.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "87a5c39b385dbc501f6870645e2a772a0484c2e9d4c7b78af31fced7bc7ebfa4", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "# Guide for Computer Systems Validation\n\nincluding Disaster Recovery Planning, identifying key processes and services for the business. Obtaining support from senior management;\n\n## Guide for Computer Systems Validation\n### Guide n\u00b0 33/2020 - version 1, of 03/26/2020\n\n----\n\n2. **Risk assessment and analysis.** Determination of adverse events and damages that may adversely affect the organization. Evaluation of the severity of each event and the probability of its occurrence;\n\n3. **Definition of strategies for Business Continuity.** Selection of alternative strategies for recovery, while maintaining the organization's ability to perform its critical functions;\n\n4. **Development of the Business Continuity Plan.** Identification of roles and responsibilities, organizational resources and the triggers that can cause the use of the Plan and its escalation;\n\n5. **Implementation of the Business Continuity Plan;**\n\n6. **Maintenance and Testing.** Pre-planning and coordination of trials, documenting and evaluating the results of each test, incorporating the lessons learned within the Business Continuity Plan. Maintenance of the Plan's timeliness and its capability according to the company's strategy and requirements regulatory requirements. Publication of test results to key stakeholders.\n\n## 11.12 SYSTEM SECURITY MANAGEMENT\n\n### 11.12.1 Introduction\n\nSystem security management is the process of ensuring reliability, integrity and availability of the regulated company's systems, records and processes.\n\nEffective security management protects the company's computer systems so that minimize business impacts caused by security vulnerabilities and incidents.\n\n### 11.12.2 Key requirements\n\nMeasures must be put in place to ensure that the computerized systems of regulated companies and your data is adequate and protected against accidental or intentional loss, damage or unintended changes authorized.\n\nSuch measures should ensure continuous control, integrity and availability and, where appropriate, confidentiality of regulated data.\n\nThis process should include:\n\n- Establishment and maintenance of roles and responsibilities, policies, standards and procedures security-related;\n- Periodic safety monitoring and testing, for example, manual book verification system access, automated notifications of system access locks, token testing and so on onwards;\n- Implementation of corrective actions for identified weaknesses and security incidents;\n- Ensure that there is a list of people authorized to access the system.", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 2537, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "10444ab2-5ff5-4d2f-ad76-9aaf8c736c8e": {"__data__": {"id_": "10444ab2-5ff5-4d2f-ad76-9aaf8c736c8e", "embedding": null, "metadata": {"page_label": "88", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 11.12.3 Responsibilities\n\nResponsibility for the security of the system, including access control, should be agreed between the owner of the process and the system owner.\n\nIt is the responsibility of the Quality Unit to ensure that safety procedures are followed.\n\nThe computer system user is responsible for meeting the security requirements defined while using the computerized system.\n\n# 11.12.4 Principles\n\nSecurity management measures should be planned and implemented based on the following considerations:\n\n- System impact - assessment of the risks associated with the system;\n- Awareness of employees - training of users;\n- Incident management - records and actions taken to resolve incidents;\n- Information security policy - physical security; security of access to the system; access by the 3rd; electronic messaging systems; shared network resources; internet access and use; use of mobile computing resources; connectivity to external computer systems; policies antivirus and intrusion detection.\n\n# 11.13 SYSTEM ADMINISTRATION\n\n## 11.13.1 Introduction\n\nSystem administration involves routine systems management and support to ensure that they are operating efficiently and effectively.\n\n## 11.13.2 Key requirements\n\nSystem administration tasks must be identified, documented and supported by control procedures.\n\nSystem administrators must be trained and have their competence evidenced in the execution of the", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos establece directrices sobre la responsabilidad de la seguridad del sistema, la gesti\u00f3n de la seguridad y la administraci\u00f3n del sistema. Se enfatiza la importancia de la colaboraci\u00f3n entre el propietario del proceso y el propietario del sistema para garantizar la seguridad, as\u00ed como la necesidad de formaci\u00f3n y documentaci\u00f3n adecuada para los administradores del sistema. Tambi\u00e9n se abordan principios clave para la gesti\u00f3n de la seguridad, incluyendo la evaluaci\u00f3n de riesgos, la formaci\u00f3n de empleados y la gesti\u00f3n de incidentes.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfQu\u00e9 papel desempe\u00f1a la Unidad de Calidad en la seguridad del sistema seg\u00fan el documento?**\n   - La Unidad de Calidad es responsable de garantizar que se sigan los procedimientos de seguridad establecidos para el sistema.\n\n2. **\u00bfCu\u00e1les son algunos de los elementos que deben considerarse al planificar y aplicar medidas de gesti\u00f3n de seguridad?**\n   - Los elementos incluyen la evaluaci\u00f3n del impacto del sistema, la formaci\u00f3n de los empleados, la gesti\u00f3n de incidentes y la implementaci\u00f3n de pol\u00edticas de seguridad de la informaci\u00f3n, que abarcan aspectos como la seguridad f\u00edsica, el acceso al sistema y el uso de recursos inform\u00e1ticos m\u00f3viles.\n\n3. **\u00bfQu\u00e9 requisitos clave se mencionan para la administraci\u00f3n del sistema en el documento?**\n   - Las tareas de administraci\u00f3n del sistema deben ser identificadas, documentadas y respaldadas por procedimientos de control, y los administradores del sistema deben estar capacitados y demostrar competencia en la ejecuci\u00f3n de sus funciones.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n**1. Planificaci\u00f3n de la Continuidad del Negocio:**\n   - **Evaluaci\u00f3n de Riesgos:** Identificaci\u00f3n de eventos adversos y evaluaci\u00f3n de su gravedad y probabilidad de ocurrencia.\n   - **Definici\u00f3n de Estrategias de Recuperaci\u00f3n:** Selecci\u00f3n de estrategias alternativas para asegurar la continuidad de funciones cr\u00edticas.\n   - **Desarrollo del Plan de Continuidad del Negocio:** Identificaci\u00f3n de roles, responsabilidades y recursos organizacionales necesarios.\n   - **Implementaci\u00f3n y Mantenimiento del Plan:** Coordinaci\u00f3n de pruebas, documentaci\u00f3n de resultados y actualizaci\u00f3n del plan seg\u00fan lecciones aprendidas.\n\n**2. Gesti\u00f3n de la Seguridad del Sistema:**\n   - **Introducci\u00f3n a la Gesti\u00f3n de Seguridad:** Asegurar la fiabilidad, integridad y disponibilidad de los sistemas y datos regulados.\n   - **Requisitos Clave de Seguridad:**\n     - Establecimiento de roles y pol\u00edticas de seguridad.\n     - Monitoreo y pruebas peri\u00f3dicas de seguridad.\n     - Implementaci\u00f3n de acciones correctivas ante vulnerabilidades.\n     - Mantenimiento de una lista de personas autorizadas para acceder a los sistemas.\n\n### Entidades Clave\n- **ANVISA:** Agencia Nacional de Vigilancia Sanitaria de Brasil, responsable de la regulaci\u00f3n y supervisi\u00f3n de sistemas inform\u00e1ticos en el sector salud.\n- **Plan de Continuidad del Negocio:** Documento que detalla c\u00f3mo una organizaci\u00f3n mantendr\u00e1 sus funciones cr\u00edticas durante y despu\u00e9s de un evento adverso.\n- **Sistema de Seguridad:** Conjunto de medidas y procedimientos dise\u00f1ados para proteger la integridad y disponibilidad de los datos y sistemas inform\u00e1ticos.\n\nEste resumen destaca la importancia de la planificaci\u00f3n y gesti\u00f3n de la seguridad en el contexto de la validaci\u00f3n de sistemas inform\u00e1ticos, enfatizando la necesidad de un enfoque estructurado para mitigar riesgos y asegurar la continuidad operativa.", "excerpt_keywords": "Keywords: security management, system administration, quality unit, risk assessment, incident management"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "3c7a0786-30de-476b-8c7f-c875d20ca060", "node_type": "4", "metadata": {"page_label": "88", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 11.12.3 Responsibilities\n\nResponsibility for the security of the system, including access control, should be agreed between the owner of the process and the system owner.\n\nIt is the responsibility of the Quality Unit to ensure that safety procedures are followed.\n\nThe computer system user is responsible for meeting the security requirements defined while using the computerized system.\n\n# 11.12.4 Principles\n\nSecurity management measures should be planned and implemented based on the following considerations:\n\n- System impact - assessment of the risks associated with the system;\n- Awareness of employees - training of users;\n- Incident management - records and actions taken to resolve incidents;\n- Information security policy - physical security; security of access to the system; access by the 3rd; electronic messaging systems; shared network resources; internet access and use; use of mobile computing resources; connectivity to external computer systems; policies antivirus and intrusion detection.\n\n# 11.13 SYSTEM ADMINISTRATION\n\n## 11.13.1 Introduction\n\nSystem administration involves routine systems management and support to ensure that they are operating efficiently and effectively.\n\n## 11.13.2 Key requirements\n\nSystem administration tasks must be identified, documented and supported by control procedures.\n\nSystem administrators must be trained and have their competence evidenced in the execution of the", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "e2518f3738ff5edc65d46a4e6918e2233af6e1acfd0b38e2e46283c2e040116d", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "# 11.12.3 Responsibilities\n\nResponsibility for the security of the system, including access control, should be agreed between the owner of the process and the system owner.\n\nIt is the responsibility of the Quality Unit to ensure that safety procedures are followed.\n\nThe computer system user is responsible for meeting the security requirements defined while using the computerized system.\n\n# 11.12.4 Principles\n\nSecurity management measures should be planned and implemented based on the following considerations:\n\n- System impact - assessment of the risks associated with the system;\n- Awareness of employees - training of users;\n- Incident management - records and actions taken to resolve incidents;\n- Information security policy - physical security; security of access to the system; access by the 3rd; electronic messaging systems; shared network resources; internet access and use; use of mobile computing resources; connectivity to external computer systems; policies antivirus and intrusion detection.\n\n# 11.13 SYSTEM ADMINISTRATION\n\n## 11.13.1 Introduction\n\nSystem administration involves routine systems management and support to ensure that they are operating efficiently and effectively.\n\n## 11.13.2 Key requirements\n\nSystem administration tasks must be identified, documented and supported by control procedures.\n\nSystem administrators must be trained and have their competence evidenced in the execution of the", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 1425, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "b9da006e-fca6-4aa1-9009-0406ebb55197": {"__data__": {"id_": "b9da006e-fca6-4aa1-9009-0406ebb55197", "embedding": null, "metadata": {"page_label": "89", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 11.13.3 Responsibilities\n\nThe process owner has overall responsibility for ensuring that the system is used and maintained in a through detailed work instructions and procedures.\n\nIt is the responsibility of the system owner to ensure that tasks delegated to the system administrator are clearly identified and documented. The system owner and the system administrator can be the same person.\n\n# 11.13.4 Execution of Activities\n\nSystem administration activities involve performing the following actions:\n\n1. Establishing the needs and scope of system administration activities computerized;\n2. Establishment of the support schedule for regular activities (daily, weekly, monthly, etc.);\n3. Identification of tasks related to system administration, which can be motivated by the Incident Management process;\n4. Establishment of standard operating procedures for system administration.\n\n# 11.14 RECORD MANAGEMENT (RETENTION, ARCHIVING AND RECOVERY)\n\n## 11.14.1 Introduction\n\nRecords retention policies should be established, based on a clear understanding of the regulatory requirements, corporate policies and existing guides. Archiving requirements are relevant to any registry that needs to be removed from operating systems before the end of its defined retention period.\n\nArchiving is the process of removing records and data from the computerized system and placing them in a different location or system, often protecting them from further changes. Can also be it is necessary to retain on file the applications that support records and data.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos establece responsabilidades claras para los propietarios y administradores de sistemas, as\u00ed como directrices para la ejecuci\u00f3n de actividades de administraci\u00f3n del sistema. Tambi\u00e9n aborda la gesti\u00f3n de registros, enfatizando la importancia de las pol\u00edticas de retenci\u00f3n y el proceso de archivo, que implica la eliminaci\u00f3n de registros de los sistemas operativos y su almacenamiento en ubicaciones seguras.\n\n### Preguntas\n\n1. **\u00bfCu\u00e1les son las responsabilidades espec\u00edficas del propietario del sistema en relaci\u00f3n con la administraci\u00f3n del sistema?**\n   - El propietario del sistema es responsable de garantizar que el sistema se utilice y mantenga de acuerdo con instrucciones de trabajo detalladas y procedimientos. Adem\u00e1s, debe asegurarse de que las tareas delegadas al administrador del sistema est\u00e9n claramente identificadas y documentadas.\n\n2. **\u00bfQu\u00e9 pasos se deben seguir para establecer un programa de soporte para las actividades de administraci\u00f3n del sistema?**\n   - Se debe establecer un cronograma de soporte para las actividades regulares de administraci\u00f3n del sistema, que puede incluir actividades diarias, semanales, mensuales, etc. Esto es parte de la ejecuci\u00f3n de actividades de administraci\u00f3n del sistema.\n\n3. **\u00bfQu\u00e9 implica el proceso de archivo de registros y por qu\u00e9 es importante?**\n   - El proceso de archivo implica la eliminaci\u00f3n de registros y datos del sistema inform\u00e1tico y su colocaci\u00f3n en una ubicaci\u00f3n o sistema diferente, protegi\u00e9ndolos de cambios adicionales. Es importante porque asegura que los registros se mantengan de acuerdo con las pol\u00edticas de retenci\u00f3n y se gestionen adecuadamente antes de que finalice su per\u00edodo de retenci\u00f3n definido.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Responsabilidades de Seguridad del Sistema**:\n   - La responsabilidad de la seguridad del sistema, incluyendo el control de acceso, debe ser acordada entre el propietario del proceso y el propietario del sistema.\n   - La Unidad de Calidad tiene la responsabilidad de asegurar que se sigan los procedimientos de seguridad.\n   - Los usuarios del sistema inform\u00e1tico son responsables de cumplir con los requisitos de seguridad establecidos.\n\n2. **Principios de Gesti\u00f3n de Seguridad**:\n   - Las medidas de gesti\u00f3n de seguridad deben planificarse e implementarse considerando:\n     - **Impacto del Sistema**: Evaluaci\u00f3n de riesgos asociados.\n     - **Conciencia de los Empleados**: Capacitaci\u00f3n de los usuarios.\n     - **Gesti\u00f3n de Incidentes**: Registro y acciones para resolver incidentes.\n     - **Pol\u00edtica de Seguridad de la Informaci\u00f3n**: Incluye seguridad f\u00edsica, control de acceso, uso de recursos compartidos, acceso a internet, uso de dispositivos m\u00f3viles, y pol\u00edticas de antivirus e intrusi\u00f3n.\n\n3. **Administraci\u00f3n del Sistema**:\n   - La administraci\u00f3n del sistema implica la gesti\u00f3n y soporte rutinario para asegurar un funcionamiento eficiente y efectivo.\n   - Las tareas de administraci\u00f3n deben ser identificadas, documentadas y respaldadas por procedimientos de control.\n   - Los administradores del sistema deben estar capacitados y demostrar competencia en sus funciones.\n\n### Entidades Clave:\n- **Unidad de Calidad**: Responsable de la supervisi\u00f3n de procedimientos de seguridad.\n- **Propietario del Proceso**: Parte que colabora en la seguridad del sistema.\n- **Propietario del Sistema**: Parte que colabora en la seguridad del sistema.\n- **Usuarios del Sistema**: Responsables de cumplir con los requisitos de seguridad.\n- **Administradores del Sistema**: Encargados de la gesti\u00f3n y soporte del sistema, deben estar capacitados y documentar sus tareas. \n\nEste resumen destaca la importancia de la colaboraci\u00f3n y la capacitaci\u00f3n en la gesti\u00f3n de la seguridad y la administraci\u00f3n de sistemas inform\u00e1ticos seg\u00fan las directrices de ANVISA.", "excerpt_keywords": "Keywords: responsibilities, system administration, records management, archiving, validation"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "cd043f06-2b14-49aa-843f-77b0b1b5ad5b", "node_type": "4", "metadata": {"page_label": "89", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 11.13.3 Responsibilities\n\nThe process owner has overall responsibility for ensuring that the system is used and maintained in a through detailed work instructions and procedures.\n\nIt is the responsibility of the system owner to ensure that tasks delegated to the system administrator are clearly identified and documented. The system owner and the system administrator can be the same person.\n\n# 11.13.4 Execution of Activities\n\nSystem administration activities involve performing the following actions:\n\n1. Establishing the needs and scope of system administration activities computerized;\n2. Establishment of the support schedule for regular activities (daily, weekly, monthly, etc.);\n3. Identification of tasks related to system administration, which can be motivated by the Incident Management process;\n4. Establishment of standard operating procedures for system administration.\n\n# 11.14 RECORD MANAGEMENT (RETENTION, ARCHIVING AND RECOVERY)\n\n## 11.14.1 Introduction\n\nRecords retention policies should be established, based on a clear understanding of the regulatory requirements, corporate policies and existing guides. Archiving requirements are relevant to any registry that needs to be removed from operating systems before the end of its defined retention period.\n\nArchiving is the process of removing records and data from the computerized system and placing them in a different location or system, often protecting them from further changes. Can also be it is necessary to retain on file the applications that support records and data.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "18d09918607c7326309b026cc9a3974a161bc94649362556315c5450976cafd9", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "# 11.13.3 Responsibilities\n\nThe process owner has overall responsibility for ensuring that the system is used and maintained in a through detailed work instructions and procedures.\n\nIt is the responsibility of the system owner to ensure that tasks delegated to the system administrator are clearly identified and documented. The system owner and the system administrator can be the same person.\n\n# 11.13.4 Execution of Activities\n\nSystem administration activities involve performing the following actions:\n\n1. Establishing the needs and scope of system administration activities computerized;\n2. Establishment of the support schedule for regular activities (daily, weekly, monthly, etc.);\n3. Identification of tasks related to system administration, which can be motivated by the Incident Management process;\n4. Establishment of standard operating procedures for system administration.\n\n# 11.14 RECORD MANAGEMENT (RETENTION, ARCHIVING AND RECOVERY)\n\n## 11.14.1 Introduction\n\nRecords retention policies should be established, based on a clear understanding of the regulatory requirements, corporate policies and existing guides. Archiving requirements are relevant to any registry that needs to be removed from operating systems before the end of its defined retention period.\n\nArchiving is the process of removing records and data from the computerized system and placing them in a different location or system, often protecting them from further changes. Can also be it is necessary to retain on file the applications that support records and data.", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 1549, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "1d67c12a-2ae6-45e9-8bff-e9e88c669d41": {"__data__": {"id_": "1d67c12a-2ae6-45e9-8bff-e9e88c669d41", "embedding": null, "metadata": {"page_label": "90", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "Archiving and retrieval procedures should be established on the basis of a clear understanding of regulatory requirements.\n\nArchiving and recovery should not be confused with backup and restore.\n\nArchiving must be subject to periodic internal audits.\n\n## 11.14.2 Key requirements\n\nGMP-relevant records and data must be physically and electronically insured against accidental damage or willful, for the entire required retention period.\n\nThe roles, responsibilities and procedures for filing and retrieval must be defined, and there should be a standard operating procedure that describes the archiving strategy.\n\nRecords and stored data should be initially and then periodically checked for their accessibility, durability, accuracy and completeness, based on a risk analysis, taking into account considering the type of storage, the media and the method of access.\n\nArchiving processes must ensure that the content is preserved. Records with approvals required by GMP regulations must ensure that the validity of approval is maintained throughout the archiving period.\n\nRegulatory agencies must have access to GMP records during an inspection, within a specified period. Readable copies of archived records must be available on request.\n\n## 11.14.3 Responsibilities\n\nIt is the responsibility of the process owner to ensure that a filing process/procedure is established.\n\nIt is the responsibility of the Quality Unit to ensure that the filing process/procedure is followed.\n\nThe person performing the archiving is responsible for receiving from users the records to be archived, keeping these records in the state in which they were received and returning them in the same state.\n\nThe system owner is responsible for maintaining or updating the systems necessary to access the records.\n\n## 11.14.4 Archiving and Retention\n\nThe filing procedure should provide controls for:\n\n- Ensure secure storage facilities;\n- Check and maintain archived records for the entire retention period, that is, to manage the aging of storage media;", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "### Resumen del contexto\n\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos establece procedimientos claros para el archivo y recuperaci\u00f3n de registros relevantes para las Buenas Pr\u00e1cticas de Manufactura (GMP). Se enfatiza la importancia de diferenciar entre archivo y respaldo, as\u00ed como la necesidad de auditor\u00edas internas peri\u00f3dicas. Se detallan las responsabilidades de los propietarios de procesos, la unidad de calidad y el personal encargado del archivo, as\u00ed como los requisitos clave para asegurar la integridad y accesibilidad de los registros durante su per\u00edodo de retenci\u00f3n.\n\n### Preguntas espec\u00edficas\n\n1. **\u00bfCu\u00e1les son los criterios que deben considerarse al realizar un an\u00e1lisis de riesgo para la accesibilidad y durabilidad de los registros archivados?**\n   - Esta pregunta busca informaci\u00f3n sobre los factores espec\u00edficos que se deben evaluar en un an\u00e1lisis de riesgo, que no se detalla expl\u00edcitamente en el texto.\n\n2. **\u00bfQu\u00e9 procedimientos espec\u00edficos deben seguirse para garantizar que los registros archivados mantengan la validez de las aprobaciones requeridas por las regulaciones GMP durante el per\u00edodo de archivo?**\n   - Esta pregunta se centra en los pasos concretos que deben implementarse para asegurar la validez de las aprobaciones, un aspecto cr\u00edtico que podr\u00eda no estar ampliamente documentado en otras fuentes.\n\n3. **\u00bfQu\u00e9 tipo de auditor\u00edas internas se recomiendan para el proceso de archivo y con qu\u00e9 frecuencia deben llevarse a cabo?**\n   - Esta pregunta busca detalles sobre la naturaleza y frecuencia de las auditor\u00edas internas, que son esenciales para garantizar el cumplimiento, pero que pueden no estar claramente especificadas en otros documentos.\n\nEstas preguntas est\u00e1n dise\u00f1adas para extraer informaci\u00f3n espec\u00edfica y detallada que podr\u00eda no estar disponible en otras fuentes, bas\u00e1ndose en el contenido del documento de ANVISA.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Responsabilidades del Propietario del Sistema**:\n   - El propietario del sistema es responsable de asegurar el uso y mantenimiento del sistema mediante instrucciones de trabajo detalladas.\n   - Debe documentar claramente las tareas delegadas al administrador del sistema, quien puede ser la misma persona que el propietario.\n\n2. **Ejecuci\u00f3n de Actividades de Administraci\u00f3n del Sistema**:\n   - Implica establecer las necesidades y el alcance de las actividades de administraci\u00f3n.\n   - Se debe crear un cronograma de soporte para actividades regulares (diarias, semanales, mensuales).\n   - Identificaci\u00f3n de tareas relacionadas con la administraci\u00f3n del sistema, que pueden surgir del proceso de gesti\u00f3n de incidentes.\n   - Establecimiento de procedimientos operativos est\u00e1ndar para la administraci\u00f3n del sistema.\n\n3. **Gesti\u00f3n de Registros (Retenci\u00f3n, Archivo y Recuperaci\u00f3n)**:\n   - Las pol\u00edticas de retenci\u00f3n de registros deben basarse en requisitos regulatorios y pol\u00edticas corporativas.\n   - El archivo implica la eliminaci\u00f3n de registros del sistema y su almacenamiento en una ubicaci\u00f3n diferente, protegi\u00e9ndolos de cambios adicionales.\n   - Es esencial mantener aplicaciones que soporten registros y datos.\n\n### Entidades Clave\n- **Propietario del Sistema**: Responsable de la administraci\u00f3n y mantenimiento del sistema.\n- **Administrador del Sistema**: Persona encargada de ejecutar tareas espec\u00edficas de administraci\u00f3n.\n- **Actividades de Administraci\u00f3n del Sistema**: Acciones necesarias para mantener el sistema operativo.\n- **Pol\u00edticas de Retenci\u00f3n de Registros**: Normativas que dictan c\u00f3mo y cu\u00e1ndo se deben conservar los registros.\n- **Proceso de Archivo**: M\u00e9todo para mover registros a un lugar seguro, fuera del sistema operativo principal. \n\nEste resumen destaca las responsabilidades, procesos y pol\u00edticas clave relacionadas con la administraci\u00f3n de sistemas inform\u00e1ticos y la gesti\u00f3n de registros seg\u00fan el documento de ANVISA.", "excerpt_keywords": "Keywords: archiving, GMP, records management, internal audits, regulatory compliance"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "05b33809-a719-4040-bc9f-ff84b5ed5bc7", "node_type": "4", "metadata": {"page_label": "90", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "Archiving and retrieval procedures should be established on the basis of a clear understanding of regulatory requirements.\n\nArchiving and recovery should not be confused with backup and restore.\n\nArchiving must be subject to periodic internal audits.\n\n## 11.14.2 Key requirements\n\nGMP-relevant records and data must be physically and electronically insured against accidental damage or willful, for the entire required retention period.\n\nThe roles, responsibilities and procedures for filing and retrieval must be defined, and there should be a standard operating procedure that describes the archiving strategy.\n\nRecords and stored data should be initially and then periodically checked for their accessibility, durability, accuracy and completeness, based on a risk analysis, taking into account considering the type of storage, the media and the method of access.\n\nArchiving processes must ensure that the content is preserved. Records with approvals required by GMP regulations must ensure that the validity of approval is maintained throughout the archiving period.\n\nRegulatory agencies must have access to GMP records during an inspection, within a specified period. Readable copies of archived records must be available on request.\n\n## 11.14.3 Responsibilities\n\nIt is the responsibility of the process owner to ensure that a filing process/procedure is established.\n\nIt is the responsibility of the Quality Unit to ensure that the filing process/procedure is followed.\n\nThe person performing the archiving is responsible for receiving from users the records to be archived, keeping these records in the state in which they were received and returning them in the same state.\n\nThe system owner is responsible for maintaining or updating the systems necessary to access the records.\n\n## 11.14.4 Archiving and Retention\n\nThe filing procedure should provide controls for:\n\n- Ensure secure storage facilities;\n- Check and maintain archived records for the entire retention period, that is, to manage the aging of storage media;", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "f8274ae46e605c15e1b086b01537a293fe921960fa52dac9f6e0febab97aa95c", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "Archiving and retrieval procedures should be established on the basis of a clear understanding of regulatory requirements.\n\nArchiving and recovery should not be confused with backup and restore.\n\nArchiving must be subject to periodic internal audits.\n\n## 11.14.2 Key requirements\n\nGMP-relevant records and data must be physically and electronically insured against accidental damage or willful, for the entire required retention period.\n\nThe roles, responsibilities and procedures for filing and retrieval must be defined, and there should be a standard operating procedure that describes the archiving strategy.\n\nRecords and stored data should be initially and then periodically checked for their accessibility, durability, accuracy and completeness, based on a risk analysis, taking into account considering the type of storage, the media and the method of access.\n\nArchiving processes must ensure that the content is preserved. Records with approvals required by GMP regulations must ensure that the validity of approval is maintained throughout the archiving period.\n\nRegulatory agencies must have access to GMP records during an inspection, within a specified period. Readable copies of archived records must be available on request.\n\n## 11.14.3 Responsibilities\n\nIt is the responsibility of the process owner to ensure that a filing process/procedure is established.\n\nIt is the responsibility of the Quality Unit to ensure that the filing process/procedure is followed.\n\nThe person performing the archiving is responsible for receiving from users the records to be archived, keeping these records in the state in which they were received and returning them in the same state.\n\nThe system owner is responsible for maintaining or updating the systems necessary to access the records.\n\n## 11.14.4 Archiving and Retention\n\nThe filing procedure should provide controls for:\n\n- Ensure secure storage facilities;\n- Check and maintain archived records for the entire retention period, that is, to manage the aging of storage media;", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 2029, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "a8a75fc7-7f9a-4db4-b6c3-675448b4a18c": {"__data__": {"id_": "a8a75fc7-7f9a-4db4-b6c3-675448b4a18c", "embedding": null, "metadata": {"page_label": "91", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "- Provide indexing capabilities;\n- Detect the end of the intended retention period for specified records and notify management when appropriate;\n- Provide management with the option of extending the retention period;\n- Ensure that any changes to the records are carried out under change control;\n- Destroy records securely when proper authorization is given;\n- Ensure that the technology for reading archived records remains available throughout the retention period.\n\nIf the archiving process is computerized, the system must be validated. This system of automated archiving of records should:\n\n- Ensure that data is backed up at regular intervals. The data from the backup files must be stored for the retention period, in a separate secure location;\n- Ensure that the system and its content are secure;\n- Allow verification of the accessibility, accuracy and completeness of the records, after the making changes related to hardware and software;\n- Have the ability to keep track of changes in records;\n\n----\n\nGuide for Computer Systems Validation\nGuide n\u00b0 33/2020 - version 1, of 03/26/2020\n\n----\n\n- Ensure that the system and its contents are safe, keeping its meaning preserved;\n- Consider the continuous availability of devices and software needed to access the records.\n\n## 11.14.5 Recovery\n\nRetained records must be readily recoverable for business and regulatory purposes. The process recovery should be documented and consideration should be given to the following points:\n\n- There must be formal authorization to access the retained records;\n- There must be the ability to access online and offline electronic data, if applicable;\n- There must be an ability to obtain hard copies and readable electronic copies of the data electronically stored;\n- There should be a means to recover any registration required by regulation after retirement from a system regulated by GMP;\n- There should be a periodic recovery exercise or verification process to check your continuous operation.\n\n## 11.14.6 Execution of Activities\n\nArchiving and Recovery activities involve the following actions:\n\n1. Identification of records and data relevant to GMP;\n2. Definition of the retention policy for these records and data;\n- Definition of the archiving strategy, covering frequency, location, time required for", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento \"Gu\u00eda para la Validaci\u00f3n de Sistemas Inform\u00e1ticos\" de ANVISA establece directrices sobre el archivo y recuperaci\u00f3n de registros en el contexto de Buenas Pr\u00e1cticas de Manufactura (GMP). Se enfatiza la importancia de la validaci\u00f3n de sistemas automatizados de archivo, la seguridad de los datos, la accesibilidad y la recuperaci\u00f3n de registros para cumplir con requisitos regulatorios. Se detallan las acciones necesarias para la identificaci\u00f3n, definici\u00f3n de pol\u00edticas de retenci\u00f3n y estrategias de archivo.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfQu\u00e9 medidas deben implementarse para garantizar la seguridad de los datos en un sistema de archivo automatizado?**\n   - El sistema debe asegurar que los datos est\u00e9n respaldados a intervalos regulares, que el contenido del sistema sea seguro y que se pueda verificar la accesibilidad, precisi\u00f3n y completitud de los registros tras cambios en hardware y software.\n\n2. **\u00bfCu\u00e1les son los requisitos para la recuperaci\u00f3n de registros retenidos seg\u00fan la gu\u00eda de ANVISA?**\n   - La recuperaci\u00f3n de registros debe estar documentada y requiere autorizaci\u00f3n formal para acceder a los registros retenidos, as\u00ed como la capacidad de acceder a datos electr\u00f3nicos en l\u00ednea y fuera de l\u00ednea, y obtener copias impresas y electr\u00f3nicas legibles.\n\n3. **\u00bfQu\u00e9 acciones se deben llevar a cabo para la ejecuci\u00f3n de actividades de archivo y recuperaci\u00f3n en el contexto de GMP?**\n   - Las acciones incluyen la identificaci\u00f3n de registros y datos relevantes para GMP, la definici\u00f3n de la pol\u00edtica de retenci\u00f3n para estos registros y datos, y la definici\u00f3n de la estrategia de archivo, que abarca la frecuencia, ubicaci\u00f3n y tiempo requerido para el archivo.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Procedimientos de Archivo y Recuperaci\u00f3n**:\n   - Establecimiento de procedimientos claros basados en requisitos regulatorios.\n   - Diferenciaci\u00f3n entre archivo y respaldo.\n   - Auditor\u00edas internas peri\u00f3dicas para el proceso de archivo.\n\n2. **Requisitos Clave (Secci\u00f3n 11.14.2)**:\n   - Protecci\u00f3n f\u00edsica y electr\u00f3nica de registros y datos relevantes para GMP contra da\u00f1os accidentales o intencionados durante el per\u00edodo de retenci\u00f3n.\n   - Definici\u00f3n de roles, responsabilidades y procedimientos para el archivo y recuperaci\u00f3n.\n   - Verificaci\u00f3n inicial y peri\u00f3dica de la accesibilidad, durabilidad, precisi\u00f3n y completitud de los registros, basada en un an\u00e1lisis de riesgo.\n   - Preservaci\u00f3n del contenido durante el archivo, asegurando la validez de las aprobaciones requeridas por GMP.\n   - Acceso de agencias regulatorias a registros GMP durante inspecciones, con copias legibles disponibles a solicitud.\n\n3. **Responsabilidades (Secci\u00f3n 11.14.3)**:\n   - Propietario del proceso: Asegurar el establecimiento de un procedimiento de archivo.\n   - Unidad de Calidad: Garantizar el cumplimiento del procedimiento de archivo.\n   - Personal de archivo: Recibir, mantener y devolver registros en el estado en que fueron recibidos.\n   - Propietario del sistema: Mantener o actualizar los sistemas necesarios para acceder a los registros.\n\n4. **Archivo y Retenci\u00f3n (Secci\u00f3n 11.14.4)**:\n   - Provisi\u00f3n de controles para asegurar instalaciones de almacenamiento seguras.\n   - Verificaci\u00f3n y mantenimiento de registros archivados durante todo el per\u00edodo de retenci\u00f3n, gestionando el envejecimiento de los medios de almacenamiento.\n\n### Entidades Clave\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil.\n- **GMP**: Buenas Pr\u00e1cticas de Manufactura.\n- **Unidad de Calidad**: Entidad responsable de asegurar el cumplimiento de los procedimientos.\n- **Propietario del Proceso**: Persona encargada de establecer procedimientos de archivo.\n- **Personal de Archivo**: Encargado de la gesti\u00f3n de registros archivados.\n- **Agencias Regulatorias**: Entidades que supervisan el cumplimiento de las normativas. \n\nEste resumen destaca los aspectos fundamentales del documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos, centr\u00e1ndose en los procedimientos de archivo y las responsabilidades asociadas.", "excerpt_keywords": "Keywords: archiving, recovery, data security, GMP, validation"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "a1591ff5-f46a-4980-8e52-cf32c0330994", "node_type": "4", "metadata": {"page_label": "91", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "- Provide indexing capabilities;\n- Detect the end of the intended retention period for specified records and notify management when appropriate;\n- Provide management with the option of extending the retention period;\n- Ensure that any changes to the records are carried out under change control;\n- Destroy records securely when proper authorization is given;\n- Ensure that the technology for reading archived records remains available throughout the retention period.\n\nIf the archiving process is computerized, the system must be validated. This system of automated archiving of records should:\n\n- Ensure that data is backed up at regular intervals. The data from the backup files must be stored for the retention period, in a separate secure location;\n- Ensure that the system and its content are secure;\n- Allow verification of the accessibility, accuracy and completeness of the records, after the making changes related to hardware and software;\n- Have the ability to keep track of changes in records;\n\n----\n\nGuide for Computer Systems Validation\nGuide n\u00b0 33/2020 - version 1, of 03/26/2020\n\n----\n\n- Ensure that the system and its contents are safe, keeping its meaning preserved;\n- Consider the continuous availability of devices and software needed to access the records.\n\n## 11.14.5 Recovery\n\nRetained records must be readily recoverable for business and regulatory purposes. The process recovery should be documented and consideration should be given to the following points:\n\n- There must be formal authorization to access the retained records;\n- There must be the ability to access online and offline electronic data, if applicable;\n- There must be an ability to obtain hard copies and readable electronic copies of the data electronically stored;\n- There should be a means to recover any registration required by regulation after retirement from a system regulated by GMP;\n- There should be a periodic recovery exercise or verification process to check your continuous operation.\n\n## 11.14.6 Execution of Activities\n\nArchiving and Recovery activities involve the following actions:\n\n1. Identification of records and data relevant to GMP;\n2. Definition of the retention policy for these records and data;\n- Definition of the archiving strategy, covering frequency, location, time required for", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "220e09fca0a7850ba626a83deb315080d1ede53521eb7ecb65674f0da7e9b350", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "- Provide indexing capabilities;\n- Detect the end of the intended retention period for specified records and notify management when appropriate;\n- Provide management with the option of extending the retention period;\n- Ensure that any changes to the records are carried out under change control;\n- Destroy records securely when proper authorization is given;\n- Ensure that the technology for reading archived records remains available throughout the retention period.\n\nIf the archiving process is computerized, the system must be validated. This system of automated archiving of records should:\n\n- Ensure that data is backed up at regular intervals. The data from the backup files must be stored for the retention period, in a separate secure location;\n- Ensure that the system and its content are secure;\n- Allow verification of the accessibility, accuracy and completeness of the records, after the making changes related to hardware and software;\n- Have the ability to keep track of changes in records;\n\n----\n\nGuide for Computer Systems Validation\nGuide n\u00b0 33/2020 - version 1, of 03/26/2020\n\n----\n\n- Ensure that the system and its contents are safe, keeping its meaning preserved;\n- Consider the continuous availability of devices and software needed to access the records.\n\n## 11.14.5 Recovery\n\nRetained records must be readily recoverable for business and regulatory purposes. The process recovery should be documented and consideration should be given to the following points:\n\n- There must be formal authorization to access the retained records;\n- There must be the ability to access online and offline electronic data, if applicable;\n- There must be an ability to obtain hard copies and readable electronic copies of the data electronically stored;\n- There should be a means to recover any registration required by regulation after retirement from a system regulated by GMP;\n- There should be a periodic recovery exercise or verification process to check your continuous operation.\n\n## 11.14.6 Execution of Activities\n\nArchiving and Recovery activities involve the following actions:\n\n1. Identification of records and data relevant to GMP;\n2. Definition of the retention policy for these records and data;\n- Definition of the archiving strategy, covering frequency, location, time required for", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 2302, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "d0396dc4-95c0-4bb3-a79c-7cd1ae457c18": {"__data__": {"id_": "d0396dc4-95c0-4bb3-a79c-7cd1ae457c18", "embedding": null, "metadata": {"page_label": "92", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 12 DATA MIGRATION\n\n## 12.1 INTRODUCTION\n\nThis section covers procedures related to the planning, execution and verification of data migration.\n\nIt does not cover the transfer of data from one system to another, within a business process in progress. Such a situation must be addressed through typical specification and verification activities.\n\nData migration is an activity that can often occur during the life cycles of systems computerized systems used by regulated companies.\n\n----\n\nData migration is the activity of transporting electronic data from one system to another, or simply the transition of data from one system to another.\n\nSome examples of data migration are:\n\n- An update to an existing version of a database or application;\n- Data conversion (e.g., from a supplier's database to another);\n- Migration within the same system (e.g., transporting data from an application on a server to another);\n- Migration from a source system to a target system;\n- Migration from multiple source systems to a target system.\n\nThe complexity and risk involved in the data migration effort can increase significantly if rules are used to select a subset of data from the source system or if data is transformed (e.g., data type conversion; filtering; cleaning; aggregation; normalization) before being inserted into the target system. The ultimate goal of any data migration is to obtain data that remain usable and retain their contextual meaning. Quality management controls must exist to ensure that data migration efforts are successful, compatible and repeatable.\n\nEach data migration activity must be managed through a plan and report.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas que se pueden responder espec\u00edficamente con el contexto proporcionado sobre la migraci\u00f3n de datos seg\u00fan la gu\u00eda de ANVISA:\n\n1. **\u00bfCu\u00e1les son los principales riesgos asociados con la migraci\u00f3n de datos y c\u00f3mo se pueden mitigar?**\n   - La complejidad y el riesgo en la migraci\u00f3n de datos pueden aumentar significativamente si se aplican reglas para seleccionar un subconjunto de datos o si se realizan transformaciones en los datos antes de insertarlos en el sistema de destino. Para mitigar estos riesgos, es esencial implementar controles de gesti\u00f3n de calidad que aseguren que los esfuerzos de migraci\u00f3n sean exitosos, compatibles y repetibles.\n\n2. **\u00bfQu\u00e9 tipo de actividades de migraci\u00f3n de datos se consideran dentro del ciclo de vida de los sistemas utilizados por empresas reguladas?**\n   - Las actividades de migraci\u00f3n de datos que pueden ocurrir durante el ciclo de vida de los sistemas incluyen actualizaciones de versiones existentes de bases de datos o aplicaciones, conversiones de datos entre diferentes bases de datos, migraciones dentro del mismo sistema y migraciones desde m\u00faltiples sistemas de origen a un sistema de destino.\n\n3. **\u00bfQu\u00e9 documentaci\u00f3n es necesaria para gestionar adecuadamente una actividad de migraci\u00f3n de datos?**\n   - Cada actividad de migraci\u00f3n de datos debe ser gestionada a trav\u00e9s de un plan y un informe, lo que implica que se debe documentar el proceso de migraci\u00f3n, los datos involucrados, las transformaciones realizadas y los resultados obtenidos para asegurar la trazabilidad y la verificaci\u00f3n del proceso.\n\n### Resumen de nivel superior:\nLa secci\u00f3n sobre migraci\u00f3n de datos en la gu\u00eda de ANVISA destaca la importancia de planificar, ejecutar y verificar las actividades de migraci\u00f3n de datos en sistemas utilizados por empresas reguladas. Se enfatiza que la migraci\u00f3n de datos no solo implica el traslado de datos, sino que tambi\u00e9n puede incluir transformaciones complejas que requieren un manejo cuidadoso para garantizar la calidad y la integridad de los datos. Adem\u00e1s, se subraya la necesidad de documentaci\u00f3n adecuada para gestionar estos procesos de manera efectiva.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\nEl documento \"Gu\u00eda para la Validaci\u00f3n de Sistemas Inform\u00e1ticos\" de ANVISA aborda aspectos fundamentales relacionados con el archivo y recuperaci\u00f3n de registros en el contexto de Buenas Pr\u00e1cticas de Manufactura (GMP). A continuaci\u00f3n se presentan los temas clave y entidades mencionadas en la secci\u00f3n:\n\n#### Temas Clave:\n1. **Validaci\u00f3n de Sistemas de Archivo Automatizado**: Se requiere que los sistemas de archivo automatizados sean validados para garantizar su eficacia y seguridad.\n2. **Seguridad de los Datos**: Es esencial que los datos est\u00e9n respaldados regularmente y que el sistema y su contenido sean seguros.\n3. **Accesibilidad y Recuperaci\u00f3n de Registros**: Los registros deben ser f\u00e1cilmente recuperables para fines comerciales y regulatorios, con procesos documentados y autorizaciones formales para el acceso.\n4. **Pol\u00edticas de Retenci\u00f3n**: Se debe definir una pol\u00edtica de retenci\u00f3n clara para los registros y datos relevantes, as\u00ed como una estrategia de archivo que contemple frecuencia, ubicaci\u00f3n y tiempo de archivo.\n5. **Control de Cambios**: Cualquier modificaci\u00f3n a los registros debe realizarse bajo control de cambios para mantener la integridad de los datos.\n6. **Ejercicios de Recuperaci\u00f3n**: Se deben llevar a cabo ejercicios peri\u00f3dicos de recuperaci\u00f3n para verificar la operatividad continua del sistema.\n\n#### Entidades:\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil, responsable de la regulaci\u00f3n y supervisi\u00f3n de la salud p\u00fablica.\n- **GMP (Buenas Pr\u00e1cticas de Manufactura)**: Conjunto de normas y directrices que aseguran que los productos se fabriquen de manera consistente y controlada seg\u00fan est\u00e1ndares de calidad.\n- **Registros**: Documentos y datos que deben ser archivados y recuperados de acuerdo con las regulaciones establecidas.\n- **Sistema de Archivo Automatizado**: Tecnolog\u00eda utilizada para el almacenamiento y recuperaci\u00f3n de registros de manera digital.\n\nEste resumen destaca la importancia de la validaci\u00f3n, seguridad y accesibilidad de los registros en el contexto de la regulaci\u00f3n sanitaria y las buenas pr\u00e1cticas de manufactura.", "excerpt_keywords": "Keywords: data migration, quality management, regulated companies, data transformation, migration planning"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "cd6a5d36-8e26-45a7-b612-dcf0a4e586d5", "node_type": "4", "metadata": {"page_label": "92", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 12 DATA MIGRATION\n\n## 12.1 INTRODUCTION\n\nThis section covers procedures related to the planning, execution and verification of data migration.\n\nIt does not cover the transfer of data from one system to another, within a business process in progress. Such a situation must be addressed through typical specification and verification activities.\n\nData migration is an activity that can often occur during the life cycles of systems computerized systems used by regulated companies.\n\n----\n\nData migration is the activity of transporting electronic data from one system to another, or simply the transition of data from one system to another.\n\nSome examples of data migration are:\n\n- An update to an existing version of a database or application;\n- Data conversion (e.g., from a supplier's database to another);\n- Migration within the same system (e.g., transporting data from an application on a server to another);\n- Migration from a source system to a target system;\n- Migration from multiple source systems to a target system.\n\nThe complexity and risk involved in the data migration effort can increase significantly if rules are used to select a subset of data from the source system or if data is transformed (e.g., data type conversion; filtering; cleaning; aggregation; normalization) before being inserted into the target system. The ultimate goal of any data migration is to obtain data that remain usable and retain their contextual meaning. Quality management controls must exist to ensure that data migration efforts are successful, compatible and repeatable.\n\nEach data migration activity must be managed through a plan and report.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "ba3464b3ee84f7d3f1161318d189ec2c75b31d9df5a2ba072f211a467b5401fa", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "# 12 DATA MIGRATION\n\n## 12.1 INTRODUCTION\n\nThis section covers procedures related to the planning, execution and verification of data migration.\n\nIt does not cover the transfer of data from one system to another, within a business process in progress. Such a situation must be addressed through typical specification and verification activities.\n\nData migration is an activity that can often occur during the life cycles of systems computerized systems used by regulated companies.\n\n----\n\nData migration is the activity of transporting electronic data from one system to another, or simply the transition of data from one system to another.\n\nSome examples of data migration are:\n\n- An update to an existing version of a database or application;\n- Data conversion (e.g., from a supplier's database to another);\n- Migration within the same system (e.g., transporting data from an application on a server to another);\n- Migration from a source system to a target system;\n- Migration from multiple source systems to a target system.\n\nThe complexity and risk involved in the data migration effort can increase significantly if rules are used to select a subset of data from the source system or if data is transformed (e.g., data type conversion; filtering; cleaning; aggregation; normalization) before being inserted into the target system. The ultimate goal of any data migration is to obtain data that remain usable and retain their contextual meaning. Quality management controls must exist to ensure that data migration efforts are successful, compatible and repeatable.\n\nEach data migration activity must be managed through a plan and report.", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 1643, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "7795c406-c3e7-474d-bb7f-45490cd7c9e5": {"__data__": {"id_": "7795c406-c3e7-474d-bb7f-45490cd7c9e5", "embedding": null, "metadata": {"page_label": "93", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 12.2 QUALITY MANAGEMENT\n\n## 12.2.1 System Life Cycle\n\nData migration can occur many times during the life cycle of a computer system, in the following situations:\n\n- During the development and initial deployment of the system;\n- During application updates;\n- During the retirement of the system.\n\nAs with other life cycle phases and activities, data migration activities will be more consistent and successful if the life cycle contains procedures, tools, *templates* and examples of data migration.\n\nA complete life cycle should provide guidance for all aspects related to data migration, including:\n\n- Roles and responsibilities;\n- Documentation requirements;\n- Quality and compliance controls;\n- Technical and verification activities;\n- Project management.\n\nA standard operating procedure is the best method for describing and documenting the process, including quality and compliance requirements.\n\n## 12.2.2 Risk Management\n\nThe life cycle should include an established risk management process for assessing risks that are specific to activities related to computerized systems. In addition to the risks normally found in technological projects, the following items should be evaluated when carrying out the migration of regulated data:\n\n- The risk inherent in the quality and compliance associated with data migration, such as: the impact on patient safety, product quality and integrity;\n- The risk related to the business processes associated with the computer system involved;\n- The risk to the business due to the system becoming unavailable or the migrated data is not reliable;\n- The level of complexity (e.g., multiple sources or target systems; multiple phases; a lot of transformation data);\n- Technological risk due to the use of complex or cutting edge systems or tools.\n\n## 12.2.3 Configuration Management and Change Control", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior del contenido:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos destaca la importancia de la gesti\u00f3n de calidad a lo largo del ciclo de vida de un sistema. Se enfatiza la necesidad de procedimientos, herramientas y plantillas para la migraci\u00f3n de datos, as\u00ed como la gesti\u00f3n de riesgos asociados a esta actividad. Se identifican varios tipos de riesgos que deben ser evaluados, incluyendo aquellos relacionados con la calidad de los datos, la disponibilidad del sistema y la complejidad tecnol\u00f3gica. Adem\u00e1s, se menciona la importancia de la gesti\u00f3n de configuraci\u00f3n y el control de cambios.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfCu\u00e1les son las etapas del ciclo de vida de un sistema inform\u00e1tico en las que puede ocurrir la migraci\u00f3n de datos?**\n   - Respuesta: La migraci\u00f3n de datos puede ocurrir durante el desarrollo y la implementaci\u00f3n inicial del sistema, durante actualizaciones de la aplicaci\u00f3n y durante la jubilaci\u00f3n del sistema.\n\n2. **\u00bfQu\u00e9 elementos deben incluirse en un ciclo de vida completo para garantizar una migraci\u00f3n de datos exitosa?**\n   - Respuesta: Un ciclo de vida completo debe proporcionar orientaci\u00f3n sobre roles y responsabilidades, requisitos de documentaci\u00f3n, controles de calidad y cumplimiento, actividades t\u00e9cnicas y de verificaci\u00f3n, y gesti\u00f3n de proyectos.\n\n3. **\u00bfQu\u00e9 tipos de riesgos deben evaluarse espec\u00edficamente durante la migraci\u00f3n de datos regulados?**\n   - Respuesta: Los riesgos a evaluar incluyen el riesgo inherente a la calidad y cumplimiento de la migraci\u00f3n de datos (impacto en la seguridad del paciente, calidad del producto e integridad), riesgos relacionados con los procesos de negocio, riesgos por la falta de disponibilidad del sistema o la fiabilidad de los datos migrados, la complejidad del proceso de migraci\u00f3n y riesgos tecnol\u00f3gicos asociados al uso de sistemas o herramientas complejas.", "prev_section_summary": "### Resumen de la Secci\u00f3n sobre Migraci\u00f3n de Datos\n\n**Temas Clave:**\n\n1. **Definici\u00f3n de Migraci\u00f3n de Datos:**\n   - La migraci\u00f3n de datos implica el transporte de datos electr\u00f3nicos de un sistema a otro, lo que puede incluir actualizaciones, conversiones y migraciones dentro del mismo sistema o entre m\u00faltiples sistemas.\n\n2. **Ejemplos de Migraci\u00f3n de Datos:**\n   - Actualizaci\u00f3n de versiones de bases de datos o aplicaciones.\n   - Conversi\u00f3n de datos entre diferentes bases de datos.\n   - Migraci\u00f3n de datos dentro del mismo sistema.\n   - Migraci\u00f3n de un sistema de origen a un sistema de destino.\n   - Migraci\u00f3n desde m\u00faltiples sistemas de origen a un sistema de destino.\n\n3. **Complejidad y Riesgos:**\n   - La complejidad y el riesgo aumentan si se aplican reglas para seleccionar subconjuntos de datos o si se realizan transformaciones en los datos (como conversi\u00f3n de tipos, filtrado, limpieza, agregaci\u00f3n y normalizaci\u00f3n) antes de la inserci\u00f3n en el sistema de destino.\n\n4. **Objetivo de la Migraci\u00f3n de Datos:**\n   - Asegurar que los datos migrados sean utilizables y mantengan su significado contextual.\n\n5. **Controles de Gesti\u00f3n de Calidad:**\n   - Es esencial implementar controles de calidad para garantizar que los esfuerzos de migraci\u00f3n sean exitosos, compatibles y repetibles.\n\n6. **Documentaci\u00f3n:**\n   - Cada actividad de migraci\u00f3n debe ser gestionada mediante un plan y un informe, asegurando la trazabilidad y verificaci\u00f3n del proceso.\n\n**Entidades:**\n\n- **Sistemas Computarizados:** Utilizados por empresas reguladas.\n- **Datos Electr\u00f3nicos:** Elemento central de la migraci\u00f3n.\n- **Controles de Calidad:** Mecanismos necesarios para asegurar la integridad de la migraci\u00f3n.\n- **Plan y Reporte:** Documentaci\u00f3n requerida para gestionar la migraci\u00f3n de datos.\n\nEste resumen destaca la importancia de una planificaci\u00f3n cuidadosa, la gesti\u00f3n de riesgos y la documentaci\u00f3n adecuada en el proceso de migraci\u00f3n de datos, especialmente en el contexto de empresas reguladas.", "excerpt_keywords": "Keywords: data migration, quality management, risk management, system life cycle, compliance controls"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "f2f0eeb7-ecab-4410-9846-c73c93acbe7b", "node_type": "4", "metadata": {"page_label": "93", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 12.2 QUALITY MANAGEMENT\n\n## 12.2.1 System Life Cycle\n\nData migration can occur many times during the life cycle of a computer system, in the following situations:\n\n- During the development and initial deployment of the system;\n- During application updates;\n- During the retirement of the system.\n\nAs with other life cycle phases and activities, data migration activities will be more consistent and successful if the life cycle contains procedures, tools, *templates* and examples of data migration.\n\nA complete life cycle should provide guidance for all aspects related to data migration, including:\n\n- Roles and responsibilities;\n- Documentation requirements;\n- Quality and compliance controls;\n- Technical and verification activities;\n- Project management.\n\nA standard operating procedure is the best method for describing and documenting the process, including quality and compliance requirements.\n\n## 12.2.2 Risk Management\n\nThe life cycle should include an established risk management process for assessing risks that are specific to activities related to computerized systems. In addition to the risks normally found in technological projects, the following items should be evaluated when carrying out the migration of regulated data:\n\n- The risk inherent in the quality and compliance associated with data migration, such as: the impact on patient safety, product quality and integrity;\n- The risk related to the business processes associated with the computer system involved;\n- The risk to the business due to the system becoming unavailable or the migrated data is not reliable;\n- The level of complexity (e.g., multiple sources or target systems; multiple phases; a lot of transformation data);\n- Technological risk due to the use of complex or cutting edge systems or tools.\n\n## 12.2.3 Configuration Management and Change Control", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "8b989d8596d2f72d41ea59d4ebb3664aecee482b27621ead69eecd286fbf65be", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "# 12.2 QUALITY MANAGEMENT\n\n## 12.2.1 System Life Cycle\n\nData migration can occur many times during the life cycle of a computer system, in the following situations:\n\n- During the development and initial deployment of the system;\n- During application updates;\n- During the retirement of the system.\n\nAs with other life cycle phases and activities, data migration activities will be more consistent and successful if the life cycle contains procedures, tools, *templates* and examples of data migration.\n\nA complete life cycle should provide guidance for all aspects related to data migration, including:\n\n- Roles and responsibilities;\n- Documentation requirements;\n- Quality and compliance controls;\n- Technical and verification activities;\n- Project management.\n\nA standard operating procedure is the best method for describing and documenting the process, including quality and compliance requirements.\n\n## 12.2.2 Risk Management\n\nThe life cycle should include an established risk management process for assessing risks that are specific to activities related to computerized systems. In addition to the risks normally found in technological projects, the following items should be evaluated when carrying out the migration of regulated data:\n\n- The risk inherent in the quality and compliance associated with data migration, such as: the impact on patient safety, product quality and integrity;\n- The risk related to the business processes associated with the computer system involved;\n- The risk to the business due to the system becoming unavailable or the migrated data is not reliable;\n- The level of complexity (e.g., multiple sources or target systems; multiple phases; a lot of transformation data);\n- Technological risk due to the use of complex or cutting edge systems or tools.\n\n## 12.2.3 Configuration Management and Change Control", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 1844, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "fb2617cc-25ae-4f3c-b6bd-5349bd3d28da": {"__data__": {"id_": "fb2617cc-25ae-4f3c-b6bd-5349bd3d28da", "embedding": null, "metadata": {"page_label": "94", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 12.3 IMPORTANT POINTS\n\n## 12.3.1 Suitability of the Software Tools to the Intended Use\n\nData migration typically involves using *software* tools to automate some or all extraction, transformation, loading and verification activities. These tools tend to belong to GAMP category 1 - infrastructure tools (e.g., database migrators and verifiers purchased from a *software* vendor) or category 5 - custom applications (e.g., SQL scripts, data migration robots, internally developed programs).\n\nInfrastructure tools must be suitable for the intended use. The rigor of the activities of related specification and verification must be proportionate to the associated risks. Depending on the scope, complexity and customization of the *software* tools used, validation requirements may vary from obtaining evidence of basic testing to preparing full *software* and its formal verification.\n\nThe Subject Specialist (SME) should ensure that appropriate life cycle activities and objectives are reached are identified and executed.\n\nThe Quality Unit must review and approve the key documentation, in accordance with the procedures of the company.\n\nFor *software* tools that move or transform data, there are three main areas of risk:\n\n1. The data is moved or transformed incorrectly or incompletely;\n2. The data already existing in the target system is damaged;\n3. In case only part of the data is migrated, the residual data from the source system is adversely affected by the removal of the migrated data.\n\nIt is important that a data mapping table (i.e., fields in the model source system data mapped to the target system data model), when using *software* tools for migration.\n\n## 12.3.2 Verification of Data\n\nThe data must be verified whenever they are moved or transformed. There are two general types of post-migration verification of data: verification in a test environment and verification in an environment.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos destaca la importancia de la adecuaci\u00f3n de las herramientas de software para la migraci\u00f3n de datos. Se menciona que estas herramientas pueden clasificarse en categor\u00edas de GAMP y que su validaci\u00f3n debe ser proporcional a los riesgos asociados. Adem\u00e1s, se identifican \u00e1reas de riesgo en la migraci\u00f3n de datos y se enfatiza la necesidad de verificar los datos despu\u00e9s de su movimiento o transformaci\u00f3n.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfCu\u00e1les son las categor\u00edas de GAMP a las que pertenecen las herramientas de software utilizadas en la migraci\u00f3n de datos y qu\u00e9 ejemplos se dan para cada categor\u00eda?**\n   - Respuesta: Las herramientas de software utilizadas en la migraci\u00f3n de datos pertenecen a GAMP categor\u00eda 1 (herramientas de infraestructura, como migradores y verificadores de bases de datos) y categor\u00eda 5 (aplicaciones personalizadas, como scripts SQL y robots de migraci\u00f3n de datos).\n\n2. **\u00bfQu\u00e9 tres \u00e1reas de riesgo se identifican en el uso de herramientas de software para mover o transformar datos?**\n   - Respuesta: Las tres \u00e1reas de riesgo son: 1) el movimiento o transformaci\u00f3n incorrecta o incompleta de los datos; 2) el da\u00f1o a los datos existentes en el sistema de destino; y 3) el efecto adverso en los datos residuales del sistema de origen si solo se migra parte de los datos.\n\n3. **\u00bfQu\u00e9 tipo de verificaci\u00f3n se debe realizar despu\u00e9s de la migraci\u00f3n de datos y en qu\u00e9 entornos se puede llevar a cabo?**\n   - Respuesta: Se debe realizar una verificaci\u00f3n de los datos despu\u00e9s de su movimiento o transformaci\u00f3n, que puede llevarse a cabo en un entorno de prueba y en un entorno de producci\u00f3n.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Gesti\u00f3n de Calidad**: Se enfatiza la importancia de una gesti\u00f3n de calidad efectiva a lo largo del ciclo de vida de un sistema inform\u00e1tico, especialmente en las actividades de migraci\u00f3n de datos.\n\n2. **Ciclo de Vida del Sistema**:\n   - **Etapas de Migraci\u00f3n de Datos**: La migraci\u00f3n de datos puede ocurrir en tres momentos clave: durante el desarrollo y la implementaci\u00f3n inicial, durante actualizaciones de la aplicaci\u00f3n y al retirar el sistema.\n   - **Elementos de un Ciclo de Vida Completo**: Debe incluir roles y responsabilidades, requisitos de documentaci\u00f3n, controles de calidad y cumplimiento, actividades t\u00e9cnicas y de verificaci\u00f3n, y gesti\u00f3n de proyectos.\n\n3. **Gesti\u00f3n de Riesgos**:\n   - **Proceso de Evaluaci\u00f3n de Riesgos**: Se debe establecer un proceso de gesti\u00f3n de riesgos para evaluar los riesgos espec\u00edficos asociados con la migraci\u00f3n de datos regulados.\n   - **Tipos de Riesgos a Evaluar**:\n     - Riesgos relacionados con la calidad y cumplimiento de los datos migrados (impacto en la seguridad del paciente, calidad del producto e integridad).\n     - Riesgos asociados con los procesos de negocio del sistema.\n     - Riesgos por la falta de disponibilidad del sistema o la fiabilidad de los datos migrados.\n     - Complejidad del proceso de migraci\u00f3n (m\u00faltiples fuentes o sistemas de destino, m\u00faltiples fases, gran cantidad de datos transformados).\n     - Riesgos tecnol\u00f3gicos derivados del uso de sistemas o herramientas complejas.\n\n4. **Gesti\u00f3n de Configuraci\u00f3n y Control de Cambios**: Aunque no se detalla en esta secci\u00f3n, se menciona la importancia de estos aspectos en el contexto de la gesti\u00f3n de calidad y la migraci\u00f3n de datos.\n\n### Entidades Clave\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil, responsable de la regulaci\u00f3n de sistemas inform\u00e1ticos en el \u00e1mbito de la salud.\n- **Sistemas Inform\u00e1ticos**: Sistemas que requieren validaci\u00f3n y gesti\u00f3n de calidad en su ciclo de vida.\n- **Migraci\u00f3n de Datos**: Proceso cr\u00edtico que debe ser gestionado cuidadosamente para asegurar la calidad y cumplimiento.\n- **Riesgos**: Elementos que deben ser evaluados y gestionados durante la migraci\u00f3n de datos, incluyendo riesgos tecnol\u00f3gicos y de negocio.", "excerpt_keywords": "Keywords: data migration, software validation, GAMP categories, risk management, verification processes"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "d59decc2-e47b-46c0-a1a9-4fb2a49f429d", "node_type": "4", "metadata": {"page_label": "94", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 12.3 IMPORTANT POINTS\n\n## 12.3.1 Suitability of the Software Tools to the Intended Use\n\nData migration typically involves using *software* tools to automate some or all extraction, transformation, loading and verification activities. These tools tend to belong to GAMP category 1 - infrastructure tools (e.g., database migrators and verifiers purchased from a *software* vendor) or category 5 - custom applications (e.g., SQL scripts, data migration robots, internally developed programs).\n\nInfrastructure tools must be suitable for the intended use. The rigor of the activities of related specification and verification must be proportionate to the associated risks. Depending on the scope, complexity and customization of the *software* tools used, validation requirements may vary from obtaining evidence of basic testing to preparing full *software* and its formal verification.\n\nThe Subject Specialist (SME) should ensure that appropriate life cycle activities and objectives are reached are identified and executed.\n\nThe Quality Unit must review and approve the key documentation, in accordance with the procedures of the company.\n\nFor *software* tools that move or transform data, there are three main areas of risk:\n\n1. The data is moved or transformed incorrectly or incompletely;\n2. The data already existing in the target system is damaged;\n3. In case only part of the data is migrated, the residual data from the source system is adversely affected by the removal of the migrated data.\n\nIt is important that a data mapping table (i.e., fields in the model source system data mapped to the target system data model), when using *software* tools for migration.\n\n## 12.3.2 Verification of Data\n\nThe data must be verified whenever they are moved or transformed. There are two general types of post-migration verification of data: verification in a test environment and verification in an environment.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "d0d1c8a81fc521c9773af8339f1bdbd7016fd9edb969e6ecd25be93b7045aba8", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "# 12.3 IMPORTANT POINTS\n\n## 12.3.1 Suitability of the Software Tools to the Intended Use\n\nData migration typically involves using *software* tools to automate some or all extraction, transformation, loading and verification activities. These tools tend to belong to GAMP category 1 - infrastructure tools (e.g., database migrators and verifiers purchased from a *software* vendor) or category 5 - custom applications (e.g., SQL scripts, data migration robots, internally developed programs).\n\nInfrastructure tools must be suitable for the intended use. The rigor of the activities of related specification and verification must be proportionate to the associated risks. Depending on the scope, complexity and customization of the *software* tools used, validation requirements may vary from obtaining evidence of basic testing to preparing full *software* and its formal verification.\n\nThe Subject Specialist (SME) should ensure that appropriate life cycle activities and objectives are reached are identified and executed.\n\nThe Quality Unit must review and approve the key documentation, in accordance with the procedures of the company.\n\nFor *software* tools that move or transform data, there are three main areas of risk:\n\n1. The data is moved or transformed incorrectly or incompletely;\n2. The data already existing in the target system is damaged;\n3. In case only part of the data is migrated, the residual data from the source system is adversely affected by the removal of the migrated data.\n\nIt is important that a data mapping table (i.e., fields in the model source system data mapped to the target system data model), when using *software* tools for migration.\n\n## 12.3.2 Verification of Data\n\nThe data must be verified whenever they are moved or transformed. There are two general types of post-migration verification of data: verification in a test environment and verification in an environment.", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 1910, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "e9d6862b-5ea6-435a-827f-9e23f2e831f7": {"__data__": {"id_": "e9d6862b-5ea6-435a-827f-9e23f2e831f7", "embedding": null, "metadata": {"page_label": "95", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "In testing in a test environment, a target test system is initially filled with data, then a migration test is performed and finally the data on the target system is verified to demonstrate that all the data migrated successfully and without adversely affecting the existing data. This check provides objective evidence that the software tool is suitable for its intended use and provides a level of confidence about the migration process in general.\n\nThe intention of verification in the operating environment is the same: to verify the result of the migration process both migrated data and existing data. The amount of data involved, however, is usually much larger and therefore more difficult to verify. There are two general approaches to solving this problem: data sampling and automated data verification tools.\n\nIn data sampling, a statistical sample of the population of migrated and/or existing data is verified on the target or target system. Standards such as ANSI / ASQ Z1.4 and ISO 2859, can be used to determine the appropriate sample size to verify the compliance of the entire data population at the desired confidence level.\n\nAutomated software tools can be used to verify 100% of the data on the target system or destination. However, these tools have a higher level of risk and consequently their suitability must be strictly determined.\n\nAn important part of data migration is the confirmation that all necessary data has been migrated. Verification techniques, such as checksum, can be used to corroborate the transmission complete data.\n\nObjective evidence of data verification must be generated. Check scripts and data sheets, copies screens, error logs and paper reports should be created when appropriate and feasible.\n\n## 12.3.3 Reliability of Source Data\n\nIf the source system is maintained in compliance with regulatory requirements, then the combination of controls of the source system with the controls performed during the migration process should provide sufficient guarantee of the accuracy and integrity of the migrated data.\n\nTo document this, the data migration plan must reference the appropriate system documentation source.\n\nIf the situation of the source system is unknown, then there are two problems: first, the veracity of the data migrated from the source system may not be reliable; and second, the migrated data will mix with the trusted data already in the controlled target system. After migration, existing data that is trusted and unreliable data will be mixed and difficult to distinguish unless actions are taken to identify the migrated data, such as: differences in registration dates and notes in defined fields by the user. If this is not possible, then the possible data inconsistencies should be documented, explaining the existing controls in the source system and the justification of why the migrated data should be reliable.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con res\u00famenes de nivel superior que pueden ayudar a formularlas:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos detalla los procedimientos para garantizar la integridad y precisi\u00f3n de los datos durante el proceso de migraci\u00f3n. Se enfatiza la importancia de la verificaci\u00f3n tanto en entornos de prueba como en entornos operativos, y se discuten m\u00e9todos como el muestreo de datos y herramientas de verificaci\u00f3n automatizadas. Tambi\u00e9n se aborda la fiabilidad de los datos de origen y las implicaciones de mezclar datos migrados con datos existentes en el sistema de destino.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfCu\u00e1les son las implicaciones de no poder verificar la fiabilidad del sistema de origen antes de realizar una migraci\u00f3n de datos?**\n   - Respuesta: Si la situaci\u00f3n del sistema de origen es desconocida, la veracidad de los datos migrados puede no ser confiable, lo que resulta en la mezcla de datos confiables y no confiables en el sistema de destino. Esto puede dificultar la identificaci\u00f3n de datos migrados y generar inconsistencias que deben ser documentadas.\n\n2. **\u00bfQu\u00e9 est\u00e1ndares se pueden utilizar para determinar el tama\u00f1o de la muestra en el muestreo de datos durante la verificaci\u00f3n de la migraci\u00f3n?**\n   - Respuesta: Se pueden utilizar est\u00e1ndares como ANSI / ASQ Z1.4 y ISO 2859 para determinar el tama\u00f1o de la muestra apropiado que permita verificar la conformidad de toda la poblaci\u00f3n de datos al nivel de confianza deseado.\n\n3. **\u00bfQu\u00e9 tipo de evidencia objetiva se debe generar para documentar la verificaci\u00f3n de datos durante el proceso de migraci\u00f3n?**\n   - Respuesta: Se debe generar evidencia objetiva que puede incluir scripts de verificaci\u00f3n, hojas de datos, capturas de pantalla, registros de errores y reportes en papel, siempre que sea apropiado y factible. Esto es crucial para demostrar que el proceso de migraci\u00f3n se realiz\u00f3 correctamente y que los datos son precisos y completos.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n#### Temas Clave:\n1. **Adecuaci\u00f3n de Herramientas de Software**: La migraci\u00f3n de datos requiere herramientas de software que se clasifiquen en categor\u00edas GAMP, espec\u00edficamente categor\u00eda 1 (herramientas de infraestructura) y categor\u00eda 5 (aplicaciones personalizadas). La adecuaci\u00f3n de estas herramientas debe ser evaluada en funci\u00f3n de su uso previsto.\n\n2. **Rigor en la Validaci\u00f3n**: La validaci\u00f3n de las herramientas de software debe ser proporcional a los riesgos asociados, variando desde pruebas b\u00e1sicas hasta verificaciones formales completas.\n\n3. **\u00c1reas de Riesgo en la Migraci\u00f3n de Datos**:\n   - Movimiento o transformaci\u00f3n incorrecta o incompleta de datos.\n   - Da\u00f1o a los datos existentes en el sistema de destino.\n   - Efectos adversos en los datos residuales del sistema de origen si solo se migra parte de los datos.\n\n4. **Verificaci\u00f3n de Datos**: Es esencial verificar los datos despu\u00e9s de su movimiento o transformaci\u00f3n, lo que puede realizarse en entornos de prueba y producci\u00f3n.\n\n5. **Documentaci\u00f3n y Revisi\u00f3n**: La Unidad de Calidad debe revisar y aprobar la documentaci\u00f3n clave, siguiendo los procedimientos de la empresa.\n\n#### Entidades:\n- **GAMP**: Grupo de trabajo que clasifica herramientas de software en diferentes categor\u00edas.\n- **Herramientas de Infraestructura**: Ejemplos incluyen migradores y verificadores de bases de datos.\n- **Aplicaciones Personalizadas**: Ejemplos incluyen scripts SQL y robots de migraci\u00f3n de datos.\n- **Subject Specialist (SME)**: Especialista responsable de asegurar que se cumplan las actividades y objetivos del ciclo de vida.\n- **Quality Unit**: Unidad encargada de la revisi\u00f3n y aprobaci\u00f3n de la documentaci\u00f3n relacionada con la migraci\u00f3n de datos.\n\nEste resumen destaca la importancia de la adecuaci\u00f3n y validaci\u00f3n de las herramientas de software en la migraci\u00f3n de datos, as\u00ed como los riesgos asociados y la necesidad de verificaci\u00f3n post-migraci\u00f3n.", "excerpt_keywords": "Keywords: data migration, verification, source data reliability, automated tools, data sampling"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "8e951baf-e356-4a4e-810c-eebb3fbacc7c", "node_type": "4", "metadata": {"page_label": "95", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "In testing in a test environment, a target test system is initially filled with data, then a migration test is performed and finally the data on the target system is verified to demonstrate that all the data migrated successfully and without adversely affecting the existing data. This check provides objective evidence that the software tool is suitable for its intended use and provides a level of confidence about the migration process in general.\n\nThe intention of verification in the operating environment is the same: to verify the result of the migration process both migrated data and existing data. The amount of data involved, however, is usually much larger and therefore more difficult to verify. There are two general approaches to solving this problem: data sampling and automated data verification tools.\n\nIn data sampling, a statistical sample of the population of migrated and/or existing data is verified on the target or target system. Standards such as ANSI / ASQ Z1.4 and ISO 2859, can be used to determine the appropriate sample size to verify the compliance of the entire data population at the desired confidence level.\n\nAutomated software tools can be used to verify 100% of the data on the target system or destination. However, these tools have a higher level of risk and consequently their suitability must be strictly determined.\n\nAn important part of data migration is the confirmation that all necessary data has been migrated. Verification techniques, such as checksum, can be used to corroborate the transmission complete data.\n\nObjective evidence of data verification must be generated. Check scripts and data sheets, copies screens, error logs and paper reports should be created when appropriate and feasible.\n\n## 12.3.3 Reliability of Source Data\n\nIf the source system is maintained in compliance with regulatory requirements, then the combination of controls of the source system with the controls performed during the migration process should provide sufficient guarantee of the accuracy and integrity of the migrated data.\n\nTo document this, the data migration plan must reference the appropriate system documentation source.\n\nIf the situation of the source system is unknown, then there are two problems: first, the veracity of the data migrated from the source system may not be reliable; and second, the migrated data will mix with the trusted data already in the controlled target system. After migration, existing data that is trusted and unreliable data will be mixed and difficult to distinguish unless actions are taken to identify the migrated data, such as: differences in registration dates and notes in defined fields by the user. If this is not possible, then the possible data inconsistencies should be documented, explaining the existing controls in the source system and the justification of why the migrated data should be reliable.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "248706b508e03e025644c9ca19e059a385b77714d731135d6a2e15f467c88cd5", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "In testing in a test environment, a target test system is initially filled with data, then a migration test is performed and finally the data on the target system is verified to demonstrate that all the data migrated successfully and without adversely affecting the existing data. This check provides objective evidence that the software tool is suitable for its intended use and provides a level of confidence about the migration process in general.\n\nThe intention of verification in the operating environment is the same: to verify the result of the migration process both migrated data and existing data. The amount of data involved, however, is usually much larger and therefore more difficult to verify. There are two general approaches to solving this problem: data sampling and automated data verification tools.\n\nIn data sampling, a statistical sample of the population of migrated and/or existing data is verified on the target or target system. Standards such as ANSI / ASQ Z1.4 and ISO 2859, can be used to determine the appropriate sample size to verify the compliance of the entire data population at the desired confidence level.\n\nAutomated software tools can be used to verify 100% of the data on the target system or destination. However, these tools have a higher level of risk and consequently their suitability must be strictly determined.\n\nAn important part of data migration is the confirmation that all necessary data has been migrated. Verification techniques, such as checksum, can be used to corroborate the transmission complete data.\n\nObjective evidence of data verification must be generated. Check scripts and data sheets, copies screens, error logs and paper reports should be created when appropriate and feasible.\n\n## 12.3.3 Reliability of Source Data\n\nIf the source system is maintained in compliance with regulatory requirements, then the combination of controls of the source system with the controls performed during the migration process should provide sufficient guarantee of the accuracy and integrity of the migrated data.\n\nTo document this, the data migration plan must reference the appropriate system documentation source.\n\nIf the situation of the source system is unknown, then there are two problems: first, the veracity of the data migrated from the source system may not be reliable; and second, the migrated data will mix with the trusted data already in the controlled target system. After migration, existing data that is trusted and unreliable data will be mixed and difficult to distinguish unless actions are taken to identify the migrated data, such as: differences in registration dates and notes in defined fields by the user. If this is not possible, then the possible data inconsistencies should be documented, explaining the existing controls in the source system and the justification of why the migrated data should be reliable.", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 2889, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "61820dbb-7f35-4787-a429-e6c0eb10bbcb": {"__data__": {"id_": "61820dbb-7f35-4787-a429-e6c0eb10bbcb", "embedding": null, "metadata": {"page_label": "96", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "### 12.3.4 Usability of Migrated Data on the Target System\n\nThere are three main problems to be considered, related to the usability of the data migrated to the target system:\n\n1. The functionality of the target system does not allow the performance of tasks previously performed in the source system;\n2. Lack of completeness of the migrated data affects the usability of the data;\n3. It may not be enough to migrate the data. Separate migration of metadata or system configuration destination may be required. For example, the source data has some access rights defined for it, such as user groups and user rights. Data migration may not migrate this metadata, which are normally separated from the data. However, these groups and user rights can also be required on the target system.\n\n### 12.3.5 Audit Trails (Audit trails)\n\nAudit trails can be problematic for the data migration process. If the target system has an audit trail, but the source system does not, a document must be created reflecting that the Auditing of migrated records started when they were transferred to the target system. If possible, these records must be distinguishable from the records that were generated in the target system.\n\nIf both systems have audit trails and migration is feasible, the audit trail should be migrated along with the audited data. If it is technically impossible to migrate the audit trail or doing this would be a very big risk, the original audit trail should be archived in a format that can be recovered over time.\n\nWhenever possible, an audit trail created by the computer should be created during movement and transformation associated with data migration, as this audit trail serves not only as a verification tool, but also as a historical record of changes in data and should be archived in a format that can be retrieved over time.\n\n### 12.4 DATA MIGRATION PLAN\n\nDifferent types of data migration require different activities and objectives. Each migration process must have a data migration plan. This plan serves as a high-level roadmap that guides the team that performs the migration to execute it properly.\n\nThis plan should describe the entire migration process, including:\n\n- Purpose and scope of the migration project;\n- Description of the system(s);\n- Roles and responsibilities;\n- Objectives to be achieved;\n- Risk management strategy;", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que pueden ser respondidas por el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos aborda la migraci\u00f3n de datos, destacando problemas relacionados con la usabilidad de los datos migrados, la importancia de los registros de auditor\u00eda y la necesidad de un plan de migraci\u00f3n de datos. Se identifican problemas como la falta de funcionalidad en el sistema de destino, la incompletitud de los datos migrados y la posible necesidad de migrar metadatos. Adem\u00e1s, se discute c\u00f3mo manejar los registros de auditor\u00eda durante la migraci\u00f3n y se enfatiza la importancia de tener un plan de migraci\u00f3n bien definido.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfCu\u00e1les son las implicaciones de no migrar los metadatos junto con los datos en un proceso de migraci\u00f3n?**\n   - La falta de migraci\u00f3n de metadatos puede resultar en la p\u00e9rdida de configuraciones cr\u00edticas, como derechos de acceso y grupos de usuarios, lo que podr\u00eda afectar la funcionalidad y la seguridad del sistema de destino.\n\n2. **\u00bfQu\u00e9 pasos deben seguirse si el sistema de origen no tiene un registro de auditor\u00eda y el sistema de destino s\u00ed?**\n   - En este caso, se debe crear un documento que indique que la auditor\u00eda de los registros migrados comenz\u00f3 en el momento de la transferencia al sistema de destino, y se deben distinguir estos registros de los generados en el nuevo sistema.\n\n3. **\u00bfQu\u00e9 elementos clave debe incluir un plan de migraci\u00f3n de datos seg\u00fan el documento de ANVISA?**\n   - Un plan de migraci\u00f3n de datos debe incluir el prop\u00f3sito y el alcance del proyecto de migraci\u00f3n, una descripci\u00f3n de los sistemas involucrados, roles y responsabilidades, objetivos a alcanzar y una estrategia de gesti\u00f3n de riesgos.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Verificaci\u00f3n de Datos en Migraci\u00f3n**:\n   - La verificaci\u00f3n de datos es crucial tanto en entornos de prueba como en entornos operativos para asegurar que los datos migrados no afecten negativamente a los datos existentes.\n   - Se utilizan m\u00e9todos como el muestreo de datos y herramientas de verificaci\u00f3n automatizadas para validar la migraci\u00f3n.\n\n2. **Muestreo de Datos**:\n   - Se recomienda el uso de est\u00e1ndares como ANSI / ASQ Z1.4 y ISO 2859 para determinar el tama\u00f1o de la muestra necesaria para verificar la conformidad de la poblaci\u00f3n de datos migrados y existentes.\n\n3. **Herramientas de Verificaci\u00f3n Automatizadas**:\n   - Estas herramientas pueden verificar el 100% de los datos, pero conllevan un mayor riesgo, por lo que su idoneidad debe ser evaluada cuidadosamente.\n\n4. **Evidencia Objetiva**:\n   - Es fundamental generar evidencia objetiva de la verificaci\u00f3n de datos, que puede incluir scripts de verificaci\u00f3n, hojas de datos, capturas de pantalla, registros de errores y reportes en papel.\n\n5. **Fiabilidad de los Datos de Origen**:\n   - La fiabilidad de los datos migrados depende de que el sistema de origen cumpla con los requisitos regulatorios. Si la situaci\u00f3n del sistema de origen es desconocida, puede haber problemas de veracidad y mezcla de datos confiables y no confiables en el sistema de destino.\n\n6. **Documentaci\u00f3n del Proceso de Migraci\u00f3n**:\n   - El plan de migraci\u00f3n de datos debe referirse a la documentaci\u00f3n del sistema de origen para garantizar la precisi\u00f3n e integridad de los datos migrados.\n\n### Entidades Clave\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil, responsable de la regulaci\u00f3n de sistemas inform\u00e1ticos en el \u00e1mbito de la salud.\n- **Est\u00e1ndares ANSI / ASQ Z1.4 y ISO 2859**: Normas utilizadas para determinar el tama\u00f1o de la muestra en el muestreo de datos.\n- **Herramientas de Verificaci\u00f3n Automatizadas**: Software utilizado para verificar la integridad de los datos migrados.\n- **Checksum**: T\u00e9cnica de verificaci\u00f3n utilizada para corroborar la integridad de los datos transmitidos.\n- **Datos de Origen y Datos de Destino**: Conceptos que se refieren a los datos que se migran desde un sistema (origen) a otro (destino). \n\nEste resumen abarca los aspectos esenciales de la secci\u00f3n, destacando la importancia de la verificaci\u00f3n de datos y la documentaci\u00f3n en el proceso de migraci\u00f3n.", "excerpt_keywords": "Keywords: data migration, usability, audit trails, metadata, migration plan"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "115072f6-6ef1-4403-bd3d-c292803ffe5f", "node_type": "4", "metadata": {"page_label": "96", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "### 12.3.4 Usability of Migrated Data on the Target System\n\nThere are three main problems to be considered, related to the usability of the data migrated to the target system:\n\n1. The functionality of the target system does not allow the performance of tasks previously performed in the source system;\n2. Lack of completeness of the migrated data affects the usability of the data;\n3. It may not be enough to migrate the data. Separate migration of metadata or system configuration destination may be required. For example, the source data has some access rights defined for it, such as user groups and user rights. Data migration may not migrate this metadata, which are normally separated from the data. However, these groups and user rights can also be required on the target system.\n\n### 12.3.5 Audit Trails (Audit trails)\n\nAudit trails can be problematic for the data migration process. If the target system has an audit trail, but the source system does not, a document must be created reflecting that the Auditing of migrated records started when they were transferred to the target system. If possible, these records must be distinguishable from the records that were generated in the target system.\n\nIf both systems have audit trails and migration is feasible, the audit trail should be migrated along with the audited data. If it is technically impossible to migrate the audit trail or doing this would be a very big risk, the original audit trail should be archived in a format that can be recovered over time.\n\nWhenever possible, an audit trail created by the computer should be created during movement and transformation associated with data migration, as this audit trail serves not only as a verification tool, but also as a historical record of changes in data and should be archived in a format that can be retrieved over time.\n\n### 12.4 DATA MIGRATION PLAN\n\nDifferent types of data migration require different activities and objectives. Each migration process must have a data migration plan. This plan serves as a high-level roadmap that guides the team that performs the migration to execute it properly.\n\nThis plan should describe the entire migration process, including:\n\n- Purpose and scope of the migration project;\n- Description of the system(s);\n- Roles and responsibilities;\n- Objectives to be achieved;\n- Risk management strategy;", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "4378f95968a5a221b094e351263f045923d8fca1804d895031c2c8f92fb4ad13", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "### 12.3.4 Usability of Migrated Data on the Target System\n\nThere are three main problems to be considered, related to the usability of the data migrated to the target system:\n\n1. The functionality of the target system does not allow the performance of tasks previously performed in the source system;\n2. Lack of completeness of the migrated data affects the usability of the data;\n3. It may not be enough to migrate the data. Separate migration of metadata or system configuration destination may be required. For example, the source data has some access rights defined for it, such as user groups and user rights. Data migration may not migrate this metadata, which are normally separated from the data. However, these groups and user rights can also be required on the target system.\n\n### 12.3.5 Audit Trails (Audit trails)\n\nAudit trails can be problematic for the data migration process. If the target system has an audit trail, but the source system does not, a document must be created reflecting that the Auditing of migrated records started when they were transferred to the target system. If possible, these records must be distinguishable from the records that were generated in the target system.\n\nIf both systems have audit trails and migration is feasible, the audit trail should be migrated along with the audited data. If it is technically impossible to migrate the audit trail or doing this would be a very big risk, the original audit trail should be archived in a format that can be recovered over time.\n\nWhenever possible, an audit trail created by the computer should be created during movement and transformation associated with data migration, as this audit trail serves not only as a verification tool, but also as a historical record of changes in data and should be archived in a format that can be retrieved over time.\n\n### 12.4 DATA MIGRATION PLAN\n\nDifferent types of data migration require different activities and objectives. Each migration process must have a data migration plan. This plan serves as a high-level roadmap that guides the team that performs the migration to execute it properly.\n\nThis plan should describe the entire migration process, including:\n\n- Purpose and scope of the migration project;\n- Description of the system(s);\n- Roles and responsibilities;\n- Objectives to be achieved;\n- Risk management strategy;", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 2358, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "8ab25a81-9050-4799-b072-11e5656908a9": {"__data__": {"id_": "8ab25a81-9050-4799-b072-11e5656908a9", "embedding": null, "metadata": {"page_label": "97", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "- Configuration management strategy, including source, stationary and destiny;\n- Overview and strategy of the software tool to ensure compliance and suitability for use intended;\n- Migration steps and technical activities;\n- Mapping and data modeling activities;\n- Transformation rules;\n- Data verification strategy and acceptance criteria;\n- Transition plan;\n- Reversal strategy.\n\nThe migration plan must be approved by the process owner, system owner, Quality Unit and Subject matter expert where appropriate.\n\nThere may be situations where the migration plan can be used more than once. When this occurs, a data migration report must be generated.\n\n## 12.5 DATA MIGRATION REPORT\n\nThe data migration report summarizes the activities that were conducted during the migration process. Describes any anomalies or deviations that have occurred and lists the results of the verification activities, including objective evidence, where appropriate.\n\nBecause the report is used to establish the reliability of the migrated data, it must declare clearly the result of the migration activity.\n\nThe data migration report must be approved by the process owner, system owner, Quality and subject matter expert, when appropriate.\n\nIn the event that the data migration activity is carried out as part of a system design computerized, such as replacement or update, the report can be registered within the project documentation and there needs to be a separate document.\n\n## 13 RETIREMENT OF COMPUTERIZED SYSTEMS\n\n### 13.1 INTRODUCTION\n\nThe system's retirement process must be documented through a retirement plan, which usually receives contributions from the following actors: owner of the process, Quality Unit, owner of the system and Information Technology.\n\nProcess planning content can include:\n-", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos establece directrices para la gesti\u00f3n de la migraci\u00f3n de datos y el retiro de sistemas inform\u00e1ticos. Se enfatiza la importancia de un plan de migraci\u00f3n que debe ser aprobado por varias partes interesadas y la necesidad de un informe de migraci\u00f3n de datos que documente las actividades realizadas, anomal\u00edas y resultados de verificaci\u00f3n. Adem\u00e1s, se menciona que el proceso de retiro de sistemas debe ser documentado adecuadamente, involucrando a actores clave como el propietario del proceso y la unidad de calidad.\n\n### Preguntas Espec\u00edficas\n1. **\u00bfQu\u00e9 actores deben aprobar el plan de migraci\u00f3n de datos y por qu\u00e9 es importante su aprobaci\u00f3n?**\n   - El plan de migraci\u00f3n debe ser aprobado por el propietario del proceso, el propietario del sistema, la Unidad de Calidad y el experto en la materia, cuando sea apropiado. Esta aprobaci\u00f3n es crucial para garantizar que todas las partes interesadas est\u00e9n de acuerdo con el enfoque y los procedimientos de migraci\u00f3n, lo que ayuda a asegurar la integridad y la fiabilidad de los datos migrados.\n\n2. **\u00bfQu\u00e9 informaci\u00f3n debe incluirse en el informe de migraci\u00f3n de datos y cu\u00e1l es su prop\u00f3sito?**\n   - El informe de migraci\u00f3n de datos debe resumir las actividades realizadas durante el proceso de migraci\u00f3n, describir cualquier anomal\u00eda o desviaci\u00f3n que haya ocurrido y listar los resultados de las actividades de verificaci\u00f3n, incluyendo evidencia objetiva cuando sea apropiado. Su prop\u00f3sito es establecer la fiabilidad de los datos migrados y proporcionar un registro claro de los resultados de la actividad de migraci\u00f3n.\n\n3. **\u00bfCu\u00e1les son los componentes clave que deben documentarse en un plan de retiro de sistemas inform\u00e1ticos?**\n   - El plan de retiro de sistemas inform\u00e1ticos debe documentar el proceso de retiro y generalmente incluye contribuciones de actores como el propietario del proceso, la Unidad de Calidad, el propietario del sistema y el departamento de Tecnolog\u00eda de la Informaci\u00f3n. Los contenidos del plan pueden abarcar aspectos como la estrategia de gesti\u00f3n de la configuraci\u00f3n y las actividades necesarias para asegurar un retiro ordenado y conforme a las regulaciones.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Usabilidad de los Datos Migrados**:\n   - **Problemas Identificados**:\n     - Funcionalidad del sistema de destino que puede no permitir tareas previamente realizadas en el sistema de origen.\n     - Incompletitud de los datos migrados que afecta su usabilidad.\n     - Necesidad de migrar metadatos o configuraciones del sistema de destino, como derechos de acceso y grupos de usuarios.\n\n2. **Registros de Auditor\u00eda**:\n   - **Desaf\u00edos**:\n     - Si el sistema de origen no tiene un registro de auditor\u00eda y el de destino s\u00ed, se debe documentar el inicio de la auditor\u00eda de los registros migrados.\n     - Si ambos sistemas tienen registros de auditor\u00eda, estos deben ser migrados junto con los datos auditados, a menos que sea t\u00e9cnicamente inviable o arriesgado.\n     - Importancia de crear un registro de auditor\u00eda durante el proceso de migraci\u00f3n para servir como herramienta de verificaci\u00f3n y registro hist\u00f3rico.\n\n3. **Plan de Migraci\u00f3n de Datos**:\n   - **Elementos Clave**:\n     - Prop\u00f3sito y alcance del proyecto de migraci\u00f3n.\n     - Descripci\u00f3n de los sistemas involucrados.\n     - Roles y responsabilidades del equipo de migraci\u00f3n.\n     - Objetivos a alcanzar durante la migraci\u00f3n.\n     - Estrategia de gesti\u00f3n de riesgos para abordar posibles problemas.\n\n### Entidades Clave\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil, responsable de la regulaci\u00f3n y validaci\u00f3n de sistemas inform\u00e1ticos en el \u00e1mbito de la salud.\n- **Sistemas de Origen y Destino**: Sistemas entre los cuales se realiza la migraci\u00f3n de datos.\n- **Metadatos**: Informaci\u00f3n adicional sobre los datos que puede ser crucial para la funcionalidad y seguridad del sistema de destino.\n- **Registros de Auditor\u00eda**: Documentaci\u00f3n que rastrea las acciones realizadas sobre los datos, esencial para la trazabilidad y cumplimiento normativo. \n\nEste resumen destaca la importancia de considerar la usabilidad, la gesti\u00f3n de registros de auditor\u00eda y la planificaci\u00f3n adecuada en los procesos de migraci\u00f3n de datos.", "excerpt_keywords": "Keywords: migration plan, data verification, retirement process, quality assurance, system validation"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "0eca79aa-00fd-4c30-b48b-482fb9240a7b", "node_type": "4", "metadata": {"page_label": "97", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "- Configuration management strategy, including source, stationary and destiny;\n- Overview and strategy of the software tool to ensure compliance and suitability for use intended;\n- Migration steps and technical activities;\n- Mapping and data modeling activities;\n- Transformation rules;\n- Data verification strategy and acceptance criteria;\n- Transition plan;\n- Reversal strategy.\n\nThe migration plan must be approved by the process owner, system owner, Quality Unit and Subject matter expert where appropriate.\n\nThere may be situations where the migration plan can be used more than once. When this occurs, a data migration report must be generated.\n\n## 12.5 DATA MIGRATION REPORT\n\nThe data migration report summarizes the activities that were conducted during the migration process. Describes any anomalies or deviations that have occurred and lists the results of the verification activities, including objective evidence, where appropriate.\n\nBecause the report is used to establish the reliability of the migrated data, it must declare clearly the result of the migration activity.\n\nThe data migration report must be approved by the process owner, system owner, Quality and subject matter expert, when appropriate.\n\nIn the event that the data migration activity is carried out as part of a system design computerized, such as replacement or update, the report can be registered within the project documentation and there needs to be a separate document.\n\n## 13 RETIREMENT OF COMPUTERIZED SYSTEMS\n\n### 13.1 INTRODUCTION\n\nThe system's retirement process must be documented through a retirement plan, which usually receives contributions from the following actors: owner of the process, Quality Unit, owner of the system and Information Technology.\n\nProcess planning content can include:\n-", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "9ac02fe94b79cef3b3f37935d231a72bfd396014f6115fb839b940b45f0f4102", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "- Configuration management strategy, including source, stationary and destiny;\n- Overview and strategy of the software tool to ensure compliance and suitability for use intended;\n- Migration steps and technical activities;\n- Mapping and data modeling activities;\n- Transformation rules;\n- Data verification strategy and acceptance criteria;\n- Transition plan;\n- Reversal strategy.\n\nThe migration plan must be approved by the process owner, system owner, Quality Unit and Subject matter expert where appropriate.\n\nThere may be situations where the migration plan can be used more than once. When this occurs, a data migration report must be generated.\n\n## 12.5 DATA MIGRATION REPORT\n\nThe data migration report summarizes the activities that were conducted during the migration process. Describes any anomalies or deviations that have occurred and lists the results of the verification activities, including objective evidence, where appropriate.\n\nBecause the report is used to establish the reliability of the migrated data, it must declare clearly the result of the migration activity.\n\nThe data migration report must be approved by the process owner, system owner, Quality and subject matter expert, when appropriate.\n\nIn the event that the data migration activity is carried out as part of a system design computerized, such as replacement or update, the report can be registered within the project documentation and there needs to be a separate document.\n\n## 13 RETIREMENT OF COMPUTERIZED SYSTEMS\n\n### 13.1 INTRODUCTION\n\nThe system's retirement process must be documented through a retirement plan, which usually receives contributions from the following actors: owner of the process, Quality Unit, owner of the system and Information Technology.\n\nProcess planning content can include:\n-", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 1790, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "1f838a5d-cfd5-4f54-925e-d747a78caf77": {"__data__": {"id_": "1f838a5d-cfd5-4f54-925e-d747a78caf77", "embedding": null, "metadata": {"page_label": "98", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "- Destruction and retention requirements for historical data or records;\n- Identification of the current hardware and software configuration, as well as the systems they have interface, equipment or instruments;\n- Identification of any external systems that depend on the system's data or records.\n\nThe extent and accuracy of planning depends on the impact of the system and the risks associated with loss of Dice.\n\nThe system's retirement plan must be approved by the process owner and quality unit.\n\n## 13.2 SYSTEM RETIREMENT PLAN\n\n### 13.2.1 Introduction\n\nThe introduction should include:\n\n- Who produced the document, under what authority and for what purpose;\n- Reference to policies, procedures, standards, guides and other documents.\n\n### 13.2.2 Roles and Responsibilities\n\nThe roles and responsibilities associated with the retirement process must be documented in the plan, and must include the owner of the process, the Quality Unit, the owner of the system, the retirement team and its members and any other actors that contribute to the process.\n\n### 13.2.3 Overview and Implications\n\nConsideration should be given to the retirement effect of the system in some aspects, such as:\n\n- **Strategy** - document the impact on the overall technology strategy and initiate any updates to the documentation or other necessary actions;\n- **Process** - describe the impact on supporting the business process after retirement;\n- **Technology** - the scope and boundaries of the system to be retired must be determined and documented, as well as the justification for retirement. Identify other systems, instruments or equipment that has interfaces with the system that will retire. Data or information sources can be located on multiple systems. Identify the infrastructure components (network, etc.) that will need to be decoupled from the system;\n- **Personnel** - describe the impact on users of the system.\n\n### 13.2.4 Description of the Business Process\n\nThe pre-retirement business process must be documented and understood from the perspective of the process, user and data / records. This helps to ensure that all impacts are identified and all support and automation angles are translated into a post-retirement scenario.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos establece directrices para la planificaci\u00f3n de la jubilaci\u00f3n de sistemas. Se enfatiza la importancia de documentar los roles y responsabilidades en el proceso de jubilaci\u00f3n, as\u00ed como las implicaciones estrat\u00e9gicas, de proceso, tecnol\u00f3gicas y de personal. Tambi\u00e9n se menciona la necesidad de un plan de jubilaci\u00f3n aprobado por el propietario del proceso y la unidad de calidad, y se destaca la importancia de entender el proceso de negocio previo a la jubilaci\u00f3n para identificar todos los impactos.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfQu\u00e9 elementos deben incluirse en la introducci\u00f3n del plan de jubilaci\u00f3n del sistema seg\u00fan el documento de ANVISA?**\n   - La introducci\u00f3n debe incluir qui\u00e9n produjo el documento, bajo qu\u00e9 autoridad y con qu\u00e9 prop\u00f3sito, as\u00ed como referencias a pol\u00edticas, procedimientos, est\u00e1ndares, gu\u00edas y otros documentos relevantes.\n\n2. **\u00bfCu\u00e1les son las consideraciones clave que deben tenerse en cuenta al evaluar el impacto de la jubilaci\u00f3n de un sistema en la estrategia tecnol\u00f3gica de una organizaci\u00f3n?**\n   - Se debe documentar el impacto en la estrategia tecnol\u00f3gica general, iniciar actualizaciones necesarias en la documentaci\u00f3n y considerar c\u00f3mo la jubilaci\u00f3n afectar\u00e1 el soporte de los procesos comerciales.\n\n3. **\u00bfQu\u00e9 pasos deben seguirse para identificar los sistemas externos que dependen de los datos o registros del sistema que se va a jubilar?**\n   - Es necesario identificar otros sistemas, instrumentos o equipos que tengan interfaces con el sistema que se jubilar\u00e1, as\u00ed como determinar y documentar el alcance y los l\u00edmites del sistema a jubilar, justificando su jubilaci\u00f3n y localizando fuentes de datos en m\u00faltiples sistemas.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos aborda dos temas principales: la migraci\u00f3n de datos y el retiro de sistemas inform\u00e1ticos.\n\n#### Temas Clave\n\n1. **Plan de Migraci\u00f3n de Datos**:\n   - Se requiere un plan de migraci\u00f3n que incluya estrategias de gesti\u00f3n de configuraci\u00f3n, pasos de migraci\u00f3n, actividades de mapeo y modelado de datos, reglas de transformaci\u00f3n, y criterios de verificaci\u00f3n de datos.\n   - La aprobaci\u00f3n del plan es necesaria por parte del propietario del proceso, el propietario del sistema, la Unidad de Calidad y el experto en la materia.\n\n2. **Informe de Migraci\u00f3n de Datos**:\n   - Debe resumir las actividades realizadas, describir anomal\u00edas y listar resultados de verificaci\u00f3n.\n   - Su prop\u00f3sito es establecer la fiabilidad de los datos migrados y debe ser aprobado por las mismas partes interesadas que el plan de migraci\u00f3n.\n\n3. **Retiro de Sistemas Inform\u00e1ticos**:\n   - El proceso de retiro debe ser documentado a trav\u00e9s de un plan de retiro que involucre a actores clave como el propietario del proceso, la Unidad de Calidad, el propietario del sistema y el departamento de Tecnolog\u00eda de la Informaci\u00f3n.\n   - El contenido del plan puede incluir estrategias y actividades necesarias para un retiro ordenado y conforme a las regulaciones.\n\n#### Entidades Involucradas\n\n- **Propietario del Proceso**: Responsable de la supervisi\u00f3n del proceso de migraci\u00f3n y retiro.\n- **Propietario del Sistema**: Encargado de la gesti\u00f3n del sistema inform\u00e1tico en cuesti\u00f3n.\n- **Unidad de Calidad**: Asegura que los procesos cumplan con los est\u00e1ndares de calidad requeridos.\n- **Experto en la Materia**: Proporciona conocimientos especializados relevantes para el proceso.\n- **Departamento de Tecnolog\u00eda de la Informaci\u00f3n**: Apoya en la implementaci\u00f3n t\u00e9cnica de los procesos de migraci\u00f3n y retiro.\n\nEste resumen destaca la importancia de la planificaci\u00f3n y documentaci\u00f3n en la migraci\u00f3n y retiro de sistemas inform\u00e1ticos, asegurando la integridad y fiabilidad de los datos a lo largo del proceso.", "excerpt_keywords": "Keywords: system retirement, data retention, roles and responsibilities, technology strategy, business process documentation"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "2f0329c3-19b8-4c80-8bd9-0ceb09d80315", "node_type": "4", "metadata": {"page_label": "98", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "- Destruction and retention requirements for historical data or records;\n- Identification of the current hardware and software configuration, as well as the systems they have interface, equipment or instruments;\n- Identification of any external systems that depend on the system's data or records.\n\nThe extent and accuracy of planning depends on the impact of the system and the risks associated with loss of Dice.\n\nThe system's retirement plan must be approved by the process owner and quality unit.\n\n## 13.2 SYSTEM RETIREMENT PLAN\n\n### 13.2.1 Introduction\n\nThe introduction should include:\n\n- Who produced the document, under what authority and for what purpose;\n- Reference to policies, procedures, standards, guides and other documents.\n\n### 13.2.2 Roles and Responsibilities\n\nThe roles and responsibilities associated with the retirement process must be documented in the plan, and must include the owner of the process, the Quality Unit, the owner of the system, the retirement team and its members and any other actors that contribute to the process.\n\n### 13.2.3 Overview and Implications\n\nConsideration should be given to the retirement effect of the system in some aspects, such as:\n\n- **Strategy** - document the impact on the overall technology strategy and initiate any updates to the documentation or other necessary actions;\n- **Process** - describe the impact on supporting the business process after retirement;\n- **Technology** - the scope and boundaries of the system to be retired must be determined and documented, as well as the justification for retirement. Identify other systems, instruments or equipment that has interfaces with the system that will retire. Data or information sources can be located on multiple systems. Identify the infrastructure components (network, etc.) that will need to be decoupled from the system;\n- **Personnel** - describe the impact on users of the system.\n\n### 13.2.4 Description of the Business Process\n\nThe pre-retirement business process must be documented and understood from the perspective of the process, user and data / records. This helps to ensure that all impacts are identified and all support and automation angles are translated into a post-retirement scenario.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "4e49858e51782a0adfdec7931e1d67b02adfc70122047f9163c23bc0c5fb234b", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "- Destruction and retention requirements for historical data or records;\n- Identification of the current hardware and software configuration, as well as the systems they have interface, equipment or instruments;\n- Identification of any external systems that depend on the system's data or records.\n\nThe extent and accuracy of planning depends on the impact of the system and the risks associated with loss of Dice.\n\nThe system's retirement plan must be approved by the process owner and quality unit.\n\n## 13.2 SYSTEM RETIREMENT PLAN\n\n### 13.2.1 Introduction\n\nThe introduction should include:\n\n- Who produced the document, under what authority and for what purpose;\n- Reference to policies, procedures, standards, guides and other documents.\n\n### 13.2.2 Roles and Responsibilities\n\nThe roles and responsibilities associated with the retirement process must be documented in the plan, and must include the owner of the process, the Quality Unit, the owner of the system, the retirement team and its members and any other actors that contribute to the process.\n\n### 13.2.3 Overview and Implications\n\nConsideration should be given to the retirement effect of the system in some aspects, such as:\n\n- **Strategy** - document the impact on the overall technology strategy and initiate any updates to the documentation or other necessary actions;\n- **Process** - describe the impact on supporting the business process after retirement;\n- **Technology** - the scope and boundaries of the system to be retired must be determined and documented, as well as the justification for retirement. Identify other systems, instruments or equipment that has interfaces with the system that will retire. Data or information sources can be located on multiple systems. Identify the infrastructure components (network, etc.) that will need to be decoupled from the system;\n- **Personnel** - describe the impact on users of the system.\n\n### 13.2.4 Description of the Business Process\n\nThe pre-retirement business process must be documented and understood from the perspective of the process, user and data / records. This helps to ensure that all impacts are identified and all support and automation angles are translated into a post-retirement scenario.", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 2231, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "aab4728c-037c-4724-82df-647e50078b59": {"__data__": {"id_": "aab4728c-037c-4724-82df-647e50078b59", "embedding": null, "metadata": {"page_label": "99", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "This future scenario must be documented and understood, especially with regard to changes in the process and/or user and the location or effect on the data/records.\n\n## 13.2.5 Approach to Retirement\n\nThe decision on whether to replace the system should be documented. If the system is replaced, the retirement planning should be referenced and synchronized with the substitute system. The approach for decoupling the *interface*, disconnecting the infrastructure, finalizing or transition from technical support and any assumptions, exclusions, limitations or dependencies must be documented.\n\n## 13.2.6 Migration, Archiving and Destruction of Data and Records\n\nThe plan must identify what data should be migrated, archived or destroyed and the approval process associated.\n\nThe approach to data migration and archiving should be determined based on the history of access to data, the need for reprocessing, the risk level of registration and the robustness of the media used. Controls should be established to ensure that data and records remain secure, complete, accurate and that the signature/registration relationship is preserved, when applicable.\n\nThe approach must take into account the following aspects:\n\n- If data are to be maintained, they must be **backed up** and stored, in accordance with company data retention schedules and procedures;\n- Before data is moved or archived from the system, the appropriate data recovery must be available and tested;\n- The archived data media must be stored and maintained in accordance with the recommendations of the manufacturer and under the necessary environmental conditions;\n- If data and records are migrated to a replacement system, the migration must be planned, conducted and verified to ensure data integrity. Migration procedures should be tested or confirmed before data is completely transferred out of the system;\n- The methods to be used for migration/conversion and verification of data records must be defined. This may include performing pilot work before actual data migration occurs, or temporary parallel operation of both systems (new system and the system to be retired);\n- If the data is going to be migrated to the replacement system, the testing strategy for verifying the migration must be defined. If an automated migration or conversion is used, the approach to ensuring their suitability for the intended use must be documented.\n\n## 13.2.7 Approach to Verification\n\nVerification documentation, necessary as part of the employee's retirement process, must be identified.\n\n## 13.2.8 System Maintenance and Discontinuation of Support\n\nThe necessary actions associated with (s) must be planned:", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior del contenido:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos aborda la planificaci\u00f3n y ejecuci\u00f3n de la jubilaci\u00f3n de sistemas, la migraci\u00f3n, archivo y destrucci\u00f3n de datos y registros, as\u00ed como la verificaci\u00f3n y mantenimiento de sistemas. Se enfatiza la importancia de documentar decisiones, establecer controles de seguridad y asegurar la integridad de los datos durante el proceso de migraci\u00f3n y archivo.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfCu\u00e1les son los pasos clave que deben seguirse al planificar la jubilaci\u00f3n de un sistema inform\u00e1tico seg\u00fan el documento de ANVISA?**\n   - La planificaci\u00f3n de la jubilaci\u00f3n debe incluir la documentaci\u00f3n de la decisi\u00f3n de reemplazo, la sincronizaci\u00f3n con el sistema sustituto, el desacoplamiento de interfaces, la desconexi\u00f3n de la infraestructura y la finalizaci\u00f3n del soporte t\u00e9cnico, as\u00ed como la identificaci\u00f3n de cualquier suposici\u00f3n o limitaci\u00f3n.\n\n2. **\u00bfQu\u00e9 consideraciones deben tenerse en cuenta al migrar datos a un nuevo sistema seg\u00fan las directrices de ANVISA?**\n   - La migraci\u00f3n de datos debe planificarse y verificarse para asegurar la integridad de los datos. Esto incluye realizar pruebas de los procedimientos de migraci\u00f3n, definir m\u00e9todos de conversi\u00f3n y verificaci\u00f3n, y establecer una estrategia de prueba para validar la migraci\u00f3n, especialmente si se utiliza un proceso automatizado.\n\n3. **\u00bfQu\u00e9 controles se deben establecer para garantizar la seguridad y precisi\u00f3n de los datos durante el proceso de archivo y destrucci\u00f3n?**\n   - Se deben establecer controles para asegurar que los datos y registros se mantengan seguros, completos y precisos. Esto incluye realizar copias de seguridad de los datos, probar la recuperaci\u00f3n de datos antes de moverlos, y almacenar los medios de datos archivados de acuerdo con las recomendaciones del fabricante y las condiciones ambientales necesarias.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos aborda la planificaci\u00f3n de la jubilaci\u00f3n de sistemas, destacando varios aspectos esenciales que deben considerarse para garantizar un proceso efectivo y controlado. A continuaci\u00f3n se presentan los temas clave y las entidades relevantes:\n\n#### Temas Clave\n\n1. **Requisitos de Destrucci\u00f3n y Retenci\u00f3n**: Se deben establecer requisitos claros para la destrucci\u00f3n y retenci\u00f3n de datos o registros hist\u00f3ricos.\n\n2. **Configuraci\u00f3n Actual**: Es fundamental identificar la configuraci\u00f3n actual de hardware y software, as\u00ed como los sistemas, equipos o instrumentos que interfieren con el sistema en cuesti\u00f3n.\n\n3. **Sistemas Externos Dependientes**: Se debe identificar cualquier sistema externo que dependa de los datos o registros del sistema que se va a jubilar.\n\n4. **Plan de Jubilaci\u00f3n del Sistema**: Este plan debe ser aprobado por el propietario del proceso y la unidad de calidad, y debe incluir:\n   - Introducci\u00f3n que detalle la producci\u00f3n del documento y su prop\u00f3sito.\n   - Roles y responsabilidades de los actores involucrados en el proceso de jubilaci\u00f3n.\n   - Consideraciones sobre el impacto estrat\u00e9gico, de proceso, tecnol\u00f3gico y en el personal tras la jubilaci\u00f3n del sistema.\n\n5. **Descripci\u00f3n del Proceso de Negocio**: Es crucial documentar y entender el proceso de negocio previo a la jubilaci\u00f3n para identificar todos los impactos y asegurar una transici\u00f3n adecuada.\n\n#### Entidades Relevantes\n\n- **Propietario del Proceso**: Persona o entidad responsable de la gesti\u00f3n del proceso relacionado con el sistema.\n- **Unidad de Calidad**: Entidad encargada de asegurar que el proceso de jubilaci\u00f3n cumpla con los est\u00e1ndares de calidad.\n- **Equipo de Jubilaci\u00f3n**: Grupo de personas que participan en la planificaci\u00f3n y ejecuci\u00f3n del proceso de jubilaci\u00f3n.\n- **Usuarios del Sistema**: Personas que utilizan el sistema y que se ver\u00e1n afectadas por su jubilaci\u00f3n.\n\nEste resumen proporciona una visi\u00f3n general de los elementos cr\u00edticos que deben considerarse al planificar la jubilaci\u00f3n de un sistema inform\u00e1tico, asegurando que se aborden adecuadamente los riesgos y se mantenga la integridad de los datos.", "excerpt_keywords": "Keywords: retirement planning, data migration, system validation, archiving, data integrity"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "de5593e2-4ffc-4114-ba8c-cbc70b3c89be", "node_type": "4", "metadata": {"page_label": "99", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "This future scenario must be documented and understood, especially with regard to changes in the process and/or user and the location or effect on the data/records.\n\n## 13.2.5 Approach to Retirement\n\nThe decision on whether to replace the system should be documented. If the system is replaced, the retirement planning should be referenced and synchronized with the substitute system. The approach for decoupling the *interface*, disconnecting the infrastructure, finalizing or transition from technical support and any assumptions, exclusions, limitations or dependencies must be documented.\n\n## 13.2.6 Migration, Archiving and Destruction of Data and Records\n\nThe plan must identify what data should be migrated, archived or destroyed and the approval process associated.\n\nThe approach to data migration and archiving should be determined based on the history of access to data, the need for reprocessing, the risk level of registration and the robustness of the media used. Controls should be established to ensure that data and records remain secure, complete, accurate and that the signature/registration relationship is preserved, when applicable.\n\nThe approach must take into account the following aspects:\n\n- If data are to be maintained, they must be **backed up** and stored, in accordance with company data retention schedules and procedures;\n- Before data is moved or archived from the system, the appropriate data recovery must be available and tested;\n- The archived data media must be stored and maintained in accordance with the recommendations of the manufacturer and under the necessary environmental conditions;\n- If data and records are migrated to a replacement system, the migration must be planned, conducted and verified to ensure data integrity. Migration procedures should be tested or confirmed before data is completely transferred out of the system;\n- The methods to be used for migration/conversion and verification of data records must be defined. This may include performing pilot work before actual data migration occurs, or temporary parallel operation of both systems (new system and the system to be retired);\n- If the data is going to be migrated to the replacement system, the testing strategy for verifying the migration must be defined. If an automated migration or conversion is used, the approach to ensuring their suitability for the intended use must be documented.\n\n## 13.2.7 Approach to Verification\n\nVerification documentation, necessary as part of the employee's retirement process, must be identified.\n\n## 13.2.8 System Maintenance and Discontinuation of Support\n\nThe necessary actions associated with (s) must be planned:", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "1cc8231f5f65aff6d86dcb6de60d9ad9b43ee4a5798b8219bdff9aa94dac7d79", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "This future scenario must be documented and understood, especially with regard to changes in the process and/or user and the location or effect on the data/records.\n\n## 13.2.5 Approach to Retirement\n\nThe decision on whether to replace the system should be documented. If the system is replaced, the retirement planning should be referenced and synchronized with the substitute system. The approach for decoupling the *interface*, disconnecting the infrastructure, finalizing or transition from technical support and any assumptions, exclusions, limitations or dependencies must be documented.\n\n## 13.2.6 Migration, Archiving and Destruction of Data and Records\n\nThe plan must identify what data should be migrated, archived or destroyed and the approval process associated.\n\nThe approach to data migration and archiving should be determined based on the history of access to data, the need for reprocessing, the risk level of registration and the robustness of the media used. Controls should be established to ensure that data and records remain secure, complete, accurate and that the signature/registration relationship is preserved, when applicable.\n\nThe approach must take into account the following aspects:\n\n- If data are to be maintained, they must be **backed up** and stored, in accordance with company data retention schedules and procedures;\n- Before data is moved or archived from the system, the appropriate data recovery must be available and tested;\n- The archived data media must be stored and maintained in accordance with the recommendations of the manufacturer and under the necessary environmental conditions;\n- If data and records are migrated to a replacement system, the migration must be planned, conducted and verified to ensure data integrity. Migration procedures should be tested or confirmed before data is completely transferred out of the system;\n- The methods to be used for migration/conversion and verification of data records must be defined. This may include performing pilot work before actual data migration occurs, or temporary parallel operation of both systems (new system and the system to be retired);\n- If the data is going to be migrated to the replacement system, the testing strategy for verifying the migration must be defined. If an automated migration or conversion is used, the approach to ensuring their suitability for the intended use must be documented.\n\n## 13.2.7 Approach to Verification\n\nVerification documentation, necessary as part of the employee's retirement process, must be identified.\n\n## 13.2.8 System Maintenance and Discontinuation of Support\n\nThe necessary actions associated with (s) must be planned:", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 2671, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "0762d9d8-1db4-4896-9590-c9f733cf55e1": {"__data__": {"id_": "0762d9d8-1db4-4896-9590-c9f733cf55e1", "embedding": null, "metadata": {"page_label": "100", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "- Modification or termination of internal or external support agreements;\n- Operations, *backup* and restoration, disaster recovery and business continuity plans;\n- Security, technical support and user administration and configuration management programs.\n\n## 13.2.9 Change Management\n\nFormal change management procedures must be followed for retirement from a system computerized to ensure that the retirement process is controlled and managed.\n\nChanges resulting from the retirement of the system must be addressed, such as changes in roles support (technical support, super-users, etc.) and associated training.\n\nThe approach for communicating the impact of the system's retirement to the people involved should be documented.\n\n## 13.2.10 Timetable\n\nThe schedule should be documented and include individual retirement activities and responsibilities, associated due dates and any other tasks, critical milestones and verification.\n\n## 13.2.11 Execution of Retirement\n\nThe timing of retirement execution must be carefully considered.\n\nThere should be plans for business continuity in case any problems occur during the retirement or migration work. In addition, a backup plan is recommended and should include steps detailed instructions or references to procedures for configuration and reinstallation to make the system retired operational again if necessary.\n\n## 13.2.12 System Documentation and *Software*\n\nSystem and *software documentation*, including source code (Category 5), such as life cycle, validation documentation, change history, standard operating procedures related to the system and other system documents, must be defined. The documentation to be retained must have a responsible owner and a designated safe location. Affected inventories, procedures and others documents must be updated.\n\nDecisions regarding the retention of specific *software* and documents should be based on their potential for future use and in an assessment of the risk associated with its destruction.\n\n## 13.3 SYSTEM RETIREMENT REPORT\n\nAfter executing the system's retirement plan, a summary report should be generated to describe execution and results obtained. If testing or verification activities are performed, the results of these tests should be summarized and any deviations that have occurred should be discussed together with your", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos establece procedimientos y consideraciones para la gesti\u00f3n del retiro de sistemas. Se enfatiza la importancia de seguir procedimientos formales de gesti\u00f3n de cambios, documentar el impacto del retiro, planificar la continuidad del negocio y mantener la documentaci\u00f3n del sistema y del software. Adem\u00e1s, se requiere la generaci\u00f3n de un informe de resumen tras la ejecuci\u00f3n del plan de retiro.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfQu\u00e9 procedimientos deben seguirse para garantizar que el proceso de retiro de un sistema inform\u00e1tico est\u00e9 controlado y gestionado?**\n   - El documento establece que deben seguirse procedimientos formales de gesti\u00f3n de cambios para el retiro del sistema, lo que incluye abordar cambios en roles de soporte y la capacitaci\u00f3n asociada.\n\n2. **\u00bfQu\u00e9 elementos deben incluirse en el cronograma del retiro de un sistema?**\n   - El cronograma debe documentar las actividades individuales de retiro, responsabilidades, fechas de vencimiento, tareas cr\u00edticas y hitos de verificaci\u00f3n.\n\n3. **\u00bfQu\u00e9 tipo de documentaci\u00f3n se debe conservar tras el retiro de un sistema y c\u00f3mo se debe gestionar?**\n   - Se debe conservar la documentaci\u00f3n del sistema y del software, incluyendo el c\u00f3digo fuente, documentaci\u00f3n de validaci\u00f3n, historia de cambios y procedimientos operativos est\u00e1ndar. Esta documentaci\u00f3n debe tener un propietario responsable y un lugar seguro designado, y las decisiones sobre su retenci\u00f3n deben basarse en su potencial para uso futuro y en una evaluaci\u00f3n del riesgo asociado con su destrucci\u00f3n.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Documentaci\u00f3n y Comprensi\u00f3n del Escenario Futuro**: Es fundamental documentar y entender los cambios en los procesos, usuarios y el impacto en los datos y registros.\n\n2. **Enfoque para la Jubilaci\u00f3n del Sistema**:\n   - Documentar la decisi\u00f3n de reemplazo del sistema.\n   - Sincronizar la planificaci\u00f3n de la jubilaci\u00f3n con el sistema sustituto.\n   - Desacoplar interfaces y desconectar la infraestructura.\n   - Finalizar el soporte t\u00e9cnico y documentar suposiciones, exclusiones y limitaciones.\n\n3. **Migraci\u00f3n, Archivo y Destrucci\u00f3n de Datos y Registros**:\n   - Identificar qu\u00e9 datos se migrar\u00e1n, archivar\u00e1n o destruir\u00e1n.\n   - Establecer controles para asegurar la seguridad, integridad y precisi\u00f3n de los datos.\n   - Realizar copias de seguridad y pruebas de recuperaci\u00f3n de datos.\n   - Almacenar medios de datos archivados seg\u00fan recomendaciones del fabricante.\n   - Planificar y verificar la migraci\u00f3n de datos a un sistema de reemplazo, incluyendo pruebas y validaci\u00f3n de procedimientos.\n\n4. **Enfoque para la Verificaci\u00f3n**:\n   - Identificar la documentaci\u00f3n de verificaci\u00f3n necesaria como parte del proceso de jubilaci\u00f3n de empleados.\n\n5. **Mantenimiento del Sistema y Descontinuaci\u00f3n del Soporte**:\n   - Planificar las acciones necesarias relacionadas con el mantenimiento y la discontinuaci\u00f3n del soporte del sistema.\n\n### Entidades Clave\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil, responsable de la regulaci\u00f3n de sistemas inform\u00e1ticos en el \u00e1mbito de la salud.\n- **Sistemas Inform\u00e1ticos**: Herramientas y plataformas que requieren validaci\u00f3n y gesti\u00f3n adecuada durante su ciclo de vida.\n- **Datos y Registros**: Informaci\u00f3n que debe ser gestionada con controles de seguridad y procedimientos de archivo adecuados.\n- **Migraci\u00f3n de Datos**: Proceso de trasladar datos de un sistema a otro, que debe ser cuidadosamente planificado y verificado.\n\nEste resumen destaca la importancia de la planificaci\u00f3n, documentaci\u00f3n y control en la gesti\u00f3n de sistemas inform\u00e1ticos, especialmente en lo que respecta a su jubilaci\u00f3n y manejo de datos.", "excerpt_keywords": "Keywords: system retirement, change management, documentation, business continuity, data migration"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "2b4a3677-8d19-4249-9741-d342ff5a6f13", "node_type": "4", "metadata": {"page_label": "100", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "- Modification or termination of internal or external support agreements;\n- Operations, *backup* and restoration, disaster recovery and business continuity plans;\n- Security, technical support and user administration and configuration management programs.\n\n## 13.2.9 Change Management\n\nFormal change management procedures must be followed for retirement from a system computerized to ensure that the retirement process is controlled and managed.\n\nChanges resulting from the retirement of the system must be addressed, such as changes in roles support (technical support, super-users, etc.) and associated training.\n\nThe approach for communicating the impact of the system's retirement to the people involved should be documented.\n\n## 13.2.10 Timetable\n\nThe schedule should be documented and include individual retirement activities and responsibilities, associated due dates and any other tasks, critical milestones and verification.\n\n## 13.2.11 Execution of Retirement\n\nThe timing of retirement execution must be carefully considered.\n\nThere should be plans for business continuity in case any problems occur during the retirement or migration work. In addition, a backup plan is recommended and should include steps detailed instructions or references to procedures for configuration and reinstallation to make the system retired operational again if necessary.\n\n## 13.2.12 System Documentation and *Software*\n\nSystem and *software documentation*, including source code (Category 5), such as life cycle, validation documentation, change history, standard operating procedures related to the system and other system documents, must be defined. The documentation to be retained must have a responsible owner and a designated safe location. Affected inventories, procedures and others documents must be updated.\n\nDecisions regarding the retention of specific *software* and documents should be based on their potential for future use and in an assessment of the risk associated with its destruction.\n\n## 13.3 SYSTEM RETIREMENT REPORT\n\nAfter executing the system's retirement plan, a summary report should be generated to describe execution and results obtained. If testing or verification activities are performed, the results of these tests should be summarized and any deviations that have occurred should be discussed together with your", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "4a36596818ec94767cd611d54a575f2df804e563a47fd3861ce73c0c6e10876b", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "- Modification or termination of internal or external support agreements;\n- Operations, *backup* and restoration, disaster recovery and business continuity plans;\n- Security, technical support and user administration and configuration management programs.\n\n## 13.2.9 Change Management\n\nFormal change management procedures must be followed for retirement from a system computerized to ensure that the retirement process is controlled and managed.\n\nChanges resulting from the retirement of the system must be addressed, such as changes in roles support (technical support, super-users, etc.) and associated training.\n\nThe approach for communicating the impact of the system's retirement to the people involved should be documented.\n\n## 13.2.10 Timetable\n\nThe schedule should be documented and include individual retirement activities and responsibilities, associated due dates and any other tasks, critical milestones and verification.\n\n## 13.2.11 Execution of Retirement\n\nThe timing of retirement execution must be carefully considered.\n\nThere should be plans for business continuity in case any problems occur during the retirement or migration work. In addition, a backup plan is recommended and should include steps detailed instructions or references to procedures for configuration and reinstallation to make the system retired operational again if necessary.\n\n## 13.2.12 System Documentation and *Software*\n\nSystem and *software documentation*, including source code (Category 5), such as life cycle, validation documentation, change history, standard operating procedures related to the system and other system documents, must be defined. The documentation to be retained must have a responsible owner and a designated safe location. Affected inventories, procedures and others documents must be updated.\n\nDecisions regarding the retention of specific *software* and documents should be based on their potential for future use and in an assessment of the risk associated with its destruction.\n\n## 13.3 SYSTEM RETIREMENT REPORT\n\nAfter executing the system's retirement plan, a summary report should be generated to describe execution and results obtained. If testing or verification activities are performed, the results of these tests should be summarized and any deviations that have occurred should be discussed together with your", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 2338, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "3b3c33e2-87ce-415c-aef9-0e69e649fd63": {"__data__": {"id_": "3b3c33e2-87ce-415c-aef9-0e69e649fd63", "embedding": null, "metadata": {"page_label": "101", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 14. VALIDATION OF SHEETS\n\n## 14.1 INTRODUCTION\n\nTools are available for creating a wide variety of applications for the end user, including custom statistical analysis, local databases, filtering, data manipulation and analysis multivariate. These applications can be used to carry out regulated activities, however these applications tend to be the most under-documented within a GMP environment.\n\nThis Guide will emphasize spreadsheets as they are most often used in companies for treatment of some data regulated by GMP.\n\nThe level and rigor of the specification and verification (validation) used in these applications will depend on the risk involved, its complexity and degree of innovation. The guidelines described here are directed to spreadsheets, but the same principles can be used for other types of applications for the end user.\n\n## 14.2 TYPES OF APPLICATIONS FOR END-USER\n\n### 14.2.1 Disposable Spreadsheets\n\nThey are spreadsheets used in the same way as a calculator, to perform calculations, and it is not An electronic copy of this operation is maintained.\n\nThis activity must be documented in the same way that the calculator would be used, that is, the values and results would be recorded and signed. Results can be printed, labeled and signed. It should be clear on the record sheet exactly which arithmetic operation was performed. This can be facilitated by printing a copy of the spreadsheet showing the calculation formula used. This copy becomes part of the GMP record.\n\nThe calculations used for processing GMP data must be verified. This does not mean that algorithms used by the spreadsheet's native functions need to be checked for accuracy, but rather demonstrate that the correct formulas are being used. Ex: (a + b) * c is different from a + (b * c), and this it is a possible error to occur.\n\nThe verification of the algorithms can be carried out by printing the formula (cell formulae) or by third party review.\n\n### 14.2.2 Spreadsheets Retained as Documents\n\nThere are spreadsheets that are used as a word processor and not as a traditional application. The main difference is that the spreadsheet can be used both to record BPF data and to manipulate it. Of that Therefore, it is advisable to manage them as documents and not as applications. It is extremely difficult establish that all copies saved later are the same as the originals. Calculations, therefore, they should be checked and explained in detail, when they exist in a text document. This includes", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "### Preguntas y Respuestas\n\n1. **\u00bfCu\u00e1l es la principal diferencia entre las hojas de c\u00e1lculo desechables y las hojas de c\u00e1lculo retenidas como documentos seg\u00fan la gu\u00eda de ANVISA?**\n   - Las hojas de c\u00e1lculo desechables se utilizan como calculadoras para realizar c\u00e1lculos sin mantener una copia electr\u00f3nica de la operaci\u00f3n, y su uso debe ser documentado de manera similar a un c\u00e1lculo manual. En cambio, las hojas de c\u00e1lculo retenidas como documentos se utilizan para registrar y manipular datos, y es recomendable gestionarlas como documentos, lo que implica que es dif\u00edcil asegurar que todas las copias guardadas sean id\u00e9nticas a las originales.\n\n2. **\u00bfQu\u00e9 tipo de verificaci\u00f3n se requiere para las hojas de c\u00e1lculo utilizadas en el procesamiento de datos regulados por BPF?**\n   - La verificaci\u00f3n de las hojas de c\u00e1lculo implica demostrar que se est\u00e1n utilizando las f\u00f3rmulas correctas, en lugar de verificar la precisi\u00f3n de los algoritmos de las funciones nativas de la hoja de c\u00e1lculo. Esto puede hacerse imprimiendo las f\u00f3rmulas utilizadas o mediante una revisi\u00f3n por parte de un tercero.\n\n3. **\u00bfPor qu\u00e9 se considera que las hojas de c\u00e1lculo son las aplicaciones m\u00e1s subdocumentadas en un entorno de BPF?**\n   - Las hojas de c\u00e1lculo son consideradas subdocumentadas porque, a menudo, se utilizan para actividades reguladas sin la debida documentaci\u00f3n y validaci\u00f3n, lo que puede llevar a errores en el procesamiento de datos cr\u00edticos. La gu\u00eda de ANVISA enfatiza la necesidad de un enfoque m\u00e1s riguroso en la especificaci\u00f3n y verificaci\u00f3n de estas herramientas.\n\n### Resumen de Nivel Superior\n\nLa gu\u00eda de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos destaca la importancia de las hojas de c\u00e1lculo en el contexto de las Buenas Pr\u00e1cticas de Fabricaci\u00f3n (BPF). Se identifican dos tipos de hojas de c\u00e1lculo: desechables, que se utilizan para c\u00e1lculos simples sin mantener registros electr\u00f3nicos, y aquellas que se retienen como documentos, que permiten tanto el registro como la manipulaci\u00f3n de datos. La gu\u00eda subraya la necesidad de documentar adecuadamente el uso de estas herramientas y de verificar las f\u00f3rmulas utilizadas para garantizar la integridad de los datos regulados. Esto es crucial en un entorno donde la precisi\u00f3n y la trazabilidad son esenciales para cumplir con las normativas de calidad.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Gesti\u00f3n del Cambio**:\n   - Se deben seguir procedimientos formales para gestionar el retiro de sistemas inform\u00e1ticos, asegurando que el proceso sea controlado y documentado.\n   - Es importante abordar los cambios en roles de soporte y proporcionar capacitaci\u00f3n asociada.\n\n2. **Cronograma de Retiro**:\n   - El cronograma debe incluir actividades individuales de retiro, responsabilidades, fechas de vencimiento, tareas cr\u00edticas y hitos de verificaci\u00f3n.\n\n3. **Ejecuci\u00f3n del Retiro**:\n   - La ejecuci\u00f3n del retiro debe planificarse cuidadosamente, considerando la continuidad del negocio y estableciendo un plan de respaldo.\n   - Se deben incluir instrucciones detalladas para la reconfiguraci\u00f3n y reinstalaci\u00f3n del sistema si es necesario.\n\n4. **Documentaci\u00f3n del Sistema y Software**:\n   - Se debe conservar la documentaci\u00f3n del sistema y del software, incluyendo el c\u00f3digo fuente, documentaci\u00f3n de validaci\u00f3n, historia de cambios y procedimientos operativos est\u00e1ndar.\n   - La documentaci\u00f3n debe tener un propietario responsable y un lugar seguro, y las decisiones sobre su retenci\u00f3n deben basarse en su posible uso futuro y en la evaluaci\u00f3n de riesgos.\n\n5. **Informe de Retiro del Sistema**:\n   - Tras la ejecuci\u00f3n del plan de retiro, se debe generar un informe resumen que describa la ejecuci\u00f3n y los resultados obtenidos, incluyendo cualquier actividad de prueba o verificaci\u00f3n realizada.\n\n### Entidades Clave\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil.\n- **Sistema Inform\u00e1tico**: Cualquier sistema que se est\u00e9 retirando o migrando.\n- **Documentaci\u00f3n**: Incluye manuales, procedimientos, c\u00f3digo fuente y registros de validaci\u00f3n.\n- **Roles de Soporte**: Incluye soporte t\u00e9cnico, superusuarios y otros roles relacionados con el sistema.\n- **Plan de Continuidad del Negocio**: Estrategias para asegurar la operaci\u00f3n continua durante el proceso de retiro. \n\nEste resumen destaca la importancia de la planificaci\u00f3n, documentaci\u00f3n y gesti\u00f3n adecuada en el proceso de retiro de sistemas inform\u00e1ticos, conforme a las directrices de ANVISA.", "excerpt_keywords": "Keywords: validation, spreadsheets, GMP, documentation, data integrity"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "d97c5be0-06bc-490e-9cc9-ca19a09b799d", "node_type": "4", "metadata": {"page_label": "101", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 14. VALIDATION OF SHEETS\n\n## 14.1 INTRODUCTION\n\nTools are available for creating a wide variety of applications for the end user, including custom statistical analysis, local databases, filtering, data manipulation and analysis multivariate. These applications can be used to carry out regulated activities, however these applications tend to be the most under-documented within a GMP environment.\n\nThis Guide will emphasize spreadsheets as they are most often used in companies for treatment of some data regulated by GMP.\n\nThe level and rigor of the specification and verification (validation) used in these applications will depend on the risk involved, its complexity and degree of innovation. The guidelines described here are directed to spreadsheets, but the same principles can be used for other types of applications for the end user.\n\n## 14.2 TYPES OF APPLICATIONS FOR END-USER\n\n### 14.2.1 Disposable Spreadsheets\n\nThey are spreadsheets used in the same way as a calculator, to perform calculations, and it is not An electronic copy of this operation is maintained.\n\nThis activity must be documented in the same way that the calculator would be used, that is, the values and results would be recorded and signed. Results can be printed, labeled and signed. It should be clear on the record sheet exactly which arithmetic operation was performed. This can be facilitated by printing a copy of the spreadsheet showing the calculation formula used. This copy becomes part of the GMP record.\n\nThe calculations used for processing GMP data must be verified. This does not mean that algorithms used by the spreadsheet's native functions need to be checked for accuracy, but rather demonstrate that the correct formulas are being used. Ex: (a + b) * c is different from a + (b * c), and this it is a possible error to occur.\n\nThe verification of the algorithms can be carried out by printing the formula (cell formulae) or by third party review.\n\n### 14.2.2 Spreadsheets Retained as Documents\n\nThere are spreadsheets that are used as a word processor and not as a traditional application. The main difference is that the spreadsheet can be used both to record BPF data and to manipulate it. Of that Therefore, it is advisable to manage them as documents and not as applications. It is extremely difficult establish that all copies saved later are the same as the originals. Calculations, therefore, they should be checked and explained in detail, when they exist in a text document. This includes", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "4492c76542ec5265301e31d7f0687c085a8f0d6596e72c4bb8eec5ca0ee498cc", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "# 14. VALIDATION OF SHEETS\n\n## 14.1 INTRODUCTION\n\nTools are available for creating a wide variety of applications for the end user, including custom statistical analysis, local databases, filtering, data manipulation and analysis multivariate. These applications can be used to carry out regulated activities, however these applications tend to be the most under-documented within a GMP environment.\n\nThis Guide will emphasize spreadsheets as they are most often used in companies for treatment of some data regulated by GMP.\n\nThe level and rigor of the specification and verification (validation) used in these applications will depend on the risk involved, its complexity and degree of innovation. The guidelines described here are directed to spreadsheets, but the same principles can be used for other types of applications for the end user.\n\n## 14.2 TYPES OF APPLICATIONS FOR END-USER\n\n### 14.2.1 Disposable Spreadsheets\n\nThey are spreadsheets used in the same way as a calculator, to perform calculations, and it is not An electronic copy of this operation is maintained.\n\nThis activity must be documented in the same way that the calculator would be used, that is, the values and results would be recorded and signed. Results can be printed, labeled and signed. It should be clear on the record sheet exactly which arithmetic operation was performed. This can be facilitated by printing a copy of the spreadsheet showing the calculation formula used. This copy becomes part of the GMP record.\n\nThe calculations used for processing GMP data must be verified. This does not mean that algorithms used by the spreadsheet's native functions need to be checked for accuracy, but rather demonstrate that the correct formulas are being used. Ex: (a + b) * c is different from a + (b * c), and this it is a possible error to occur.\n\nThe verification of the algorithms can be carried out by printing the formula (cell formulae) or by third party review.\n\n### 14.2.2 Spreadsheets Retained as Documents\n\nThere are spreadsheets that are used as a word processor and not as a traditional application. The main difference is that the spreadsheet can be used both to record BPF data and to manipulate it. Of that Therefore, it is advisable to manage them as documents and not as applications. It is extremely difficult establish that all copies saved later are the same as the originals. Calculations, therefore, they should be checked and explained in detail, when they exist in a text document. This includes", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 2501, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "d7e82b14-c1d4-4801-b968-ef7a0fbd844e": {"__data__": {"id_": "d7e82b14-c1d4-4801-b968-ef7a0fbd844e", "embedding": null, "metadata": {"page_label": "102", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# Guide for Computer Systems Validation\n\n## Page 95\n\n- Use of the spreadsheet's internal security options, such as cells or tabs protected by passwords;\n- Storing the spreadsheet in a secure directory;\n- Spreadsheet management in an electronic document management system.\n\n### 14.2.3 Spreadsheets Used as Database\n\nThese are spreadsheets used to manage or store GMP data electronically. The data can be updated frequently, which can cause difficulties because spreadsheets don't have the controls intrinsic features of relational databases, necessary to ensure data integrity.\n\nSpreadsheets generally have limited or no capability to control data editing or to support audit trails when needed. When creating a spreadsheet, controls must be developed to overcome these deficiencies.\n\nUsers should therefore be fully aware of the limitations and vulnerabilities of spreadsheets when proposed as an alternative to a database application.\n\nDue to the limitations of spreadsheets, relational databases should be used instead of electronic spreadsheets, since these are limited in terms of data storage and management and the file can be corrupt when it reaches certain data values.\n\nAlthough there are commercially available products designed to provide audit trail capabilities for spreadsheets, as a general rule, the use of spreadsheets in which audit trails are needed should not be used.\n\nSpreadsheet software is generally not designed to provide audit trail functionality. Therefore, the use of a database with this intrinsic capacity is preferable.\n\n### 14.2.4 Template-Type Applications\n\nA very common use of spreadsheets is the development of template-type solutions, where data they can be subject to standard manipulation and the result saved as a single document. Applications for performing statistical analysis or filtering and manipulating data may also belong to this sub-category. The templates can be used for example for the tab and a data processing clinical study or, similarly for tabulation and data processing of control test results before the product is released.\n\nWhen developing such templates, users and developers must fully understand and document the necessary handling. This allows for clear confirmation of design intentions against package features.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "### Res\u00famenes de nivel superior del contexto\n\n1. **Limitaciones de las hojas de c\u00e1lculo**: Las hojas de c\u00e1lculo, aunque son herramientas comunes para la gesti\u00f3n de datos, presentan limitaciones significativas en t\u00e9rminos de control de edici\u00f3n, integridad de datos y capacidad de auditor\u00eda. Se recomienda el uso de bases de datos relacionales para la gesti\u00f3n de datos cr\u00edticos, especialmente en entornos de Buenas Pr\u00e1cticas de Manufactura (GMP).\n\n2. **Uso de plantillas en hojas de c\u00e1lculo**: Las hojas de c\u00e1lculo pueden ser utilizadas para desarrollar soluciones tipo plantilla que permiten la manipulaci\u00f3n est\u00e1ndar de datos. Sin embargo, es crucial que los usuarios y desarrolladores comprendan y documenten adecuadamente el manejo de estos datos para asegurar que las intenciones de dise\u00f1o se alineen con las caracter\u00edsticas del software.\n\n3. **Seguridad y gesti\u00f3n de hojas de c\u00e1lculo**: Para mitigar los riesgos asociados con el uso de hojas de c\u00e1lculo, se deben implementar medidas de seguridad, como la protecci\u00f3n de celdas con contrase\u00f1as y el almacenamiento en directorios seguros. Adem\u00e1s, la gesti\u00f3n de hojas de c\u00e1lculo debe realizarse dentro de un sistema de gesti\u00f3n de documentos electr\u00f3nicos.\n\n### Preguntas espec\u00edficas\n\n1. **\u00bfCu\u00e1les son las principales deficiencias de las hojas de c\u00e1lculo en comparaci\u00f3n con las bases de datos relacionales en el contexto de la gesti\u00f3n de datos GMP?**\n   - Respuesta: Las hojas de c\u00e1lculo tienen limitaciones en el control de edici\u00f3n, carecen de capacidades intr\u00ednsecas para mantener la integridad de los datos y no soportan auditor\u00edas adecuadas, lo que las hace menos adecuadas para la gesti\u00f3n de datos GMP en comparaci\u00f3n con las bases de datos relacionales.\n\n2. **\u00bfQu\u00e9 medidas de seguridad se recomiendan para el manejo de hojas de c\u00e1lculo utilizadas en la gesti\u00f3n de datos cr\u00edticos?**\n   - Respuesta: Se recomienda utilizar opciones de seguridad internas de las hojas de c\u00e1lculo, como proteger celdas o pesta\u00f1as con contrase\u00f1as, almacenar las hojas en directorios seguros y gestionar las hojas de c\u00e1lculo dentro de un sistema de gesti\u00f3n de documentos electr\u00f3nicos.\n\n3. **\u00bfQu\u00e9 consideraciones deben tener en cuenta los desarrolladores al crear plantillas en hojas de c\u00e1lculo para an\u00e1lisis estad\u00edstico?**\n   - Respuesta: Los desarrolladores deben comprender y documentar el manejo necesario de los datos, asegurando que las intenciones de dise\u00f1o se confirmen con las caracter\u00edsticas del paquete de software utilizado, para evitar errores en el an\u00e1lisis y la manipulaci\u00f3n de datos.", "prev_section_summary": "### Resumen de Temas Clave y Entidades de la Secci\u00f3n\n\n1. **Validaci\u00f3n de Hojas de C\u00e1lculo**: La gu\u00eda de ANVISA se centra en la validaci\u00f3n de hojas de c\u00e1lculo dentro del contexto de las Buenas Pr\u00e1cticas de Fabricaci\u00f3n (BPF), destacando su uso com\u00fan en la manipulaci\u00f3n de datos regulados.\n\n2. **Tipos de Hojas de C\u00e1lculo**:\n   - **Hojas de C\u00e1lculo Desechables**: Utilizadas como calculadoras para realizar c\u00e1lculos sin mantener una copia electr\u00f3nica. Su uso debe ser documentado, registrando valores y resultados, y se recomienda imprimir las f\u00f3rmulas utilizadas como parte del registro GMP.\n   - **Hojas de C\u00e1lculo Retenidas como Documentos**: Utilizadas para registrar y manipular datos. Se deben gestionar como documentos, lo que implica un desaf\u00edo en asegurar que las copias guardadas sean id\u00e9nticas a las originales.\n\n3. **Verificaci\u00f3n de C\u00e1lculos**: La verificaci\u00f3n de las hojas de c\u00e1lculo implica demostrar que se est\u00e1n utilizando las f\u00f3rmulas correctas, en lugar de verificar la precisi\u00f3n de los algoritmos de las funciones nativas. Esto puede hacerse imprimiendo las f\u00f3rmulas o mediante revisi\u00f3n por terceros.\n\n4. **Subdocumentaci\u00f3n en Entornos GMP**: Las hojas de c\u00e1lculo son consideradas subdocumentadas en entornos GMP, lo que puede llevar a errores en el procesamiento de datos cr\u00edticos. La gu\u00eda enfatiza la necesidad de un enfoque m\u00e1s riguroso en la documentaci\u00f3n y validaci\u00f3n de estas herramientas.\n\n5. **Importancia de la Documentaci\u00f3n**: La correcta documentaci\u00f3n y verificaci\u00f3n de las hojas de c\u00e1lculo son esenciales para garantizar la integridad y trazabilidad de los datos regulados, cumpliendo as\u00ed con las normativas de calidad.\n\n### Entidades Clave\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil.\n- **BPF (Buenas Pr\u00e1cticas de Fabricaci\u00f3n)**: Normativas que aseguran la calidad en la producci\u00f3n de productos regulados.\n- **Hojas de C\u00e1lculo**: Herramientas utilizadas para c\u00e1lculos y manipulaci\u00f3n de datos en un entorno regulado.", "excerpt_keywords": "Keywords: validation, spreadsheets, data integrity, GMP, audit trails"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "d9d483d0-e975-4695-987b-e37c12345373", "node_type": "4", "metadata": {"page_label": "102", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# Guide for Computer Systems Validation\n\n## Page 95\n\n- Use of the spreadsheet's internal security options, such as cells or tabs protected by passwords;\n- Storing the spreadsheet in a secure directory;\n- Spreadsheet management in an electronic document management system.\n\n### 14.2.3 Spreadsheets Used as Database\n\nThese are spreadsheets used to manage or store GMP data electronically. The data can be updated frequently, which can cause difficulties because spreadsheets don't have the controls intrinsic features of relational databases, necessary to ensure data integrity.\n\nSpreadsheets generally have limited or no capability to control data editing or to support audit trails when needed. When creating a spreadsheet, controls must be developed to overcome these deficiencies.\n\nUsers should therefore be fully aware of the limitations and vulnerabilities of spreadsheets when proposed as an alternative to a database application.\n\nDue to the limitations of spreadsheets, relational databases should be used instead of electronic spreadsheets, since these are limited in terms of data storage and management and the file can be corrupt when it reaches certain data values.\n\nAlthough there are commercially available products designed to provide audit trail capabilities for spreadsheets, as a general rule, the use of spreadsheets in which audit trails are needed should not be used.\n\nSpreadsheet software is generally not designed to provide audit trail functionality. Therefore, the use of a database with this intrinsic capacity is preferable.\n\n### 14.2.4 Template-Type Applications\n\nA very common use of spreadsheets is the development of template-type solutions, where data they can be subject to standard manipulation and the result saved as a single document. Applications for performing statistical analysis or filtering and manipulating data may also belong to this sub-category. The templates can be used for example for the tab and a data processing clinical study or, similarly for tabulation and data processing of control test results before the product is released.\n\nWhen developing such templates, users and developers must fully understand and document the necessary handling. This allows for clear confirmation of design intentions against package features.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "468153441ab2a589892d1a2eeb7f13aa7433312379baca7de886bd961201b3f1", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "# Guide for Computer Systems Validation\n\n## Page 95\n\n- Use of the spreadsheet's internal security options, such as cells or tabs protected by passwords;\n- Storing the spreadsheet in a secure directory;\n- Spreadsheet management in an electronic document management system.\n\n### 14.2.3 Spreadsheets Used as Database\n\nThese are spreadsheets used to manage or store GMP data electronically. The data can be updated frequently, which can cause difficulties because spreadsheets don't have the controls intrinsic features of relational databases, necessary to ensure data integrity.\n\nSpreadsheets generally have limited or no capability to control data editing or to support audit trails when needed. When creating a spreadsheet, controls must be developed to overcome these deficiencies.\n\nUsers should therefore be fully aware of the limitations and vulnerabilities of spreadsheets when proposed as an alternative to a database application.\n\nDue to the limitations of spreadsheets, relational databases should be used instead of electronic spreadsheets, since these are limited in terms of data storage and management and the file can be corrupt when it reaches certain data values.\n\nAlthough there are commercially available products designed to provide audit trail capabilities for spreadsheets, as a general rule, the use of spreadsheets in which audit trails are needed should not be used.\n\nSpreadsheet software is generally not designed to provide audit trail functionality. Therefore, the use of a database with this intrinsic capacity is preferable.\n\n### 14.2.4 Template-Type Applications\n\nA very common use of spreadsheets is the development of template-type solutions, where data they can be subject to standard manipulation and the result saved as a single document. Applications for performing statistical analysis or filtering and manipulating data may also belong to this sub-category. The templates can be used for example for the tab and a data processing clinical study or, similarly for tabulation and data processing of control test results before the product is released.\n\nWhen developing such templates, users and developers must fully understand and document the necessary handling. This allows for clear confirmation of design intentions against package features.", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 2280, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "180e9299-9c95-4cc3-ae3b-de9580b4b96b": {"__data__": {"id_": "180e9299-9c95-4cc3-ae3b-de9580b4b96b", "embedding": null, "metadata": {"page_label": "103", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "- standards to be established and confirmed.\n\nThe following items should be considered:\n\n- Calculations should be checked for accuracy;\n- The template will run on a single workstation or available for download from a single lease? If not, how can you be sure that all users will use the correct version? The control version must be established, supported by an effective change management process;\n\n----\n\n- How access to the application and data fields by users and the developer will be controlled? Preferably all cells, except those used for data entry, they must be blocked and inaccessible to the user;\n- How will the features be configured? There is a requirement for a custom script when application wizards are used? A \u201cmacro\u201d is customized software. Even when created by key capture, there is a program written in a language such as Visual Basic for Applications\u00ae (VBA) behind each macro;\n- Will there be more than one module? Integration tests are appropriate in these cases. For spreadsheets this may involve direct cell links to other spreadsheets. These links can be affected by changes and should be addressed as part of change control.\n- Will data entry be via keyboard only? External data feeds require configuration and a spreadsheet may not be sophisticated enough to handle unusual entries (eg, a string that is too long can be truncated and only part of that string is imported);\n- Will the output be saved to a file or just printed? Electronic record controls can be necessary if the document is held electronically.\n\n## 14.2.5 Desktop Database\n\nDesktop Databases are those designed and installed on a workstation or computer for routine use. These simple solutions are designed for the storage of small amounts of data (eg MS Access).\n\nThe proprietary and open source desktop database offers solutions for managing large volumes of data when compared to spreadsheets, but they still are generally significantly less secure than more database management systems sophisticated systems designed to run in environments based on dedicated servers and managed by IT sector through DBA (eg Oracle\u00ae, MS SQL Server, etc.).\n\nThe use of these less secure banks can present significant risks to GMP-relevant records. External controls are required to protect these records.\n\n## 14.3 RISK-BASED APPROACH", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "### Resumen del Contexto\n\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos destaca la importancia de establecer est\u00e1ndares y controles en el uso de plantillas y bases de datos de escritorio. Se enfatiza la necesidad de verificar la precisi\u00f3n de los c\u00e1lculos, gestionar el control de versiones, y asegurar que el acceso a las aplicaciones y campos de datos est\u00e9 restringido adecuadamente. Adem\u00e1s, se menciona la importancia de realizar pruebas de integraci\u00f3n cuando hay m\u00faltiples m\u00f3dulos y se discuten los riesgos asociados con el uso de bases de datos menos seguras en comparaci\u00f3n con sistemas de gesti\u00f3n de bases de datos m\u00e1s sofisticados.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfQu\u00e9 medidas espec\u00edficas se pueden implementar para garantizar que todos los usuarios utilicen la versi\u00f3n correcta de una plantilla cuando se distribuye en m\u00faltiples estaciones de trabajo?**\n   - Esta pregunta busca respuestas sobre los procedimientos de control de versiones y gesti\u00f3n de cambios que no se detallan expl\u00edcitamente en el texto.\n\n2. **\u00bfCu\u00e1les son los riesgos espec\u00edficos asociados con el uso de bases de datos de escritorio en comparaci\u00f3n con sistemas de gesti\u00f3n de bases de datos m\u00e1s robustos, y qu\u00e9 controles externos se pueden aplicar para mitigar estos riesgos?**\n   - Esta pregunta se centra en los riesgos mencionados y busca ejemplos concretos de controles externos que podr\u00edan implementarse.\n\n3. **\u00bfQu\u00e9 tipo de pruebas de integraci\u00f3n son recomendadas para hojas de c\u00e1lculo que contienen enlaces directos a otras hojas, y c\u00f3mo se deben documentar estos procesos?**\n   - Esta pregunta busca informaci\u00f3n sobre las mejores pr\u00e1cticas para realizar pruebas de integraci\u00f3n y la documentaci\u00f3n necesaria, que no se aborda en el contexto proporcionado. \n\nEstas preguntas est\u00e1n dise\u00f1adas para extraer informaci\u00f3n m\u00e1s detallada y espec\u00edfica que podr\u00eda no estar disponible en otras fuentes, bas\u00e1ndose en el contenido del documento.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Limitaciones de las Hojas de C\u00e1lculo**:\n   - Las hojas de c\u00e1lculo presentan deficiencias significativas en comparaci\u00f3n con las bases de datos relacionales, especialmente en el contexto de la gesti\u00f3n de datos de Buenas Pr\u00e1cticas de Manufactura (GMP). Estas limitaciones incluyen:\n     - Falta de controles intr\u00ednsecos para mantener la integridad de los datos.\n     - Limitaciones en el control de edici\u00f3n.\n     - Ausencia de capacidades adecuadas para auditor\u00edas.\n\n2. **Uso de Bases de Datos Relacionales**:\n   - Se recomienda el uso de bases de datos relacionales en lugar de hojas de c\u00e1lculo para la gesti\u00f3n de datos cr\u00edticos, ya que ofrecen mejor almacenamiento, gesti\u00f3n y protecci\u00f3n contra la corrupci\u00f3n de archivos.\n\n3. **Medidas de Seguridad para Hojas de C\u00e1lculo**:\n   - Para mitigar riesgos, se sugieren varias medidas de seguridad:\n     - Uso de opciones de seguridad internas, como la protecci\u00f3n de celdas o pesta\u00f1as con contrase\u00f1as.\n     - Almacenamiento de hojas de c\u00e1lculo en directorios seguros.\n     - Gesti\u00f3n de hojas de c\u00e1lculo dentro de un sistema de gesti\u00f3n de documentos electr\u00f3nicos.\n\n4. **Aplicaciones Tipo Plantilla**:\n   - Las hojas de c\u00e1lculo son com\u00fanmente utilizadas para desarrollar soluciones tipo plantilla que permiten la manipulaci\u00f3n est\u00e1ndar de datos. Ejemplos incluyen:\n     - An\u00e1lisis estad\u00edstico.\n     - Procesamiento de datos en estudios cl\u00ednicos.\n     - Tabulaci\u00f3n de resultados de pruebas de control antes de la liberaci\u00f3n de productos.\n   - Es crucial que los desarrolladores comprendan y documenten adecuadamente el manejo de datos en estas plantillas para asegurar la alineaci\u00f3n entre las intenciones de dise\u00f1o y las caracter\u00edsticas del software.\n\n### Entidades Clave\n- **Hojas de C\u00e1lculo**: Herramientas utilizadas para la gesti\u00f3n de datos, pero con limitaciones significativas.\n- **Bases de Datos Relacionales**: Alternativa recomendada para la gesti\u00f3n de datos cr\u00edticos.\n- **Buenas Pr\u00e1cticas de Manufactura (GMP)**: Normativas que regulan la gesti\u00f3n de datos en entornos de producci\u00f3n.\n- **Seguridad de Datos**: Medidas implementadas para proteger la integridad y confidencialidad de los datos en hojas de c\u00e1lculo.\n- **Plantillas**: Soluciones desarrolladas en hojas de c\u00e1lculo para la manipulaci\u00f3n y an\u00e1lisis de datos.", "excerpt_keywords": "Keywords: validation, computer systems, data integrity, risk management, GMP"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "87633561-307a-470c-bc73-9b597f68d364", "node_type": "4", "metadata": {"page_label": "103", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "- standards to be established and confirmed.\n\nThe following items should be considered:\n\n- Calculations should be checked for accuracy;\n- The template will run on a single workstation or available for download from a single lease? If not, how can you be sure that all users will use the correct version? The control version must be established, supported by an effective change management process;\n\n----\n\n- How access to the application and data fields by users and the developer will be controlled? Preferably all cells, except those used for data entry, they must be blocked and inaccessible to the user;\n- How will the features be configured? There is a requirement for a custom script when application wizards are used? A \u201cmacro\u201d is customized software. Even when created by key capture, there is a program written in a language such as Visual Basic for Applications\u00ae (VBA) behind each macro;\n- Will there be more than one module? Integration tests are appropriate in these cases. For spreadsheets this may involve direct cell links to other spreadsheets. These links can be affected by changes and should be addressed as part of change control.\n- Will data entry be via keyboard only? External data feeds require configuration and a spreadsheet may not be sophisticated enough to handle unusual entries (eg, a string that is too long can be truncated and only part of that string is imported);\n- Will the output be saved to a file or just printed? Electronic record controls can be necessary if the document is held electronically.\n\n## 14.2.5 Desktop Database\n\nDesktop Databases are those designed and installed on a workstation or computer for routine use. These simple solutions are designed for the storage of small amounts of data (eg MS Access).\n\nThe proprietary and open source desktop database offers solutions for managing large volumes of data when compared to spreadsheets, but they still are generally significantly less secure than more database management systems sophisticated systems designed to run in environments based on dedicated servers and managed by IT sector through DBA (eg Oracle\u00ae, MS SQL Server, etc.).\n\nThe use of these less secure banks can present significant risks to GMP-relevant records. External controls are required to protect these records.\n\n## 14.3 RISK-BASED APPROACH", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "eb7f351755084e3adf2b63e999476eb2b4e588a5a00bad687ef0ab6bbf5ce909", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "- standards to be established and confirmed.\n\nThe following items should be considered:\n\n- Calculations should be checked for accuracy;\n- The template will run on a single workstation or available for download from a single lease? If not, how can you be sure that all users will use the correct version? The control version must be established, supported by an effective change management process;\n\n----\n\n- How access to the application and data fields by users and the developer will be controlled? Preferably all cells, except those used for data entry, they must be blocked and inaccessible to the user;\n- How will the features be configured? There is a requirement for a custom script when application wizards are used? A \u201cmacro\u201d is customized software. Even when created by key capture, there is a program written in a language such as Visual Basic for Applications\u00ae (VBA) behind each macro;\n- Will there be more than one module? Integration tests are appropriate in these cases. For spreadsheets this may involve direct cell links to other spreadsheets. These links can be affected by changes and should be addressed as part of change control.\n- Will data entry be via keyboard only? External data feeds require configuration and a spreadsheet may not be sophisticated enough to handle unusual entries (eg, a string that is too long can be truncated and only part of that string is imported);\n- Will the output be saved to a file or just printed? Electronic record controls can be necessary if the document is held electronically.\n\n## 14.2.5 Desktop Database\n\nDesktop Databases are those designed and installed on a workstation or computer for routine use. These simple solutions are designed for the storage of small amounts of data (eg MS Access).\n\nThe proprietary and open source desktop database offers solutions for managing large volumes of data when compared to spreadsheets, but they still are generally significantly less secure than more database management systems sophisticated systems designed to run in environments based on dedicated servers and managed by IT sector through DBA (eg Oracle\u00ae, MS SQL Server, etc.).\n\nThe use of these less secure banks can present significant risks to GMP-relevant records. External controls are required to protect these records.\n\n## 14.3 RISK-BASED APPROACH", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 2311, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "6365050a-ad92-49d1-bd0d-2f3c15be2d74": {"__data__": {"id_": "6365050a-ad92-49d1-bd0d-2f3c15be2d74", "embedding": null, "metadata": {"page_label": "104", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "Spreadsheets can vary significantly in risk and complexity. The following points should be considered for this type of end user application:\n\n- Risk assessment and appropriate risk control measures to manage the identified risks;\n- The adoption of the most appropriate strategy to establish the stages of Specification and Verification of spreadsheet, so that it is shown to work as intended. This strategy should be based on:\n- \u2713 System impact on patient safety, product quality and data integrity (risk assessment);\n- \u2713 System complexity and innovation (architecture and categorization of the components of the system).\n\n----\n\n- Proper security to mitigate the risk of unauthorized changes to data and data spreadsheet;\n- Change management application management.\n\nThe regulated company's policies and procedures should define its specific approach to obtaining and maintenance of attendance and adaptation to the intended use of the spreadsheet.\n\n## 14.4 USE OF GAMP CATEGORIES\n\nThe product on which the application (Spreadsheets, templates, etc.) is built must belong to Category 1. The categories for spreadsheets and other end user applications range from Category 3 to 5.\n\nThe definition of the worksheet category depends on its complexity and innovation. It should be noted that a spreadsheet that merely uses its tabular editing power and does not perform calculations should be considered a document.\n\nA spreadsheet that simply uses its original functions (averages, standard deviations) to perform calculations, with no configuration, just acting as a calculator, it belongs to Category 3.\n\nWhen the arithmetic functions of the spreadsheet are used, the calculations must be fully explained. This includes verifying that the formula used has been used properly and that the results obtained are correct. Such verification can be documented through the review and approval of the spreadsheet by a second person. No additional verification is necessary, as there is no need to challenge the accuracy of calculations.\n\nA template-type spreadsheet in which the user inserts data that is automatically sent to another cell where specific calculations are performed, belongs to Category 4, since the template is configured by before use.\n\nA spreadsheet that uses custom macros or other more sophisticated operations (e.g., editing code source) belongs to Category 5.\n\nFor situations other than those mentioned above, consult the bibliographic references in this guide.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos destaca la importancia de evaluar los riesgos y establecer medidas de control adecuadas al utilizar aplicaciones de usuario final como hojas de c\u00e1lculo. Se enfatiza la necesidad de una estrategia de especificaci\u00f3n y verificaci\u00f3n que considere el impacto del sistema en la seguridad del paciente, la calidad del producto y la integridad de los datos. Adem\u00e1s, se presentan las categor\u00edas GAMP para clasificar las hojas de c\u00e1lculo seg\u00fan su complejidad e innovaci\u00f3n, desde documentos simples hasta aplicaciones que utilizan macros personalizadas.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfQu\u00e9 criterios se deben considerar para clasificar una hoja de c\u00e1lculo en una categor\u00eda GAMP espec\u00edfica?**\n   - La clasificaci\u00f3n de una hoja de c\u00e1lculo en una categor\u00eda GAMP depende de su complejidad e innovaci\u00f3n. Por ejemplo, una hoja de c\u00e1lculo que solo utiliza funciones b\u00e1sicas sin configuraci\u00f3n se considera un documento, mientras que una que usa funciones aritm\u00e9ticas simples pertenece a la Categor\u00eda 3. Las hojas de c\u00e1lculo que requieren plantillas configuradas se clasifican en la Categor\u00eda 4, y aquellas que utilizan macros personalizadas o operaciones sofisticadas pertenecen a la Categor\u00eda 5.\n\n2. **\u00bfQu\u00e9 medidas de seguridad se deben implementar para mitigar el riesgo de cambios no autorizados en las hojas de c\u00e1lculo?**\n   - Se deben establecer medidas de seguridad adecuadas para proteger las hojas de c\u00e1lculo contra cambios no autorizados en los datos. Esto incluye la implementaci\u00f3n de controles de acceso, auditor\u00edas de cambios y procedimientos de gesti\u00f3n de cambios que aseguren la integridad de los datos y la funcionalidad de la hoja de c\u00e1lculo.\n\n3. **\u00bfC\u00f3mo se debe documentar la verificaci\u00f3n de c\u00e1lculos en una hoja de c\u00e1lculo seg\u00fan el documento de ANVISA?**\n   - La verificaci\u00f3n de c\u00e1lculos en una hoja de c\u00e1lculo debe incluir una explicaci\u00f3n completa de las f\u00f3rmulas utilizadas y la confirmaci\u00f3n de que se han aplicado correctamente. Esta verificaci\u00f3n puede ser documentada a trav\u00e9s de la revisi\u00f3n y aprobaci\u00f3n de la hoja de c\u00e1lculo por una segunda persona, lo que asegura que no se requiere una verificaci\u00f3n adicional, dado que no hay necesidad de cuestionar la precisi\u00f3n de los c\u00e1lculos.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Establecimiento de Est\u00e1ndares y Controles**:\n   - Importancia de definir y confirmar est\u00e1ndares en el uso de plantillas y bases de datos.\n   - Necesidad de verificar la precisi\u00f3n de los c\u00e1lculos.\n\n2. **Control de Versiones**:\n   - Pregunta sobre c\u00f3mo asegurar que todos los usuarios utilicen la versi\u00f3n correcta de una plantilla, especialmente cuando se distribuye en m\u00faltiples estaciones de trabajo.\n   - Se requiere un proceso de gesti\u00f3n de cambios efectivo.\n\n3. **Control de Acceso**:\n   - Necesidad de restringir el acceso a aplicaciones y campos de datos, bloqueando celdas que no son para entrada de datos.\n\n4. **Configuraci\u00f3n de Funciones**:\n   - Consideraciones sobre la necesidad de scripts personalizados y el uso de macros, que son programas escritos en lenguajes como VBA.\n\n5. **Pruebas de Integraci\u00f3n**:\n   - Importancia de realizar pruebas de integraci\u00f3n cuando hay m\u00faltiples m\u00f3dulos o enlaces directos entre hojas de c\u00e1lculo.\n   - Necesidad de abordar los enlaces en el control de cambios.\n\n6. **Entrada y Salida de Datos**:\n   - Consideraciones sobre la entrada de datos solo a trav\u00e9s del teclado y la gesti\u00f3n de entradas inusuales.\n   - Pregunta sobre c\u00f3mo se guardar\u00e1 la salida (archivo o impresi\u00f3n) y la necesidad de controles de registros electr\u00f3nicos.\n\n7. **Bases de Datos de Escritorio**:\n   - Definici\u00f3n y caracter\u00edsticas de las bases de datos de escritorio, como MS Access.\n   - Comparaci\u00f3n de seguridad entre bases de datos de escritorio y sistemas de gesti\u00f3n de bases de datos m\u00e1s sofisticados (ej. Oracle, MS SQL Server).\n   - Riesgos asociados con el uso de bases de datos menos seguras y la necesidad de controles externos para proteger registros relevantes para GMP.\n\n8. **Enfoque Basado en Riesgos**:\n   - Se menciona un enfoque basado en riesgos, aunque no se detalla en el contenido proporcionado.\n\n### Entidades Clave\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil.\n- **VBA**: Visual Basic for Applications, lenguaje de programaci\u00f3n utilizado para crear macros.\n- **MS Access**: Ejemplo de base de datos de escritorio.\n- **Oracle, MS SQL Server**: Ejemplos de sistemas de gesti\u00f3n de bases de datos m\u00e1s sofisticados.\n- **GMP**: Buenas Pr\u00e1cticas de Manufactura, relevantes para la gesti\u00f3n de registros. \n\nEste resumen destaca los puntos cr\u00edticos y las entidades relevantes en el contexto de la validaci\u00f3n de sistemas inform\u00e1ticos seg\u00fan la gu\u00eda de ANVISA.", "excerpt_keywords": "Keywords: validation, spreadsheets, risk assessment, GAMP categories, data integrity"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "31a771be-8937-48cd-9ff9-c9b623bf1b4b", "node_type": "4", "metadata": {"page_label": "104", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "Spreadsheets can vary significantly in risk and complexity. The following points should be considered for this type of end user application:\n\n- Risk assessment and appropriate risk control measures to manage the identified risks;\n- The adoption of the most appropriate strategy to establish the stages of Specification and Verification of spreadsheet, so that it is shown to work as intended. This strategy should be based on:\n- \u2713 System impact on patient safety, product quality and data integrity (risk assessment);\n- \u2713 System complexity and innovation (architecture and categorization of the components of the system).\n\n----\n\n- Proper security to mitigate the risk of unauthorized changes to data and data spreadsheet;\n- Change management application management.\n\nThe regulated company's policies and procedures should define its specific approach to obtaining and maintenance of attendance and adaptation to the intended use of the spreadsheet.\n\n## 14.4 USE OF GAMP CATEGORIES\n\nThe product on which the application (Spreadsheets, templates, etc.) is built must belong to Category 1. The categories for spreadsheets and other end user applications range from Category 3 to 5.\n\nThe definition of the worksheet category depends on its complexity and innovation. It should be noted that a spreadsheet that merely uses its tabular editing power and does not perform calculations should be considered a document.\n\nA spreadsheet that simply uses its original functions (averages, standard deviations) to perform calculations, with no configuration, just acting as a calculator, it belongs to Category 3.\n\nWhen the arithmetic functions of the spreadsheet are used, the calculations must be fully explained. This includes verifying that the formula used has been used properly and that the results obtained are correct. Such verification can be documented through the review and approval of the spreadsheet by a second person. No additional verification is necessary, as there is no need to challenge the accuracy of calculations.\n\nA template-type spreadsheet in which the user inserts data that is automatically sent to another cell where specific calculations are performed, belongs to Category 4, since the template is configured by before use.\n\nA spreadsheet that uses custom macros or other more sophisticated operations (e.g., editing code source) belongs to Category 5.\n\nFor situations other than those mentioned above, consult the bibliographic references in this guide.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "c75c819f2814e2682eda5c9fe04c970b3f53548955bc29af7a0896cba8f08e0a", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "Spreadsheets can vary significantly in risk and complexity. The following points should be considered for this type of end user application:\n\n- Risk assessment and appropriate risk control measures to manage the identified risks;\n- The adoption of the most appropriate strategy to establish the stages of Specification and Verification of spreadsheet, so that it is shown to work as intended. This strategy should be based on:\n- \u2713 System impact on patient safety, product quality and data integrity (risk assessment);\n- \u2713 System complexity and innovation (architecture and categorization of the components of the system).\n\n----\n\n- Proper security to mitigate the risk of unauthorized changes to data and data spreadsheet;\n- Change management application management.\n\nThe regulated company's policies and procedures should define its specific approach to obtaining and maintenance of attendance and adaptation to the intended use of the spreadsheet.\n\n## 14.4 USE OF GAMP CATEGORIES\n\nThe product on which the application (Spreadsheets, templates, etc.) is built must belong to Category 1. The categories for spreadsheets and other end user applications range from Category 3 to 5.\n\nThe definition of the worksheet category depends on its complexity and innovation. It should be noted that a spreadsheet that merely uses its tabular editing power and does not perform calculations should be considered a document.\n\nA spreadsheet that simply uses its original functions (averages, standard deviations) to perform calculations, with no configuration, just acting as a calculator, it belongs to Category 3.\n\nWhen the arithmetic functions of the spreadsheet are used, the calculations must be fully explained. This includes verifying that the formula used has been used properly and that the results obtained are correct. Such verification can be documented through the review and approval of the spreadsheet by a second person. No additional verification is necessary, as there is no need to challenge the accuracy of calculations.\n\nA template-type spreadsheet in which the user inserts data that is automatically sent to another cell where specific calculations are performed, belongs to Category 4, since the template is configured by before use.\n\nA spreadsheet that uses custom macros or other more sophisticated operations (e.g., editing code source) belongs to Category 5.\n\nFor situations other than those mentioned above, consult the bibliographic references in this guide.", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 2473, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "470efe3c-bf1f-4423-84b8-9576e96f5a64": {"__data__": {"id_": "470efe3c-bf1f-4423-84b8-9576e96f5a64", "embedding": null, "metadata": {"page_label": "105", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 14.5 RISK-BASED CONTROLS\n\nGMP risks must be assessed. The following aspects must be considered:\n\n- The integrity of the data related to the control of the data files, since most of the developed spreadsheets process data;\n- The complexity of the spreadsheet, based on the assumption that undetected systematic errors are more likely to occur in software not developed under a strict development method and that more complex spreadsheets have more opportunity for errors to occur;\n- The potential impact on patient safety, product quality and data integrity.\n\nBased on these assessments, controls should be established with a focus on:\n\n- Degree of verification;\n- Security control (both for the spreadsheet code and for the BPx records that are in the spreadsheet);\n\nPage 98\n\n- Change control;\n- Control of the infrastructure on which the spreadsheet is built.\n\n## 14.5.1 Degree of Verification\n\nThe extent and rigor of the verification depends on the risk, complexity and innovation of the spreadsheet.\n\nComplex, high-risk spreadsheets require more rigorous testing. The number of logical branches in the spreadsheet is a good indicator of its complexity; if there are many logical functions (IF, AND, OR, etc.) or Lookup tables, the complexity is greater. Although they are native functions, they introduce more paths potentials within the spreadsheet and therefore more ramifications that require a more testing strategy sophisticated.\n\nMacros also increase the complexity of spreadsheets, because they are effectively secondary applications embedded. Even when created using key capture, there is a program with a language for behind the macro, although macros that simply automate a series of actions are less worrying than those that contain logical ramifications. Macros must be challenged through functionality tests. Macros that include logical paths should be subject to a more stringent verification, with due attention to the multiple logic paths.\n\n## 14.5.2 Security Control\n\nSecurity considerations for spreadsheets are similar to those for applications on the network or server, such as: access to the spreadsheet, access to data through the spreadsheet and access to data at the operating system or spreadsheet code. Security within the operating environment must be appropriate to the type of information stored or processed.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos establece la importancia de evaluar los riesgos asociados con las hojas de c\u00e1lculo en el contexto de las Buenas Pr\u00e1cticas de Manufactura (GMP). Se enfatiza la necesidad de considerar la integridad de los datos, la complejidad de las hojas de c\u00e1lculo y su impacto potencial en la seguridad del paciente y la calidad del producto. Se sugieren controles basados en el grado de verificaci\u00f3n, la seguridad, el control de cambios y la infraestructura. Adem\u00e1s, se detalla que la verificaci\u00f3n debe ser m\u00e1s rigurosa para hojas de c\u00e1lculo complejas y de alto riesgo, y se discuten las implicaciones de las macros en la complejidad y seguridad de las hojas de c\u00e1lculo.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfCu\u00e1les son los factores que determinan el grado de verificaci\u00f3n necesario para una hoja de c\u00e1lculo en el contexto de GMP?**\n   - La verificaci\u00f3n depende del riesgo, la complejidad y la innovaci\u00f3n de la hoja de c\u00e1lculo. Hojas de c\u00e1lculo complejas y de alto riesgo requieren pruebas m\u00e1s rigurosas, y la cantidad de ramas l\u00f3gicas es un buen indicador de su complejidad.\n\n2. **\u00bfQu\u00e9 aspectos de seguridad deben considerarse al manejar hojas de c\u00e1lculo en un entorno de GMP?**\n   - Las consideraciones de seguridad incluyen el acceso a la hoja de c\u00e1lculo, el acceso a los datos a trav\u00e9s de la hoja de c\u00e1lculo y el acceso a los datos en el sistema operativo o el c\u00f3digo de la hoja de c\u00e1lculo. La seguridad debe ser adecuada al tipo de informaci\u00f3n almacenada o procesada.\n\n3. **\u00bfC\u00f3mo afectan las macros a la complejidad y la verificaci\u00f3n de las hojas de c\u00e1lculo?**\n   - Las macros aumentan la complejidad de las hojas de c\u00e1lculo, ya que son aplicaciones secundarias integradas. Las macros que contienen ramificaciones l\u00f3gicas deben someterse a pruebas de funcionalidad m\u00e1s estrictas debido a las m\u00faltiples rutas l\u00f3gicas que pueden introducir.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Evaluaci\u00f3n de Riesgos**: Se enfatiza la importancia de realizar una evaluaci\u00f3n de riesgos para identificar y gestionar los riesgos asociados con el uso de hojas de c\u00e1lculo como aplicaciones de usuario final.\n\n2. **Medidas de Control**: Se deben implementar medidas de control adecuadas para mitigar los riesgos identificados, incluyendo la seguridad para prevenir cambios no autorizados en los datos.\n\n3. **Estrategia de Especificaci\u00f3n y Verificaci\u00f3n**: Es crucial adoptar una estrategia que establezca las etapas de especificaci\u00f3n y verificaci\u00f3n de las hojas de c\u00e1lculo, considerando su impacto en la seguridad del paciente, la calidad del producto y la integridad de los datos.\n\n4. **Categor\u00edas GAMP**: Las hojas de c\u00e1lculo se clasifican en categor\u00edas GAMP (Good Automated Manufacturing Practice) que van de la Categor\u00eda 3 a la 5, dependiendo de su complejidad e innovaci\u00f3n:\n   - **Categor\u00eda 1**: Producto base de la aplicaci\u00f3n.\n   - **Categor\u00eda 3**: Hojas de c\u00e1lculo que utilizan funciones aritm\u00e9ticas simples sin configuraci\u00f3n.\n   - **Categor\u00eda 4**: Hojas de c\u00e1lculo tipo plantilla que requieren configuraci\u00f3n previa.\n   - **Categor\u00eda 5**: Hojas de c\u00e1lculo que utilizan macros personalizadas o funciones sofisticadas.\n\n5. **Documentaci\u00f3n de Verificaci\u00f3n**: La verificaci\u00f3n de c\u00e1lculos en las hojas de c\u00e1lculo debe ser documentada a trav\u00e9s de la revisi\u00f3n y aprobaci\u00f3n por una segunda persona, asegurando que las f\u00f3rmulas se apliquen correctamente y que los resultados sean precisos.\n\n6. **Pol\u00edticas y Procedimientos**: Las pol\u00edticas y procedimientos de la empresa regulada deben definir el enfoque espec\u00edfico para la obtenci\u00f3n y mantenimiento de las hojas de c\u00e1lculo, asegurando su adaptaci\u00f3n al uso previsto.\n\n### Entidades Clave\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil.\n- **GAMP**: Buenas Pr\u00e1cticas de Fabricaci\u00f3n Automatizadas.\n- **Hojas de C\u00e1lculo**: Aplicaciones de usuario final que requieren validaci\u00f3n y categorizaci\u00f3n seg\u00fan su complejidad.\n- **Seguridad de Datos**: Medidas para proteger la integridad de los datos en hojas de c\u00e1lculo.\n- **Gesti\u00f3n de Cambios**: Proceso para manejar modificaciones en las hojas de c\u00e1lculo y asegurar su correcto funcionamiento. \n\nEste resumen destaca los aspectos fundamentales de la validaci\u00f3n de sistemas inform\u00e1ticos en el contexto de las hojas de c\u00e1lculo, as\u00ed como las categor\u00edas GAMP que ayudan a clasificar su complejidad y riesgo.", "excerpt_keywords": "Keywords: risk assessment, spreadsheet validation, GMP compliance, data integrity, security controls"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "de4404b5-5b99-4153-8af1-26528f12228d", "node_type": "4", "metadata": {"page_label": "105", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 14.5 RISK-BASED CONTROLS\n\nGMP risks must be assessed. The following aspects must be considered:\n\n- The integrity of the data related to the control of the data files, since most of the developed spreadsheets process data;\n- The complexity of the spreadsheet, based on the assumption that undetected systematic errors are more likely to occur in software not developed under a strict development method and that more complex spreadsheets have more opportunity for errors to occur;\n- The potential impact on patient safety, product quality and data integrity.\n\nBased on these assessments, controls should be established with a focus on:\n\n- Degree of verification;\n- Security control (both for the spreadsheet code and for the BPx records that are in the spreadsheet);\n\nPage 98\n\n- Change control;\n- Control of the infrastructure on which the spreadsheet is built.\n\n## 14.5.1 Degree of Verification\n\nThe extent and rigor of the verification depends on the risk, complexity and innovation of the spreadsheet.\n\nComplex, high-risk spreadsheets require more rigorous testing. The number of logical branches in the spreadsheet is a good indicator of its complexity; if there are many logical functions (IF, AND, OR, etc.) or Lookup tables, the complexity is greater. Although they are native functions, they introduce more paths potentials within the spreadsheet and therefore more ramifications that require a more testing strategy sophisticated.\n\nMacros also increase the complexity of spreadsheets, because they are effectively secondary applications embedded. Even when created using key capture, there is a program with a language for behind the macro, although macros that simply automate a series of actions are less worrying than those that contain logical ramifications. Macros must be challenged through functionality tests. Macros that include logical paths should be subject to a more stringent verification, with due attention to the multiple logic paths.\n\n## 14.5.2 Security Control\n\nSecurity considerations for spreadsheets are similar to those for applications on the network or server, such as: access to the spreadsheet, access to data through the spreadsheet and access to data at the operating system or spreadsheet code. Security within the operating environment must be appropriate to the type of information stored or processed.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "396b40341b74870a6c2a586aecfc4185434a60e4eb381d98e07d9e54f7c0a3a3", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "# 14.5 RISK-BASED CONTROLS\n\nGMP risks must be assessed. The following aspects must be considered:\n\n- The integrity of the data related to the control of the data files, since most of the developed spreadsheets process data;\n- The complexity of the spreadsheet, based on the assumption that undetected systematic errors are more likely to occur in software not developed under a strict development method and that more complex spreadsheets have more opportunity for errors to occur;\n- The potential impact on patient safety, product quality and data integrity.\n\nBased on these assessments, controls should be established with a focus on:\n\n- Degree of verification;\n- Security control (both for the spreadsheet code and for the BPx records that are in the spreadsheet);\n\nPage 98\n\n- Change control;\n- Control of the infrastructure on which the spreadsheet is built.\n\n## 14.5.1 Degree of Verification\n\nThe extent and rigor of the verification depends on the risk, complexity and innovation of the spreadsheet.\n\nComplex, high-risk spreadsheets require more rigorous testing. The number of logical branches in the spreadsheet is a good indicator of its complexity; if there are many logical functions (IF, AND, OR, etc.) or Lookup tables, the complexity is greater. Although they are native functions, they introduce more paths potentials within the spreadsheet and therefore more ramifications that require a more testing strategy sophisticated.\n\nMacros also increase the complexity of spreadsheets, because they are effectively secondary applications embedded. Even when created using key capture, there is a program with a language for behind the macro, although macros that simply automate a series of actions are less worrying than those that contain logical ramifications. Macros must be challenged through functionality tests. Macros that include logical paths should be subject to a more stringent verification, with due attention to the multiple logic paths.\n\n## 14.5.2 Security Control\n\nSecurity considerations for spreadsheets are similar to those for applications on the network or server, such as: access to the spreadsheet, access to data through the spreadsheet and access to data at the operating system or spreadsheet code. Security within the operating environment must be appropriate to the type of information stored or processed.", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 2344, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "7104b48c-9f7d-4219-ad79-f06bd413d1d2": {"__data__": {"id_": "7104b48c-9f7d-4219-ad79-f06bd413d1d2", "embedding": null, "metadata": {"page_label": "106", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "For many spreadsheets, a combination of infrastructure controls (eg, restricted access to directories) and controls available on the spreadsheet (eg password protection for spreadsheet cells) can provide some security against unintended changes. However, these controls can be inefficient to prevent the spreadsheet creator makes changes outside of the change control process, particularly if the spreadsheet to be located on an individual workstation. In these situations, the ideal is to place the spreadsheet in a network environment in which the rights of all users, including the author, are limited, also adding a regular scheduled backup process.\n\nOften, data is saved within the spreadsheet itself. Ensuring the integrity of this data requires the use of very strict controls, including any necessary controls on electronic records. In cases where the spreadsheet is subject to some type of editing, proper control may involve the use of a Electronic Document Management (EDMS). Alternatively, controlled copies can be kept in a format that cannot be altered or printed.\n\nGMP-relevant data cannot be saved to a local disk drive that is not secure and is not submitted to performing backups (backup) regularly.\n\nIf the security level of the spreadsheet is not adequate enough for the data managed in it, the company should seek an application that runs in a more robust operating environment.\n\n----\n\n## 14.5.3 Change Control\n\nSpreadsheets that process data relevant to GMP should be subject to change control. The management versioning is difficult in the case of spreadsheets. In some cases, spreadsheet management within an EDMS can be an appropriate solution, since this system maintains an audit trail of the spreadsheet versions.\n\nAnother solution is the use of library tools that are frequently used by developers to manage code. These tools can be used to manage any type files, can be effective, relatively easy to implement and are less expensive than a system like EDMS.\n\nAs with any change control process, changes to the spreadsheet must have a record of change that includes a description of the change and an impact assessment. Where appropriate, tests associated with this function should be documented.\n\n## 15.5.4 Infrastructure Control\n\nEnvironments in which the spreadsheet is installed belong to Software Category 1. These tools provide application environment for spreadsheets, databases, scripts or scripts that are developed by users.\n\nThe installation of the environment must be verified and the environment must be managed for changes and for your configuration.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "### Resumen del Contexto\n\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos destaca la importancia de implementar controles de infraestructura y de cambio para las hojas de c\u00e1lculo que manejan datos relevantes para las Buenas Pr\u00e1cticas de Manufactura (GMP). Se enfatiza la necesidad de restringir el acceso a las hojas de c\u00e1lculo, mantener un entorno de red seguro, y realizar copias de seguridad regulares. Adem\u00e1s, se sugiere el uso de sistemas de gesti\u00f3n de documentos electr\u00f3nicos (EDMS) para mantener un registro de cambios y versiones, as\u00ed como la utilizaci\u00f3n de herramientas de gesti\u00f3n de c\u00f3digo para facilitar el control de versiones. La integridad de los datos y la seguridad son aspectos cr\u00edticos que deben ser abordados para cumplir con las regulaciones.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfCu\u00e1les son las medidas espec\u00edficas que se deben implementar para garantizar la integridad de los datos en hojas de c\u00e1lculo que contienen informaci\u00f3n GMP?**\n   - Respuesta: Se deben utilizar controles estrictos, que incluyan restricciones de acceso, protecci\u00f3n por contrase\u00f1a de celdas, y la posibilidad de utilizar un sistema de gesti\u00f3n de documentos electr\u00f3nicos (EDMS) para mantener un registro de cambios y versiones. Adem\u00e1s, es crucial que los datos no se guarden en unidades de disco locales no seguras y que se realicen copias de seguridad regularmente.\n\n2. **\u00bfQu\u00e9 alternativas se sugieren para la gesti\u00f3n de versiones de hojas de c\u00e1lculo si no se utiliza un sistema EDMS?**\n   - Respuesta: Se pueden utilizar herramientas de biblioteca que son com\u00fanmente empleadas por desarrolladores para gestionar c\u00f3digo. Estas herramientas son efectivas, relativamente f\u00e1ciles de implementar y menos costosas que un sistema EDMS, permitiendo as\u00ed un control adecuado de las versiones de las hojas de c\u00e1lculo.\n\n3. **\u00bfQu\u00e9 criterios se deben considerar al decidir si una hoja de c\u00e1lculo tiene un nivel de seguridad adecuado para los datos que maneja?**\n   - Respuesta: Se debe evaluar si el nivel de seguridad de la hoja de c\u00e1lculo es suficiente para proteger la informaci\u00f3n sensible. Si no es adecuado, la empresa debe considerar la adopci\u00f3n de una aplicaci\u00f3n que funcione en un entorno operativo m\u00e1s robusto, que ofrezca mejores controles de seguridad y gesti\u00f3n de datos.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Evaluaci\u00f3n de Riesgos en GMP**:\n   - Importancia de evaluar los riesgos asociados con las hojas de c\u00e1lculo en el contexto de las Buenas Pr\u00e1cticas de Manufactura (GMP).\n   - Factores a considerar: integridad de los datos, complejidad de la hoja de c\u00e1lculo y su impacto en la seguridad del paciente y la calidad del producto.\n\n2. **Controles Basados en Riesgos**:\n   - Establecimiento de controles enfocados en:\n     - Grado de verificaci\u00f3n.\n     - Control de seguridad (c\u00f3digo de la hoja de c\u00e1lculo y registros BPx).\n     - Control de cambios.\n     - Control de la infraestructura.\n\n3. **Grado de Verificaci\u00f3n**:\n   - La verificaci\u00f3n debe ser proporcional al riesgo, complejidad e innovaci\u00f3n de la hoja de c\u00e1lculo.\n   - Hojas de c\u00e1lculo complejas y de alto riesgo requieren pruebas m\u00e1s rigurosas.\n   - Indicadores de complejidad: n\u00famero de ramas l\u00f3gicas y uso de funciones l\u00f3gicas (IF, AND, OR).\n\n4. **Complejidad de Macros**:\n   - Las macros aumentan la complejidad de las hojas de c\u00e1lculo.\n   - Macros con ramificaciones l\u00f3gicas requieren pruebas de funcionalidad m\u00e1s estrictas.\n\n5. **Control de Seguridad**:\n   - Consideraciones de seguridad similares a las de aplicaciones en red o servidor.\n   - Aspectos a considerar: acceso a la hoja de c\u00e1lculo, acceso a datos a trav\u00e9s de la hoja y acceso a datos en el sistema operativo o c\u00f3digo de la hoja de c\u00e1lculo.\n   - La seguridad debe ser adecuada al tipo de informaci\u00f3n almacenada o procesada.\n\n### Entidades Clave\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil.\n- **GMP**: Buenas Pr\u00e1cticas de Manufactura.\n- **Hojas de C\u00e1lculo**: Herramientas utilizadas para procesar datos que requieren validaci\u00f3n y control de riesgos.\n- **Macros**: Funciones automatizadas que pueden aumentar la complejidad y riesgo de errores en las hojas de c\u00e1lculo.", "excerpt_keywords": "Keywords: ANVISA, GMP, spreadsheets, change control, data integrity"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "bcfa7345-4346-4ef6-b5d7-f8b12d931c59", "node_type": "4", "metadata": {"page_label": "106", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "For many spreadsheets, a combination of infrastructure controls (eg, restricted access to directories) and controls available on the spreadsheet (eg password protection for spreadsheet cells) can provide some security against unintended changes. However, these controls can be inefficient to prevent the spreadsheet creator makes changes outside of the change control process, particularly if the spreadsheet to be located on an individual workstation. In these situations, the ideal is to place the spreadsheet in a network environment in which the rights of all users, including the author, are limited, also adding a regular scheduled backup process.\n\nOften, data is saved within the spreadsheet itself. Ensuring the integrity of this data requires the use of very strict controls, including any necessary controls on electronic records. In cases where the spreadsheet is subject to some type of editing, proper control may involve the use of a Electronic Document Management (EDMS). Alternatively, controlled copies can be kept in a format that cannot be altered or printed.\n\nGMP-relevant data cannot be saved to a local disk drive that is not secure and is not submitted to performing backups (backup) regularly.\n\nIf the security level of the spreadsheet is not adequate enough for the data managed in it, the company should seek an application that runs in a more robust operating environment.\n\n----\n\n## 14.5.3 Change Control\n\nSpreadsheets that process data relevant to GMP should be subject to change control. The management versioning is difficult in the case of spreadsheets. In some cases, spreadsheet management within an EDMS can be an appropriate solution, since this system maintains an audit trail of the spreadsheet versions.\n\nAnother solution is the use of library tools that are frequently used by developers to manage code. These tools can be used to manage any type files, can be effective, relatively easy to implement and are less expensive than a system like EDMS.\n\nAs with any change control process, changes to the spreadsheet must have a record of change that includes a description of the change and an impact assessment. Where appropriate, tests associated with this function should be documented.\n\n## 15.5.4 Infrastructure Control\n\nEnvironments in which the spreadsheet is installed belong to Software Category 1. These tools provide application environment for spreadsheets, databases, scripts or scripts that are developed by users.\n\nThe installation of the environment must be verified and the environment must be managed for changes and for your configuration.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "e6b409f6ea1d6eb9ef238e5fcb09bd745a166c7d6f121998044b16ada0d0dcfe", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "For many spreadsheets, a combination of infrastructure controls (eg, restricted access to directories) and controls available on the spreadsheet (eg password protection for spreadsheet cells) can provide some security against unintended changes. However, these controls can be inefficient to prevent the spreadsheet creator makes changes outside of the change control process, particularly if the spreadsheet to be located on an individual workstation. In these situations, the ideal is to place the spreadsheet in a network environment in which the rights of all users, including the author, are limited, also adding a regular scheduled backup process.\n\nOften, data is saved within the spreadsheet itself. Ensuring the integrity of this data requires the use of very strict controls, including any necessary controls on electronic records. In cases where the spreadsheet is subject to some type of editing, proper control may involve the use of a Electronic Document Management (EDMS). Alternatively, controlled copies can be kept in a format that cannot be altered or printed.\n\nGMP-relevant data cannot be saved to a local disk drive that is not secure and is not submitted to performing backups (backup) regularly.\n\nIf the security level of the spreadsheet is not adequate enough for the data managed in it, the company should seek an application that runs in a more robust operating environment.\n\n----\n\n## 14.5.3 Change Control\n\nSpreadsheets that process data relevant to GMP should be subject to change control. The management versioning is difficult in the case of spreadsheets. In some cases, spreadsheet management within an EDMS can be an appropriate solution, since this system maintains an audit trail of the spreadsheet versions.\n\nAnother solution is the use of library tools that are frequently used by developers to manage code. These tools can be used to manage any type files, can be effective, relatively easy to implement and are less expensive than a system like EDMS.\n\nAs with any change control process, changes to the spreadsheet must have a record of change that includes a description of the change and an impact assessment. Where appropriate, tests associated with this function should be documented.\n\n## 15.5.4 Infrastructure Control\n\nEnvironments in which the spreadsheet is installed belong to Software Category 1. These tools provide application environment for spreadsheets, databases, scripts or scripts that are developed by users.\n\nThe installation of the environment must be verified and the environment must be managed for changes and for your configuration.", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 2593, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "7900104b-543a-4836-a9b0-e35df388e2e4": {"__data__": {"id_": "7900104b-543a-4836-a9b0-e35df388e2e4", "embedding": null, "metadata": {"page_label": "107", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 14.6 APPROACHES FOR VALIDATION\n\nBelow are 05 (five) different applications for the end user, including the spreadsheet and a summary of potential approaches based on considerations about the impact on GMP and the complexity of application. They are illustrative examples and are not definitive.\n\n## 14.6.1 Type A - Simple Spreadsheets for Calculations\n\n**Assessment:** high impact and low complexity\n\n**Recommended approach:**\n\n- Preparation of the ERU (URS);\n- Documented verification, carried out by a third person, that the calculations are correct;\n- Security to ensure that it is protected from unauthorized change;\n- Security to ensure that users can access only approved versions;\n- Secure storage of the electronic document.\n\n## 14.6.2 Type B - Training Record Worksheet\n\n**Evaluation:** low impact and low complexity.\n\n**Recommended approach:**\n\n- No specific functionality requires specification and verification;\n\n**Standard controls for electronic documents containing evidence to meet GMP.**\n\n## 14.6.3 Type C - Desktop database\n\n**Assessment:** high impact and medium complexity\n\n**Recommended approach:**\n\n- Typical Category 4 approach: validation plan; ERU / URS; Project / Functional Specification (can be combined); traceability; documented tests, with pre-defined acceptance criteria; report of validation;\n- Security to limit access to authorized persons only;\n- Change control.\n\n## 14.6.4 Type D - Worksheets for Statistical Analysis - Clinical Study\n\n**Assessment:** high impact and high complexity", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos presenta diferentes enfoques para la validaci\u00f3n de aplicaciones utilizadas en el \u00e1mbito de las Buenas Pr\u00e1cticas de Manufactura (GMP). Se identifican cinco tipos de aplicaciones, cada una con su evaluaci\u00f3n de impacto y complejidad, as\u00ed como recomendaciones espec\u00edficas para su validaci\u00f3n. Las aplicaciones var\u00edan desde hojas de c\u00e1lculo simples hasta bases de datos de escritorio y hojas de trabajo para an\u00e1lisis estad\u00edsticos en estudios cl\u00ednicos.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfQu\u00e9 medidas de seguridad se recomiendan para las hojas de c\u00e1lculo simples (Tipo A) en t\u00e9rminos de protecci\u00f3n contra cambios no autorizados?**\n   - El documento sugiere implementar seguridad para proteger las hojas de c\u00e1lculo de cambios no autorizados, asegurando que solo se puedan acceder a versiones aprobadas y que el documento electr\u00f3nico est\u00e9 almacenado de manera segura.\n\n2. **\u00bfCu\u00e1l es la diferencia en el enfoque de validaci\u00f3n entre una hoja de registro de entrenamiento (Tipo B) y una base de datos de escritorio (Tipo C)?**\n   - Para la hoja de registro de entrenamiento (Tipo B), no se requiere una funcionalidad espec\u00edfica que necesite especificaci\u00f3n y verificaci\u00f3n, dado que su impacto y complejidad son bajos. En cambio, la base de datos de escritorio (Tipo C) requiere un enfoque m\u00e1s estructurado, incluyendo un plan de validaci\u00f3n, especificaciones funcionales, trazabilidad y pruebas documentadas con criterios de aceptaci\u00f3n predefinidos.\n\n3. **\u00bfQu\u00e9 tipo de documentaci\u00f3n se sugiere para la validaci\u00f3n de aplicaciones de alta complejidad, como las hojas de trabajo para an\u00e1lisis estad\u00edsticos en estudios cl\u00ednicos (Tipo D)?**\n   - Aunque el contexto no proporciona detalles espec\u00edficos para el Tipo D, se puede inferir que, dado su alto impacto y complejidad, se requerir\u00eda una documentaci\u00f3n exhaustiva similar a la del Tipo C, que incluir\u00eda un plan de validaci\u00f3n, especificaciones, pruebas documentadas y controles de cambio, aunque se necesitar\u00edan detalles adicionales para un enfoque espec\u00edfico.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Controles de Infraestructura**:\n   - Importancia de restringir el acceso a las hojas de c\u00e1lculo mediante controles de infraestructura, como acceso restringido a directorios y protecci\u00f3n por contrase\u00f1a de celdas.\n   - Necesidad de ubicar las hojas de c\u00e1lculo en un entorno de red seguro donde los derechos de los usuarios, incluido el autor, est\u00e9n limitados.\n   - Implementaci\u00f3n de un proceso de copias de seguridad programadas para proteger los datos.\n\n2. **Integridad de los Datos**:\n   - Uso de controles estrictos para garantizar la integridad de los datos almacenados en las hojas de c\u00e1lculo.\n   - Recomendaci\u00f3n de utilizar un Sistema de Gesti\u00f3n de Documentos Electr\u00f3nicos (EDMS) para mantener un registro de cambios y versiones.\n   - Alternativa de mantener copias controladas en formatos que no puedan ser alterados o impresos.\n\n3. **Datos Relevantes para GMP**:\n   - Prohibici\u00f3n de guardar datos relevantes para las Buenas Pr\u00e1cticas de Manufactura (GMP) en unidades de disco locales no seguras y sin copias de seguridad regulares.\n   - Evaluaci\u00f3n del nivel de seguridad de las hojas de c\u00e1lculo y la necesidad de adoptar aplicaciones en entornos operativos m\u00e1s robustos si la seguridad es insuficiente.\n\n4. **Control de Cambios**:\n   - Las hojas de c\u00e1lculo que procesan datos relevantes para GMP deben estar sujetas a un control de cambios.\n   - Dificultades en la gesti\u00f3n de versiones de hojas de c\u00e1lculo y la posibilidad de utilizar un EDMS para mantener un historial de versiones.\n   - Uso de herramientas de biblioteca para gestionar archivos como una alternativa menos costosa y efectiva.\n\n5. **Control de Infraestructura**:\n   - Clasificaci\u00f3n de los entornos donde se instalan las hojas de c\u00e1lculo como Software Categor\u00eda 1.\n   - Necesidad de verificar la instalaci\u00f3n del entorno y gestionar los cambios y configuraciones adecuadamente.\n\n### Entidades Clave\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil.\n- **GMP**: Buenas Pr\u00e1cticas de Manufactura.\n- **EDMS**: Sistema de Gesti\u00f3n de Documentos Electr\u00f3nicos.\n- **Controles de Seguridad**: Medidas implementadas para proteger la integridad y confidencialidad de los datos.\n- **Herramientas de Biblioteca**: Herramientas utilizadas por desarrolladores para gestionar versiones de archivos y c\u00f3digo.", "excerpt_keywords": "Keywords: validation, GMP, spreadsheets, electronic documents, ANVISA"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "b592a522-ade0-4abe-ba9a-1103ee3b45f1", "node_type": "4", "metadata": {"page_label": "107", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 14.6 APPROACHES FOR VALIDATION\n\nBelow are 05 (five) different applications for the end user, including the spreadsheet and a summary of potential approaches based on considerations about the impact on GMP and the complexity of application. They are illustrative examples and are not definitive.\n\n## 14.6.1 Type A - Simple Spreadsheets for Calculations\n\n**Assessment:** high impact and low complexity\n\n**Recommended approach:**\n\n- Preparation of the ERU (URS);\n- Documented verification, carried out by a third person, that the calculations are correct;\n- Security to ensure that it is protected from unauthorized change;\n- Security to ensure that users can access only approved versions;\n- Secure storage of the electronic document.\n\n## 14.6.2 Type B - Training Record Worksheet\n\n**Evaluation:** low impact and low complexity.\n\n**Recommended approach:**\n\n- No specific functionality requires specification and verification;\n\n**Standard controls for electronic documents containing evidence to meet GMP.**\n\n## 14.6.3 Type C - Desktop database\n\n**Assessment:** high impact and medium complexity\n\n**Recommended approach:**\n\n- Typical Category 4 approach: validation plan; ERU / URS; Project / Functional Specification (can be combined); traceability; documented tests, with pre-defined acceptance criteria; report of validation;\n- Security to limit access to authorized persons only;\n- Change control.\n\n## 14.6.4 Type D - Worksheets for Statistical Analysis - Clinical Study\n\n**Assessment:** high impact and high complexity", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "e329fd1b90fdf9d790592f763348c869f0f249f5fa1711e84b3960a674478704", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "# 14.6 APPROACHES FOR VALIDATION\n\nBelow are 05 (five) different applications for the end user, including the spreadsheet and a summary of potential approaches based on considerations about the impact on GMP and the complexity of application. They are illustrative examples and are not definitive.\n\n## 14.6.1 Type A - Simple Spreadsheets for Calculations\n\n**Assessment:** high impact and low complexity\n\n**Recommended approach:**\n\n- Preparation of the ERU (URS);\n- Documented verification, carried out by a third person, that the calculations are correct;\n- Security to ensure that it is protected from unauthorized change;\n- Security to ensure that users can access only approved versions;\n- Secure storage of the electronic document.\n\n## 14.6.2 Type B - Training Record Worksheet\n\n**Evaluation:** low impact and low complexity.\n\n**Recommended approach:**\n\n- No specific functionality requires specification and verification;\n\n**Standard controls for electronic documents containing evidence to meet GMP.**\n\n## 14.6.3 Type C - Desktop database\n\n**Assessment:** high impact and medium complexity\n\n**Recommended approach:**\n\n- Typical Category 4 approach: validation plan; ERU / URS; Project / Functional Specification (can be combined); traceability; documented tests, with pre-defined acceptance criteria; report of validation;\n- Security to limit access to authorized persons only;\n- Change control.\n\n## 14.6.4 Type D - Worksheets for Statistical Analysis - Clinical Study\n\n**Assessment:** high impact and high complexity", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 1522, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "4d049284-a173-49da-9276-5987a87815c9": {"__data__": {"id_": "4d049284-a173-49da-9276-5987a87815c9", "embedding": null, "metadata": {"page_label": "108", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "Recommended approach:\n\n- Typical Category 5 approach: validation plan; ERU / URS; Project / Functional Specification (can be combined); traceability; documented tests, with pre-defined acceptance criteria; report of validation;\n- Security to limit access to authorized persons only;\n- Change control.\n\n## 14.6.5 Type E - Worksheets for Statistical Analysis - Clinical Study\n\nEvaluation: low impact and high complexity.\n\nRecommended approach:\n\n- Documented verification, carried out by a third person, that the calculations are correct;\n- Change control;\n- Security to ensure that it is protected from unauthorized change;\n- Security to ensure that users can access only approved versions.\n\n## 14.6.6 Type F - Work Area Databases - Traceability of productive materials\n\nExample of using this type of software: layout of printed labels.\n\nEvaluation: medium impact and medium complexity.\n\nRecommended approach:\n\n----\n\nGuide for Computer Systems Validation\nGuide n\u00b0 33/2020 - version 1, of 03/26/2020\n\n----\n\nPage 101\n\n- Typical Category 4 approach: validation plan; ERU / URS; Project / Functional Specification (can be combined); traceability; documented tests, with pre-defined acceptance criteria; report of validation;\n- Security to limit access to authorized persons only;\n- Change control.\n\n## 15 FINAL CONSIDERATIONS\n\nFor systems already installed, the company must decide whether the system can be validated or not.\n\nThe first step to be followed should be the preparation of the ERU / URS document starting from the guidelines described in this Guide, similar to what would be done for the purchase of a new system.\n\nThe next step is the evaluation of this non-validated system using the ERU / URS document to decide\n\n----\n\nhttps://translate.googleusercontent.com/translate_f", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior:\nEl documento \"Gu\u00eda para la Validaci\u00f3n de Sistemas Inform\u00e1ticos\" de ANVISA (Gu\u00eda n\u00b0 33/2020) establece enfoques recomendados para la validaci\u00f3n de diferentes tipos de sistemas inform\u00e1ticos en el \u00e1mbito de la salud. Se clasifican los sistemas en diferentes categor\u00edas seg\u00fan su impacto y complejidad, y se sugieren pasos espec\u00edficos para la validaci\u00f3n, incluyendo la preparaci\u00f3n de documentos como el ERU/URS, la implementaci\u00f3n de controles de cambio y medidas de seguridad para proteger la integridad de los datos.\n\n### Preguntas Espec\u00edficas:\n\n1. **\u00bfQu\u00e9 pasos espec\u00edficos se deben seguir para validar un sistema inform\u00e1tico ya instalado seg\u00fan la Gu\u00eda de ANVISA?**\n   - La gu\u00eda sugiere que el primer paso es la preparaci\u00f3n del documento ERU/URS, seguido de la evaluaci\u00f3n del sistema no validado utilizando dicho documento para decidir sobre su validaci\u00f3n.\n\n2. **\u00bfCu\u00e1les son las medidas de seguridad recomendadas para los sistemas de tipo E y F en la Gu\u00eda de ANVISA?**\n   - Para los sistemas de tipo E, se recomienda asegurar que el sistema est\u00e9 protegido contra cambios no autorizados y que los usuarios solo puedan acceder a versiones aprobadas. Para los sistemas de tipo F, se sugiere implementar medidas similares de seguridad para proteger la trazabilidad de los materiales productivos.\n\n3. **\u00bfQu\u00e9 enfoque se recomienda para la validaci\u00f3n de sistemas de tipo F, como las bases de datos de \u00e1reas de trabajo?**\n   - Se recomienda un enfoque t\u00edpico de categor\u00eda 4, que incluye un plan de validaci\u00f3n, la preparaci\u00f3n de un ERU/URS, especificaciones funcionales del proyecto, trazabilidad, pruebas documentadas con criterios de aceptaci\u00f3n predefinidos y un informe de validaci\u00f3n. Adem\u00e1s, se deben implementar controles de cambio y medidas de seguridad para limitar el acceso a personas autorizadas.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos presenta diferentes enfoques para validar aplicaciones en el contexto de las Buenas Pr\u00e1cticas de Manufactura (GMP). Se identifican cinco tipos de aplicaciones, cada una evaluada seg\u00fan su impacto y complejidad, junto con recomendaciones espec\u00edficas para su validaci\u00f3n.\n\n#### Tipos de Aplicaciones y Enfoques de Validaci\u00f3n:\n\n1. **Tipo A - Hojas de C\u00e1lculo Simples**\n   - **Impacto:** Alto\n   - **Complejidad:** Baja\n   - **Enfoque:** Preparaci\u00f3n de ERU (URS), verificaci\u00f3n documentada por terceros, seguridad contra cambios no autorizados, acceso restringido a versiones aprobadas, almacenamiento seguro.\n\n2. **Tipo B - Hoja de Registro de Entrenamiento**\n   - **Impacto:** Bajo\n   - **Complejidad:** Baja\n   - **Enfoque:** No se requiere especificaci\u00f3n y verificaci\u00f3n de funcionalidades espec\u00edficas; controles est\u00e1ndar para documentos electr\u00f3nicos.\n\n3. **Tipo C - Base de Datos de Escritorio**\n   - **Impacto:** Alto\n   - **Complejidad:** Media\n   - **Enfoque:** Plan de validaci\u00f3n, ERU/URS, especificaciones funcionales, trazabilidad, pruebas documentadas con criterios de aceptaci\u00f3n, informe de validaci\u00f3n, seguridad de acceso y control de cambios.\n\n4. **Tipo D - Hojas de Trabajo para An\u00e1lisis Estad\u00edsticos en Estudios Cl\u00ednicos**\n   - **Impacto:** Alto\n   - **Complejidad:** Alta\n   - **Enfoque:** Aunque no se detallan las recomendaciones espec\u00edficas, se infiere que se requerir\u00eda una documentaci\u00f3n exhaustiva similar a la del Tipo C.\n\n### Entidades Clave:\n- **ANVISA:** Agencia Nacional de Vigilancia Sanitaria de Brasil.\n- **GMP:** Buenas Pr\u00e1cticas de Manufactura.\n- **ERU (URS):** Requisitos de Usuario (User Requirements Specification).\n- **Tipo A, B, C, D:** Clasificaci\u00f3n de aplicaciones seg\u00fan impacto y complejidad.\n\nEste resumen destaca la importancia de la validaci\u00f3n de sistemas inform\u00e1ticos en el cumplimiento de las GMP y proporciona un marco para abordar diferentes tipos de aplicaciones seg\u00fan su riesgo y complejidad.", "excerpt_keywords": "Keywords: validation, ANVISA, computer systems, regulatory compliance, statistical analysis"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "2f2a1d32-3cfe-44a1-a630-245ca34f11dc", "node_type": "4", "metadata": {"page_label": "108", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "Recommended approach:\n\n- Typical Category 5 approach: validation plan; ERU / URS; Project / Functional Specification (can be combined); traceability; documented tests, with pre-defined acceptance criteria; report of validation;\n- Security to limit access to authorized persons only;\n- Change control.\n\n## 14.6.5 Type E - Worksheets for Statistical Analysis - Clinical Study\n\nEvaluation: low impact and high complexity.\n\nRecommended approach:\n\n- Documented verification, carried out by a third person, that the calculations are correct;\n- Change control;\n- Security to ensure that it is protected from unauthorized change;\n- Security to ensure that users can access only approved versions.\n\n## 14.6.6 Type F - Work Area Databases - Traceability of productive materials\n\nExample of using this type of software: layout of printed labels.\n\nEvaluation: medium impact and medium complexity.\n\nRecommended approach:\n\n----\n\nGuide for Computer Systems Validation\nGuide n\u00b0 33/2020 - version 1, of 03/26/2020\n\n----\n\nPage 101\n\n- Typical Category 4 approach: validation plan; ERU / URS; Project / Functional Specification (can be combined); traceability; documented tests, with pre-defined acceptance criteria; report of validation;\n- Security to limit access to authorized persons only;\n- Change control.\n\n## 15 FINAL CONSIDERATIONS\n\nFor systems already installed, the company must decide whether the system can be validated or not.\n\nThe first step to be followed should be the preparation of the ERU / URS document starting from the guidelines described in this Guide, similar to what would be done for the purchase of a new system.\n\nThe next step is the evaluation of this non-validated system using the ERU / URS document to decide\n\n----\n\nhttps://translate.googleusercontent.com/translate_f", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "2ea5e393a78bf12446ffa463200a5594ca04ba137b882d071956fbe9af0de3c0", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "Recommended approach:\n\n- Typical Category 5 approach: validation plan; ERU / URS; Project / Functional Specification (can be combined); traceability; documented tests, with pre-defined acceptance criteria; report of validation;\n- Security to limit access to authorized persons only;\n- Change control.\n\n## 14.6.5 Type E - Worksheets for Statistical Analysis - Clinical Study\n\nEvaluation: low impact and high complexity.\n\nRecommended approach:\n\n- Documented verification, carried out by a third person, that the calculations are correct;\n- Change control;\n- Security to ensure that it is protected from unauthorized change;\n- Security to ensure that users can access only approved versions.\n\n## 14.6.6 Type F - Work Area Databases - Traceability of productive materials\n\nExample of using this type of software: layout of printed labels.\n\nEvaluation: medium impact and medium complexity.\n\nRecommended approach:\n\n----\n\nGuide for Computer Systems Validation\nGuide n\u00b0 33/2020 - version 1, of 03/26/2020\n\n----\n\nPage 101\n\n- Typical Category 4 approach: validation plan; ERU / URS; Project / Functional Specification (can be combined); traceability; documented tests, with pre-defined acceptance criteria; report of validation;\n- Security to limit access to authorized persons only;\n- Change control.\n\n## 15 FINAL CONSIDERATIONS\n\nFor systems already installed, the company must decide whether the system can be validated or not.\n\nThe first step to be followed should be the preparation of the ERU / URS document starting from the guidelines described in this Guide, similar to what would be done for the purchase of a new system.\n\nThe next step is the evaluation of this non-validated system using the ERU / URS document to decide\n\n----\n\nhttps://translate.googleusercontent.com/translate_f", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 1780, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "021847e4-9e19-4eee-9251-03bae2d59890": {"__data__": {"id_": "021847e4-9e19-4eee-9251-03bae2d59890", "embedding": null, "metadata": {"page_label": "109", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 16 GLOSSARY AND ACRONYMS\n\n**Antivirus** - *Software* used to protect computers against malware. It also has the utility to decontaminate a computer that is infected with viruses, worms, and malicious code. These programs need to be updated frequently to ensure their effectiveness. There are corporate antiviruses, which are more complete and effective, depending on the scenario, than the free antivirus.\n\n**Application** - *Software* that makes use of network services such as file transfer, remote login, and mail electronic.\n\n**Backup** - Security routine used for storage, that is, a copy of data or settings, usually on removable media, all or part of the information on hard drives or the network. IS a solution that can be adapted, according to the needs of the company.\n\n**ERP (Enterprise Resource Planning or \u201cEnterprise resource planning\u201d)** - These are *software* that integrate all the data and processes of an organization in a single system. Examples: Protheus, Focco, EMS, SAP, Sige Cloud, Blue Account.\n\n**Firmware** - Set of operating instructions programmed directly into the hardware of a device electronic.\n\n**Hardware** - Generic designation of all types of computer equipment, that is, it is the physical part of the computer. Examples: microcomputer, hard drives, memory, printer, scanner, among others.\n\n**LAN (Local Area Network)** - It is a set of computers that belong to the same organization and which are linked together in a small geographical area by a network, often through the same technology (the most used is Ethernet).\n\n**Login** - Identification (user name) for access to a specific computer or system.\n\n----\n\n**Data log** - It is an expression used to describe the process of recording relevant events in a computational system.\n\n**Malware (Malicious Software or Software Malicious)** - It is software designed to infiltrate a system illegally using someone else's computer in order to cause some damage or theft of information (confidential or not). Computer viruses, worms, trojan horses, and spyware are considered malware.\n\n**MAN** - Company that has several offices in the same city and wants computers remain interconnected. For this there is the (Metropolitan Area Network), or Metropolitan Network, which connects several Local Area Networks within a few dozen kilometers.\n\n**Oracle** - It is a DBMS (Database Management System) written in C language and available in several electronic.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas que se pueden responder espec\u00edficamente con la informaci\u00f3n proporcionada en el contexto, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento es una gu\u00eda de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos, que incluye un glosario de t\u00e9rminos y acr\u00f3nimos relevantes en el \u00e1mbito de la inform\u00e1tica y la gesti\u00f3n de datos. Se definen conceptos clave como antivirus, aplicaciones, backup, ERP, firmware, hardware, LAN, login, data log, malware, MAN y Oracle, proporcionando una base de conocimiento esencial para entender la infraestructura y la seguridad de los sistemas inform\u00e1ticos en un entorno organizacional.\n\n### Preguntas\n1. **\u00bfCu\u00e1l es la diferencia entre un antivirus corporativo y un antivirus gratuito seg\u00fan el documento?**\n   - Respuesta: El documento menciona que los antivirus corporativos son m\u00e1s completos y efectivos, dependiendo del escenario, en comparaci\u00f3n con los antivirus gratuitos.\n\n2. **\u00bfQu\u00e9 tipo de software se considera un ERP y cu\u00e1les son algunos ejemplos mencionados en la gu\u00eda?**\n   - Respuesta: Un ERP (Enterprise Resource Planning) es un software que integra todos los datos y procesos de una organizaci\u00f3n en un solo sistema. Ejemplos mencionados incluyen Protheus, Focco, EMS, SAP, Sige Cloud y Blue Account.\n\n3. **\u00bfQu\u00e9 es un MAN y cu\u00e1l es su prop\u00f3sito seg\u00fan el contexto proporcionado?**\n   - Respuesta: Un MAN (Metropolitan Area Network) es una red que conecta varias Local Area Networks (LAN) dentro de una misma ciudad, permitiendo que las computadoras de diferentes oficinas de una empresa permanezcan interconectadas en un \u00e1rea geogr\u00e1fica relativamente peque\u00f1a.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Gu\u00eda de ANVISA**: El documento se titula \"Gu\u00eda para la Validaci\u00f3n de Sistemas Inform\u00e1ticos\" (Gu\u00eda n\u00b0 33/2020) y proporciona directrices sobre la validaci\u00f3n de sistemas inform\u00e1ticos en el sector salud.\n\n2. **Categor\u00edas de Sistemas**: Los sistemas se clasifican en diferentes categor\u00edas (por ejemplo, Tipo E y Tipo F) seg\u00fan su impacto y complejidad, lo que determina el enfoque de validaci\u00f3n a seguir.\n\n3. **Enfoques Recomendados**:\n   - **Tipo E (Hojas de C\u00e1lculo para An\u00e1lisis Estad\u00edstico)**: Se recomienda una verificaci\u00f3n documentada por un tercero, controles de cambio y medidas de seguridad para proteger contra cambios no autorizados.\n   - **Tipo F (Bases de Datos de \u00c1reas de Trabajo)**: Se sugiere un enfoque t\u00edpico de categor\u00eda 4 que incluye un plan de validaci\u00f3n, especificaciones funcionales, trazabilidad, pruebas documentadas y controles de cambio.\n\n4. **Documentaci\u00f3n Clave**: La preparaci\u00f3n del documento ERU/URS es fundamental para la validaci\u00f3n, tanto para sistemas nuevos como para aquellos ya instalados.\n\n5. **Seguridad y Control de Cambios**: Se enfatiza la importancia de implementar medidas de seguridad para limitar el acceso a personas autorizadas y asegurar que solo se puedan acceder a versiones aprobadas de los sistemas.\n\n6. **Consideraciones Finales**: Para sistemas ya instalados, se debe evaluar si pueden ser validados, comenzando con la preparaci\u00f3n del ERU/URS y la evaluaci\u00f3n del sistema existente.\n\n### Entidades Clave\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil.\n- **ERU/URS**: Documentos de Requisitos de Usuario y Requisitos de Usuario Espec\u00edficos.\n- **Tipos de Sistemas**: Tipo E (Hojas de C\u00e1lculo) y Tipo F (Bases de Datos de \u00c1reas de Trabajo).\n- **Categor\u00edas de Enfoque**: Categor\u00eda 4 y Categor\u00eda 5 para la validaci\u00f3n de sistemas. \n\nEste resumen destaca los aspectos esenciales de la gu\u00eda y proporciona una visi\u00f3n clara de los enfoques recomendados para la validaci\u00f3n de sistemas inform\u00e1ticos en el \u00e1mbito de la salud.", "excerpt_keywords": "Keywords: Antivirus, ERP, Malware, LAN, Oracle"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "4025c2d2-71a9-4a49-98f7-1ab0b1575818", "node_type": "4", "metadata": {"page_label": "109", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 16 GLOSSARY AND ACRONYMS\n\n**Antivirus** - *Software* used to protect computers against malware. It also has the utility to decontaminate a computer that is infected with viruses, worms, and malicious code. These programs need to be updated frequently to ensure their effectiveness. There are corporate antiviruses, which are more complete and effective, depending on the scenario, than the free antivirus.\n\n**Application** - *Software* that makes use of network services such as file transfer, remote login, and mail electronic.\n\n**Backup** - Security routine used for storage, that is, a copy of data or settings, usually on removable media, all or part of the information on hard drives or the network. IS a solution that can be adapted, according to the needs of the company.\n\n**ERP (Enterprise Resource Planning or \u201cEnterprise resource planning\u201d)** - These are *software* that integrate all the data and processes of an organization in a single system. Examples: Protheus, Focco, EMS, SAP, Sige Cloud, Blue Account.\n\n**Firmware** - Set of operating instructions programmed directly into the hardware of a device electronic.\n\n**Hardware** - Generic designation of all types of computer equipment, that is, it is the physical part of the computer. Examples: microcomputer, hard drives, memory, printer, scanner, among others.\n\n**LAN (Local Area Network)** - It is a set of computers that belong to the same organization and which are linked together in a small geographical area by a network, often through the same technology (the most used is Ethernet).\n\n**Login** - Identification (user name) for access to a specific computer or system.\n\n----\n\n**Data log** - It is an expression used to describe the process of recording relevant events in a computational system.\n\n**Malware (Malicious Software or Software Malicious)** - It is software designed to infiltrate a system illegally using someone else's computer in order to cause some damage or theft of information (confidential or not). Computer viruses, worms, trojan horses, and spyware are considered malware.\n\n**MAN** - Company that has several offices in the same city and wants computers remain interconnected. For this there is the (Metropolitan Area Network), or Metropolitan Network, which connects several Local Area Networks within a few dozen kilometers.\n\n**Oracle** - It is a DBMS (Database Management System) written in C language and available in several electronic.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "4b91f20d2fe44aa153db786c9ecc33ecc9f11dad13b36104de387a68a1691d84", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "# 16 GLOSSARY AND ACRONYMS\n\n**Antivirus** - *Software* used to protect computers against malware. It also has the utility to decontaminate a computer that is infected with viruses, worms, and malicious code. These programs need to be updated frequently to ensure their effectiveness. There are corporate antiviruses, which are more complete and effective, depending on the scenario, than the free antivirus.\n\n**Application** - *Software* that makes use of network services such as file transfer, remote login, and mail electronic.\n\n**Backup** - Security routine used for storage, that is, a copy of data or settings, usually on removable media, all or part of the information on hard drives or the network. IS a solution that can be adapted, according to the needs of the company.\n\n**ERP (Enterprise Resource Planning or \u201cEnterprise resource planning\u201d)** - These are *software* that integrate all the data and processes of an organization in a single system. Examples: Protheus, Focco, EMS, SAP, Sige Cloud, Blue Account.\n\n**Firmware** - Set of operating instructions programmed directly into the hardware of a device electronic.\n\n**Hardware** - Generic designation of all types of computer equipment, that is, it is the physical part of the computer. Examples: microcomputer, hard drives, memory, printer, scanner, among others.\n\n**LAN (Local Area Network)** - It is a set of computers that belong to the same organization and which are linked together in a small geographical area by a network, often through the same technology (the most used is Ethernet).\n\n**Login** - Identification (user name) for access to a specific computer or system.\n\n----\n\n**Data log** - It is an expression used to describe the process of recording relevant events in a computational system.\n\n**Malware (Malicious Software or Software Malicious)** - It is software designed to infiltrate a system illegally using someone else's computer in order to cause some damage or theft of information (confidential or not). Computer viruses, worms, trojan horses, and spyware are considered malware.\n\n**MAN** - Company that has several offices in the same city and wants computers remain interconnected. For this there is the (Metropolitan Area Network), or Metropolitan Network, which connects several Local Area Networks within a few dozen kilometers.\n\n**Oracle** - It is a DBMS (Database Management System) written in C language and available in several electronic.", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 2438, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "95862c08-7b54-4591-99cb-83e78f83dc73": {"__data__": {"id_": "95862c08-7b54-4591-99cb-83e78f83dc73", "embedding": null, "metadata": {"page_label": "110", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "Patch 1 - Piece of object code inserted in an executable program as a temporary correction of an error.\n\nPatch 2 - Fix with patch 1. Programming consists of repairing a deficiency in the functionality of a existing routine or program, in general, in response to an unforeseen need or set of operating circumstances. The correction by means of patches is a common way to add a feature or function to a program while the next version of the software is not released.\n\nPDF (Portable Document Format) - It is a file format created by Adobe Systems for any document is viewed, regardless of which program originated it.\n\nRAM (Random Access Memory) - It is the memory available for use by applications and processing. Its volatile content is lost whenever the computer is turned off.\n\nNetwork - Generically a set of connected computers that communicate with each other.\n\nDisaster Recovery (DR) - From English Disaster Recovery. It involves a set of policies and procedures to enable the recovery or continuation of vital technology and systems infrastructure following a natural or man-made disaster.\n\nRedundancy - It is a broad term that represents the duplication of critical components, adding system reliability. In information technology the definition is applied more frequently as the duplication of devices that are used for backup.\n\nServer - It is basically a computer more powerful than the average desktop. It was developed specifically to transmit information and provide software products to other computers that connected to it by a network. Servers have the hardware to manage health wireless network and ethernet cable, usually through a router. They were developed to handle with heavier workloads and more applications, taking advantage of hardware to increase productivity and reduce downtime.\n\nSLA (Service Level Agreement) - Consists of a contract between two parties: the entity that intends to provide the service and the customer that wishes to benefit from it. In it are specified, in detail, all aspects of the type of service that will be provided, as well as the contractual terms, the quality of service and the price to be paid for the work.\n\nSoftware - It is a set of codes developed to perform specific functions, normally for the user.\n\nTemplate - It is a model to be followed, with a predefined structure that facilitates the development and creation of content from something constructed.\n\n----\n\nPage 103\n\nViruses - Denomination given to small programs developed to cause damage at different levels, affecting the integrity of data files (removing parts or files completely), a particular computer or the entire company network.\n\nWAN (Wide Area Network) - It is the type of network that allows the interconnection of local, metropolitan and network equipment in a large geographical area (Example: country, continent, etc.).\n\nWireless - Technology capable of joining electronic terminals, usually computers, to each other due to the waves.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "### Res\u00famenes de Nivel Superior\n\n1. **Definiciones T\u00e9cnicas**: El documento proporciona definiciones clave relacionadas con la validaci\u00f3n de sistemas inform\u00e1ticos, incluyendo t\u00e9rminos como \"patch\", \"RAM\", \"SLA\", y \"viruses\". Estas definiciones son esenciales para entender el contexto de la validaci\u00f3n y gesti\u00f3n de sistemas tecnol\u00f3gicos.\n\n2. **Conceptos de Infraestructura y Seguridad**: Se abordan conceptos relacionados con la infraestructura tecnol\u00f3gica, como \"servidores\", \"redes\", \"redundancia\" y \"recuperaci\u00f3n ante desastres\". Estos conceptos son fundamentales para garantizar la continuidad y seguridad de los sistemas inform\u00e1ticos.\n\n3. **Acuerdos y Contratos**: Se menciona la importancia de los acuerdos de nivel de servicio (SLA) en la relaci\u00f3n entre proveedores de servicios y clientes, destacando la necesidad de especificar claramente los t\u00e9rminos del servicio y la calidad esperada.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfCu\u00e1l es la diferencia entre un \"patch\" y un \"SLA\" en el contexto de la validaci\u00f3n de sistemas inform\u00e1ticos?**\n   - Esta pregunta busca aclarar dos conceptos que, aunque ambos son importantes en la gesti\u00f3n de software y servicios, cumplen funciones muy diferentes.\n\n2. **\u00bfC\u00f3mo se relacionan los conceptos de \"redundancia\" y \"disaster recovery\" en la planificaci\u00f3n de infraestructura tecnol\u00f3gica?**\n   - Esta pregunta indaga sobre la interconexi\u00f3n de dos conceptos que son cr\u00edticos para la resiliencia de los sistemas inform\u00e1ticos, lo que puede no estar expl\u00edcitamente detallado en otros documentos.\n\n3. **\u00bfQu\u00e9 implicaciones tiene la volatilidad de la RAM en la recuperaci\u00f3n de datos tras un desastre?**\n   - Esta pregunta explora c\u00f3mo la naturaleza vol\u00e1til de la RAM puede afectar los procedimientos de recuperaci\u00f3n de datos, un aspecto que podr\u00eda no ser evidente en discusiones m\u00e1s generales sobre recuperaci\u00f3n ante desastres.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\nLa secci\u00f3n proporcionada es un glosario que define t\u00e9rminos y acr\u00f3nimos relevantes en el contexto de la inform\u00e1tica y la gesti\u00f3n de sistemas. A continuaci\u00f3n se presentan los temas clave y las entidades mencionadas:\n\n1. **Antivirus**: Software dise\u00f1ado para proteger computadoras contra malware y para desinfectar sistemas infectados. Se distingue entre antivirus corporativos (m\u00e1s completos y efectivos) y gratuitos.\n\n2. **Aplicaci\u00f3n**: Software que utiliza servicios de red, como transferencia de archivos y correo electr\u00f3nico.\n\n3. **Backup**: Rutina de seguridad que implica hacer copias de datos o configuraciones, adapt\u00e1ndose a las necesidades de la empresa.\n\n4. **ERP (Enterprise Resource Planning)**: Software que integra todos los datos y procesos de una organizaci\u00f3n. Ejemplos incluyen Protheus, Focco, EMS, SAP, Sige Cloud y Blue Account.\n\n5. **Firmware**: Conjunto de instrucciones operativas programadas en el hardware de un dispositivo electr\u00f3nico.\n\n6. **Hardware**: Parte f\u00edsica de los equipos inform\u00e1ticos, que incluye componentes como microcomputadoras, discos duros, impresoras y esc\u00e1neres.\n\n7. **LAN (Local Area Network)**: Red de computadoras dentro de una misma organizaci\u00f3n, conectadas en un \u00e1rea geogr\u00e1fica peque\u00f1a, com\u00fanmente utilizando tecnolog\u00eda Ethernet.\n\n8. **Login**: Identificaci\u00f3n (nombre de usuario) para acceder a un sistema o computadora espec\u00edfica.\n\n9. **Data log**: Proceso de registro de eventos relevantes en un sistema computacional.\n\n10. **Malware**: Software malicioso dise\u00f1ado para infiltrarse en sistemas y causar da\u00f1o o robo de informaci\u00f3n. Incluye virus, gusanos, caballos de Troya y spyware.\n\n11. **MAN (Metropolitan Area Network)**: Red que conecta varias LAN dentro de una misma ciudad, permitiendo la interconexi\u00f3n de computadoras en diferentes oficinas de una empresa.\n\n12. **Oracle**: Sistema de gesti\u00f3n de bases de datos (DBMS) escrito en lenguaje C, disponible en diversas plataformas electr\u00f3nicas.\n\nEste glosario proporciona una base esencial para comprender la infraestructura y la seguridad de los sistemas inform\u00e1ticos en un entorno organizacional, facilitando la validaci\u00f3n y gesti\u00f3n de sistemas conforme a las directrices de ANVISA.", "excerpt_keywords": "Keywords: validation, infrastructure, redundancy, disaster recovery, service level agreement"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "9bfcb04a-2f0b-414c-a4ec-eedf1d567126", "node_type": "4", "metadata": {"page_label": "110", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "Patch 1 - Piece of object code inserted in an executable program as a temporary correction of an error.\n\nPatch 2 - Fix with patch 1. Programming consists of repairing a deficiency in the functionality of a existing routine or program, in general, in response to an unforeseen need or set of operating circumstances. The correction by means of patches is a common way to add a feature or function to a program while the next version of the software is not released.\n\nPDF (Portable Document Format) - It is a file format created by Adobe Systems for any document is viewed, regardless of which program originated it.\n\nRAM (Random Access Memory) - It is the memory available for use by applications and processing. Its volatile content is lost whenever the computer is turned off.\n\nNetwork - Generically a set of connected computers that communicate with each other.\n\nDisaster Recovery (DR) - From English Disaster Recovery. It involves a set of policies and procedures to enable the recovery or continuation of vital technology and systems infrastructure following a natural or man-made disaster.\n\nRedundancy - It is a broad term that represents the duplication of critical components, adding system reliability. In information technology the definition is applied more frequently as the duplication of devices that are used for backup.\n\nServer - It is basically a computer more powerful than the average desktop. It was developed specifically to transmit information and provide software products to other computers that connected to it by a network. Servers have the hardware to manage health wireless network and ethernet cable, usually through a router. They were developed to handle with heavier workloads and more applications, taking advantage of hardware to increase productivity and reduce downtime.\n\nSLA (Service Level Agreement) - Consists of a contract between two parties: the entity that intends to provide the service and the customer that wishes to benefit from it. In it are specified, in detail, all aspects of the type of service that will be provided, as well as the contractual terms, the quality of service and the price to be paid for the work.\n\nSoftware - It is a set of codes developed to perform specific functions, normally for the user.\n\nTemplate - It is a model to be followed, with a predefined structure that facilitates the development and creation of content from something constructed.\n\n----\n\nPage 103\n\nViruses - Denomination given to small programs developed to cause damage at different levels, affecting the integrity of data files (removing parts or files completely), a particular computer or the entire company network.\n\nWAN (Wide Area Network) - It is the type of network that allows the interconnection of local, metropolitan and network equipment in a large geographical area (Example: country, continent, etc.).\n\nWireless - Technology capable of joining electronic terminals, usually computers, to each other due to the waves.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "89695b8c9c2e83b37640ce3fb6ee168201a5038b9c897709a171c7c7c208db5e", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "Patch 1 - Piece of object code inserted in an executable program as a temporary correction of an error.\n\nPatch 2 - Fix with patch 1. Programming consists of repairing a deficiency in the functionality of a existing routine or program, in general, in response to an unforeseen need or set of operating circumstances. The correction by means of patches is a common way to add a feature or function to a program while the next version of the software is not released.\n\nPDF (Portable Document Format) - It is a file format created by Adobe Systems for any document is viewed, regardless of which program originated it.\n\nRAM (Random Access Memory) - It is the memory available for use by applications and processing. Its volatile content is lost whenever the computer is turned off.\n\nNetwork - Generically a set of connected computers that communicate with each other.\n\nDisaster Recovery (DR) - From English Disaster Recovery. It involves a set of policies and procedures to enable the recovery or continuation of vital technology and systems infrastructure following a natural or man-made disaster.\n\nRedundancy - It is a broad term that represents the duplication of critical components, adding system reliability. In information technology the definition is applied more frequently as the duplication of devices that are used for backup.\n\nServer - It is basically a computer more powerful than the average desktop. It was developed specifically to transmit information and provide software products to other computers that connected to it by a network. Servers have the hardware to manage health wireless network and ethernet cable, usually through a router. They were developed to handle with heavier workloads and more applications, taking advantage of hardware to increase productivity and reduce downtime.\n\nSLA (Service Level Agreement) - Consists of a contract between two parties: the entity that intends to provide the service and the customer that wishes to benefit from it. In it are specified, in detail, all aspects of the type of service that will be provided, as well as the contractual terms, the quality of service and the price to be paid for the work.\n\nSoftware - It is a set of codes developed to perform specific functions, normally for the user.\n\nTemplate - It is a model to be followed, with a predefined structure that facilitates the development and creation of content from something constructed.\n\n----\n\nPage 103\n\nViruses - Denomination given to small programs developed to cause damage at different levels, affecting the integrity of data files (removing parts or files completely), a particular computer or the entire company network.\n\nWAN (Wide Area Network) - It is the type of network that allows the interconnection of local, metropolitan and network equipment in a large geographical area (Example: country, continent, etc.).\n\nWireless - Technology capable of joining electronic terminals, usually computers, to each other due to the waves.", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 2968, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "980e5d2c-9cd0-418f-8908-ece75f059086": {"__data__": {"id_": "980e5d2c-9cd0-418f-8908-ece75f059086", "embedding": null, "metadata": {"page_label": "111", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 17 BIBLIOGRAPHIC REFERENCES\n\n## 17.1 REGULATORY\n\n- Resolution - RDC No. 69 of December 8, 2014;\n- Resolution - RDC n\u00ba 301, of August 21, 2019;\n- Normative Instruction - IN n\u00ba 43, of August 21, 2019;\n- Normative Instruction - IN n\u00ba 47, of August 21, 2019.\n\n## 17.2 TECHNIQUES\n\n- GAMP 5 - A Risk-Based Approach to Compliant GxP Computerized Systems.\n- PIC / S Guidance on Good Practices for Computerized Systems in Regulated \u201cGxP\u201d Environments (PI 011-3) - September 2007 (available on the website http://www.picscheme.org).\n- FDA Guidance for Industry Part 11, Electronic Records / Electronic Signatures - Scope and Application (August 2003).\n- Practical Computer Dictionary, Microsoft, 2000.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento \"ANVISA - Guide for Computer Systems Validation 33/2020\" incluye una secci\u00f3n de referencias bibliogr\u00e1ficas que se divide en dos categor\u00edas: regulaciones y t\u00e9cnicas. En la parte regulatoria, se mencionan resoluciones y normativas de la ANVISA que son relevantes para la validaci\u00f3n de sistemas inform\u00e1ticos. En la secci\u00f3n t\u00e9cnica, se citan gu\u00edas y documentos que ofrecen enfoques y pr\u00e1cticas recomendadas para sistemas inform\u00e1ticos en entornos regulados.\n\n### Preguntas\n\n1. **\u00bfCu\u00e1les son las resoluciones espec\u00edficas de la ANVISA que se mencionan en el documento y en qu\u00e9 fechas fueron emitidas?**\n   - Respuesta: Se mencionan las siguientes resoluciones: RDC No. 69 de diciembre 8, 2014; RDC n\u00ba 301 de agosto 21, 2019; Normativa IN n\u00ba 43 de agosto 21, 2019; y Normativa IN n\u00ba 47 de agosto 21, 2019.\n\n2. **\u00bfQu\u00e9 documento se considera una gu\u00eda de referencia para un enfoque basado en riesgos en sistemas inform\u00e1ticos GxP?**\n   - Respuesta: El documento \"GAMP 5 - A Risk-Based Approach to Compliant GxP Computerized Systems\" es la gu\u00eda de referencia mencionada.\n\n3. **\u00bfD\u00f3nde se puede encontrar la gu\u00eda de PIC/S sobre buenas pr\u00e1cticas para sistemas inform\u00e1ticos en entornos regulados?**\n   - Respuesta: La gu\u00eda de PIC/S est\u00e1 disponible en el sitio web http://www.picscheme.org y se titula \"PIC / S Guidance on Good Practices for Computerized Systems in Regulated 'GxP' Environments (PI 011-3) - September 2007\".", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Definiciones T\u00e9cnicas**:\n   - **Patch**: C\u00f3digo objeto insertado temporalmente en un programa para corregir errores.\n   - **PDF**: Formato de archivo creado por Adobe para visualizar documentos independientemente del programa de origen.\n   - **RAM**: Memoria vol\u00e1til utilizada por aplicaciones; su contenido se pierde al apagar el ordenador.\n   - **Red**: Conjunto de computadoras conectadas que se comunican entre s\u00ed.\n   - **Viruses**: Programas da\u00f1inos que afectan la integridad de datos y sistemas.\n   - **WAN**: Red que conecta equipos en grandes \u00e1reas geogr\u00e1ficas.\n\n2. **Conceptos de Infraestructura y Seguridad**:\n   - **Disaster Recovery (DR)**: Pol\u00edticas y procedimientos para la recuperaci\u00f3n de sistemas tras desastres.\n   - **Redundancia**: Duplicaci\u00f3n de componentes cr\u00edticos para aumentar la fiabilidad del sistema.\n   - **Servidor**: Computadora potente dise\u00f1ada para transmitir informaci\u00f3n y gestionar redes.\n   - **Wireless**: Tecnolog\u00eda que conecta dispositivos electr\u00f3nicos a trav\u00e9s de ondas.\n\n3. **Acuerdos y Contratos**:\n   - **SLA (Service Level Agreement)**: Contrato que detalla los t\u00e9rminos del servicio entre proveedor y cliente, incluyendo calidad y precio.\n\n4. **Software y Plantillas**:\n   - **Software**: Conjunto de c\u00f3digos para realizar funciones espec\u00edficas.\n   - **Template**: Modelo con estructura predefinida para facilitar la creaci\u00f3n de contenido.\n\n### Entidades Clave:\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria en Brasil, responsable de la regulaci\u00f3n de sistemas inform\u00e1ticos en el \u00e1mbito de la salud.\n- **Adobe Systems**: Empresa creadora del formato PDF.\n- **Tecnolog\u00edas de Red**: Incluyen conceptos como WAN y Wireless, esenciales para la conectividad y comunicaci\u00f3n entre sistemas. \n\nEste resumen proporciona una visi\u00f3n general de los conceptos fundamentales relacionados con la validaci\u00f3n de sistemas inform\u00e1ticos, infraestructura tecnol\u00f3gica y acuerdos de servicio, esenciales para la gesti\u00f3n y seguridad de sistemas en el contexto de ANVISA.", "excerpt_keywords": "Keywords: ANVISA, Computer Systems Validation, GxP, Regulatory References, Risk-Based Approach"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "710408db-79f7-4007-bbd2-be01377ddb72", "node_type": "4", "metadata": {"page_label": "111", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 17 BIBLIOGRAPHIC REFERENCES\n\n## 17.1 REGULATORY\n\n- Resolution - RDC No. 69 of December 8, 2014;\n- Resolution - RDC n\u00ba 301, of August 21, 2019;\n- Normative Instruction - IN n\u00ba 43, of August 21, 2019;\n- Normative Instruction - IN n\u00ba 47, of August 21, 2019.\n\n## 17.2 TECHNIQUES\n\n- GAMP 5 - A Risk-Based Approach to Compliant GxP Computerized Systems.\n- PIC / S Guidance on Good Practices for Computerized Systems in Regulated \u201cGxP\u201d Environments (PI 011-3) - September 2007 (available on the website http://www.picscheme.org).\n- FDA Guidance for Industry Part 11, Electronic Records / Electronic Signatures - Scope and Application (August 2003).\n- Practical Computer Dictionary, Microsoft, 2000.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "1e83262f11395847896bb8f467a6b62ca2bf44dfedb8e1a5f23e0afd9740e140", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "# 17 BIBLIOGRAPHIC REFERENCES\n\n## 17.1 REGULATORY\n\n- Resolution - RDC No. 69 of December 8, 2014;\n- Resolution - RDC n\u00ba 301, of August 21, 2019;\n- Normative Instruction - IN n\u00ba 43, of August 21, 2019;\n- Normative Instruction - IN n\u00ba 47, of August 21, 2019.\n\n## 17.2 TECHNIQUES\n\n- GAMP 5 - A Risk-Based Approach to Compliant GxP Computerized Systems.\n- PIC / S Guidance on Good Practices for Computerized Systems in Regulated \u201cGxP\u201d Environments (PI 011-3) - September 2007 (available on the website http://www.picscheme.org).\n- FDA Guidance for Industry Part 11, Electronic Records / Electronic Signatures - Scope and Application (August 2003).\n- Practical Computer Dictionary, Microsoft, 2000.", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 693, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}, "b6b3eae9-1e38-47d6-98f0-e15580b1878e": {"__data__": {"id_": "b6b3eae9-1e38-47d6-98f0-e15580b1878e", "embedding": null, "metadata": {"page_label": "112", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "NO_CONTENT_HERE", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas que podr\u00edan derivarse del contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior:\nEl documento titulado \"ANVISA - Guide for Computer Systems Validation 33/2020\" es una gu\u00eda emitida por la Agencia Nacional de Vigilancia Sanitaria (ANVISA) de Brasil, que aborda los requisitos y procedimientos para la validaci\u00f3n de sistemas inform\u00e1ticos en el \u00e1mbito de la salud. Este tipo de validaci\u00f3n es crucial para garantizar que los sistemas utilizados en la industria farmac\u00e9utica y de salud cumplan con las normativas y est\u00e1ndares de calidad necesarios para asegurar la seguridad y eficacia de los productos y servicios.\n\n### Preguntas:\n1. **\u00bfCu\u00e1les son los principales requisitos establecidos por ANVISA para la validaci\u00f3n de sistemas inform\u00e1ticos en el sector salud seg\u00fan la gu\u00eda 33/2020?**\n   - Esta pregunta busca informaci\u00f3n espec\u00edfica sobre los requisitos normativos que deben cumplirse, que probablemente no se encuentre en otras fuentes.\n\n2. **\u00bfQu\u00e9 metodolog\u00edas de validaci\u00f3n se recomiendan en la gu\u00eda de ANVISA para asegurar la integridad y confiabilidad de los sistemas inform\u00e1ticos?**\n   - Esta pregunta se enfoca en las metodolog\u00edas espec\u00edficas que ANVISA sugiere, lo cual puede no estar ampliamente documentado en otros lugares.\n\n3. **\u00bfC\u00f3mo se debe documentar el proceso de validaci\u00f3n de sistemas inform\u00e1ticos seg\u00fan las directrices de ANVISA en el documento 33/2020?**\n   - Esta pregunta busca detalles sobre la documentaci\u00f3n requerida durante el proceso de validaci\u00f3n, un aspecto cr\u00edtico que puede no estar claramente definido en otras gu\u00edas o documentos.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\nLa secci\u00f3n 17 del documento \"ANVISA - Guide for Computer Systems Validation 33/2020\" se centra en las referencias bibliogr\u00e1ficas relevantes para la validaci\u00f3n de sistemas inform\u00e1ticos, organizadas en dos categor\u00edas principales: regulaciones y t\u00e9cnicas.\n\n#### Temas Clave:\n\n1. **Regulaciones**:\n   - Se mencionan varias resoluciones y normativas de la ANVISA que son fundamentales para la validaci\u00f3n de sistemas inform\u00e1ticos en entornos regulados.\n   - Las fechas de emisi\u00f3n de estas regulaciones son importantes para entender su contexto y aplicabilidad.\n\n2. **T\u00e9cnicas**:\n   - Se citan gu\u00edas y documentos que ofrecen enfoques y pr\u00e1cticas recomendadas para la gesti\u00f3n de sistemas inform\u00e1ticos en entornos GxP (buenas pr\u00e1cticas de fabricaci\u00f3n).\n   - Se destaca la importancia de un enfoque basado en riesgos y se proporcionan recursos adicionales para la implementaci\u00f3n de buenas pr\u00e1cticas.\n\n#### Entidades:\n\n- **Regulaciones de ANVISA**:\n  - RDC No. 69 (2014)\n  - RDC n\u00ba 301 (2019)\n  - IN n\u00ba 43 (2019)\n  - IN n\u00ba 47 (2019)\n\n- **Documentos T\u00e9cnicos**:\n  - GAMP 5\n  - PIC/S Guidance (PI 011-3)\n  - FDA Guidance for Industry Part 11\n  - Practical Computer Dictionary (Microsoft, 2000)\n\nEste resumen proporciona una visi\u00f3n general de las referencias clave que gu\u00edan la validaci\u00f3n de sistemas inform\u00e1ticos en el contexto regulatorio brasile\u00f1o.", "excerpt_keywords": "Keywords: ANVISA, validaci\u00f3n, sistemas inform\u00e1ticos, regulaciones, buenas pr\u00e1cticas"}, "excluded_embed_metadata_keys": [], "excluded_llm_metadata_keys": [], "relationships": {"1": {"node_id": "06174fe5-fa05-4b66-bbe0-409cf6f1e649", "node_type": "4", "metadata": {"page_label": "112", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "NO_CONTENT_HERE", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020"}, "hash": "f738d25792e5f3393074331138558500abe508c028acc754ac28da12a081b660", "class_name": "RelatedNodeInfo"}}, "metadata_template": "{key}: {value}", "metadata_separator": "\n", "text": "NO_CONTENT_HERE", "mimetype": "text/plain", "start_char_idx": 0, "end_char_idx": 15, "metadata_seperator": "\n", "text_template": "[Excerpt from document]\n{metadata_str}\nExcerpt:\n-----\n{content}\n-----\n", "class_name": "TextNode"}, "__type__": "1"}}, "docstore/metadata": {"cc53f633-1a8e-42df-93bc-982da454d32d": {"doc_hash": "83654882f786a098d2f079acb1be26b3b4b06de675c10b995b18fd5f359d42ab", "ref_doc_id": "ec2746c9-df75-4485-88c9-b0ad698a0979"}, "12d10f50-b772-4758-985f-10aa807d40e3": {"doc_hash": "38eae70141db26588485277d18c40e9af6af3c421db9217ff91c3abb292e8db2", "ref_doc_id": "a9bd1347-1d55-4117-ad94-1570a52c7caa"}, "adba163d-3a2c-4ab6-b0d2-9fc1cdcd94bf": {"doc_hash": "0467531984287cfd3d800c8ca4a9e6322d7a40e30eea77bb91deb1f6f78b90cb", "ref_doc_id": "3f08a92e-1331-4339-957a-a549ee49a71c"}, "d0fb92e5-8538-445f-9d90-f23ea47246ab": {"doc_hash": "4bca2133e62cab2d7a18bb4a2f4ba1020744d8844edfb5047300d4db2595a26b", "ref_doc_id": "a76cf395-5ffe-422f-8188-30d4bcb04aed"}, "60edc40c-35bd-4e67-81b5-91322b4abecc": {"doc_hash": "e058be9b6071d15c8cac5bcda6e882e33224a1e646a67fa6ef980494682266e8", "ref_doc_id": "4c4570df-4b29-448d-9673-43faf57b3599"}, "743311df-d416-4c46-8dff-cd20882b4af8": {"doc_hash": "bc90182ada855bb3389252dbebe083981d987490790f2eb88731590edd840217", "ref_doc_id": "246485af-178d-4954-9b40-2e6dc0edcb69"}, "528151a7-bf41-4bf6-8b4f-3f78a5f03d6b": {"doc_hash": "b114cfa7bc320a0711fb326ddf9206ed2c29c228ec1cea492a87e8c59cc34d59", "ref_doc_id": "5617ce46-ab7d-4bb6-9091-e9bfdc17a96b"}, "301dbbb2-75d9-462c-aaf8-b96445f3aa43": {"doc_hash": "32165d0d46d896d2c161b778a64f614f7e8ccf59a105233f461da70db1a7dea7", "ref_doc_id": "469f6b51-7c6b-4827-804a-e5b763865f1b"}, "da5c0c36-aff5-4886-a7bd-edd89d4792a7": {"doc_hash": "3a4dade4e8942e1f2f67573b84ac83c89f8f2bc30ab4b6b7abdcf5cd3ca2055c", "ref_doc_id": "d1ce5258-0704-4fd1-9da3-cf2354ae25d6"}, "25b3af9f-ac91-443c-92e6-3f2f02b79c98": {"doc_hash": "80d9a8bd01dba0c6cc24129a1795d9b1621846c73751d2eab571c6d806608b0f", "ref_doc_id": "94f75d3e-f2eb-4b11-a89a-0f04baee7d73"}, "c8676a15-2747-415c-9e97-fa49a6267697": {"doc_hash": "3b98ad1a51419f213b01e1856169cc81683769f7168491239c342fa46bcdf79b", "ref_doc_id": "dbf54242-7f90-49bf-a42a-72d7f92b5c5b"}, "84a23a5f-9d44-43f0-8cb1-bd700b02eaae": {"doc_hash": "2ba44975e5e9c5fac0bdf78b851d99eacf201fba99d16f98972e5a163a39b399", "ref_doc_id": "1235ada1-552c-4c0b-bb7f-bbd6d854393c"}, "0ed97d4b-d4d7-4fb3-a169-8946a117ebbf": {"doc_hash": "4a8358b5065df5c21f8a60c53e98b6095a14de4c33aeabbe6ee32d42d864e8b4", "ref_doc_id": "e7b278b6-e0af-45d1-a230-c28eb69e443f"}, "d1711c4a-a00f-4a42-b5ec-3ca221788f30": {"doc_hash": "574841cdb7b9690252208333bd48b840ee5198f57f057e05d76d6e86f1515218", "ref_doc_id": "5d32fec2-7ef7-429b-9904-0bc2d4d9daef"}, "4f11fb41-89c6-48ef-8841-01b6f2d72544": {"doc_hash": "4f9c6ffb68e47b54b5e2ba38c2cfe7fbac71435f5f14fb0cbf39fef981c62478", "ref_doc_id": "8ab28ffd-7b16-434d-b047-d1a558e705db"}, "9d7f17e3-ce33-48e0-8a01-9ccf3c5c291f": {"doc_hash": "4a1c84c36043881d9484412ecedc9ca3cf5d3ee81698cfbb5b7518a86cfaf942", "ref_doc_id": "5a11b3f2-3c48-4c12-a4f1-a005f6dcc9b7"}, "1cef5e62-ef32-44a4-8cc0-fdf95becdca7": {"doc_hash": "29173f88fb6b0f644a2077bbf7af6246a10e7afaba6c33686729922ddc9a2621", "ref_doc_id": "b647fc95-5d2f-4a34-bbbd-cc7bb64d1536"}, "00e0e258-c7b5-4d48-af42-0241fff302c4": {"doc_hash": "38698a2bb612dd6ca3d4622c459370cb16917472a108de1774ec9c0123683fe5", "ref_doc_id": "0f629c74-6df3-43ab-9eb1-75dc782d9d21"}, "cc109235-45cb-4ae1-9679-0e8c67978f37": {"doc_hash": "720e4a20484c7cf1fb8664b0fb86de5281154092dca9a2093c221e05f7367d8d", "ref_doc_id": "877a7c4c-cb00-4bf3-892c-bdd6e1392f0c"}, "fcdc40a9-53f9-4e24-a5a0-d9d9eb5c8ea2": {"doc_hash": "63f69f856edcaf2217306001bc344e6a52ca65658adfb1fbe7aa13a5ac37f654", "ref_doc_id": "6f2de107-1150-4718-92c1-9375d716b98c"}, "e1fcca3b-7aa9-43b8-9eca-6024c171017c": {"doc_hash": "91b166ee7264c40783be9cbaba464bc708fbe725e6cfe39ea3c0538331988237", "ref_doc_id": "76e8b089-1a40-4e02-94f9-011528c911a5"}, "fc5a006b-3c37-4cd9-b03b-88f0909e63fa": {"doc_hash": "8664cc3cad9a86a54c023fd196cfb3989923b66fb3f7cbc8e4bf3042515838fa", "ref_doc_id": "5435101f-974e-4cfb-952e-1c37b395f2ed"}, "5e04fbf7-bb13-4899-8553-d09dfb47369c": {"doc_hash": "83ac203e7d12b639cc065d4cb3d105e07d06680874c9e3b353336340eba7ec5c", "ref_doc_id": "6de85024-463c-476c-9bdc-fb2066a7c0ac"}, "64ba19f4-b70a-44f6-ab1f-53ac04faa227": {"doc_hash": "02b797b176b0f194459d91d14f2360846bfa603044ff55daf5e4bff55ccc4e61", "ref_doc_id": "66c91d9d-ac86-4430-8fa3-d94b775b57ea"}, "02820a20-016d-417c-b944-ab6ded78ddcc": {"doc_hash": "1b1902f5e81983b3d2c4dfc1ac371da43a4dd91cc6e004f10598133d4c44868e", "ref_doc_id": "49d7f001-25fa-4f15-8fb5-a3b7cd17f6ef"}, "3cf3da5a-c30c-4361-9275-af504462ca0e": {"doc_hash": "e27f1db7e35c2fef4ebe1af2e43fb86b6cdf51b22d3f53291e1da9f4a9923d3d", "ref_doc_id": "b45b42aa-5a09-45d7-96c2-b3d71f97e566"}, "45f476a3-b9dc-4651-b69f-a838f188c788": {"doc_hash": "e6888bbaaec8cb3294d1a320cabc8a711fc522fbd2a6673ed7a26dd0fbdb0a9a", "ref_doc_id": "b06664d2-716f-4168-8e50-e517dc380321"}, "ce8294e8-23e5-41b3-ba42-4cb5c9672a7e": {"doc_hash": "c03b339475f6ea85c322440894d01df312abef05e40412dd4a9a8aadb1bd6587", "ref_doc_id": "f582481a-ebdc-4a01-bb07-47b6e4aea29f"}, "aee154af-6447-48ca-9b55-47fc6442b3d3": {"doc_hash": "b9afb4f046b62bf14c781da200993249d38ddf26b92d8e0bbe6d9db97f5a7780", "ref_doc_id": "e6359bf0-11b9-42e5-9008-8bd9933a81a9"}, "7251ee91-e46f-4db2-8a48-a07e76aaa196": {"doc_hash": "a81106c2e6dd3f8877217edbc4a6e992d2ec0a56a25dc93357bfd2bc75b1f54a", "ref_doc_id": "173bccdd-a95d-433a-b7ba-46be0d9f78db"}, "05d76d05-cf6a-4b68-a9f9-ea6f174fd999": {"doc_hash": "00519bdc3427e32159b68690faff7ce7e3634c0e4c8c3a33f4ad056a6873c037", "ref_doc_id": "ee4fc947-9c1b-4654-bdab-6aab89b63f14"}, "ab407e80-d9c0-4b55-8dd4-29c7589d232b": {"doc_hash": "9cf81e29cf442d9f1c8baa61e440522ed541df4e593a5ceffbf31f3af0c96ddf", "ref_doc_id": "1eede705-799b-4f4e-a048-745494508601"}, "583850af-1bd9-43e7-a376-d7319e2f881f": {"doc_hash": "c503ed3891443596782956b77c09b18c9d2e1b65fe85fa9f5473f12ffab1f9f2", "ref_doc_id": "4364c695-55ac-4c09-b882-33be2ff148d2"}, "9a12ea6b-8f72-4c28-8816-5cfe5ea15130": {"doc_hash": "4a9deb33fe7f3e32c0088f5c01c53e929f32afaeb0c8f51603b42b823cd9260f", "ref_doc_id": "cdd7265a-089b-42c9-84ac-beecc831b31d"}, "cb0ffbae-5b26-4d72-b4bd-9ffc30bf7b3b": {"doc_hash": "f7eef1649f1e844d87afb1bbcb5518a1edc5b41193bfe7486cf9f91d47293427", "ref_doc_id": "850ab2bb-012a-42bc-bd46-6470cc141e7a"}, "b87f51bd-ff00-4117-a5e2-6448238b02bf": {"doc_hash": "30d38eb19ea2527ebad58b983c5a84fb08d24ea38e75f0be5c37dc37ba4b322f", "ref_doc_id": "52a74506-6878-42c0-a05a-69933984d353"}, "9fc8611f-c591-4572-84a6-ebbff9015309": {"doc_hash": "813ee85a547a7e4705e67a5c9af1a0d2d76770bdfbd10446e663c971b0d7951a", "ref_doc_id": "4e9099ba-e104-4ef4-88d0-dc186687db1b"}, "b8506d63-27cf-4e6a-a53c-c38f26d487f8": {"doc_hash": "175cd699360d5ebcc1e775624fc5ddb1c1f77912528c9ae7d5c0f06903b2efc4", "ref_doc_id": "13589dfe-4b52-4471-b972-2f62d3f7780a"}, "0d196aa7-c82a-4523-be73-ad088e908b69": {"doc_hash": "4db020519705797ae683a044208541d9a443841821c9a6990af977a9ca4f6bd6", "ref_doc_id": "d049c578-fc0a-4eec-ba62-7eba5d500b10"}, "04a50fa5-2627-4899-b511-ad46b2091cec": {"doc_hash": "9ce627d11ed808ec4e19fda5ba236932321259bcafc82cf45d981c2c65059610", "ref_doc_id": "8634242a-1aa1-4dc4-b36c-aad86e2326a5"}, "7f7fad55-48c4-4bba-9877-36a7b76d2480": {"doc_hash": "a7ca8e1c91959a9746777836c608b7c96c45af3981f9a24f87b029d6eba331a6", "ref_doc_id": "f5116f2a-d1a9-4264-9ea9-400fa804bd27"}, "411fe2d7-de39-4de5-b410-8a60bcc09248": {"doc_hash": "c9b55a162a5feef38f1d04e3a79c66d4226464703d79f4732b5d4929fc293ba1", "ref_doc_id": "0c6daacb-2fad-43c6-9b94-40496aec89da"}, "0fe90363-d79f-44b6-bf0d-46b9efaa7794": {"doc_hash": "5cf2a25628845d87f203831f1c36635fe4a513e141a6cb31dfbde6bdc00b366d", "ref_doc_id": "172fc6d8-cd1a-4723-ad44-b082b5837f92"}, "f56798e3-7d61-4ed0-8ec4-5c050fd9f440": {"doc_hash": "b492b85f72e0b89459fdabde758f9c6103241fea25c2fdf8308460d5615e4df4", "ref_doc_id": "2be94c47-30fd-4311-937b-2227a8d6e06f"}, "e67d1aa3-cf60-4b55-83f7-2a71e02dc2dc": {"doc_hash": "fc725a014b01a8c1b8637348d4a00ca23fec1e9af8c68319e6f64f401f66dc5b", "ref_doc_id": "6985d1eb-6ef0-41dc-91a0-a1b91c1be8cf"}, "7b4a6013-aee5-4027-aacd-ed113f9dc1df": {"doc_hash": "d01ad55ed32bd9f7c5bd67cb43927e0ad8b4d0e26121aa52650cb00f7f564327", "ref_doc_id": "c8573085-049f-4f3c-8628-6902ca8dc188"}, "f14eb3ea-a08c-4175-9c15-09bbd1610b5d": {"doc_hash": "104b0b2c46bd11336c1a626178f951b69c4393b3316aea44310c00ac21145968", "ref_doc_id": "b603c7f1-0d4d-490a-8ef6-6fd3e8e3b8fb"}, "2c4bc896-70b7-40a2-8fb4-c51363ebebbd": {"doc_hash": "6257d560226805bb5e1e85e35240df15618784484e11f0dab90d1411e03eda0a", "ref_doc_id": "afad6838-9e2b-4d9d-a713-7a39b0e64bb4"}, "62d167be-3328-49ef-a411-cc7d810784d9": {"doc_hash": "6c57b7a3fa2ec45e402c62c59145a4538aa1fd8786a20992fc629444e5ab659b", "ref_doc_id": "060263e9-c831-41cd-81ef-1f5bc32356a7"}, "08884b1a-dd94-4fcb-87e9-bb37bbee213f": {"doc_hash": "ca76046786cfb8cc33fd47ebb5231be7457816c6433b0d7c02116bf58a5318e1", "ref_doc_id": "cec2f0ca-65ca-434a-b41c-d23642da723e"}, "1df903e2-7973-4824-a948-3ef861d97f52": {"doc_hash": "a563ec214a67fc465a3b45fcb2c9a557c316a9ce1fe44a4a51b72711da96e7f4", "ref_doc_id": "1c54d830-e6ca-4bbb-beaf-cfc2ec0f71b7"}, "12317370-c0fe-4965-a79e-3e14ea4656c2": {"doc_hash": "0140fc5b561bc77dc2effd78b630f9fa3999cebf66b4a837682054651a8b40b9", "ref_doc_id": "f180220c-af47-4d63-b9a2-c94e0f93c150"}, "da55b95f-68a7-4b81-bb5a-a1c22c7b4318": {"doc_hash": "5b5e00dda8e6e95f8cb01bc65ff325808d1ab4a5ef6651b74925c2a9d56f874e", "ref_doc_id": "0e5a5b83-4c39-45ed-a018-143cfa8d9c89"}, "f4e36642-eb32-4bb2-b93e-65aa3fbdf0f9": {"doc_hash": "12c711015960f0263ee729a193e86c2fc9d864174c36261de3ca498f0a2d241a", "ref_doc_id": "9cf4ba71-d35f-43f9-aec0-5645c4c8b8b2"}, "3bf391c2-cf68-4bbc-afc4-73188a85c64a": {"doc_hash": "e59af31e1ae98a3e90556fde3ac4e1122ddcf1081888f647ae375e8c28a61229", "ref_doc_id": "28faf88e-7303-49c9-9516-7da7a1273085"}, "fcc219dd-636a-4d0b-91f2-991df927a3d3": {"doc_hash": "f661099c5d644f36e4d57c7d9c1039f9a553c2b81a7c47106cc1be2398561e20", "ref_doc_id": "4507c7cc-82d3-46d4-ab98-219da0bad8a9"}, "c3b3ebc5-bceb-47af-84ff-c25f6959c958": {"doc_hash": "e5ef351e802a524feaf1edbdfc33058c5e345f4ca799799ece55d86a72b79ba9", "ref_doc_id": "72821ccf-6662-475b-82db-f8b108bdd182"}, "df98e9a8-f727-4c83-9093-87e3f855b23e": {"doc_hash": "c28187ba00cd192dd06d486db9c63f45e674c85ccffaaa77a747ce8d43f9596f", "ref_doc_id": "2b801409-2af4-46dc-9dce-d78d0eb2d3b7"}, "0b0e083f-c19a-4c70-83ca-95b9ce9f4c7d": {"doc_hash": "f0e1eb322e1812cd78c49c28dee0b9772b934874f7b9f48f5d381dd7f54d7c02", "ref_doc_id": "b4014e3b-c980-4a13-accb-cfe14b4ac16e"}, "d5ede07b-fd19-4ec4-b750-b1139c2bf665": {"doc_hash": "1a000a2400b32b30ceb7153ca7654c67733e36a8f787b45311d86ffe50aefd6b", "ref_doc_id": "2e8ba283-1d95-4faa-ac5f-ed1096860f77"}, "089d5a2e-c302-430d-b7ea-a78a03b66994": {"doc_hash": "362e93050481400e3fd1c795fd64dadad800ef0307be44b772187aaafcbdee9d", "ref_doc_id": "3cdf8fcf-2031-486b-b62f-ccea0c169673"}, "bef21dec-6bab-4dae-93a1-1eeebec9f706": {"doc_hash": "bafac24c85c922bda0fc13afdf6f1c99cb95e484aa3baae1201c5c4d673068ca", "ref_doc_id": "5e8d9b11-53e2-4e2b-878b-6bf424bf98da"}, "4cdb5f35-36f8-4bf1-86ed-8c4c4244da9f": {"doc_hash": "092e0edf58ecc4119f1ecca67e61635c044b23453ab56a190549380f239dc50d", "ref_doc_id": "cde9d584-3ead-480f-9958-8d1ab94189de"}, "82e2cd1a-7363-451b-87ef-6d62ff681e10": {"doc_hash": "fa88e8769525896fd5f0dc3e79179e75f11c838e4bd1bae8aa011804c4592b19", "ref_doc_id": "bd3d8e62-05ce-492b-9ca6-df5e7f6ba34a"}, "cb8b5958-df63-4c4e-b8cc-5740f607474b": {"doc_hash": "9a2fdf5e7db4e4c601321b05dc0e05143174c0addcc32b54a5d2c2ce7934e7b6", "ref_doc_id": "82e0a5f5-c0c5-40f8-bf7a-8087c49d713f"}, "f056e0a6-30d6-4501-9f61-5ee7bb05c9f4": {"doc_hash": "aa840b0d131af4b7c081e29044a462781029c9df8d82814312a3a7f5874ff2d1", "ref_doc_id": "01f24c7d-c222-482c-b65d-76cdf7b38555"}, "ce9faee6-937c-4f6c-817e-a14f4a1cfa9d": {"doc_hash": "6d778414e5246e04546c9c8b8feb0c19365c03f47b4b51ceb70b16ea0d918fe3", "ref_doc_id": "b9331827-a872-41b0-9d25-cb87dbb5570c"}, "69ed7cb5-c79a-4cae-843d-85114f0db572": {"doc_hash": "1362fd4568b72bcf752edf90d14e8c2ab7091e8b5ac15a3909ee3ec58ac561a2", "ref_doc_id": "66204439-cfae-441a-bd32-67eb98c3eb93"}, "238b9f03-05bb-4db8-a2e5-c6a0d548f413": {"doc_hash": "7db13c69fc43b562ed0f3ed94a33010e684c67920c43442334ed3266ffde98c1", "ref_doc_id": "7cfc95ef-0d04-4e28-b51e-9bf255e21649"}, "2eed0715-580b-4181-a143-00769b3b5d95": {"doc_hash": "07dcb9ecce78780e828d8d5861930b1e6f3e221acad3f6fc122a75dbe0d00210", "ref_doc_id": "6b0aca27-3ab2-41f1-8fe6-2b87e39665db"}, "47e1db0f-5738-4dc3-82fe-5f9ae6ab018e": {"doc_hash": "1ee3a89ceca9a067eaaaa773f2307489d07de7e27c8e426bc4ea7417bf83e881", "ref_doc_id": "2719f7a0-e9c3-45cc-a0ef-7b3641bc0817"}, "f1e96510-941a-4a2f-a052-606433f5934d": {"doc_hash": "8e4f00e9bd5727b8219633ada1e8bfea6c8286af54de9ca8b0a942ee2d008e9e", "ref_doc_id": "33db9069-74e5-4a9d-9e86-a34c6a3907e4"}, "aac2e433-6caf-453d-956e-4ae63fd9e42a": {"doc_hash": "2e5a4137e7b3395b2111beaee7bee6543054f747f04bc7078850c5dff8eda620", "ref_doc_id": "6c2cad81-9f81-4b21-bfa2-f869f258d9c9"}, "702231ac-75ce-4e3c-8ae9-03028151ef2e": {"doc_hash": "e46b88788adde1987a95fe3542199f1f184dc23927ffa7e867f739e1c1fb6337", "ref_doc_id": "385c48b4-1acd-4629-a46a-25fac43ae31f"}, "95d39973-156c-4ab7-a7e4-1ee24e7c4886": {"doc_hash": "3f2b9e504cd9d47addf6f80e3e522de6dbc065ff90632685d7e851385da65d0d", "ref_doc_id": "f37402a7-6e7b-4fa7-914c-62435d55e6c9"}, "0f8e54b1-bae0-416a-9f5b-5424a1e2a12e": {"doc_hash": "2e8679746fdb5d6b2e1eea1543dbc5174c534e38ae95d8225087d1328b0c41a7", "ref_doc_id": "d83e698a-0fdd-43fc-a101-995d50708ee4"}, "743d43df-8b23-430c-89bd-25db18e1189a": {"doc_hash": "e32301b89c1d9aa5fb3e8fe41956d99ad727a5b31f51babfab1f8fe3a39b52ca", "ref_doc_id": "1e70b5d9-7d70-4c51-9aab-9f5a1d0efba0"}, "0b328365-eae4-4433-aa33-12a9aeba4033": {"doc_hash": "cd5ee13460711e749cb6e31771814e2ce4d8e93583f19279b780d0e980cabaa6", "ref_doc_id": "83e36738-a729-4179-b711-b38e7d1e0ee3"}, "af2d3fdd-876b-413e-bfb6-24a924d0f838": {"doc_hash": "043d02da573a93fffb7d994687ab2a01aa52b915198f95f1483ae1101f168bf3", "ref_doc_id": "0ebd4c0c-1965-4833-bef9-675cef79d75d"}, "fbdeb945-9a6b-4165-a800-7c6a7438a549": {"doc_hash": "57008eeecb1226052ae4382a8c3cd37c326f73d062ebe781f328e56665208aea", "ref_doc_id": "7db8007e-74a7-40d3-93b4-1227fc12fc60"}, "c716a4f7-919b-4f96-b072-04b27b74bd14": {"doc_hash": "b897f365e62b18db55f1c7e664adf7a51839a225d481300979941acf16fc963c", "ref_doc_id": "3dc021b5-fabf-4e32-8fe0-abeeb3fce5ef"}, "519bc754-1312-4f67-830e-516f302b7c80": {"doc_hash": "0be3725e4d011e9e2b556e77893fdb6735feba255d83ddce24a03f05502af066", "ref_doc_id": "812a04f9-69bf-4f1b-91c1-bf1e942e3394"}, "8c01c01b-3a92-41b6-9eb8-869049a840c9": {"doc_hash": "2dd3bc07aa70417f9a5f9111d34c1297416ec8db2bea275374e3478aad01f8df", "ref_doc_id": "63a2000e-1fd5-4a74-860f-59a3fe0b7e91"}, "67088541-d093-471b-a8a6-a237b7cc7f6b": {"doc_hash": "3fe5c23ed53a6a8c0a6dad0d19b703b80fcded5349430dcd48da11bc4ac31c94", "ref_doc_id": "1ec71e0f-34db-4e11-8e7b-07dd594810ec"}, "7c20cbe8-9dd8-4c83-91c5-3ec8e51aa9f9": {"doc_hash": "229a8ad91d5ae4e0d38ff64837ca618c8974f81ed5f9fc77f910f9c4b7d37f3e", "ref_doc_id": "46739c31-4f45-4c47-ad64-8f751f42fa94"}, "d39c41e3-0a18-4cb7-901a-d83078ba53c8": {"doc_hash": "a81c45ffe4dfa32a73b4c95aa2247cceb9ad88bb995dbe86a5fef218eb069d03", "ref_doc_id": "ff54a2c8-ba1e-4a51-a97c-fb26576f326b"}, "2116a15e-3afe-4c29-b1a4-3cdc56847cd6": {"doc_hash": "b354e1715b4631f14aa9ad7f241a83410f1d14862c9e1544a09ff573706b473a", "ref_doc_id": "8aa247cd-101d-437e-ad40-679a3d96127b"}, "10444ab2-5ff5-4d2f-ad76-9aaf8c736c8e": {"doc_hash": "a9c396ee440af1151a41e06a05779d815c7f73a63a3010fb60307aed0a415b0f", "ref_doc_id": "3c7a0786-30de-476b-8c7f-c875d20ca060"}, "b9da006e-fca6-4aa1-9009-0406ebb55197": {"doc_hash": "6689f2e6fd26393fee640a13ac16d18ff1ee8e970c47daa275d5edab49b2ecc2", "ref_doc_id": "cd043f06-2b14-49aa-843f-77b0b1b5ad5b"}, "1d67c12a-2ae6-45e9-8bff-e9e88c669d41": {"doc_hash": "8db3c995dde629130b9add50e6a39080cc3e2350d17755051e79bfa8bfc21f35", "ref_doc_id": "05b33809-a719-4040-bc9f-ff84b5ed5bc7"}, "a8a75fc7-7f9a-4db4-b6c3-675448b4a18c": {"doc_hash": "37cfbc71706fff07ce4f932d9662efe276f6d0fe2eba455522a9f6e87060adae", "ref_doc_id": "a1591ff5-f46a-4980-8e52-cf32c0330994"}, "d0396dc4-95c0-4bb3-a79c-7cd1ae457c18": {"doc_hash": "c3b923f7b9e005b4ca822b050bf1680c97d0187d9ebc8ea80bf423f5befa5dbf", "ref_doc_id": "cd6a5d36-8e26-45a7-b612-dcf0a4e586d5"}, "7795c406-c3e7-474d-bb7f-45490cd7c9e5": {"doc_hash": "f8e677f2a194afc4c629dee277819b0dbb326866ad47411666f83cf021d5ec59", "ref_doc_id": "f2f0eeb7-ecab-4410-9846-c73c93acbe7b"}, "fb2617cc-25ae-4f3c-b6bd-5349bd3d28da": {"doc_hash": "86ededffdcff0a20e86d7fc80f284910543d05e4050954d790dc5db347392f0a", "ref_doc_id": "d59decc2-e47b-46c0-a1a9-4fb2a49f429d"}, "e9d6862b-5ea6-435a-827f-9e23f2e831f7": {"doc_hash": "5f5e887b4f05459738bec13b8f2b7a016fb2490f5347a1f21dfa302d96c665c8", "ref_doc_id": "8e951baf-e356-4a4e-810c-eebb3fbacc7c"}, "61820dbb-7f35-4787-a429-e6c0eb10bbcb": {"doc_hash": "4d1ba014b3de633b28793b417776b78e959149f3ba7ae62976192c7c8bdce457", "ref_doc_id": "115072f6-6ef1-4403-bd3d-c292803ffe5f"}, "8ab25a81-9050-4799-b072-11e5656908a9": {"doc_hash": "6e66a1edf45df41eed5f939627566622b6c191112138a7c0ca50fe1ddf10cf40", "ref_doc_id": "0eca79aa-00fd-4c30-b48b-482fb9240a7b"}, "1f838a5d-cfd5-4f54-925e-d747a78caf77": {"doc_hash": "afa4a000a02f913bdba274d7c673afe22b9842e7934e23b073e98a7329c25af7", "ref_doc_id": "2f0329c3-19b8-4c80-8bd9-0ceb09d80315"}, "aab4728c-037c-4724-82df-647e50078b59": {"doc_hash": "688194295cda734676bd07533bb05dfaa248d2cde781692485bb65ad38fecaf5", "ref_doc_id": "de5593e2-4ffc-4114-ba8c-cbc70b3c89be"}, "0762d9d8-1db4-4896-9590-c9f733cf55e1": {"doc_hash": "e29dfb6dd3055ccaf3463b2b4b69e1a44b0282bd1fe55a8d755ea2224a1dcee2", "ref_doc_id": "2b4a3677-8d19-4249-9741-d342ff5a6f13"}, "3b3c33e2-87ce-415c-aef9-0e69e649fd63": {"doc_hash": "6714ad2c10b9d74b423a5a694bd806ddced768aa7284ac529f6a1bf2592c10a3", "ref_doc_id": "d97c5be0-06bc-490e-9cc9-ca19a09b799d"}, "d7e82b14-c1d4-4801-b968-ef7a0fbd844e": {"doc_hash": "3acb2f567317a6731ddcd9bbe9bc5fd318e4260c2e977efd071560dc05eaa3cd", "ref_doc_id": "d9d483d0-e975-4695-987b-e37c12345373"}, "180e9299-9c95-4cc3-ae3b-de9580b4b96b": {"doc_hash": "512ae8f44386f00297543ae3618b69762e89d77eb8bb755fbccf1d72f1527222", "ref_doc_id": "87633561-307a-470c-bc73-9b597f68d364"}, "6365050a-ad92-49d1-bd0d-2f3c15be2d74": {"doc_hash": "ad93fcefd93c3940a5e1338cd4e13cde73be39e1fee26b1dee71290cf2987220", "ref_doc_id": "31a771be-8937-48cd-9ff9-c9b623bf1b4b"}, "470efe3c-bf1f-4423-84b8-9576e96f5a64": {"doc_hash": "b7a543e8afa9925e42ce97e8543d703c588b32759ab29c256a3ea3d48336eaee", "ref_doc_id": "de4404b5-5b99-4153-8af1-26528f12228d"}, "7104b48c-9f7d-4219-ad79-f06bd413d1d2": {"doc_hash": "8494908ba004c15fc82d5c4657213e65ac4ffed154198b871e521701a0af8553", "ref_doc_id": "bcfa7345-4346-4ef6-b5d7-f8b12d931c59"}, "7900104b-543a-4836-a9b0-e35df388e2e4": {"doc_hash": "047ab036278102941cf1f844615361d8d9c15d0af858a56a7fe887ceaada7de3", "ref_doc_id": "b592a522-ade0-4abe-ba9a-1103ee3b45f1"}, "4d049284-a173-49da-9276-5987a87815c9": {"doc_hash": "8fdd36e3b86bdf9402e4cc8658087d25e423cb6457f23a91a84af6691e715f95", "ref_doc_id": "2f2a1d32-3cfe-44a1-a630-245ca34f11dc"}, "021847e4-9e19-4eee-9251-03bae2d59890": {"doc_hash": "7fb4127b883c4367ed59ab4752c68ead1a9174e6a7a47f7421de5cc2d192a91d", "ref_doc_id": "4025c2d2-71a9-4a49-98f7-1ab0b1575818"}, "95862c08-7b54-4591-99cb-83e78f83dc73": {"doc_hash": "393dea86fa031d665cb278c6533644a14be5444eb1e909414044d765d13e6f54", "ref_doc_id": "9bfcb04a-2f0b-414c-a4ec-eedf1d567126"}, "980e5d2c-9cd0-418f-8908-ece75f059086": {"doc_hash": "cd63ec220b937ab1c150f88a95c14d0f31db9aa6529fa200ec2d3ea34f4dc95b", "ref_doc_id": "710408db-79f7-4007-bbd2-be01377ddb72"}, "b6b3eae9-1e38-47d6-98f0-e15580b1878e": {"doc_hash": "857db23572f52e44bcef5bfbcd2c8854aca51de914ece0d03c201e760af12011", "ref_doc_id": "06174fe5-fa05-4b66-bbe0-409cf6f1e649"}}, "docstore/ref_doc_info": {"ec2746c9-df75-4485-88c9-b0ad698a0979": {"node_ids": ["cc53f633-1a8e-42df-93bc-982da454d32d"], "metadata": {"page_label": "1", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# Guide for Computer Systems Validation\n\n*Guide n\u00b0 33/2020 - version 1*", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas que podr\u00edan proporcionar respuestas espec\u00edficas basadas en el contexto del documento \"ANVISA Guide for Computer Systems Validation 33/2020\":\n\n1. **\u00bfCu\u00e1les son los principales requisitos establecidos por la ANVISA para la validaci\u00f3n de sistemas inform\u00e1ticos en el sector de la salud?**\n   - Esta pregunta busca detalles espec\u00edficos sobre los requisitos que la ANVISA establece en su gu\u00eda, que pueden no estar disponibles en otros documentos o fuentes.\n\n2. **\u00bfQu\u00e9 metodolog\u00edas o enfoques recomienda la ANVISA para llevar a cabo la validaci\u00f3n de sistemas inform\u00e1ticos?**\n   - Esta pregunta se centra en las metodolog\u00edas espec\u00edficas que la gu\u00eda sugiere, lo cual puede ser crucial para las organizaciones que buscan cumplir con las normativas de la ANVISA.\n\n3. **\u00bfQu\u00e9 implicaciones tiene la falta de validaci\u00f3n de sistemas inform\u00e1ticos seg\u00fan la gu\u00eda de la ANVISA?**\n   - Esta pregunta busca entender las consecuencias o riesgos asociados con no seguir las pautas de validaci\u00f3n, lo que puede ser un aspecto cr\u00edtico para las empresas en el sector de la salud.\n\n### Resumen de nivel superior:\nEl documento \"ANVISA Guide for Computer Systems Validation 33/2020\" proporciona directrices sobre c\u00f3mo las organizaciones del sector salud deben validar sus sistemas inform\u00e1ticos para garantizar la calidad y la conformidad con las regulaciones. La gu\u00eda aborda aspectos como los requisitos de validaci\u00f3n, las metodolog\u00edas recomendadas y las implicaciones de no cumplir con estas normativas.", "excerpt_keywords": "Keywords: ANVISA, computer systems validation, health sector, regulatory compliance, validation methodologies"}}, "a9bd1347-1d55-4117-ad94-1570a52c7caa": {"node_ids": ["12d10f50-b772-4758-985f-10aa807d40e3"], "metadata": {"page_label": "2", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# Guide for Computer Systems Validation\n\n**EFFECTIVE FROM 4/14/2020**\n\n**Start of the contribution period: 4/14/2020**\n\n**End of the contribution period: 08/12/2020**\n\nThis Guide expresses Anvisa's understanding of best practices with respect to procedures, routines and methods considered adequate to meet technical requirements or administrative requirements required by the Agency's legislative and regulatory frameworks.\n\nIt is a non-normative regulatory instrument, of a recommendatory and non-binding nature, therefore, it is possible to use alternative approaches to the propositions provided here, since compatible with the requirements related to the specific case. Failure to comply with the content of this document does not characterize a health violation, nor does it constitute a reason for refusing petitions, provided the requirements of the legislation are met.\n\nThe recommendations contained in this Guide take effect from the date of its publication on the Portal Anvisa, are subject to receiving suggestions from society through a form electronic.\n\nContributions received will be evaluated and may support the revision of the Guide and the consequent publication of a new version of the document. Regardless of the area's decision, it will be published general analysis of contributions and rational that justifies the revision or not of the Guide.\n\nOrdinance No. 1,741, of December 12, 2018, which provides for guidelines and procedures for quality improvement regulatory agency at the National Health Surveillance Agency (Anvisa).\n\nIn order to ensure greater transparency in the process of preparing the regulatory instruments issued by Anvisa, clarify that the names of those responsible for contributions (individuals and legal entities) are considered information public and will be made available in an unrestricted manner in reports and other documents generated from the results of this Guide. The participants' e-mail and CPF, which are considered direct confidential information, will have their access restricted to agents legally authorized public bodies and the persons to whom such information refers, as recommended in article 31, paragraph 1, of Law No. 12,527, of November 18, 2011. Other information that may be considered confidential by the participants may be joined in a specific field on the electronic form.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior del contenido:\n\n### Resumen de Nivel Superior\nEl documento es una gu\u00eda emitida por la Agencia Nacional de Vigilancia Sanitaria (Anvisa) de Brasil, que establece las mejores pr\u00e1cticas para la validaci\u00f3n de sistemas inform\u00e1ticos en el \u00e1mbito de la salud. Es un instrumento no normativo y de car\u00e1cter recomendatorio, lo que significa que no es obligatorio seguir sus directrices, aunque se espera que se cumplan los requisitos legales pertinentes. La gu\u00eda tambi\u00e9n menciona un proceso de contribuci\u00f3n p\u00fablica para recibir sugerencias y mejorar el documento, asegurando la transparencia en la gesti\u00f3n de las contribuciones.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfQu\u00e9 implicaciones tiene el car\u00e1cter no normativo de la gu\u00eda para las organizaciones que buscan cumplir con los requisitos de Anvisa?**\n   - La gu\u00eda es de car\u00e1cter recomendatorio y no vinculante, lo que permite a las organizaciones utilizar enfoques alternativos siempre que sean compatibles con los requisitos legales espec\u00edficos. Esto significa que no seguir las recomendaciones de la gu\u00eda no se considera una violaci\u00f3n de salud, siempre que se cumplan las normativas vigentes.\n\n2. **\u00bfC\u00f3mo se manejar\u00e1n las contribuciones recibidas de la sociedad en relaci\u00f3n con la gu\u00eda?**\n   - Las contribuciones ser\u00e1n evaluadas y podr\u00edan llevar a la revisi\u00f3n de la gu\u00eda, resultando en la publicaci\u00f3n de una nueva versi\u00f3n. Anvisa publicar\u00e1 un an\u00e1lisis general de las contribuciones y la justificaci\u00f3n de cualquier decisi\u00f3n tomada respecto a la revisi\u00f3n del documento.\n\n3. **\u00bfQu\u00e9 tipo de informaci\u00f3n se considera p\u00fablica y cu\u00e1l es confidencial en el proceso de contribuci\u00f3n?**\n   - Los nombres de los responsables de las contribuciones (tanto individuos como entidades legales) se consideran informaci\u00f3n p\u00fablica y se har\u00e1n accesibles en informes y documentos relacionados. Sin embargo, la informaci\u00f3n confidencial, como correos electr\u00f3nicos y CPF de los participantes, estar\u00e1 restringida a agentes autorizados y a las personas a las que se refiere dicha informaci\u00f3n, de acuerdo con la legislaci\u00f3n vigente.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\nEl documento \"ANVISA Guide for Computer Systems Validation 33/2020\" se centra en la validaci\u00f3n de sistemas inform\u00e1ticos en el sector de la salud, estableciendo directrices esenciales para garantizar la calidad y el cumplimiento normativo. Los temas clave incluyen:\n\n1. **Requisitos de Validaci\u00f3n**: Detalla los principales requisitos que las organizaciones deben cumplir para validar sus sistemas inform\u00e1ticos, asegurando que estos operen de manera efectiva y segura.\n\n2. **Metodolog\u00edas y Enfoques**: Proporciona recomendaciones sobre las metodolog\u00edas y enfoques que las organizaciones pueden adoptar para llevar a cabo la validaci\u00f3n de sus sistemas, lo que es crucial para cumplir con las normativas de la ANVISA.\n\n3. **Implicaciones de la Falta de Validaci\u00f3n**: Aborda las consecuencias y riesgos asociados con la falta de validaci\u00f3n de sistemas inform\u00e1ticos, enfatizando la importancia de seguir las pautas establecidas para evitar problemas legales y de calidad.\n\n### Entidades Clave\n\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil, responsable de regular y supervisar el sector de la salud.\n- **Sistemas Inform\u00e1ticos**: Herramientas y plataformas tecnol\u00f3gicas utilizadas en el sector salud que requieren validaci\u00f3n para asegurar su correcto funcionamiento y cumplimiento normativo.\n\nEste resumen proporciona una visi\u00f3n general de los aspectos m\u00e1s relevantes del documento, destacando su importancia para las organizaciones del sector salud en Brasil.", "excerpt_keywords": "Keywords: ANVISA, Computer Systems Validation, regulatory framework, best practices, non-normative guidelines"}}, "3f08a92e-1331-4339-957a-a549ee49a71c": {"node_ids": ["adba163d-3a2c-4ab6-b0d2-9fc1cdcd94bf"], "metadata": {"page_label": "3", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# SUMMARY\n\n1. **SCOPE**\n.................................................................................................................. 5\n\n2. **INTRODUCTION**\n.................................................................................................................. 5\n\n3. **LEGAL BASE**\n.................................................................................................................. 5\n\n4. **CONCEPTS, TERMS AND DEFINITIONS**\n.................................................................................................................. 5\n\n4.1 **KEY CONCEPTS**\n.................................................................................................................. 5\n\n4.2 **KEY TERMS**\n.................................................................................................................. 7\n\n5. **LIFE CYCLE APPROACH**\n.................................................................................................................. 9\n\n5.1 **INTRODUCTION**\n.................................................................................................................. 9\n\n5.2 **LIFE CYCLE OF COMPUTERIZED SYSTEMS**\n.................................................................................................................. 10\n\n5.3 **COMPUTERIZED SYSTEM VALIDATION STRUCTURE**\n.................................................................................................................. 11\n\n6. **QUALITY RISK MANAGEMENT**\n.................................................................................................................. 13\n\n6.1 **INTRODUCTION**\n.................................................................................................................. 13\n\n6.2 **QUALITY RISK MANAGEMENT WITH SCIENTIFIC BASIS**\n.................................................................................................................. 14\n\n6.3 **QUALITY RISK MANAGEMENT PROCESS**\n.................................................................................................................. 14\n\n7. **SOFTWARE AND HARDWARE CATEGORIZATION**\n.................................................................................................................. 17\n\n7.1 **INTRODUCTION**\n.................................................................................................................. 17\n\n7.2 **USE OF GAMP CATEGORIES**\n.................................................................................................................. 17\n\n7.3 **SOFTWARE CATEGORIES**\n.................................................................................................................. 18\n\n7.4 **HARDWARE CATEGORIES**\n.................................................................................................................. 21\n\n8. **INVENTORY LIST**\n.................................................................................................................. 22\n\n9. **VALIDATION OF COMPUTERIZED SYSTEMS**\n.................................................................................................................. 22\n\n9.1 **INTRODUCTION**\n.................................................................................................................. 22\n\n9.2 **VALIDATION PLAN**\n.................................................................................................................. 24\n\n9.3 **DOCUMENT CONTAINING USER REQUIREMENTS SPECIFICATIONS (ERU/URS)**\n.................................................................................................................. 27", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas que pueden proporcionar respuestas espec\u00edficas basadas en el contexto del documento \"ANVISA - Guide for Computer Systems Validation 33/2020\":\n\n1. **\u00bfCu\u00e1les son los principales conceptos y t\u00e9rminos definidos en la secci\u00f3n 4 del documento, y por qu\u00e9 son importantes para la validaci\u00f3n de sistemas computarizados?**\n   - Esta pregunta busca profundizar en la secci\u00f3n de conceptos y t\u00e9rminos, que es fundamental para entender el marco de referencia del documento.\n\n2. **\u00bfQu\u00e9 pasos se describen en el proceso de gesti\u00f3n de riesgos de calidad en la secci\u00f3n 6, y c\u00f3mo se aplican a la validaci\u00f3n de sistemas computarizados?**\n   - Esta pregunta se centra en el proceso de gesti\u00f3n de riesgos, que es crucial para garantizar la calidad y la seguridad en la validaci\u00f3n de sistemas.\n\n3. **\u00bfC\u00f3mo se categoriza el software y hardware en la secci\u00f3n 7, y qu\u00e9 criterios se utilizan para determinar estas categor\u00edas?**\n   - Esta pregunta busca explorar la categorizaci\u00f3n de software y hardware, lo cual es esencial para aplicar un enfoque adecuado en la validaci\u00f3n de sistemas.\n\n### Res\u00famenes de nivel superior del contexto circundante:\n\n- **Alcance y Objetivo del Documento:** El documento establece directrices para la validaci\u00f3n de sistemas computarizados en el contexto de la regulaci\u00f3n de la ANVISA, asegurando que estos sistemas cumplan con los est\u00e1ndares de calidad y seguridad requeridos en la industria.\n\n- **Enfoque del Ciclo de Vida:** Se presenta un enfoque basado en el ciclo de vida para la validaci\u00f3n de sistemas, que incluye desde la planificaci\u00f3n hasta la ejecuci\u00f3n y el mantenimiento, asegurando que cada etapa del ciclo se gestione adecuadamente.\n\n- **Gesti\u00f3n de Riesgos de Calidad:** Se enfatiza la importancia de la gesti\u00f3n de riesgos de calidad, proporcionando un marco para identificar, evaluar y mitigar riesgos asociados con el uso de sistemas computarizados en entornos regulados.\n\nEstos res\u00famenes pueden ayudar a formular preguntas m\u00e1s espec\u00edficas y relevantes sobre el contenido del documento.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n**Temas Clave:**\n\n1. **Gu\u00eda de Validaci\u00f3n de Sistemas Inform\u00e1ticos:** El documento establece las mejores pr\u00e1cticas para la validaci\u00f3n de sistemas inform\u00e1ticos en el \u00e1mbito de la salud, seg\u00fan la Agencia Nacional de Vigilancia Sanitaria (Anvisa).\n\n2. **Car\u00e1cter No Normativo:** La gu\u00eda es un instrumento no vinculante y recomendatorio, lo que permite a las organizaciones adoptar enfoques alternativos siempre que cumplan con los requisitos legales pertinentes.\n\n3. **Proceso de Contribuci\u00f3n P\u00fablica:** Se establece un mecanismo para recibir sugerencias de la sociedad, que ser\u00e1n evaluadas y podr\u00edan llevar a la revisi\u00f3n de la gu\u00eda.\n\n4. **Transparencia en la Gesti\u00f3n de Contribuciones:** Se aclara que los nombres de los contribuyentes ser\u00e1n p\u00fablicos, mientras que la informaci\u00f3n confidencial, como correos electr\u00f3nicos y CPF, estar\u00e1 restringida a agentes autorizados.\n\n5. **Vigencia de la Gu\u00eda:** Las recomendaciones son efectivas desde la fecha de publicaci\u00f3n en el Portal Anvisa y est\u00e1n sujetas a revisi\u00f3n en funci\u00f3n de las contribuciones recibidas.\n\n**Entidades:**\n\n- **ANVISA (Agencia Nacional de Vigilancia Sanitaria):** La entidad responsable de emitir la gu\u00eda y regular las pr\u00e1cticas de validaci\u00f3n de sistemas inform\u00e1ticos en el sector salud en Brasil.\n\n- **Contribuyentes:** Individuos y entidades que aportan sugerencias para la mejora de la gu\u00eda.\n\n- **Legislaci\u00f3n:** Referencias a leyes y normativas que regulan la transparencia y el manejo de informaci\u00f3n confidencial, como la Ley No. 12,527 de 2011.\n\nEste resumen destaca los aspectos m\u00e1s relevantes del documento, as\u00ed como las entidades involucradas en su creaci\u00f3n y aplicaci\u00f3n.", "excerpt_keywords": "Keywords: validation, computerized systems, quality risk management, software categorization, ANVISA"}}, "a76cf395-5ffe-422f-8188-30d4bcb04aed": {"node_ids": ["d0fb92e5-8538-445f-9d90-f23ea47246ab"], "metadata": {"page_label": "4", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# Guide for Computer Systems Validation\n\n## 9.4 SELECTION OF COMPUTER SYSTEMS SUPPLIER\n... 32\n\n## 9.5 DOCUMENT CONTAINING FUNCTIONAL SPECIFICATIONS (EF / FS)\n... 33\n\n## 9.6 DOCUMENT CONTAINING THE CONFIGURATION AND THE PROJECT\n... 36\n\n## 9.7 TESTING PLAN FOR COMPUTERIZED SYSTEMS\n... 41\n\n## 9.8 COMPLEMENTARY ACTIVITIES\n... 54\n\n## 9.9 VALIDATION REPORT\n... 57\n\n## 10. INVENTORY LIST\n... 59\n\n## 11. OPERATIONAL PHASE OF COMPUTERIZED SYSTEMS\n... 60\n\n### 11.1 INTRODUCTION\n... 60\n\n### 11.2 SYSTEM DELIVERY\n... 61\n\n### 11.3 SUPPORT SERVICE MANAGEMENT\n... 62\n\n## 11.4 MONITORING SYSTEM PERFORMANCE\n... 63\n\n## 11.5 INCIDENT MANAGEMENT\n... 66\n\n## 11.6 CORRECTIVE AND PREVENTIVE ACTIONS (COVER)\n... 67\n\n## 11.7 MANAGEMENT OF CHANGES AND SYSTEM CONFIGURATION\n... 68\n\n## 11.8 SYSTEM REPAIR ACTIVITIES\n... 71\n\n## 11.9 PERIODIC REVIEW\n... 73\n\n## 11.10 BACKUP AND RESTORATION\n... 75\n\n## 11.11 BUSINESS CONTINUITY PLANNING / DISASTER RECOVERY\n... 79\n\n## 11.12 SYSTEM SECURITY MANAGEMENT\n... 81\n\n## 11.13 SYSTEM ADMINISTRATION\n... 82\n\n## 11.14 RECORD MANAGEMENT (RETENTION, ARCHIVING AND RECOVERY)\n... 83\n\n## 12 DATA MIGRATION\n... 85\n\n### 12.1 INTRODUCTION\n... 85\n\n### 12.2 QUALITY MANAGEMENT\n... 86\n\n### 12.3 IMPORTANT POINTS\n... 87\n\n### 12.4 DATA MIGRATION PLAN\n... 89\n\n### 12.5 DATA MIGRATION REPORT\n... 90\n\n## 13 RETIREMENT OF COMPUTERIZED SYSTEMS\n... 90\n\n### 13.1 INTRODUCTION\n... 90\n\n### 13.2 SYSTEM RETIREMENT PLAN\n... 91\n\n### 13.3 SYSTEM RETIREMENT REPORT\n... 93\n\n## 14. VALIDATION OF SHEETS\n... 94", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento \"ANVISA - Guide for Computer Systems Validation 33/2020\" es una gu\u00eda que establece los lineamientos y procedimientos para la validaci\u00f3n de sistemas computacionales en el \u00e1mbito regulado por ANVISA (Ag\u00eancia Nacional de Vigil\u00e2ncia Sanit\u00e1ria) en Brasil. La gu\u00eda abarca desde la selecci\u00f3n de proveedores de sistemas hasta la gesti\u00f3n de cambios, la seguridad del sistema y la planificaci\u00f3n de la continuidad del negocio. Tambi\u00e9n incluye secciones sobre la migraci\u00f3n de datos y el retiro de sistemas, asegurando que todos los aspectos del ciclo de vida del sistema est\u00e9n debidamente documentados y validados.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfCu\u00e1les son los elementos clave que deben incluirse en un \"Plan de Migraci\u00f3n de Datos\" seg\u00fan la gu\u00eda?**\n   - Esta pregunta busca detalles espec\u00edficos sobre los requisitos y consideraciones que deben tenerse en cuenta al planificar la migraci\u00f3n de datos, que se menciona en la secci\u00f3n 12.\n\n2. **\u00bfQu\u00e9 aspectos se deben considerar en la \"Gesti\u00f3n de Cambios y Configuraci\u00f3n del Sistema\" seg\u00fan la gu\u00eda de ANVISA?**\n   - Esta pregunta se centra en los procedimientos y pr\u00e1cticas recomendadas para gestionar cambios en los sistemas computacionales, lo cual es crucial para mantener la integridad y la validaci\u00f3n del sistema.\n\n3. **\u00bfQu\u00e9 se debe incluir en un \"Informe de Validaci\u00f3n\" y cu\u00e1l es su prop\u00f3sito dentro del proceso de validaci\u00f3n de sistemas?**\n   - Esta pregunta busca informaci\u00f3n sobre el contenido y la importancia del informe de validaci\u00f3n, que es un documento clave en el proceso de validaci\u00f3n de sistemas computacionales seg\u00fan la gu\u00eda. \n\nEstas preguntas est\u00e1n dise\u00f1adas para extraer informaci\u00f3n espec\u00edfica que puede no estar disponible en otras fuentes, enfoc\u00e1ndose en los detalles y procedimientos que la gu\u00eda establece.", "prev_section_summary": "### Resumen de Temas Clave y Entidades de la Secci\u00f3n\n\n1. **Alcance (SCOPE)**: Define el \u00e1mbito de aplicaci\u00f3n del documento, estableciendo las directrices para la validaci\u00f3n de sistemas computarizados en el contexto regulatorio de ANVISA.\n\n2. **Introducci\u00f3n (INTRODUCTION)**: Presenta el prop\u00f3sito del documento y su relevancia en la industria, as\u00ed como una visi\u00f3n general de los temas que se abordar\u00e1n.\n\n3. **Base Legal (LEGAL BASE)**: Describe el marco legal que sustenta las directrices de validaci\u00f3n, asegurando que se alineen con las normativas vigentes.\n\n4. **Conceptos, T\u00e9rminos y Definiciones (CONCEPTS, TERMS AND DEFINITIONS)**:\n   - **Conceptos Clave (KEY CONCEPTS)**: Introduce los conceptos fundamentales que son esenciales para la comprensi\u00f3n de la validaci\u00f3n de sistemas.\n   - **T\u00e9rminos Clave (KEY TERMS)**: Define t\u00e9rminos espec\u00edficos utilizados en el documento, facilitando una comunicaci\u00f3n clara y precisa.\n\n5. **Enfoque del Ciclo de Vida (LIFE CYCLE APPROACH)**:\n   - **Ciclo de Vida de Sistemas Computarizados (LIFE CYCLE OF COMPUTERIZED SYSTEMS)**: Detalla las etapas del ciclo de vida que deben considerarse en la validaci\u00f3n.\n   - **Estructura de Validaci\u00f3n de Sistemas Computarizados (COMPUTERIZED SYSTEM VALIDATION STRUCTURE)**: Describe c\u00f3mo se organiza el proceso de validaci\u00f3n a lo largo del ciclo de vida.\n\n6. **Gesti\u00f3n de Riesgos de Calidad (QUALITY RISK MANAGEMENT)**:\n   - **Gesti\u00f3n de Riesgos con Base Cient\u00edfica (QUALITY RISK MANAGEMENT WITH SCIENTIFIC BASIS)**: Enfatiza la importancia de un enfoque basado en evidencia para la gesti\u00f3n de riesgos.\n   - **Proceso de Gesti\u00f3n de Riesgos (QUALITY RISK MANAGEMENT PROCESS)**: Especifica los pasos a seguir para identificar y mitigar riesgos en la validaci\u00f3n de sistemas.\n\n7. **Categorizaci\u00f3n de Software y Hardware (SOFTWARE AND HARDWARE CATEGORIZATION)**:\n   - **Uso de Categor\u00edas GAMP (USE OF GAMP CATEGORIES)**: Explica c\u00f3mo se aplican las categor\u00edas GAMP para clasificar software y hardware.\n   - **Categor\u00edas de Software (SOFTWARE CATEGORIES)** y **Categor\u00edas de Hardware (HARDWARE CATEGORIES)**: Proporciona criterios para clasificar diferentes tipos de software y hardware utilizados en sistemas computarizados.\n\n8. **Lista de Inventario (INVENTORY LIST)**: Presenta un listado de los sistemas y componentes que requieren validaci\u00f3n.\n\n9. **Validaci\u00f3n de Sistemas Computarizados (VALIDATION OF COMPUTERIZED SYSTEMS)**:\n   - **Plan de Validaci\u00f3n (VALIDATION PLAN)**: Describe c\u00f3mo se debe estructurar un plan de validaci\u00f3n efectivo.\n   - **Documento de Especificaciones de Requisitos del Usuario (ERU/URS)**: Detalla la importancia de documentar los requisitos del usuario para asegurar que el sistema cumpla con las expectativas y necesidades.\n\nEste resumen abarca los temas clave y entidades presentes en la secci\u00f3n, proporcionando una visi\u00f3n general de los aspectos fundamentales relacionados con la validaci\u00f3n de sistemas computarizados seg\u00fan las directrices de ANVISA.", "excerpt_keywords": "Keywords: validation, computerized systems, ANVISA, data migration, system retirement"}}, "4c4570df-4b29-448d-9673-43faf57b3599": {"node_ids": ["60edc40c-35bd-4e67-81b5-91322b4abecc"], "metadata": {"page_label": "5", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# Guide for Computer Systems Validation\n\n## Table of Contents\n\n- **14.1 INTRODUCTION** ........................................................................................................... 94\n- **14.2 TYPES OF APPLICATIONS FOR END USER** .......................................................... 94\n- **14.3 RISK-BASED APPROACH** ......................................................................................... 96\n- **14.4 USE OF GAMP CATEGORIES** .................................................................................. 97\n- **14.5 RISK-BASED CONTROLS** ......................................................................................... 97\n- **14.6 APPROACHES FOR VALIDATION** .......................................................................... 99\n- **15 FINAL CONSIDERATIONS** .......................................................................................... 101\n- **16 GLOSSARY AND ACRONYMS** ................................................................................... 101\n- **17 BIBLIOGRAPHICAL REFERENCES** .......................................................................... 103\n- **17.1 REGULATORY** ....................................................................................................... 103\n- **17.2 TECHNIQUES** ......................................................................................................... 103\n\n----\n\n## 1. SCOPE\n\nThe purpose of this guide is to propose guidelines to help obtain, by the regulated sector, computer systems correctly installed and validated and that meet regulatory requirements.\n\nThis Guide is applicable to the computerized systems used in the areas, equipment and other activities relevant to Good Manufacturing Practices for Inputs and Medicines. The proposal is to internalize the document GAMP 5 in order to facilitate the reader's understanding of the guidelines proposed by that international guide.\n\nThe scope of this Guide includes computerized systems categories 3, 4 and 5, the interfaces between systems and spreadsheets.\n\nThe above mentioned systems are included, installed in stand-alone or network architecture, this network to be installed locally, nationally or globally.\n\nThis guide replaces the eponymous guide published by this Agency in April 2010.\n\n## 2. INTRODUCTION\n\nIf the regulated company decides to use this Guide, it is recommended that its implementation be carried out in its entirety (where applicable) and not partially, since all the activities described in this document are necessary jointly for the achievement of an adequate sequence of acquisition, validation, operationalization and finally retirement of the computerized system, especially for more complex systems.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento es una gu\u00eda de ANVISA (Ag\u00eancia Nacional de Vigil\u00e2ncia Sanit\u00e1ria) sobre la validaci\u00f3n de sistemas inform\u00e1ticos, aplicable a la industria regulada de medicamentos y productos de salud. La gu\u00eda propone directrices para asegurar que los sistemas inform\u00e1ticos est\u00e9n correctamente instalados y validados, cumpliendo con los requisitos regulatorios. Se enfoca en sistemas de categor\u00edas 3, 4 y 5, y enfatiza la importancia de implementar todas las actividades descritas en el documento de manera conjunta para lograr una validaci\u00f3n adecuada.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfCu\u00e1les son las categor\u00edas de sistemas inform\u00e1ticos que abarca la gu\u00eda de ANVISA y qu\u00e9 tipos de sistemas se incluyen en cada categor\u00eda?**\n   - La gu\u00eda se aplica a los sistemas inform\u00e1ticos de categor\u00edas 3, 4 y 5, as\u00ed como a las interfaces entre sistemas y hojas de c\u00e1lculo.\n\n2. **\u00bfPor qu\u00e9 es importante implementar la gu\u00eda de ANVISA en su totalidad y no de manera parcial?**\n   - La implementaci\u00f3n completa es crucial porque todas las actividades descritas en el documento son necesarias de manera conjunta para asegurar una secuencia adecuada de adquisici\u00f3n, validaci\u00f3n, operaci\u00f3n y eventual retiro del sistema inform\u00e1tico, especialmente en sistemas m\u00e1s complejos.\n\n3. **\u00bfQu\u00e9 documento internacional se busca internalizar en la gu\u00eda de ANVISA y cu\u00e1l es su prop\u00f3sito?**\n   - La gu\u00eda busca internalizar el documento GAMP 5, con el prop\u00f3sito de facilitar la comprensi\u00f3n de las directrices propuestas por esa gu\u00eda internacional en el contexto de la validaci\u00f3n de sistemas inform\u00e1ticos en el sector regulado.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\nEl documento \"ANVISA - Guide for Computer Systems Validation 33/2020\" aborda diversos aspectos relacionados con la validaci\u00f3n de sistemas computacionales en el contexto regulado por ANVISA. A continuaci\u00f3n se presentan los temas clave y entidades mencionadas en la secci\u00f3n:\n\n1. **Selecci\u00f3n de Proveedores de Sistemas Computacionales**:\n   - Importancia de elegir proveedores adecuados para garantizar la calidad y conformidad de los sistemas.\n\n2. **Documentaci\u00f3n de Especificaciones Funcionales (EF / FS)**:\n   - Necesidad de tener documentos claros que definan las funcionalidades requeridas del sistema.\n\n3. **Configuraci\u00f3n y Proyecto del Sistema**:\n   - Documentaci\u00f3n que detalla la configuraci\u00f3n del sistema y su dise\u00f1o.\n\n4. **Plan de Pruebas para Sistemas Computacionales**:\n   - Estrategias y procedimientos para validar que el sistema funcione como se espera.\n\n5. **Informe de Validaci\u00f3n**:\n   - Documento que resume los resultados de la validaci\u00f3n y su importancia en el proceso.\n\n6. **Fase Operativa de Sistemas Computacionales**:\n   - Incluye la entrega del sistema, gesti\u00f3n del soporte, y monitoreo del rendimiento.\n\n7. **Gesti\u00f3n de Cambios y Configuraci\u00f3n del Sistema**:\n   - Procedimientos para manejar cambios en el sistema y asegurar su integridad.\n\n8. **Migraci\u00f3n de Datos**:\n   - Proceso de trasladar datos de un sistema a otro, incluyendo la planificaci\u00f3n y gesti\u00f3n de calidad.\n\n9. **Retiro de Sistemas Computacionales**:\n   - Proceso y documentaci\u00f3n necesaria para la desactivaci\u00f3n de sistemas obsoletos.\n\n10. **Validaci\u00f3n de Hojas**:\n    - Proceso de validaci\u00f3n espec\u00edfico para documentos y hojas de c\u00e1lculo utilizadas en el sistema.\n\n### Entidades Clave\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria en Brasil.\n- **Sistemas Computacionales**: Software y hardware utilizados en el \u00e1mbito regulado.\n- **Proveedores de Sistemas**: Empresas o individuos que ofrecen soluciones de software.\n- **Documentaci\u00f3n**: Informes y planes que detallan los procesos de validaci\u00f3n y operaci\u00f3n.\n\nEste resumen proporciona una visi\u00f3n general de los temas y entidades clave que se abordan en la gu\u00eda, destacando la importancia de la validaci\u00f3n y gesti\u00f3n de sistemas computacionales en el contexto regulado.", "excerpt_keywords": "Keywords: ANVISA, computer systems validation, GAMP 5, regulatory compliance, Good Manufacturing Practices"}}, "246485af-178d-4954-9b40-2e6dc0edcb69": {"node_ids": ["743311df-d416-4c46-8dff-cd20882b4af8"], "metadata": {"page_label": "6", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 3. LEGAL BASE\n\n- Resolution - RDC No. 69 of December 8, 2014 - which provides for Good Manufacturing Practices of Active Pharmaceutical Inputs;\n- Resolution - RDC n\u00ba 301, of August 21, 2019 - which provides for the General Good Guidelines Drug Manufacturing Practices;\n- Normative Instruction - IN n\u00ba 43, of August 21, 2019 - which provides for the Good Practices of Manufacturing complementary to the computerized systems used in the manufacture of Medicines;\n- Normative Instruction - IN n\u00ba 47, of August 21, 2019 - which provides for the Good Practices of Manufacturing complementary to qualification and validation activities\n\n# 4. CONCEPTS, TERMS AND DEFINITIONS\n\n## 4.1 KEY CONCEPTS\n\n### 4.1.1 Understanding the Process and the Product\n\nThe understanding of the process to be automated / computerized (eg: materials management; document management; management of analytical records, etc.) is fundamental in defining the system requirements. Understanding the process and the product is the basis for making decisions based on science and risk to ensure that the system is suitable for its intended use.\n\nEfforts to ensure suitability for the intended use should focus on those aspects that are critical to patient safety, product quality and data integrity. These critical aspects must be identified, specified and verified.\n\nFor some systems used in manufacturing, the process requirements depend on a complete understanding of product characteristics. For these systems, the identification of Critical Attributes of Quality Control (ACQ) and the associated Critical Process Parameters allow the control requirements of processes are defined.\n\nThe requirements specification should focus on the critical aspects. The extent and details of the specification of the requirement must be commensurate with the associated risk, complexity and innovation of the system.\n\nIncomplete understanding of the process makes effective and efficient service of the system's benefit difficult computerized to the business.\n\n### 4.1.2 Life Cycle Approach within the Quality Management System (QMS)\n\nIt implies carrying out activities in a systematic way from conception to retirement of the system, allowing for consistent management and approach for all systems.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento \"ANVISA - Guide for Computer Systems Validation 33/2020\" establece un marco legal y conceptual para la validaci\u00f3n de sistemas inform\u00e1ticos en la industria farmac\u00e9utica en Brasil. Se mencionan resoluciones y normativas que regulan las Buenas Pr\u00e1cticas de Manufactura (BPM) y se enfatiza la importancia de comprender los procesos y productos para definir requisitos del sistema. Adem\u00e1s, se introduce un enfoque de ciclo de vida dentro del Sistema de Gesti\u00f3n de Calidad (QMS) para asegurar una gesti\u00f3n coherente de los sistemas desde su concepci\u00f3n hasta su retiro.\n\n### Preguntas\n\n1. **\u00bfCu\u00e1les son las resoluciones y normativas espec\u00edficas mencionadas en el documento que regulan las Buenas Pr\u00e1cticas de Manufactura en Brasil?**\n   - Respuesta: El documento menciona la Resoluci\u00f3n RDC No. 69 de diciembre de 2014, la Resoluci\u00f3n RDC n\u00ba 301 de agosto de 2019, la Instrucci\u00f3n Normativa IN n\u00ba 43 de agosto de 2019 y la Instrucci\u00f3n Normativa IN n\u00ba 47 de agosto de 2019.\n\n2. **\u00bfPor qu\u00e9 es fundamental entender el proceso y el producto al definir los requisitos del sistema en la industria farmac\u00e9utica?**\n   - Respuesta: Entender el proceso y el producto es esencial para tomar decisiones basadas en ciencia y riesgo, asegurando que el sistema sea adecuado para su uso previsto. Esto permite identificar y verificar aspectos cr\u00edticos para la seguridad del paciente, la calidad del producto y la integridad de los datos.\n\n3. **\u00bfQu\u00e9 implica el enfoque de ciclo de vida dentro del Sistema de Gesti\u00f3n de Calidad (QMS) seg\u00fan el documento?**\n   - Respuesta: Implica realizar actividades de manera sistem\u00e1tica desde la concepci\u00f3n hasta el retiro del sistema, lo que permite una gesti\u00f3n y un enfoque coherentes para todos los sistemas involucrados en el proceso de manufactura.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n**Temas Clave:**\n\n1. **Objetivo de la Gu\u00eda:** Proporcionar directrices para la correcta instalaci\u00f3n y validaci\u00f3n de sistemas inform\u00e1ticos en el sector regulado, asegurando el cumplimiento de los requisitos regulatorios.\n\n2. **\u00c1mbito de Aplicaci\u00f3n:** La gu\u00eda se aplica a sistemas inform\u00e1ticos en las \u00e1reas relevantes para las Buenas Pr\u00e1cticas de Manufactura de Insumos y Medicamentos, incluyendo sistemas de categor\u00edas 3, 4 y 5, as\u00ed como interfaces entre sistemas y hojas de c\u00e1lculo.\n\n3. **Internalizaci\u00f3n de GAMP 5:** Se busca facilitar la comprensi\u00f3n de las directrices del documento internacional GAMP 5 en el contexto de la validaci\u00f3n de sistemas inform\u00e1ticos.\n\n4. **Importancia de la Implementaci\u00f3n Completa:** Se enfatiza que la implementaci\u00f3n de la gu\u00eda debe ser total y no parcial, ya que todas las actividades descritas son necesarias para asegurar una secuencia adecuada en la adquisici\u00f3n, validaci\u00f3n, operaci\u00f3n y retiro de los sistemas inform\u00e1ticos.\n\n**Entidades:**\n\n- **ANVISA:** Ag\u00eancia Nacional de Vigil\u00e2ncia Sanit\u00e1ria, responsable de la regulaci\u00f3n en el sector de medicamentos y productos de salud en Brasil.\n- **GAMP 5:** Buenas Pr\u00e1cticas de Manufactura (Good Automated Manufacturing Practice), un documento internacional que proporciona directrices sobre la validaci\u00f3n de sistemas inform\u00e1ticos.\n- **Categor\u00edas de Sistemas:** Se mencionan las categor\u00edas 3, 4 y 5, que se refieren a diferentes tipos de sistemas inform\u00e1ticos en el contexto de la validaci\u00f3n.\n\nEste resumen destaca los aspectos fundamentales de la gu\u00eda y su relevancia en la validaci\u00f3n de sistemas inform\u00e1ticos en el sector regulado.", "excerpt_keywords": "Keywords: validation, pharmaceutical, Good Manufacturing Practices, quality management, system requirements"}}, "5617ce46-ab7d-4bb6-9091-e9bfdc17a96b": {"node_ids": ["528151a7-bf41-4bf6-8b4f-3f78a5f03d6b"], "metadata": {"page_label": "7", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "As more knowledge of the system is acquired during use, the Quality Management (QMS) should allow continuous improvement of the process and the system, based on periodic reviews and evaluations of operational and performance data and analysis of the root causes of failures occurred. Improvements identified and corrective actions taken should follow change management.\n\nAn appropriate life-cycle approach allows for quality assurance and suitability for the intended use system, in addition to obtaining and maintaining compliance with regulatory requirements.\n\n## 4.1.3 Scalable Life Cycle Activities\n\nLife cycle activities should be staggered according to:\n\n- The impact of the system on patient safety, product quality and data integrity (risk assessment);\n- The complexity of the system and its innovation (architecture and categorization of system components);\n- The result of the supplier's assessment (capability);\n- The impact of the system on business (can also motivate escalation).\n\nThe scheduling strategy must be clearly defined in a plan and follow policies and procedures established and approved.\n\n## 4.1.4 Science-Based Quality Risk Management\n\nQuality risk management is a systematic process for assessing, controlling, communicating and risk review. Its application allows efforts to be concentrated on the critical aspects of a system computerized in a controlled and justified manner.\n\nGuide for Computer Systems Validation\nGuide n\u00b0 33/2020 - version 1, of 03/26/2020\n\nQuality risk management should be based on a clear understanding of the process and the impact potential for patient safety, product quality and data integrity. For systems that control or monitor Critical Process Parameters, they must be traceable to Critical Attributes of Quality and to the regulatory submissions of the manufacturing systems.\n\nQuantitative and qualitative techniques can be used to identify and manage risks. Controls and measures mitigation measures are developed to reduce risks to an acceptable level. The implemented controls must be monitored during day-to-day operation to ensure continuous effectiveness.\n\n## 4.1.5 Leveraging Supplier Involvement\n\nCompanies in the regulated sector should seek to maximize supplier engagement throughout the life cycle of the system, if it has a satisfactory evaluation, with the purpose of using its knowledge, experience and documentation.\n\nThe supplier can assist in determining user requirements, in risk assessments, in creating functional and other specifications, system configuration, testing, support and system maintenance.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la Validaci\u00f3n de Sistemas Inform\u00e1ticos enfatiza la importancia de un enfoque de ciclo de vida escalable y la gesti\u00f3n de riesgos de calidad en sistemas regulados. Se destaca la necesidad de mejorar continuamente los procesos y sistemas mediante revisiones peri\u00f3dicas y la identificaci\u00f3n de causas ra\u00edz de fallos. Adem\u00e1s, se sugiere que la gesti\u00f3n de riesgos debe centrarse en aspectos cr\u00edticos que afectan la seguridad del paciente, la calidad del producto y la integridad de los datos. Tambi\u00e9n se menciona la importancia de involucrar a los proveedores a lo largo del ciclo de vida del sistema para aprovechar su experiencia y conocimientos.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfCu\u00e1les son los criterios que determinan c\u00f3mo se deben escalar las actividades del ciclo de vida de un sistema inform\u00e1tico seg\u00fan el documento de ANVISA?**\n   - El documento menciona que las actividades del ciclo de vida deben escalarse seg\u00fan el impacto del sistema en la seguridad del paciente, la calidad del producto y la integridad de los datos, la complejidad e innovaci\u00f3n del sistema, los resultados de la evaluaci\u00f3n del proveedor y el impacto del sistema en el negocio.\n\n2. **\u00bfQu\u00e9 t\u00e9cnicas se pueden utilizar para identificar y gestionar riesgos en sistemas inform\u00e1ticos, seg\u00fan la gu\u00eda de ANVISA?**\n   - Se pueden utilizar t\u00e9cnicas cuantitativas y cualitativas para identificar y gestionar riesgos. Adem\u00e1s, se deben desarrollar controles y medidas de mitigaci\u00f3n para reducir los riesgos a un nivel aceptable, y estos controles deben ser monitoreados durante la operaci\u00f3n diaria para asegurar su efectividad continua.\n\n3. **\u00bfC\u00f3mo se sugiere que las empresas del sector regulado involucren a los proveedores en el ciclo de vida del sistema?**\n   - Las empresas deben maximizar la participaci\u00f3n de los proveedores a lo largo del ciclo de vida del sistema, siempre que estos tengan una evaluaci\u00f3n satisfactoria. Los proveedores pueden ayudar en la determinaci\u00f3n de requisitos del usuario, en evaluaciones de riesgo, en la creaci\u00f3n de especificaciones funcionales, en la configuraci\u00f3n del sistema, en pruebas, y en el soporte y mantenimiento del sistema.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n#### 1. **Marco Legal**\n   - **Resoluciones y Normativas:**\n     - **RDC No. 69 (2014):** Buenas Pr\u00e1cticas de Manufactura de Insumos Farmac\u00e9uticos Activos.\n     - **RDC n\u00ba 301 (2019):** Directrices Generales de Buenas Pr\u00e1cticas de Manufactura de Medicamentos.\n     - **IN n\u00ba 43 (2019):** Buenas Pr\u00e1cticas de Manufactura para sistemas computarizados en la fabricaci\u00f3n de medicamentos.\n     - **IN n\u00ba 47 (2019):** Buenas Pr\u00e1cticas de Manufactura para actividades de calificaci\u00f3n y validaci\u00f3n.\n\n#### 2. **Conceptos Clave**\n   - **Comprensi\u00f3n del Proceso y del Producto:**\n     - Es fundamental para definir los requisitos del sistema.\n     - Permite tomar decisiones basadas en ciencia y riesgo, asegurando la idoneidad del sistema para su uso previsto.\n     - Identificaci\u00f3n de Atributos Cr\u00edticos de Calidad (ACQ) y Par\u00e1metros Cr\u00edticos de Proceso para definir requisitos de control.\n\n   - **Enfoque de Ciclo de Vida en el Sistema de Gesti\u00f3n de Calidad (QMS):**\n     - Implica una gesti\u00f3n sistem\u00e1tica desde la concepci\u00f3n hasta el retiro del sistema.\n     - Asegura un enfoque coherente para todos los sistemas involucrados en la manufactura.\n\n#### 3. **Importancia de la Validaci\u00f3n de Sistemas Inform\u00e1ticos**\n   - La validaci\u00f3n es crucial para garantizar la seguridad del paciente, la calidad del producto y la integridad de los datos.\n   - Un entendimiento incompleto del proceso puede dificultar la efectividad y eficiencia del sistema.\n\nEste resumen destaca la importancia de las regulaciones y la comprensi\u00f3n de los procesos en la validaci\u00f3n de sistemas inform\u00e1ticos en la industria farmac\u00e9utica, as\u00ed como la necesidad de un enfoque sistem\u00e1tico a lo largo del ciclo de vida del sistema.", "excerpt_keywords": "Keywords: validation, quality management, risk assessment, life cycle, supplier involvement"}}, "469f6b51-7c6b-4827-804a-e5b763865f1b": {"node_ids": ["301dbbb2-75d9-462c-aaf8-b96445f3aa43"], "metadata": {"page_label": "8", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "Planning should determine how to use the vendor's documentation, including tests, to avoid wasted effort and duplication. The justification for using this documentation should be based on your satisfactory assessment of the supplier, which may include conducting on-site audits.\n\nThis documentation must be assessed for suitability, accuracy and comprehensiveness and made available during the life cycle of the system.\n\n## 4.2 KEY TERMS\n\n### 4.2.1 Service to BPx\n\nCompliance with all pharmaceutical regulatory requirements and associated with life science.\n\n### 4.2.2 Process owner (Process Owner)\n\nThe process owner is responsible for ensuring that the computerized system and its operation are compliant and suitable for the intended use according to standard operating procedures (POP) by its entire life cycle. It is the individual responsible for the business process or managed processes. It is person may be the head of the unit or department using the system, but responsibility should be based primarily on specific knowledge of the process rather than position in the organization.\n\n### Owner System 4.2.3 (System Owner)\n\nIt is the individual responsible for the availability, support and maintenance of a computerized system, as well as the security of the data kept in this system. It is usually the head of the department responsible for support and maintenance of the system, the role of which must be based on specific knowledge of the system rather than the position in the organization. The system owner is responsible for ensuring that the system has support and maintenance in accordance with applicable procedures.\n\n**NOTE:** Responsibility for controlling access to the system must be agreed between the process owner and the system owner. In some situations the owner of the process may also be the owner of the system.\n\nThe ownership of the data kept in the system must be defined and normally belongs to the owner of the process.\n\n### 4.2.4 Expert Opinion (Subject Matter Expert)\n\nIt is the individual with deep knowledge in a specific area or field (chromatography, management materials, manufacturing process, etc.). The specialist's responsibilities include planning and definition of the verification strategy, definition of acceptance criteria, selection of the appropriate methods, execution of the verification tests and review of the results obtained in the tests.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "### Res\u00famenes de nivel superior del contexto:\n\n1. **Importancia de la Documentaci\u00f3n del Proveedor**: La planificaci\u00f3n en la validaci\u00f3n de sistemas inform\u00e1ticos debe incluir una evaluaci\u00f3n cuidadosa de la documentaci\u00f3n proporcionada por el proveedor, asegurando que sea adecuada, precisa y completa a lo largo del ciclo de vida del sistema. Esto ayuda a evitar esfuerzos duplicados y a garantizar la conformidad con los requisitos regulatorios.\n\n2. **Roles y Responsabilidades**: Se definen claramente los roles del propietario del proceso y del propietario del sistema. El propietario del proceso es responsable de la conformidad y adecuaci\u00f3n del sistema, mientras que el propietario del sistema se encarga de su disponibilidad, soporte y mantenimiento. La colaboraci\u00f3n entre ambos es crucial para el control de acceso y la propiedad de los datos.\n\n3. **Expertos en la Materia**: Los expertos en la materia juegan un papel fundamental en la validaci\u00f3n de sistemas inform\u00e1ticos, ya que son responsables de definir estrategias de verificaci\u00f3n, criterios de aceptaci\u00f3n y llevar a cabo pruebas de verificaci\u00f3n, asegurando que el sistema cumpla con los est\u00e1ndares requeridos.\n\n### Preguntas espec\u00edficas que el contexto puede responder:\n\n1. **\u00bfCu\u00e1les son los criterios que deben considerarse al evaluar la documentaci\u00f3n del proveedor para la validaci\u00f3n de sistemas inform\u00e1ticos?**\n   - El contexto menciona que la documentaci\u00f3n debe ser evaluada por su idoneidad, precisi\u00f3n y exhaustividad, y debe estar disponible durante todo el ciclo de vida del sistema.\n\n2. **\u00bfQu\u00e9 responsabilidades espec\u00edficas tiene el propietario del proceso en relaci\u00f3n con el sistema inform\u00e1tico?**\n   - El propietario del proceso es responsable de garantizar que el sistema y su operaci\u00f3n sean conformes y adecuados para el uso previsto, siguiendo los procedimientos operativos est\u00e1ndar a lo largo de todo su ciclo de vida.\n\n3. **\u00bfQu\u00e9 papel desempe\u00f1a un experto en la materia en el proceso de validaci\u00f3n de sistemas inform\u00e1ticos?**\n   - Un experto en la materia es responsable de planificar y definir la estrategia de verificaci\u00f3n, establecer criterios de aceptaci\u00f3n, seleccionar m\u00e9todos apropiados, ejecutar pruebas de verificaci\u00f3n y revisar los resultados obtenidos.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Mejora Continua**: Se enfatiza la importancia de la mejora continua de los procesos y sistemas a trav\u00e9s de revisiones peri\u00f3dicas y an\u00e1lisis de datos operativos y de rendimiento, as\u00ed como la identificaci\u00f3n de causas ra\u00edz de fallos.\n\n2. **Enfoque del Ciclo de Vida**: Se propone un enfoque escalable para las actividades del ciclo de vida de los sistemas inform\u00e1ticos, que debe considerar:\n   - Impacto en la seguridad del paciente, calidad del producto e integridad de los datos.\n   - Complejidad e innovaci\u00f3n del sistema.\n   - Resultados de la evaluaci\u00f3n del proveedor.\n   - Impacto en el negocio.\n\n3. **Gesti\u00f3n de Riesgos de Calidad**: Se describe la gesti\u00f3n de riesgos de calidad como un proceso sistem\u00e1tico que incluye la evaluaci\u00f3n, control, comunicaci\u00f3n y revisi\u00f3n de riesgos. Debe centrarse en aspectos cr\u00edticos que afectan la seguridad del paciente y la calidad del producto.\n\n4. **T\u00e9cnicas de Gesti\u00f3n de Riesgos**: Se pueden utilizar t\u00e9cnicas cuantitativas y cualitativas para identificar y gestionar riesgos. Se deben desarrollar controles y medidas de mitigaci\u00f3n, que deben ser monitoreados para asegurar su efectividad continua.\n\n5. **Involucramiento de Proveedores**: Se sugiere que las empresas del sector regulado maximicen la participaci\u00f3n de los proveedores a lo largo del ciclo de vida del sistema, aprovechando su conocimiento y experiencia en diversas \u00e1reas, como la determinaci\u00f3n de requisitos, evaluaciones de riesgo, especificaciones funcionales, configuraci\u00f3n del sistema, pruebas y mantenimiento.\n\n### Entidades Clave\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil.\n- **QMS (Quality Management System)**: Sistema de Gesti\u00f3n de Calidad.\n- **Proveedores**: Entidades que ofrecen servicios o productos relacionados con el sistema inform\u00e1tico.\n- **Par\u00e1metros Cr\u00edticos de Proceso**: Elementos que deben ser controlados para asegurar la calidad del producto.\n- **Atributos Cr\u00edticos de Calidad**: Caracter\u00edsticas esenciales que deben ser monitoreadas para cumplir con los est\u00e1ndares regulatorios. \n\nEste resumen destaca la importancia de un enfoque estructurado y colaborativo en la validaci\u00f3n de sistemas inform\u00e1ticos en el contexto regulado, asegurando la calidad y la seguridad en el uso de estos sistemas.", "excerpt_keywords": "Keywords: validation, documentation, process owner, system owner, subject matter expert"}}, "d1ce5258-0704-4fd1-9da3-cf2354ae25d6": {"node_ids": ["da5c0c36-aff5-4886-a7bd-edd89d4792a7"], "metadata": {"page_label": "9", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "## 4.2.5 BPx Regulations\n\nInternational pharmaceutical requirements, such as those established by ANVISA, FDA, Directives European regulations, Japanese regulations and other applicable national laws or internal regulations of the companies.\n\nBPX regulations include, but are not limited to: GMP; BPC; BPL; BPD; Good Quality Practices; Good Pharmacovigilance Practices and Medical Product Regulations.\n\n## 4.2.6 Quality Management System\n\nManagement system to direct and control an organization with respect to quality.\n\n## 4.2.7 Computerized System\n\nA computerized system consists of: **hardware**, **software** and network components, together with the controlled functions and associated documentation. Figure 1 shows a schematic representation of a computerized system.\n\n## 4.2.8 Computerized System Meeting BPx\n\nComputerized systems subject to BPx regulations. The regulated company must ensure that such systems meet the appropriate regulations.\n\n## 4.2.9 Computer Systems Validation\n\nObtaining and maintaining compliance with the applicable BPx regulations and their suitability for the intended use through the use of:\n\n- Adoption of life cycle principles, approaches and activities within the framework of plans and validation reports;\n- The application of appropriate operational controls throughout the system's life cycle.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, as\u00ed como un resumen de nivel superior del contenido:\n\n### Resumen de Nivel Superior\nEl documento \"ANVISA - Guide for Computer Systems Validation 33/2020\" aborda las regulaciones internacionales en la industria farmac\u00e9utica, destacando la importancia de cumplir con las normativas BPx, que incluyen Buenas Pr\u00e1cticas de Manufactura (GMP), Buenas Pr\u00e1cticas de Calidad (BPC), y Buenas Pr\u00e1cticas de Farmacovigilancia, entre otras. Tambi\u00e9n se define un sistema computarizado como un conjunto de hardware, software y componentes de red, y se enfatiza la necesidad de validar estos sistemas para asegurar su conformidad con las regulaciones aplicables y su idoneidad para el uso previsto.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfQu\u00e9 componentes se consideran parte de un sistema computarizado seg\u00fan el documento de ANVISA?**\n   - Respuesta: Un sistema computarizado consiste en hardware, software y componentes de red, junto con las funciones controladas y la documentaci\u00f3n asociada.\n\n2. **\u00bfCu\u00e1les son algunos ejemplos de regulaciones BPx mencionadas en el documento?**\n   - Respuesta: Las regulaciones BPx incluyen, pero no se limitan a, Buenas Pr\u00e1cticas de Manufactura (GMP), Buenas Pr\u00e1cticas de Calidad (BPC), Buenas Pr\u00e1cticas de Laboratorio (BPL), Buenas Pr\u00e1cticas de Documentaci\u00f3n (BPD), Buenas Pr\u00e1cticas de Calidad y Buenas Pr\u00e1cticas de Farmacovigilancia.\n\n3. **\u00bfQu\u00e9 enfoques se deben adoptar para asegurar la validaci\u00f3n de sistemas computarizados seg\u00fan el documento?**\n   - Respuesta: Se deben adoptar principios del ciclo de vida, enfoques y actividades dentro del marco de planes y reportes de validaci\u00f3n, as\u00ed como la aplicaci\u00f3n de controles operativos apropiados a lo largo del ciclo de vida del sistema.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Documentaci\u00f3n del Proveedor**:\n   - La planificaci\u00f3n en la validaci\u00f3n de sistemas inform\u00e1ticos debe incluir el uso adecuado de la documentaci\u00f3n del proveedor para evitar esfuerzos duplicados. \n   - La documentaci\u00f3n debe ser evaluada en t\u00e9rminos de idoneidad, precisi\u00f3n y exhaustividad, y debe estar disponible durante todo el ciclo de vida del sistema.\n\n2. **Roles y Responsabilidades**:\n   - **Propietario del Proceso**: Responsable de la conformidad y adecuaci\u00f3n del sistema para su uso previsto, siguiendo los procedimientos operativos est\u00e1ndar a lo largo de su ciclo de vida. Este rol se basa en el conocimiento espec\u00edfico del proceso m\u00e1s que en la posici\u00f3n jer\u00e1rquica.\n   - **Propietario del Sistema**: Encargado de la disponibilidad, soporte y mantenimiento del sistema, as\u00ed como de la seguridad de los datos. Tambi\u00e9n se basa en el conocimiento espec\u00edfico del sistema. La responsabilidad del control de acceso debe ser acordada entre el propietario del proceso y el propietario del sistema.\n\n3. **Expertos en la Materia**:\n   - Individuos con profundo conocimiento en \u00e1reas espec\u00edficas (como cromatograf\u00eda o procesos de fabricaci\u00f3n). Sus responsabilidades incluyen la planificaci\u00f3n de la estrategia de verificaci\u00f3n, definici\u00f3n de criterios de aceptaci\u00f3n, selecci\u00f3n de m\u00e9todos, ejecuci\u00f3n de pruebas de verificaci\u00f3n y revisi\u00f3n de resultados.\n\n### Entidades Clave:\n- **Documentaci\u00f3n del Proveedor**\n- **Propietario del Proceso**\n- **Propietario del Sistema**\n- **Experto en la Materia (Subject Matter Expert)**\n\nEste resumen destaca la importancia de la documentaci\u00f3n adecuada, la definici\u00f3n clara de roles y la participaci\u00f3n de expertos en la validaci\u00f3n de sistemas inform\u00e1ticos en el contexto regulatorio farmac\u00e9utico.", "excerpt_keywords": "Keywords: ANVISA, BPx regulations, Computer Systems Validation, Quality Management System, Pharmaceutical Compliance"}}, "94f75d3e-f2eb-4b11-a89a-0f04baee7d73": {"node_ids": ["25b3af9f-ac91-443c-92e6-3f2f02b79c98"], "metadata": {"page_label": "10", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 5. LIFE CYCLE APPROACH\n\n## 5.1 INTRODUCTION\n\nCompliance with regulatory requirements and suitability for the intended use can be achieved by adopting a life cycle approach following Best Practices.\n\nA life cycle approach implies defining and carrying out activities in a systematic way from the conception, understanding of requirements from development, release and operational use, to system retirement.\n\nThis section of the guide presents: the life cycle of the computerized system, a general approach to specification and verification and a structure for the validation of a computerized system.\n\nAn important part of implementing the lifecycle approach for computer systems is the definition, by the regulated company, of the employees who will exercise the roles of Process Owner, System Owner and Subject Specialist, for each of the systems installed in the company.\n\nThe understanding and qualification of the employees chosen from / in their respective functions are the stone fundamental for all computerized systems to be properly chosen, validated, operationalized and retired, meeting the relevant GMP and regulatory demands.\n\n## 5.2 LIFE CYCLE OF COMPUTERIZED SYSTEMS\n\nThe life cycle of a computerized system covers all activities from the initial concept to the retirement.\n\nThe life cycle of any system consists of four phases:", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas que se pueden formular a partir del contexto proporcionado, junto con respuestas espec\u00edficas que probablemente no se encuentren en otro lugar:\n\n### Preguntas y Respuestas\n\n1. **\u00bfCu\u00e1les son los roles clave que deben definirse en una empresa regulada para implementar adecuadamente el enfoque del ciclo de vida en los sistemas computarizados?**\n   - **Respuesta:** Los roles clave que deben definirse son el Propietario del Proceso, el Propietario del Sistema y el Especialista en la Materia. Cada uno de estos roles es fundamental para asegurar que los sistemas sean elegidos, validados, operados y retirados de manera adecuada, cumpliendo con las demandas de Buenas Pr\u00e1cticas de Manufactura (GMP) y regulaciones pertinentes.\n\n2. **\u00bfQu\u00e9 implica un enfoque de ciclo de vida en la validaci\u00f3n de sistemas computarizados seg\u00fan la gu\u00eda de ANVISA?**\n   - **Respuesta:** Un enfoque de ciclo de vida implica llevar a cabo actividades de manera sistem\u00e1tica desde la concepci\u00f3n del sistema, pasando por la comprensi\u00f3n de los requisitos durante el desarrollo, hasta su liberaci\u00f3n, uso operativo y eventual retiro. Este enfoque asegura que se cumplan los requisitos regulatorios y que el sistema sea adecuado para su uso previsto.\n\n3. **\u00bfPor qu\u00e9 es fundamental la comprensi\u00f3n y calificaci\u00f3n de los empleados en el contexto de la validaci\u00f3n de sistemas computarizados?**\n   - **Respuesta:** La comprensi\u00f3n y calificaci\u00f3n de los empleados en sus respectivas funciones son fundamentales porque garantizan que los sistemas computarizados sean seleccionados, validados, operados y retirados correctamente. Esto es esencial para cumplir con las demandas regulatorias y de GMP, asegurando la integridad y eficacia del sistema a lo largo de su ciclo de vida.\n\n### Resumen de Nivel Superior\n\nEl enfoque del ciclo de vida en la validaci\u00f3n de sistemas computarizados, seg\u00fan la gu\u00eda de ANVISA, es un proceso sistem\u00e1tico que abarca desde la concepci\u00f3n del sistema hasta su retiro. Este enfoque requiere la definici\u00f3n de roles espec\u00edficos dentro de la empresa y la calificaci\u00f3n adecuada de los empleados para asegurar que se cumplan los requisitos regulatorios y de calidad. La gu\u00eda enfatiza la importancia de seguir las mejores pr\u00e1cticas para garantizar la idoneidad del sistema para su uso previsto y el cumplimiento de las normativas aplicables.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Regulaciones BPx**: \n   - Se refiere a los requisitos internacionales en la industria farmac\u00e9utica, incluyendo regulaciones de ANVISA, FDA, y normativas europeas y japonesas.\n   - Ejemplos de regulaciones BPx: Buenas Pr\u00e1cticas de Manufactura (GMP), Buenas Pr\u00e1cticas de Calidad (BPC), Buenas Pr\u00e1cticas de Laboratorio (BPL), Buenas Pr\u00e1cticas de Documentaci\u00f3n (BPD), Buenas Pr\u00e1cticas de Calidad y Buenas Pr\u00e1cticas de Farmacovigilancia.\n\n2. **Sistema de Gesti\u00f3n de Calidad**: \n   - Un sistema que dirige y controla una organizaci\u00f3n en relaci\u00f3n con la calidad.\n\n3. **Sistema Computarizado**: \n   - Compuesto por hardware, software y componentes de red, junto con funciones controladas y documentaci\u00f3n asociada.\n\n4. **Cumplimiento de Regulaciones BPx**: \n   - Los sistemas computarizados deben cumplir con las regulaciones BPx pertinentes, asegurando su conformidad.\n\n5. **Validaci\u00f3n de Sistemas Computarizados**: \n   - Proceso de obtener y mantener la conformidad con las regulaciones BPx y asegurar la idoneidad para el uso previsto.\n   - Implica la adopci\u00f3n de principios del ciclo de vida y la aplicaci\u00f3n de controles operativos a lo largo del ciclo de vida del sistema.\n\n### Entidades Clave\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil.\n- **FDA**: Administraci\u00f3n de Alimentos y Medicamentos de EE. UU.\n- **Regulaciones Internacionales**: Normativas de diferentes pa\u00edses y organizaciones que rigen la industria farmac\u00e9utica.\n- **BPx**: Conjunto de regulaciones que incluyen GMP, BPC, BPL, BPD, Buenas Pr\u00e1cticas de Calidad y Buenas Pr\u00e1cticas de Farmacovigilancia. \n\nEste resumen destaca la importancia de la regulaci\u00f3n y validaci\u00f3n de sistemas computarizados en la industria farmac\u00e9utica, as\u00ed como los componentes y principios que deben considerarse para asegurar la calidad y conformidad.", "excerpt_keywords": "Keywords: life cycle approach, computerized systems, validation, regulatory compliance, roles and responsibilities"}}, "dbf54242-7f90-49bf-a42a-72d7f92b5c5b": {"node_ids": ["c8676a15-2747-415c-9e97-fa49a6267697"], "metadata": {"page_label": "11", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "- Concept\n- Project\n- Operation\n- Retirement\n\nAn inventory of computerized systems must be maintained. An impact assessment on BPx should be carried out at the beginning of the design phase to determine whether a system is regulated by BPX, and if so, what specific regulations apply. This should be done as part of the initial risk assessment of the system. For similar systems, it may be appropriate to base the BPx assessment on the results of an assessment above, as long as the regulated company has a procedure established for such activity.\n\n## 5.2.1 Concept\n\nDuring the concept phase, the regulated company considers the opportunity to automate one or more processes based on business needs and benefits. Usually at this stage the initial requirements are developed and potential solutions are considered. Based on an initial understanding of the scope, costs and benefits, a decision is made about the progress of the design phase. It is the stage in which company makes the decision to change an activity performed manually by a system computerized.\n\n## 5.2.2 Project\n\nThe design phase involves planning, evaluating and selecting the supplier, the various levels of specification, configuration (or coding for custom applications) and verification that leads to acceptance and release for operation. Risk management is applied to identify risks and to remove or reduce them at an acceptable level.\n\nThis phase covers the activities of defining the user's requirements, based on the decision taken in the concept, followed by the evaluation and selection of the supplier to acquire the system, with consequent installation and validation of the computerized system by the regulated company. **In summary, in this stage the computerized system acquisition and validation activities.**\n\n## 5.2.3 Operation\n\nThis is usually the longest phase and is managed through the use of defined operating procedures and updated by people who have been properly trained, educated and experienced. **This phase is equivalent to practical use of the computerized system validated by the regulated company.** The maintenance control (including safety), adequacy of intended use and compliance with BPx are aspects-key. Managing changes of different impacts, scope and complexity is an activity important during this phase.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos describe un proceso estructurado que abarca cuatro fases: Concepto, Proyecto, Operaci\u00f3n y Retiro. Se enfatiza la importancia de mantener un inventario de sistemas inform\u00e1ticos y realizar una evaluaci\u00f3n de impacto en BPx al inicio de la fase de dise\u00f1o. Cada fase tiene objetivos y actividades espec\u00edficas, desde la identificaci\u00f3n de oportunidades de automatizaci\u00f3n hasta la gesti\u00f3n de cambios durante la operaci\u00f3n del sistema.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfCu\u00e1l es el prop\u00f3sito de realizar una evaluaci\u00f3n de impacto en BPx al inicio de la fase de dise\u00f1o?**\n   - La evaluaci\u00f3n de impacto en BPx tiene como objetivo determinar si un sistema est\u00e1 regulado por BPx y qu\u00e9 regulaciones espec\u00edficas se aplican, lo cual es crucial para la gesti\u00f3n de riesgos y el cumplimiento normativo desde el inicio del proyecto.\n\n2. **\u00bfQu\u00e9 actividades se llevan a cabo durante la fase de Proyecto en el proceso de validaci\u00f3n de sistemas inform\u00e1ticos?**\n   - Durante la fase de Proyecto, se realizan actividades como la planificaci\u00f3n, evaluaci\u00f3n y selecci\u00f3n del proveedor, especificaci\u00f3n de requisitos del usuario, configuraci\u00f3n o codificaci\u00f3n de aplicaciones personalizadas, y verificaci\u00f3n que conduce a la aceptaci\u00f3n y liberaci\u00f3n del sistema para su operaci\u00f3n.\n\n3. **\u00bfCu\u00e1les son los aspectos clave que se deben gestionar durante la fase de Operaci\u00f3n de un sistema inform\u00e1tico validado?**\n   - En la fase de Operaci\u00f3n, los aspectos clave incluyen el control de mantenimiento (incluyendo la seguridad), la adecuaci\u00f3n del uso previsto y el cumplimiento con BPx, as\u00ed como la gesti\u00f3n de cambios que pueden tener diferentes impactos, alcance y complejidad.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n**1. Enfoque del Ciclo de Vida:**\n   - Se propone un enfoque sistem\u00e1tico para la validaci\u00f3n de sistemas computarizados, que abarca desde la concepci\u00f3n hasta el retiro del sistema.\n   - Este enfoque asegura el cumplimiento de requisitos regulatorios y la idoneidad del sistema para su uso previsto.\n\n**2. Fases del Ciclo de Vida:**\n   - El ciclo de vida de un sistema computarizado incluye todas las actividades desde la idea inicial hasta su eventual retiro, aunque no se detallan las cuatro fases en el extracto proporcionado.\n\n**3. Roles Clave:**\n   - **Propietario del Proceso:** Responsable de la gesti\u00f3n del proceso relacionado con el sistema.\n   - **Propietario del Sistema:** Encargado de la supervisi\u00f3n y mantenimiento del sistema computarizado.\n   - **Especialista en la Materia:** Proporciona conocimientos t\u00e9cnicos y experiencia sobre el sistema.\n\n**4. Importancia de la Comprensi\u00f3n y Calificaci\u00f3n:**\n   - La comprensi\u00f3n y calificaci\u00f3n de los empleados en sus roles son fundamentales para garantizar que los sistemas sean seleccionados, validados, operados y retirados adecuadamente, cumpliendo con las Buenas Pr\u00e1cticas de Manufactura (GMP) y regulaciones pertinentes.\n\n**5. Mejores Pr\u00e1cticas:**\n   - Se enfatiza la adopci\u00f3n de mejores pr\u00e1cticas para asegurar la efectividad y cumplimiento de los sistemas computarizados a lo largo de su ciclo de vida.\n\nEste resumen destaca la importancia de un enfoque estructurado y la definici\u00f3n clara de roles en la gesti\u00f3n de sistemas computarizados dentro de un marco regulatorio.", "excerpt_keywords": "Keywords: validation, computerized systems, BPx, risk assessment, regulatory compliance"}}, "1235ada1-552c-4c0b-bb7f-bbd6d854393c": {"node_ids": ["84a23a5f-9d44-43f0-8cb1-bd700b02eaae"], "metadata": {"page_label": "12", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "## 5.2.3 Retirement\n\nIt is the final stage of the life cycle of the computerized system. **As the name says: the system is retired.** It involves decisions about data retention, migration or destruction and the management of these processes.\n\nSuppliers of products and services should be involved, where appropriate, throughout the life cycle. It may be appropriate to delegate many of the activities described to suppliers, if their assessment is satisfactory and control measures are in place. The life cycle phases are shown in figure 2.\n\n!Figure 2. The Life Cycle Stages.\n\n## 5.3 COMPUTERIZED SYSTEM VALIDATION STRUCTURE\n\n### 5.3.1 Introduction\n\nThere must be a structure for the validation of computerized systems that ensures obtaining and maintenance of service to BPX throughout the life cycle of the computerized system.\n\nThis structure is based on specific plans and reports per system and the application of operational controls appropriate. Validation plans and reports provide a consistent and disciplined approach to compliance with regulatory requirements. Such documents are valuable for preparation for / and during regulatory inspections.\n\nThe regulated company's Quality Risk Management System has the role of effectively and efficiently cover the wide variety of existing systems.\n\nIf the computerized system is part of a larger manufacturing process or system, mainly in an integrated Quality by Project (QbD) environment, the validation of the system carried out in a specific and separate may not be necessary. This environment requires a complete understanding of both process and the product and that the critical process parameters can be accurately and accurately reliability, planned and controlled within the project space. In this case, the adequacy of the system computerized to the intended use within the process, can be adequately demonstrated by the", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "### Res\u00famenes de nivel superior del contexto circundante\n\n1. **Ciclo de vida de los sistemas computarizados**: El ciclo de vida de un sistema computarizado incluye varias etapas, desde su desarrollo hasta su retiro. Cada etapa implica decisiones cr\u00edticas sobre la gesti\u00f3n del sistema, incluyendo la participaci\u00f3n de proveedores y la delegaci\u00f3n de actividades, siempre que se mantengan controles adecuados.\n\n2. **Estructura de validaci\u00f3n de sistemas computarizados**: Es esencial contar con una estructura de validaci\u00f3n que garantice el mantenimiento del servicio a lo largo del ciclo de vida del sistema. Esto incluye la elaboraci\u00f3n de planes y reportes espec\u00edficos que aseguren el cumplimiento de los requisitos regulatorios y faciliten las inspecciones.\n\n3. **Integraci\u00f3n en procesos m\u00e1s amplios**: En entornos donde el sistema computarizado forma parte de un proceso de fabricaci\u00f3n m\u00e1s amplio, especialmente en un contexto de Calidad por Dise\u00f1o (QbD), la validaci\u00f3n separada del sistema puede no ser necesaria. La comprensi\u00f3n integral del proceso y del producto es crucial para demostrar la adecuaci\u00f3n del sistema.\n\n### Preguntas espec\u00edficas que el contexto puede responder\n\n1. **\u00bfQu\u00e9 decisiones deben tomarse durante la etapa de retiro de un sistema computarizado?**\n   - El contexto menciona que durante la etapa de retiro se deben tomar decisiones sobre la retenci\u00f3n, migraci\u00f3n o destrucci\u00f3n de datos, as\u00ed como la gesti\u00f3n de estos procesos.\n\n2. **\u00bfCu\u00e1l es el papel de los proveedores en el ciclo de vida de un sistema computarizado?**\n   - Se indica que los proveedores de productos y servicios deben estar involucrados a lo largo del ciclo de vida del sistema y que es posible delegar actividades a ellos, siempre que se realice una evaluaci\u00f3n satisfactoria y se implementen medidas de control.\n\n3. **\u00bfPor qu\u00e9 puede no ser necesaria una validaci\u00f3n separada en un entorno de Calidad por Dise\u00f1o (QbD)?**\n   - En un entorno QbD, la validaci\u00f3n separada del sistema puede no ser necesaria porque se requiere una comprensi\u00f3n completa del proceso y del producto, lo que permite demostrar adecuadamente la adecuaci\u00f3n del sistema a su uso previsto dentro del proceso.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos se centra en un proceso estructurado que abarca cuatro fases principales: **Concepto**, **Proyecto**, **Operaci\u00f3n** y **Retiro**. A continuaci\u00f3n se presentan los temas clave y entidades relevantes de cada fase:\n\n1. **Concepto**\n   - **Objetivo**: Evaluar la oportunidad de automatizar procesos basados en necesidades y beneficios empresariales.\n   - **Actividades**: Desarrollo de requisitos iniciales y consideraci\u00f3n de soluciones potenciales.\n   - **Decisi\u00f3n**: Determinar si avanzar a la fase de dise\u00f1o.\n\n2. **Proyecto**\n   - **Objetivo**: Planificaci\u00f3n y dise\u00f1o del sistema inform\u00e1tico.\n   - **Actividades**: \n     - Evaluaci\u00f3n y selecci\u00f3n del proveedor.\n     - Especificaci\u00f3n de requisitos del usuario.\n     - Configuraci\u00f3n o codificaci\u00f3n de aplicaciones personalizadas.\n     - Verificaci\u00f3n para aceptaci\u00f3n y liberaci\u00f3n del sistema.\n   - **Gesti\u00f3n de Riesgos**: Identificaci\u00f3n y mitigaci\u00f3n de riesgos.\n\n3. **Operaci\u00f3n**\n   - **Objetivo**: Uso pr\u00e1ctico del sistema validado.\n   - **Actividades**: \n     - Mantenimiento controlado del sistema.\n     - Aseguramiento de la adecuaci\u00f3n del uso previsto.\n     - Cumplimiento con regulaciones BPx.\n     - Gesti\u00f3n de cambios con diferentes impactos y complejidades.\n   - **Importancia**: Esta fase es la m\u00e1s prolongada y requiere personal capacitado.\n\n4. **Retiro**\n   - Aunque no se detalla en el texto proporcionado, se infiere que esta fase implica la desactivaci\u00f3n y eliminaci\u00f3n segura de sistemas obsoletos o no utilizados.\n\n### Entidades Clave\n- **BPx**: Regulaciones que deben ser consideradas durante la evaluaci\u00f3n de impacto y gesti\u00f3n de riesgos.\n- **Sistemas Inform\u00e1ticos**: Elementos que deben ser validados y mantenidos a lo largo de su ciclo de vida.\n- **Proveedor**: Entidad seleccionada para la adquisici\u00f3n del sistema.\n\nEste resumen destaca la importancia de un enfoque sistem\u00e1tico en la validaci\u00f3n de sistemas inform\u00e1ticos, asegurando el cumplimiento normativo y la gesti\u00f3n efectiva de riesgos a lo largo de todas las fases del ciclo de vida del sistema.", "excerpt_keywords": "Keywords: retirement, computerized systems, validation structure, regulatory compliance, Quality by Design"}}, "e7b278b6-e0af-45d1-a230-c28eb69e443f": {"node_ids": ["0ed97d4b-d4d7-4fb3-a169-8946a117ebbf"], "metadata": {"page_label": "13", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 5.3.2 Terminology\n\nThe specific terminology used to describe life cycle activities varies from company to company. System type to another. There are several reasons for this:\n\n- Regulated companies use different approaches;\n- There is a difference in emphasis on BLP, BPC, GMP and medical devices;\n- There are differences in the requirements of the various regulatory agencies;\n- Different standards, local and international, are followed;\n- There are different types of computerized systems (IT, manufacturing, laboratories);\n- Suppliers use different models and development approaches.\n\nThis Guide, in harmony with the document GAMP 5, is intended to be flexible and is not intended to prescribe a single set of terms, excluding others.\n\nTable 1 shows the relationship between the traditional terminology for Qualification and the activities described in this Guide.\n\nThe terms used to describe the systems verification stage are the ones that have the greatest diversity. This section describes how the terminology traditionally used for qualification relates to with the activities described in this Guide.\n\nWhatever the terminology used by the company, the requirement that overlaps everything is that the regulated company can demonstrate that the system is compliant and suitable for its intended use.\n\nThe use of qualification terminology in relation to computerized systems and the relationship between QO and QD particularly, varies from company to company.\n\nIt is up to companies to decide on the verification strategy they will use.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas que pueden proporcionar respuestas espec\u00edficas basadas en el contexto proporcionado:\n\n1. **\u00bfCu\u00e1les son las razones por las que la terminolog\u00eda utilizada para describir las actividades del ciclo de vida var\u00eda entre diferentes empresas y tipos de sistemas?**\n   - Respuesta: La variaci\u00f3n en la terminolog\u00eda se debe a varios factores, incluyendo diferentes enfoques utilizados por empresas reguladas, diferencias en el \u00e9nfasis en BLP, BPC, GMP y dispositivos m\u00e9dicos, requisitos diversos de agencias regulatorias, est\u00e1ndares locales e internacionales, tipos de sistemas computarizados (como IT, manufactura y laboratorios), y modelos y enfoques de desarrollo utilizados por los proveedores.\n\n2. **\u00bfQu\u00e9 relaci\u00f3n existe entre la terminolog\u00eda tradicional de calificaci\u00f3n y las actividades descritas en la Gu\u00eda de ANVISA?**\n   - Respuesta: La Gu\u00eda de ANVISA, en armon\u00eda con el documento GAMP 5, establece una relaci\u00f3n entre la terminolog\u00eda tradicional de calificaci\u00f3n y las actividades descritas en la gu\u00eda. Aunque la terminolog\u00eda puede variar, el requisito fundamental es que la empresa regulada demuestre que el sistema es conforme y adecuado para su uso previsto.\n\n3. **\u00bfQu\u00e9 papel juega la flexibilidad en la terminolog\u00eda utilizada en la Gu\u00eda de ANVISA en comparaci\u00f3n con otros est\u00e1ndares?**\n   - Respuesta: La Gu\u00eda de ANVISA es intencionadamente flexible y no prescribe un conjunto \u00fanico de t\u00e9rminos, lo que permite a las empresas adaptar su terminolog\u00eda y estrategias de verificaci\u00f3n seg\u00fan sus necesidades espec\u00edficas y el contexto regulatorio en el que operan.\n\n### Resumen de nivel superior del contexto circundante:\nEl contexto se centra en la variabilidad de la terminolog\u00eda utilizada en la validaci\u00f3n de sistemas computarizados en empresas reguladas. Destaca la importancia de que las empresas demuestren la conformidad y adecuaci\u00f3n de sus sistemas, independientemente de la terminolog\u00eda espec\u00edfica que utilicen. La Gu\u00eda de ANVISA busca ser flexible y se alinea con el documento GAMP 5, permitiendo a las empresas decidir su propia estrategia de verificaci\u00f3n.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Retiro de Sistemas Computarizados**:\n   - El retiro es la etapa final del ciclo de vida de un sistema computarizado, donde se toman decisiones sobre la retenci\u00f3n, migraci\u00f3n o destrucci\u00f3n de datos.\n   - Es fundamental gestionar adecuadamente estos procesos.\n\n2. **Participaci\u00f3n de Proveedores**:\n   - Los proveedores de productos y servicios deben estar involucrados a lo largo del ciclo de vida del sistema.\n   - Se puede delegar actividades a proveedores, siempre que se realice una evaluaci\u00f3n satisfactoria y se implementen controles adecuados.\n\n3. **Estructura de Validaci\u00f3n**:\n   - Es esencial contar con una estructura de validaci\u00f3n que garantice el mantenimiento del servicio durante todo el ciclo de vida del sistema.\n   - Esta estructura incluye planes y reportes espec\u00edficos que aseguran el cumplimiento de requisitos regulatorios y facilitan las inspecciones.\n\n4. **Calidad por Dise\u00f1o (QbD)**:\n   - En entornos donde el sistema computarizado forma parte de un proceso de fabricaci\u00f3n m\u00e1s amplio, la validaci\u00f3n separada puede no ser necesaria.\n   - Se requiere una comprensi\u00f3n integral del proceso y del producto para demostrar la adecuaci\u00f3n del sistema a su uso previsto.\n\n### Entidades Clave\n- **Ciclo de Vida del Sistema Computarizado**: Incluye etapas desde el desarrollo hasta el retiro.\n- **Proveedores**: Entidades que ofrecen productos y servicios relacionados con el sistema.\n- **Planes y Reportes de Validaci\u00f3n**: Documentos que aseguran el cumplimiento regulatorio.\n- **Sistema de Gesti\u00f3n de Riesgos de Calidad**: Herramienta utilizada por la empresa regulada para gestionar la variedad de sistemas existentes.\n- **Entorno de Calidad por Dise\u00f1o (QbD)**: Contexto en el que se eval\u00faa la necesidad de validaci\u00f3n separada del sistema.", "excerpt_keywords": "Keywords: validation, terminology, compliance, computerized systems, regulatory agencies"}}, "5d32fec2-7ef7-429b-9904-0bc2d4d9daef": {"node_ids": ["d1711c4a-a00f-4a42-b5ec-3ca221788f30"], "metadata": {"page_label": "14", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# Table 1. Relationship between the traditional terminology for qualification and the activities described in this Guide.\n\n| Traditional term                | description                                                                 | Verification Activity - Guide                                                                 |\n|---------------------------------|-----------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------|\n| Project Qualification (QP / DQ) | Documented verification of that the proposed project for installations, systems and equipment is suitable for the intended purpose | Project Review                                                                                |\n| Installation Qualification (IQ / IQ) | Documented verification of that the system has been installed according written specifications is pre-approved. | Verification, testing or other verification to demonstrate that the activities of installation and configuration of **hardware and software** were realized correctly |\n| Operational Qualification (QO / OQ) | Documented verification of that the system operates according to specifications writing is pre-approved and across the operational range specified. | Conducting tests or another system check against specifications for demonstrate correct functionality operation that supports the process specific business across to written specifications is pre-approved |\n| Performance Qualification (QD / PQ) | Documented verification of that the system is capable of perform activities processes as expected, according to written specifications is pre-approved, within the scope of the business process and operating environment. | Conducting tests or another system check to demonstrate suitability intended use and for allow acceptance of the system from specified requirements |\n\n# 6. QUALITY RISK MANAGEMENT\n\n## 6.1 INTRODUCTION\n\nQuality risk management consists of a systematic process for assessing, controlling, communication and risk review. It is an iterative process used throughout the life cycle of the system from conception to retirement. Figure 3 presents this concept graphically.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos establece una relaci\u00f3n entre la terminolog\u00eda tradicional de calificaci\u00f3n y las actividades descritas en la gu\u00eda. Se detallan cuatro tipos de calificaci\u00f3n: calificaci\u00f3n de proyecto (QP/DQ), calificaci\u00f3n de instalaci\u00f3n (IQ/IQ), calificaci\u00f3n operativa (QO/OQ) y calificaci\u00f3n de rendimiento (QD/PQ). Cada tipo incluye una descripci\u00f3n y las actividades de verificaci\u00f3n correspondientes. Adem\u00e1s, se introduce el concepto de gesti\u00f3n de riesgos de calidad, que es un proceso sistem\u00e1tico y continuo a lo largo del ciclo de vida del sistema.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfCu\u00e1l es la diferencia entre la calificaci\u00f3n de instalaci\u00f3n (IQ) y la calificaci\u00f3n operativa (OQ) seg\u00fan la gu\u00eda de ANVISA?**\n   - La calificaci\u00f3n de instalaci\u00f3n (IQ) se centra en verificar que el sistema se haya instalado de acuerdo con las especificaciones escritas y preaprobadas, mientras que la calificaci\u00f3n operativa (OQ) se enfoca en verificar que el sistema funcione correctamente seg\u00fan las especificaciones a lo largo de su rango operativo.\n\n2. **\u00bfQu\u00e9 actividades de verificaci\u00f3n se recomiendan para la calificaci\u00f3n de rendimiento (PQ) en el contexto de la gu\u00eda de ANVISA?**\n   - Para la calificaci\u00f3n de rendimiento (PQ), se recomienda realizar pruebas u otras verificaciones para demostrar que el sistema es adecuado para su uso previsto y que cumple con los requisitos especificados.\n\n3. **\u00bfC\u00f3mo se describe el proceso de gesti\u00f3n de riesgos de calidad en el ciclo de vida del sistema seg\u00fan el documento?**\n   - La gesti\u00f3n de riesgos de calidad se describe como un proceso sistem\u00e1tico que incluye la evaluaci\u00f3n, control, comunicaci\u00f3n y revisi\u00f3n de riesgos. Este proceso es iterativo y se utiliza a lo largo de todo el ciclo de vida del sistema, desde su concepci\u00f3n hasta su retiro.", "prev_section_summary": "### Resumen de la Secci\u00f3n 5.3.2: Terminolog\u00eda\n\n**Temas Clave:**\n\n1. **Variabilidad de la Terminolog\u00eda:**\n   - La terminolog\u00eda utilizada para describir las actividades del ciclo de vida de los sistemas computarizados var\u00eda entre empresas y tipos de sistemas debido a diversos factores, como enfoques regulatorios, \u00e9nfasis en diferentes normativas (BLP, BPC, GMP, dispositivos m\u00e9dicos), requisitos de agencias regulatorias, y est\u00e1ndares locales e internacionales.\n\n2. **Flexibilidad de la Gu\u00eda:**\n   - La Gu\u00eda de ANVISA, en consonancia con el documento GAMP 5, busca ser flexible y no prescribe un conjunto \u00fanico de t\u00e9rminos, permitiendo a las empresas adaptar su terminolog\u00eda seg\u00fan sus necesidades.\n\n3. **Relaci\u00f3n entre Terminolog\u00eda y Actividades:**\n   - Se establece una relaci\u00f3n entre la terminolog\u00eda tradicional de calificaci\u00f3n y las actividades descritas en la gu\u00eda, especialmente en la etapa de verificaci\u00f3n de sistemas, que presenta la mayor diversidad terminol\u00f3gica.\n\n4. **Requisitos de Conformidad:**\n   - Independientemente de la terminolog\u00eda utilizada, las empresas reguladas deben demostrar que sus sistemas son conformes y adecuados para su uso previsto.\n\n5. **Estrategia de Verificaci\u00f3n:**\n   - Las empresas tienen la libertad de decidir su propia estrategia de verificaci\u00f3n, lo que implica que la terminolog\u00eda y los enfoques pueden variar significativamente entre diferentes organizaciones.\n\n**Entidades:**\n\n- **ANVISA:** Agencia Nacional de Vigilancia Sanitaria de Brasil.\n- **GAMP 5:** Buenas Pr\u00e1cticas de Automatizaci\u00f3n y Validaci\u00f3n de Sistemas.\n- **BLP, BPC, GMP:** Normativas relacionadas con la calidad y regulaci\u00f3n en la industria.\n- **Tipos de Sistemas Computarizados:** IT, manufactura, laboratorios.\n- **Agencias Regulatorias:** Entidades que establecen requisitos y est\u00e1ndares para la conformidad de los sistemas. \n\nEste resumen destaca la importancia de la flexibilidad y la adaptabilidad en la terminolog\u00eda y enfoques utilizados por las empresas reguladas en la validaci\u00f3n de sistemas computarizados.", "excerpt_keywords": "Keywords: validation, qualification, risk management, ANVISA, computer systems"}}, "8ab28ffd-7b16-434d-b047-d1a558e705db": {"node_ids": ["4f11fb41-89c6-48ef-8841-01b6f2d72544"], "metadata": {"page_label": "15", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 6.2 QUALITY RISK MANAGEMENT WITH SCIENTIFIC BASIS\n\nDetermining the risks inherent in a computerized system requires an understanding of the following points:\n\n- The impact of the computerized system on patient safety, product quality and data integrity;\n- The business processes supported by the system;\n- Critical Quality Attributes (CQA) for systems that monitor or control Parameters Process Critics (CPPs);\n- User requirements;\n- Regulatory requirements;\n- The project approach (contracts, methods, schedules);\n- System components and architecture;\n- System functions;\n- Supplier capability.\n\nThe company must also consider other applicable risks such as safety, health and the environment.\n\n----\n\n**Figure 3. A Risk-Based Approach for Computer Systems Compatible with BPx.**\nSource: GAMP5", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior que puede ayudar a formularlas:\n\n### Resumen de Nivel Superior:\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos destaca la importancia de la gesti\u00f3n de riesgos de calidad con base cient\u00edfica. Para determinar los riesgos inherentes a un sistema computarizado, se deben considerar varios factores, como el impacto en la seguridad del paciente, la calidad del producto y la integridad de los datos. Tambi\u00e9n se enfatiza la necesidad de evaluar atributos cr\u00edticos de calidad, requisitos de usuario y regulaciones, as\u00ed como la capacidad del proveedor y otros riesgos aplicables.\n\n### Preguntas:\n1. **\u00bfCu\u00e1les son los Atributos Cr\u00edticos de Calidad (CQA) que deben considerarse al evaluar un sistema que controla Par\u00e1metros Cr\u00edticos de Proceso (CPP)?**\n   - Esta pregunta busca informaci\u00f3n espec\u00edfica sobre los CQA relevantes en el contexto de la validaci\u00f3n de sistemas inform\u00e1ticos, que no se detalla en otras fuentes.\n\n2. **\u00bfQu\u00e9 aspectos del enfoque del proyecto deben ser considerados para la gesti\u00f3n de riesgos en la validaci\u00f3n de sistemas inform\u00e1ticos?**\n   - Esta pregunta se centra en los elementos del enfoque del proyecto, como contratos y m\u00e9todos, que son cruciales para la gesti\u00f3n de riesgos, y que pueden no estar claramente definidos en otros documentos.\n\n3. **\u00bfQu\u00e9 tipo de riesgos adicionales, m\u00e1s all\u00e1 de los relacionados con la calidad y la seguridad del paciente, deben ser considerados por las empresas al validar sistemas inform\u00e1ticos?**\n   - Esta pregunta busca explorar otros riesgos aplicables, como los relacionados con la salud y el medio ambiente, que son mencionados en el contexto pero que pueden no ser ampliamente discutidos en otras gu\u00edas o normativas.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Terminolog\u00eda de Calificaci\u00f3n**:\n   - El documento establece una relaci\u00f3n entre t\u00e9rminos tradicionales de calificaci\u00f3n y actividades de verificaci\u00f3n.\n   - Se identifican cuatro tipos de calificaci\u00f3n:\n     - **Calificaci\u00f3n de Proyecto (QP/DQ)**: Verificaci\u00f3n documentada de la idoneidad del proyecto.\n     - **Calificaci\u00f3n de Instalaci\u00f3n (IQ/IQ)**: Verificaci\u00f3n de que el sistema se ha instalado seg\u00fan especificaciones preaprobadas.\n     - **Calificaci\u00f3n Operativa (OQ)**: Verificaci\u00f3n de que el sistema opera correctamente dentro de su rango operativo.\n     - **Calificaci\u00f3n de Rendimiento (PQ)**: Verificaci\u00f3n de que el sistema puede realizar actividades seg\u00fan lo esperado.\n\n2. **Actividades de Verificaci\u00f3n**:\n   - Cada tipo de calificaci\u00f3n incluye actividades espec\u00edficas de verificaci\u00f3n, como revisiones de proyectos, pruebas de instalaci\u00f3n, y chequeos de funcionalidad.\n\n3. **Gesti\u00f3n de Riesgos de Calidad**:\n   - Se introduce el concepto de gesti\u00f3n de riesgos de calidad como un proceso sistem\u00e1tico que abarca la evaluaci\u00f3n, control, comunicaci\u00f3n y revisi\u00f3n de riesgos.\n   - Este proceso es iterativo y se aplica a lo largo del ciclo de vida del sistema, desde su concepci\u00f3n hasta su retiro.\n\n### Entidades Clave:\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil.\n- **Calificaci\u00f3n de Proyecto (QP/DQ)**.\n- **Calificaci\u00f3n de Instalaci\u00f3n (IQ/IQ)**.\n- **Calificaci\u00f3n Operativa (OQ)**.\n- **Calificaci\u00f3n de Rendimiento (PQ)**.\n- **Gesti\u00f3n de Riesgos de Calidad**. \n\nEste resumen destaca la estructura y los conceptos fundamentales presentados en la gu\u00eda de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos.", "excerpt_keywords": "Keywords: Quality Risk Management, Computerized Systems, Critical Quality Attributes, Regulatory Requirements, Supplier Capability"}}, "5a11b3f2-3c48-4c12-a4f1-a005f6dcc9b7": {"node_ids": ["9d7f17e3-ce33-48e0-8a01-9ccf3c5c291f"], "metadata": {"page_label": "16", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 6.3 QUALITY RISK MANAGEMENT PROCESS\n\nThere is an international guide available (ICH Q9) that deals with quality risk management within the pharmaceutical industry.\n\nIt defines the two primary principles of quality risk management, namely:\n\n* Quality risk assessment should be based on scientific knowledge and linked to the patient protection;\n* The level of effort, formality and documentation of the quality risk management process must be commensurate with the level of risk.\n\nIn the context of computerized systems, scientific knowledge is based on the specifications of the system and the business process that the system supports.\n\nThe quality risk management process involves the execution of 05 (five) steps:\n\n1. Performing the initial risk assessment and determining the impact of the system;\n2. Identification of functions that have an impact on patient safety, product quality and data integrity;\n3. Performing functional risk assessments and identifying the necessary controls;\n4. Implementation and verification of appropriate controls;\n5. Review of risks and monitoring of implemented controls.\n\nThese steps are detailed below.\n\n## 6.3.1 Step 1 - Initial Risk Assessment\n\nAn initial risk analysis should be carried out based on an understanding of the processes and risk assessments business requirements, user requirements, regulatory requirements and known functional areas.\n\nThe results of this initial risk assessment should include the decision on whether the system is regulated by BPx (BPx evaluation). A general assessment of the system's impact should also be included.\n\nBased on this initial risk assessment and system impact it may not be necessary to perform the steps subsequent risks if the risk is already at an acceptable level.\n\nThe necessary effort, formalization and documentation of the subsequent steps must be determined with based on the level of risk and the impact of the system on BPx.\n\n## 6.3.2 Step 2 - Identification of Functions\n\nFunctions that impact patient safety, product quality and data integrity should be identified by the construction of the information gathered in step 1, referring to the specifications relevant and taking into account the project approach, the system architecture and the categorization of system components.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos establece un proceso de gesti\u00f3n de riesgos de calidad que se basa en principios internacionales, espec\u00edficamente el ICH Q9. Este proceso consta de cinco pasos que incluyen la evaluaci\u00f3n inicial de riesgos, la identificaci\u00f3n de funciones cr\u00edticas, la evaluaci\u00f3n de riesgos funcionales, la implementaci\u00f3n de controles y la revisi\u00f3n continua de riesgos. Se enfatiza que la evaluaci\u00f3n de riesgos debe estar fundamentada en el conocimiento cient\u00edfico y que el esfuerzo y la documentaci\u00f3n deben ser proporcionales al nivel de riesgo identificado.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfCu\u00e1les son los dos principios fundamentales de la gesti\u00f3n de riesgos de calidad seg\u00fan el ICH Q9 y c\u00f3mo se aplican en el contexto de los sistemas inform\u00e1ticos?**\n   - Respuesta: Los dos principios fundamentales son que la evaluaci\u00f3n de riesgos de calidad debe basarse en el conocimiento cient\u00edfico y estar vinculada a la protecci\u00f3n del paciente, y que el nivel de esfuerzo, formalidad y documentaci\u00f3n del proceso de gesti\u00f3n de riesgos debe ser proporcional al nivel de riesgo.\n\n2. **\u00bfQu\u00e9 factores se deben considerar al realizar la evaluaci\u00f3n inicial de riesgos en un sistema inform\u00e1tico?**\n   - Respuesta: La evaluaci\u00f3n inicial de riesgos debe basarse en la comprensi\u00f3n de los procesos y requisitos de negocio, requisitos de usuario, requisitos regulatorios y \u00e1reas funcionales conocidas.\n\n3. **\u00bfQu\u00e9 pasos se deben seguir despu\u00e9s de la identificaci\u00f3n de funciones que impactan la seguridad del paciente y la calidad del producto?**\n   - Respuesta: Despu\u00e9s de identificar las funciones cr\u00edticas, se deben realizar evaluaciones de riesgos funcionales, identificar los controles necesarios, implementar y verificar los controles apropiados, y finalmente revisar los riesgos y monitorear los controles implementados.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\nLa secci\u00f3n 6.2 del documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos se centra en la gesti\u00f3n de riesgos de calidad con base cient\u00edfica. Los temas clave incluyen:\n\n1. **Riesgos Inherentes a Sistemas Computarizados**: Se enfatiza la necesidad de comprender los riesgos asociados a los sistemas inform\u00e1ticos, considerando su impacto en la seguridad del paciente, la calidad del producto y la integridad de los datos.\n\n2. **Factores a Considerar**:\n   - **Impacto en la Seguridad del Paciente**: Evaluar c\u00f3mo el sistema afecta la salud y seguridad de los pacientes.\n   - **Calidad del Producto**: Asegurar que el sistema mantenga los est\u00e1ndares de calidad del producto.\n   - **Integridad de los Datos**: Proteger la precisi\u00f3n y consistencia de los datos gestionados por el sistema.\n   - **Procesos de Negocio**: Identificar los procesos que el sistema soporta.\n   - **Atributos Cr\u00edticos de Calidad (CQA)**: Considerar los CQA relevantes para sistemas que controlan Par\u00e1metros Cr\u00edticos de Proceso (CPP).\n   - **Requisitos de Usuario y Regulatorios**: Evaluar las necesidades de los usuarios y las normativas aplicables.\n   - **Enfoque del Proyecto**: Incluir aspectos como contratos, m\u00e9todos y cronogramas en la gesti\u00f3n de riesgos.\n   - **Componentes y Arquitectura del Sistema**: Analizar la estructura y funciones del sistema.\n   - **Capacidad del Proveedor**: Evaluar la competencia y capacidad del proveedor del sistema.\n\n3. **Riesgos Adicionales**: Las empresas deben considerar otros riesgos aplicables, como los relacionados con la seguridad, la salud y el medio ambiente.\n\n### Entidades Clave\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil.\n- **CQA (Atributos Cr\u00edticos de Calidad)**: Elementos esenciales que deben ser controlados para asegurar la calidad del producto.\n- **CPP (Par\u00e1metros Cr\u00edticos de Proceso)**: Variables que deben ser controladas para garantizar la calidad del proceso.\n- **GAMP5**: Buenas Pr\u00e1cticas de Automatizaci\u00f3n y Validaci\u00f3n de Sistemas.\n\nEste resumen destaca la importancia de un enfoque integral y basado en riesgos para la validaci\u00f3n de sistemas inform\u00e1ticos en el contexto de la regulaci\u00f3n sanitaria.", "excerpt_keywords": "Keywords: quality risk management, ANVISA, computerized systems, patient safety, regulatory requirements"}}, "b647fc95-5d2f-4a34-bbbd-cc7bb64d1536": {"node_ids": ["1cef5e62-ef32-44a4-8cc0-fdf95becdca7"], "metadata": {"page_label": "17", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 6.3.3 Step 3 - Functional Risk Assessment\n\nThe functions identified in step 2 must be evaluated considering the possible dangers and how the potential damage from these hazards can be controlled.\n\nIt may be necessary to perform a more detailed assessment that subsequently analyzes the severity of the damage, the probability of occurrence and the probability of detection.\n\n*Guide for Computer Systems Validation*\n*Guide n\u00b0 33/2020 - version 1, of 03/26/2020*\n\n----\n\n## Page 16\n\nThe judgment, on whether or not to carry out a detailed assessment of specific functions, must be carried out case by case and the criteria may vary. The criteria to be taken into account are:\n\n- The criticality of the supported processes;\n- The specific impact of functions within the process;\n- The nature of the system (complexity and innovation).\n\nAppropriate controls should be identified based on the assessment carried out. There are a range of options available to carry out the required control depending on the identified risk. Controls include, among others:\n\n- Modification of the process design;\n- Modification of the system design;\n- Application of external procedures;\n- Increased details or formality of specifications;\n- Increasing the number and level of details of design reviews;\n- Increasing the extent or rigor of verification activities.\n\nWhere possible, it is preferable that risk elimination is carried out at the project level.\n\n# 6.3.4 Implementation and Verification of Controls\n\nThe control measures identified in step 3 should be implemented and verified to ensure that they have been successfully deployed. Controls must be traceable to the relevant risks identified.\n\nThe verification activity must demonstrate that the controls are effective in implementing the risk reduction required.\n\n# 6.3.5 Risk Review and Monitoring of Controls\n\nDuring the periodic system review, or at other defined opportunities, the company must review the risks. The check must show whether the controls are still effective and corrective actions must be taken, carried out if deficiencies are found.\n\nThe company should also consider the following points:", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior del contenido:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos establece un proceso estructurado para la evaluaci\u00f3n de riesgos funcionales en sistemas. En la secci\u00f3n 6.3.3, se enfatiza la importancia de evaluar las funciones identificadas en funci\u00f3n de los peligros potenciales y el da\u00f1o que pueden causar. Se sugiere que la evaluaci\u00f3n de riesgos debe ser detallada y considerar la gravedad del da\u00f1o, la probabilidad de ocurrencia y la probabilidad de detecci\u00f3n. Adem\u00e1s, se deben identificar controles apropiados basados en la evaluaci\u00f3n de riesgos, y estos controles deben ser implementados y verificados para asegurar su efectividad. Finalmente, se menciona la necesidad de revisar peri\u00f3dicamente los riesgos y la efectividad de los controles.\n\n### Preguntas Espec\u00edficas\n1. **\u00bfCu\u00e1les son los criterios que se deben considerar al decidir si realizar una evaluaci\u00f3n detallada de funciones espec\u00edficas en un sistema?**\n   - La decisi\u00f3n debe basarse en la criticalidad de los procesos soportados, el impacto espec\u00edfico de las funciones dentro del proceso y la naturaleza del sistema, que incluye su complejidad e innovaci\u00f3n.\n\n2. **\u00bfQu\u00e9 tipos de controles se pueden implementar para mitigar los riesgos identificados en la evaluaci\u00f3n funcional?**\n   - Los controles pueden incluir la modificaci\u00f3n del dise\u00f1o del proceso o del sistema, la aplicaci\u00f3n de procedimientos externos, el aumento de detalles o formalidad en las especificaciones, y el incremento en el n\u00famero y rigor de las revisiones de dise\u00f1o y actividades de verificaci\u00f3n.\n\n3. **\u00bfQu\u00e9 pasos deben seguirse para asegurar que los controles implementados son efectivos en la reducci\u00f3n de riesgos?**\n   - Los controles deben ser implementados y verificados para asegurar que han sido desplegados con \u00e9xito. La actividad de verificaci\u00f3n debe demostrar que los controles son efectivos en la reducci\u00f3n del riesgo requerido, y se deben realizar revisiones peri\u00f3dicas para evaluar la efectividad continua de los controles y tomar acciones correctivas si se encuentran deficiencias.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n**Temas Clave:**\n\n1. **Gesti\u00f3n de Riesgos de Calidad:** Se basa en el ICH Q9 y establece principios fundamentales para la evaluaci\u00f3n de riesgos en la industria farmac\u00e9utica.\n2. **Principios Fundamentales:**\n   - La evaluaci\u00f3n de riesgos debe fundamentarse en el conocimiento cient\u00edfico y estar vinculada a la protecci\u00f3n del paciente.\n   - El esfuerzo y la documentaci\u00f3n del proceso deben ser proporcionales al nivel de riesgo.\n3. **Proceso de Gesti\u00f3n de Riesgos:** Comprende cinco pasos:\n   - Evaluaci\u00f3n inicial de riesgos.\n   - Identificaci\u00f3n de funciones cr\u00edticas.\n   - Evaluaciones de riesgos funcionales.\n   - Implementaci\u00f3n y verificaci\u00f3n de controles.\n   - Revisi\u00f3n y monitoreo de riesgos y controles.\n4. **Evaluaci\u00f3n Inicial de Riesgos:** Implica entender procesos, requisitos de negocio, de usuario y regulatorios, as\u00ed como determinar el impacto del sistema.\n5. **Identificaci\u00f3n de Funciones:** Se centra en identificar funciones que afectan la seguridad del paciente, la calidad del producto y la integridad de los datos, bas\u00e1ndose en la informaci\u00f3n recopilada en la evaluaci\u00f3n inicial.\n\n**Entidades:**\n\n- **ICH Q9:** Gu\u00eda internacional sobre gesti\u00f3n de riesgos de calidad.\n- **BPx:** Referencia a la regulaci\u00f3n que puede aplicar al sistema evaluado.\n- **Sistemas Inform\u00e1ticos:** Contexto en el que se aplica la gesti\u00f3n de riesgos de calidad.\n\nEste resumen destaca la importancia de un enfoque sistem\u00e1tico y basado en el riesgo para la validaci\u00f3n de sistemas inform\u00e1ticos en la industria farmac\u00e9utica, asegurando la protecci\u00f3n del paciente y la calidad del producto.", "excerpt_keywords": "Keywords: risk assessment, controls implementation, system validation, functional evaluation, regulatory compliance"}}, "0f629c74-6df3-43ab-9eb1-75dc782d9d21": {"node_ids": ["00e0e258-c7b5-4d48-af42-0241fff302c4"], "metadata": {"page_label": "18", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 7. SOFTWARE AND HARDWARE CATEGORIZATION\n\n## 7.1 INTRODUCTION\n\nThis section describes how the **software** and **hardware** components can be analyzed and categorized. These **software** and **hardware** categories can then be used in conjunction with the Risk Assessment and Assessment Supplier to establish an appropriate life cycle strategy.\n\nCategories 3 to 5 have no absolute boundaries and that the activities recommended for a given category may be suitable for a system or component that belongs to the other category.\n\n## 7.2 USE OF GAMP CATEGORIES\n\nThere is usually an increased risk of failure and defects when progressing a set **software-hardware** standard for a set **software - hardware** customized. The increased risk comes from combination of greater complexity and less user experience. Categorization can be part of an effective approach to quality risk management when coupled with risk assessment and supplier evaluation.\n\nMost systems have components of varying complexity, such as an operating system, non-configured components, and configured or customized components. The effort must be concentrated in the following proportion: Customized > Configured > Not Configured > Infrastructure. Categorization can help focus the effort where the risk is greatest.\n\nThere are two main ways of using categories:\n\n- Evaluation of the system in a holistic way;\n- Detailed evaluation by component.\n\nIn the holistic assessment, the main component category can be used to help define the approach for supplier evaluation or selection of results to be delivered in the life cycle. The combination of categorization with the impact assessment of the system can help you decide whether a supplier audit is necessary.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "### Resumen del contexto\n\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos aborda la categorizaci\u00f3n de software y hardware como parte de un enfoque de gesti\u00f3n de riesgos de calidad. Se enfatiza la importancia de clasificar los componentes de software y hardware para identificar y mitigar riesgos, especialmente en sistemas personalizados que presentan mayor complejidad. Se mencionan dos enfoques para la categorizaci\u00f3n: una evaluaci\u00f3n hol\u00edstica del sistema y una evaluaci\u00f3n detallada por componente. La categorizaci\u00f3n ayuda a enfocar los esfuerzos de validaci\u00f3n donde el riesgo es mayor y puede influir en la necesidad de auditor\u00edas de proveedores.\n\n### Preguntas espec\u00edficas\n\n1. **\u00bfCu\u00e1les son las proporciones recomendadas para concentrar los esfuerzos de validaci\u00f3n en funci\u00f3n de la complejidad de los componentes de software y hardware?**\n   - La proporci\u00f3n recomendada es: Personalizado > Configurado > No Configurado > Infraestructura.\n\n2. **\u00bfQu\u00e9 dos enfoques se sugieren para utilizar las categor\u00edas en la evaluaci\u00f3n de sistemas?**\n   - Los dos enfoques son: la evaluaci\u00f3n del sistema de manera hol\u00edstica y la evaluaci\u00f3n detallada por componente.\n\n3. **\u00bfC\u00f3mo puede la categorizaci\u00f3n ayudar en la decisi\u00f3n de realizar una auditor\u00eda de proveedores?**\n   - La combinaci\u00f3n de la categorizaci\u00f3n con la evaluaci\u00f3n de impacto del sistema puede ayudar a determinar si es necesaria una auditor\u00eda de proveedores, bas\u00e1ndose en el riesgo asociado a los componentes del sistema.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Evaluaci\u00f3n de Riesgos Funcionales**:\n   - La secci\u00f3n 6.3.3 se centra en la evaluaci\u00f3n de las funciones identificadas en un sistema, considerando los peligros potenciales y el da\u00f1o que pueden causar.\n   - Se sugiere realizar una evaluaci\u00f3n detallada que analice la gravedad del da\u00f1o, la probabilidad de ocurrencia y la probabilidad de detecci\u00f3n.\n\n2. **Criterios para Evaluaci\u00f3n Detallada**:\n   - La decisi\u00f3n de llevar a cabo una evaluaci\u00f3n detallada debe basarse en:\n     - La criticalidad de los procesos soportados.\n     - El impacto espec\u00edfico de las funciones dentro del proceso.\n     - La naturaleza del sistema, incluyendo su complejidad e innovaci\u00f3n.\n\n3. **Controles Apropiados**:\n   - Se deben identificar controles basados en la evaluaci\u00f3n de riesgos. Las opciones de control incluyen:\n     - Modificaci\u00f3n del dise\u00f1o del proceso o del sistema.\n     - Aplicaci\u00f3n de procedimientos externos.\n     - Aumento de detalles o formalidad en las especificaciones.\n     - Incremento en el n\u00famero y rigor de las revisiones de dise\u00f1o y actividades de verificaci\u00f3n.\n\n4. **Implementaci\u00f3n y Verificaci\u00f3n de Controles**:\n   - Los controles deben ser implementados y verificados para asegurar su efectividad en la reducci\u00f3n de riesgos.\n   - La verificaci\u00f3n debe demostrar que los controles son efectivos y est\u00e1n relacionados con los riesgos identificados.\n\n5. **Revisi\u00f3n y Monitoreo de Riesgos**:\n   - Se debe realizar una revisi\u00f3n peri\u00f3dica de los riesgos y de la efectividad de los controles.\n   - Si se encuentran deficiencias, se deben tomar acciones correctivas.\n\n### Entidades Clave\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil.\n- **Gu\u00eda n\u00b0 33/2020**: Documento que establece directrices para la validaci\u00f3n de sistemas inform\u00e1ticos.\n- **Controles**: Medidas implementadas para mitigar riesgos.\n- **Riesgos**: Peligros potenciales asociados a las funciones del sistema.\n\nEste resumen destaca la importancia de un enfoque estructurado para la evaluaci\u00f3n y gesti\u00f3n de riesgos en sistemas inform\u00e1ticos, enfatizando la necesidad de controles efectivos y revisiones peri\u00f3dicas.", "excerpt_keywords": "Keywords: software categorization, hardware categorization, risk assessment, GAMP categories, supplier evaluation"}}, "877a7c4c-cb00-4bf3-892c-bdd6e1392f0c": {"node_ids": ["cc109235-45cb-4ae1-9679-0e8c67978f37"], "metadata": {"page_label": "19", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 7.3 SOFTWARE CATEGORIES\n\n## 7.3.1 Category 1 - Infrastructure Software\n\nInfrastructure elements interconnect to form an integrated environment to run and support applications and services.\n\nThere are two types of software in this category:\n\n1. **Software Layer (Layered Software) Commercially Available or Settled** - Applications are developed to run under the control of this type of software. This type of software includes: operating systems, database managers, statistical programming tools, and spreadsheet packages (but not applications developed using these packages).\n\n2. **Tools Software Infrastructure** - This type includes tools such as software to network monitoring; batch job scheduling tools; security software; antivirus and configuration management tools. Risk assessment must be carried out, however, in the tools with high potential impact, such as password or security management to determine if additional controls are appropriate.\n\nThe software layer are not subject to specific functional verification, although their characteristics are functionally tested and challenged indirectly during testing in the application. The identities and the version numbers of the software of layer and operating system should be documented and verified during installation.\n\nInfrastructure tools and software are generally highly reliable and significantly removed from any aspect of risk to the patient. All software infrastructure should be controlled and managed.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas basadas en el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos clasifica el software en diferentes categor\u00edas, enfoc\u00e1ndose en la **Categor\u00eda 1 - Software de Infraestructura**. Esta categor\u00eda incluye dos tipos de software: el **Software Layer**, que abarca sistemas operativos y herramientas de gesti\u00f3n de bases de datos, y el **Tools Software Infrastructure**, que incluye herramientas de monitoreo de red y gesti\u00f3n de seguridad. Se enfatiza la importancia de realizar evaluaciones de riesgo, especialmente en herramientas con un alto potencial de impacto, y se menciona que el software de infraestructura generalmente es confiable y debe ser controlado y gestionado adecuadamente.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfQu\u00e9 tipo de software se considera parte del \"Software Layer\" y cu\u00e1les son sus caracter\u00edsticas clave seg\u00fan la gu\u00eda de ANVISA?**\n   - Respuesta: El \"Software Layer\" incluye sistemas operativos, gestores de bases de datos, herramientas de programaci\u00f3n estad\u00edstica y paquetes de hojas de c\u00e1lculo. Este tipo de software es utilizado para desarrollar aplicaciones y no est\u00e1 sujeto a verificaciones funcionales espec\u00edficas, aunque sus caracter\u00edsticas son probadas indirectamente durante las pruebas de las aplicaciones.\n\n2. **\u00bfQu\u00e9 medidas se deben tomar en cuenta al evaluar el riesgo de las herramientas de infraestructura de software con alto potencial de impacto?**\n   - Respuesta: Se debe realizar una evaluaci\u00f3n de riesgo en herramientas como la gesti\u00f3n de contrase\u00f1as o la gesti\u00f3n de seguridad para determinar si son necesarios controles adicionales, dado su alto potencial de impacto en la seguridad y la integridad del sistema.\n\n3. **\u00bfCu\u00e1l es la importancia de documentar las identidades y n\u00fameros de versi\u00f3n del software de capa y del sistema operativo durante la instalaci\u00f3n?**\n   - Respuesta: La documentaci\u00f3n y verificaci\u00f3n de las identidades y n\u00fameros de versi\u00f3n del software de capa y del sistema operativo son cruciales para asegurar que se est\u00e1 utilizando la versi\u00f3n correcta y para mantener un registro que facilite la gesti\u00f3n y el control del software, contribuyendo as\u00ed a la integridad del sistema y a la mitigaci\u00f3n de riesgos.", "prev_section_summary": "### Resumen de la Secci\u00f3n 7: Categorizaci\u00f3n de Software y Hardware\n\n#### Temas Clave:\n1. **Categorizaci\u00f3n de Componentes**: Se describe c\u00f3mo analizar y clasificar los componentes de software y hardware para establecer estrategias adecuadas de ciclo de vida en conjunto con la evaluaci\u00f3n de riesgos y proveedores.\n  \n2. **Riesgo Asociado**: Se menciona que los sistemas personalizados presentan un mayor riesgo de fallos y defectos debido a su complejidad y menor experiencia del usuario. La categorizaci\u00f3n es una herramienta \u00fatil para la gesti\u00f3n de riesgos de calidad.\n\n3. **Proporciones de Esfuerzo**: Se recomienda concentrar los esfuerzos de validaci\u00f3n en el siguiente orden de complejidad: \n   - Personalizado > Configurado > No Configurado > Infraestructura.\n\n4. **Enfoques de Evaluaci\u00f3n**: Se sugieren dos enfoques para utilizar las categor\u00edas:\n   - Evaluaci\u00f3n hol\u00edstica del sistema.\n   - Evaluaci\u00f3n detallada por componente.\n\n5. **Auditor\u00eda de Proveedores**: La categorizaci\u00f3n, combinada con la evaluaci\u00f3n de impacto del sistema, puede ayudar a determinar la necesidad de realizar auditor\u00edas a proveedores.\n\n#### Entidades:\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil.\n- **GAMP**: Buenas Pr\u00e1cticas de Automatizaci\u00f3n de Sistemas.\n- **Componentes de Software y Hardware**: Incluyen sistemas operativos, componentes no configurados, y componentes configurados o personalizados.\n- **Riesgo**: Relacionado con la complejidad y la experiencia del usuario en sistemas personalizados.\n\nEste resumen destaca la importancia de la categorizaci\u00f3n en la validaci\u00f3n de sistemas inform\u00e1ticos y su papel en la gesti\u00f3n de riesgos y la evaluaci\u00f3n de proveedores.", "excerpt_keywords": "Keywords: software categories, infrastructure software, risk assessment, validation, ANVISA"}}, "6f2de107-1150-4718-92c1-9375d716b98c": {"node_ids": ["fcdc40a9-53f9-4e24-a5a0-d9d9eb5c8ea2"], "metadata": {"page_label": "20", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "## 7.3.2 Category 3 - Non-Configured Products\n\nThis category includes off-the-shelf products used for the business process. It covers both systems that cannot be configured to suit business processes as well as the systems that are configurable, but that only the *default* configuration is used. In both cases, the setting for run in the likely user environment (eg, printer setting). Risk-based judgment and complexity should determine whether systems used with the *default* configuration can be considered Category 3 or 4.\n\nA simplified approach to the life cycle can be applied to this category. Supplier evaluation may not be necessary. The need and extent of the supplier's assessment should be based on risk. User requirements are necessary and should focus on the key aspects of use. The specifications functional and design are not necessary, although there is a need for sufficient specification (usually in the ERU / URS) to allow testing. The verification basically consists of a single testing phase.\n\nAll changes must be controlled, including the *patch* packages provided by the supplier. Standard Operating Procedures must be established for the use and management of the system and training should be implemented.\n\nConfiguration management must be applied. For systems where the *default* configuration is used, the Configuration management demonstrates that the \u201c*default*\u201d option is selected correctly.\n\n----\n\n## 7.3.3 Category 4 - Configured Products\n\nConfigurable *software* provides standard *interfaces* and functions that allow the configuration of specific business for the user. This usually involves configuring *software* modules predefined.\n\nMuch of the risk associated with the *software* depends on how well the system is configured to meet user needs. There may be an increased risk associated with new *software* and major updates.\n\nDetailed user requirements document (ERU / URS) is required for this *software* category. THE The approach for evaluating the supplier and the configurable product must be risk-based and must be documented.\n\nThe Functional Specification document may not be owned by the regulated user / company, but must sufficient documentation to ensure traceability of functional specifications and their respective tests.\n\nThe approach used by the regulated company must cover the layers of *software* involved and their respective categories. The approach should reflect the result of the supplier's assessment, the risk to GMP, system size and complexity. It should define strategies to mitigate any weaknesses identified during the supplier assessment process.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos clasifica los productos en diferentes categor\u00edas seg\u00fan su configuraci\u00f3n y uso. La **Categor\u00eda 3** incluye productos no configurados que utilizan configuraciones predeterminadas, mientras que la **Categor\u00eda 4** abarca productos configurables que requieren una documentaci\u00f3n m\u00e1s detallada y un enfoque basado en riesgos para su evaluaci\u00f3n. Ambos tipos de productos requieren un control de cambios y gesti\u00f3n de configuraciones, pero la complejidad y el riesgo asociado var\u00edan seg\u00fan la categor\u00eda.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfQu\u00e9 tipo de documentaci\u00f3n se requiere para los productos de la Categor\u00eda 4 y por qu\u00e9 es importante?**\n   - La Categor\u00eda 4 requiere un documento detallado de requisitos del usuario (ERU / URS) para garantizar que el software est\u00e9 configurado adecuadamente para satisfacer las necesidades del usuario. Esta documentaci\u00f3n es crucial para asegurar la trazabilidad de las especificaciones funcionales y sus respectivas pruebas, lo que ayuda a mitigar riesgos asociados con la configuraci\u00f3n del software.\n\n2. **\u00bfC\u00f3mo se determina si un sistema con configuraci\u00f3n predeterminada debe clasificarse como Categor\u00eda 3 o 4?**\n   - La clasificaci\u00f3n de un sistema con configuraci\u00f3n predeterminada como Categor\u00eda 3 o 4 se basa en un juicio de riesgo y complejidad. Si el sistema se utiliza con la configuraci\u00f3n predeterminada y no se adapta a los procesos comerciales, puede considerarse Categor\u00eda 3. Sin embargo, si hay un riesgo significativo asociado con su uso o si se requiere una configuraci\u00f3n m\u00e1s espec\u00edfica, podr\u00eda clasificarse como Categor\u00eda 4.\n\n3. **\u00bfQu\u00e9 procedimientos deben establecerse para la gesti\u00f3n de cambios en productos de la Categor\u00eda 3?**\n   - Para los productos de la Categor\u00eda 3, todos los cambios deben ser controlados, incluyendo los paquetes de parches proporcionados por el proveedor. Adem\u00e1s, se deben establecer Procedimientos Operativos Est\u00e1ndar (SOP) para el uso y gesti\u00f3n del sistema, y se debe implementar capacitaci\u00f3n para los usuarios, asegurando as\u00ed que se mantenga la integridad del sistema a lo largo de su ciclo de vida.", "prev_section_summary": "### Resumen de Temas Clave y Entidades de la Secci\u00f3n\n\n**Categor\u00eda 1 - Software de Infraestructura**: Esta categor\u00eda se centra en los elementos de infraestructura que interconectan para formar un entorno integrado que soporta aplicaciones y servicios. Se divide en dos tipos principales de software:\n\n1. **Software Layer (Software de Capa)**:\n   - **Definici\u00f3n**: Software comercialmente disponible o asentado bajo el cual se desarrollan aplicaciones.\n   - **Ejemplos**: Sistemas operativos, gestores de bases de datos, herramientas de programaci\u00f3n estad\u00edstica y paquetes de hojas de c\u00e1lculo.\n   - **Caracter\u00edsticas**: No est\u00e1 sujeto a verificaciones funcionales espec\u00edficas, pero sus caracter\u00edsticas son probadas indirectamente durante las pruebas de las aplicaciones.\n\n2. **Tools Software Infrastructure (Herramientas de Infraestructura de Software)**:\n   - **Definici\u00f3n**: Herramientas que ayudan en la gesti\u00f3n y monitoreo de la infraestructura de software.\n   - **Ejemplos**: Software de monitoreo de red, herramientas de programaci\u00f3n de trabajos por lotes, software de seguridad, antivirus y herramientas de gesti\u00f3n de configuraci\u00f3n.\n   - **Evaluaci\u00f3n de Riesgo**: Se requiere una evaluaci\u00f3n de riesgo para herramientas con alto potencial de impacto, como la gesti\u00f3n de contrase\u00f1as y la gesti\u00f3n de seguridad, para determinar la necesidad de controles adicionales.\n\n**Importancia de la Documentaci\u00f3n**:\n- Se enfatiza la necesidad de documentar y verificar las identidades y n\u00fameros de versi\u00f3n del software de capa y del sistema operativo durante la instalaci\u00f3n para asegurar la correcta gesti\u00f3n y control del software.\n\n**Fiabilidad**:\n- Se menciona que las herramientas y software de infraestructura son generalmente altamente confiables y est\u00e1n significativamente alejados de cualquier riesgo para el paciente, lo que subraya la importancia de su control y gesti\u00f3n adecuada. \n\n### Entidades Clave\n- **Software Layer**: Sistemas operativos, gestores de bases de datos, herramientas de programaci\u00f3n estad\u00edstica, paquetes de hojas de c\u00e1lculo.\n- **Tools Software Infrastructure**: Herramientas de monitoreo de red, programaci\u00f3n de trabajos, software de seguridad, antivirus, gesti\u00f3n de configuraci\u00f3n.\n- **Riesgo**: Evaluaci\u00f3n de riesgo en herramientas cr\u00edticas como gesti\u00f3n de contrase\u00f1as y seguridad.\n- **Documentaci\u00f3n**: Identidades y n\u00fameros de versi\u00f3n del software.", "excerpt_keywords": "Keywords: validation, computer systems, risk-based approach, configurable products, user requirements"}}, "76e8b089-1a40-4e02-94f9-011528c911a5": {"node_ids": ["e1fcca3b-7aa9-43b8-9eca-6024c171017c"], "metadata": {"page_label": "21", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "## 7.3.4 Category 5 - Custom Applications\n\nThese systems and subsystems are developed to meet the specific needs of the regulated company. The risk inherent in customized *software* is high. The life-cycle approach and system decisions should take this high risk into account, because there is no user experience or information about system reliability.\n\nThe approach used to assess the supplier must be risk-based and documented. An audit at the supplier is required to confirm that an adequate Quality Management System exists for control development and ongoing support for the application. In the absence of a Management System Quality Assurance, suppliers must adapt to provide an appropriate basis for managing application development and support.\n\nThe approach used by the regulated company must cover the layers of *software* involved and their respective categories. The approach should reflect the result of the supplier's assessment, the risk to GMP, system size and complexity. It should define strategies to mitigate any weaknesses identified during the supplier evaluation process.\n\n## 7.3.5 Typical Examples and Approaches\n\n**Table 2. Categories of Software, Description and Typical Approach to the Life Cycle.**\n\n| Category                       | description                                                                                                                 | Typical Examples                                                                                                                                                                                                       | Typical Approach                                                                                                                                |\n| ------------------------------ | --------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- |\n| Software of Infrastructure (1) | * *software* of Layer (that is, over which applications are built)\n* *Software* used for manage the environment operational | - Operational systems\n- Mechanisms for databases\n- Middleware\n- Languages programming\n- Statistical packages\n- Spreadsheets\n- Tools network monitoring\n- Tools scheduling\n- Tools version control\n- Based Applications | * Registration of the version and verification of correct installation\n* See GAMP Good Practice Guide: IT Infrastructure Control and Compliance |\n|                                | Non-*Software* Time parameters                                                                                              |                                                                                                                                                                                                                        | Shortened life cycle                                                                                                                            |\n", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos destaca la importancia de evaluar y gestionar los riesgos asociados con el software personalizado en empresas reguladas. Se enfatiza la necesidad de un enfoque basado en riesgos para la evaluaci\u00f3n de proveedores y la implementaci\u00f3n de un sistema de gesti\u00f3n de calidad adecuado. Adem\u00e1s, se presentan categor\u00edas de software y enfoques t\u00edpicos para su ciclo de vida, subrayando la importancia de la documentaci\u00f3n y el control en el desarrollo y soporte de aplicaciones.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfCu\u00e1les son las implicaciones de no contar con un Sistema de Gesti\u00f3n de Calidad en el desarrollo de software personalizado?**\n   - La falta de un Sistema de Gesti\u00f3n de Calidad puede llevar a que los proveedores no tengan una base adecuada para gestionar el desarrollo y soporte de la aplicaci\u00f3n, aumentando as\u00ed el riesgo de fallos en el software y afectando la conformidad con las Buenas Pr\u00e1cticas de Manufactura (GMP).\n\n2. **\u00bfQu\u00e9 estrategias se deben definir para mitigar debilidades identificadas durante la evaluaci\u00f3n del proveedor?**\n   - Las estrategias deben ser espec\u00edficas y basadas en los resultados de la evaluaci\u00f3n del proveedor, el riesgo para GMP, as\u00ed como el tama\u00f1o y la complejidad del sistema. Esto puede incluir la implementaci\u00f3n de controles adicionales, auditor\u00edas m\u00e1s frecuentes o la capacitaci\u00f3n del personal.\n\n3. **\u00bfQu\u00e9 tipo de software se clasifica como \"Software de Infraestructura\" y cu\u00e1l es su enfoque t\u00edpico en el ciclo de vida?**\n   - El \"Software de Infraestructura\" incluye sistemas operativos, mecanismos para bases de datos, middleware, lenguajes de programaci\u00f3n, paquetes estad\u00edsticos, hojas de c\u00e1lculo, herramientas de monitoreo de red, herramientas de programaci\u00f3n y control de versiones. Su enfoque t\u00edpico en el ciclo de vida incluye el registro de versiones y la verificaci\u00f3n de la correcta instalaci\u00f3n, siguiendo las buenas pr\u00e1cticas de GAMP para el control y cumplimiento de la infraestructura de TI.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n#### Temas Clave\n\n1. **Clasificaci\u00f3n de Productos**:\n   - **Categor\u00eda 3 - Productos No Configurados**: Incluye productos de estanter\u00eda que utilizan configuraciones predeterminadas. Se aplica un enfoque simplificado al ciclo de vida, donde la evaluaci\u00f3n del proveedor puede no ser necesaria y se requiere un control de cambios riguroso.\n   - **Categor\u00eda 4 - Productos Configurados**: Comprende software configurable que permite personalizar funciones seg\u00fan las necesidades del usuario. Requiere documentaci\u00f3n detallada de requisitos del usuario (ERU / URS) y un enfoque basado en riesgos para la evaluaci\u00f3n del proveedor.\n\n2. **Gesti\u00f3n de Cambios y Configuraci\u00f3n**:\n   - En ambas categor\u00edas, todos los cambios deben ser controlados, incluyendo parches del proveedor. Se deben establecer Procedimientos Operativos Est\u00e1ndar (SOP) para la gesti\u00f3n del sistema y la capacitaci\u00f3n de usuarios.\n\n3. **Documentaci\u00f3n y Trazabilidad**:\n   - La documentaci\u00f3n es esencial para asegurar la trazabilidad de las especificaciones funcionales y las pruebas realizadas, especialmente en la Categor\u00eda 4, donde se requiere un enfoque m\u00e1s riguroso debido a la complejidad y riesgo asociado.\n\n4. **Evaluaci\u00f3n Basada en Riesgos**:\n   - La evaluaci\u00f3n de proveedores y productos debe basarse en un juicio de riesgo, considerando la complejidad del sistema y su adecuaci\u00f3n a los procesos comerciales.\n\n#### Entidades\n\n- **Categor\u00eda 3**: Productos No Configurados\n- **Categor\u00eda 4**: Productos Configurados\n- **ERU / URS**: Documentos de Requisitos del Usuario\n- **SOP**: Procedimientos Operativos Est\u00e1ndar\n- **Gesti\u00f3n de Configuraci\u00f3n**: Proceso para asegurar que las configuraciones predeterminadas se seleccionen y mantengan correctamente.\n- **Riesgo**: Consideraci\u00f3n clave en la evaluaci\u00f3n de productos y proveedores.\n\nEste resumen destaca la importancia de la clasificaci\u00f3n de productos en la validaci\u00f3n de sistemas inform\u00e1ticos, as\u00ed como la necesidad de una gesti\u00f3n adecuada de cambios y documentaci\u00f3n para garantizar la conformidad y la eficacia en el uso de software en entornos regulados.", "excerpt_keywords": "Keywords: validation, software, risk management, quality assurance, infrastructure"}}, "5435101f-974e-4cfb-952e-1c37b395f2ed": {"node_ids": ["fc5a006b-3c37-4cd9-b03b-88f0909e63fa"], "metadata": {"page_label": "22", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# Guide for Computer Systems Validation\n\n## Table 2: Software Categories, Description and Typical Life Cycle Approach (continued).\n\n| Category                | description                                                                 | Typical Examples                                                                 | Typical Approach                                                                 |\n|-------------------------|-----------------------------------------------------------------------------|----------------------------------------------------------------------------------|----------------------------------------------------------------------------------|\n| Configured Software (4) | Software, usually more complex, which can be configured by the user to meet your specific needs. THE software code is not changed. | - LIMS\n- Systems data acquisition\n- SCADA\n- ERU\n- MRPII\n- DCS\n- CDS\n- EDMS\n- BMS\n- Spreadsheets\n- HMI (Human Simple Machine Interfaces)\nNOTE: Specific examples of system types above can contain elements substantial custom features. | - Cycle approach of life\n- Approach to supplier assessment with risk based\n- Demonstration of that the supplier has a Management System Quality\n- Some cycle documentation life maintained by the supplier (ex: Specifications of Project)\n- Number registration version and verification correct installation |\n| Custom software (5)     | software customized designed and coded for                                 | It varies, but includes:\n- IT Applications                                    | - Testing based on risk for demonstrate that the application works as designed, in a test environment\n- Testing based on risk for demonstrate that the application works as designed, in an environment of production\n- Existence of procedures for maintenance of care and suitability for use and data management\nSame approach used for Category 4, plus: |\n\n----\n\nGuide for Computer Systems Validation\nGuide n\u00b0 33/2020 - version 1, of 03/26/2020", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas que pueden proporcionar respuestas espec\u00edficas basadas en el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento es una gu\u00eda de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos, espec\u00edficamente la Gu\u00eda n\u00b0 33/2020. En la secci\u00f3n presentada, se describen dos categor\u00edas de software: \"Software Configurado\" y \"Software Personalizado\". Se detallan sus descripciones, ejemplos t\u00edpicos y enfoques de ciclo de vida. El software configurado permite ajustes por parte del usuario sin modificar el c\u00f3digo, mientras que el software personalizado es dise\u00f1ado y codificado espec\u00edficamente para necesidades particulares. Ambos tipos requieren enfoques de validaci\u00f3n basados en riesgos y documentaci\u00f3n adecuada.\n\n### Preguntas\n1. **\u00bfCu\u00e1les son los requisitos espec\u00edficos de documentaci\u00f3n que deben mantener los proveedores de software configurado seg\u00fan la gu\u00eda de ANVISA?**\n   - Esta pregunta busca detalles sobre la documentaci\u00f3n que los proveedores deben proporcionar, lo cual no se encuentra f\u00e1cilmente en otras fuentes.\n\n2. **\u00bfQu\u00e9 diferencias clave existen en el enfoque de validaci\u00f3n entre el software configurado y el software personalizado seg\u00fan la gu\u00eda?**\n   - Esta pregunta se centra en las diferencias en los m\u00e9todos de validaci\u00f3n, lo que puede no ser evidente sin un an\u00e1lisis detallado del documento.\n\n3. **\u00bfQu\u00e9 ejemplos de software configurado se mencionan en la gu\u00eda y c\u00f3mo se relacionan con las pr\u00e1cticas de gesti\u00f3n de calidad?**\n   - Esta pregunta busca ejemplos concretos y su conexi\u00f3n con la gesti\u00f3n de calidad, lo que puede no estar disponible en otras gu\u00edas o documentos.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Categor\u00eda 5 - Aplicaciones Personalizadas**:\n   - Las aplicaciones personalizadas son sistemas desarrollados para satisfacer necesidades espec\u00edficas de empresas reguladas.\n   - Se destaca el alto riesgo asociado con el software personalizado, debido a la falta de experiencia del usuario y datos sobre la fiabilidad del sistema.\n\n2. **Evaluaci\u00f3n de Proveedores**:\n   - La evaluaci\u00f3n de proveedores debe ser basada en riesgos y documentada.\n   - Es necesario realizar auditor\u00edas a los proveedores para confirmar la existencia de un Sistema de Gesti\u00f3n de Calidad adecuado que controle el desarrollo y soporte de la aplicaci\u00f3n.\n   - En ausencia de un Sistema de Gesti\u00f3n de Calidad, los proveedores deben adaptarse para gestionar adecuadamente el desarrollo y soporte de la aplicaci\u00f3n.\n\n3. **Enfoque de la Empresa Regulada**:\n   - La empresa regulada debe considerar las capas de software involucradas y sus respectivas categor\u00edas en su enfoque.\n   - Debe reflejar los resultados de la evaluaci\u00f3n del proveedor, el riesgo para las Buenas Pr\u00e1cticas de Manufactura (GMP), as\u00ed como el tama\u00f1o y complejidad del sistema.\n   - Se deben definir estrategias para mitigar debilidades identificadas durante la evaluaci\u00f3n del proveedor.\n\n4. **Categor\u00edas de Software**:\n   - Se presenta una tabla que clasifica diferentes tipos de software, incluyendo el \"Software de Infraestructura\".\n   - Ejemplos de software de infraestructura incluyen sistemas operativos, bases de datos, middleware, lenguajes de programaci\u00f3n, herramientas de monitoreo de red, entre otros.\n   - El enfoque t\u00edpico para el ciclo de vida del software de infraestructura incluye el registro de versiones y la verificaci\u00f3n de la correcta instalaci\u00f3n, siguiendo las buenas pr\u00e1cticas de GAMP.\n\n### Entidades Clave\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria en Brasil.\n- **GMP**: Buenas Pr\u00e1cticas de Manufactura.\n- **GAMP**: Buenas Pr\u00e1cticas de Control y Cumplimiento de Infraestructura de TI.\n- **Software Personalizado**: Software desarrollado espec\u00edficamente para una empresa regulada.\n- **Sistema de Gesti\u00f3n de Calidad**: Sistema que asegura el control del desarrollo y soporte de aplicaciones. \n\nEste resumen encapsula los puntos m\u00e1s importantes de la secci\u00f3n, destacando la importancia de la gesti\u00f3n de riesgos y la calidad en el desarrollo de software en entornos regulados.", "excerpt_keywords": "Keywords: ANVISA, Computer Systems Validation, Configured Software, Custom Software, Quality Management"}}, "6de85024-463c-476c-9bdc-fb2066a7c0ac": {"node_ids": ["5e04fbf7-bb13-4899-8553-d09dfb47369c"], "metadata": {"page_label": "23", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 7.4 HARDWARE CATEGORIES\n\n## 7.4.1 Hardware Category 1 - Standard Hardware Components\n\nMost of the hardware used by regulated companies falls into this category.\n\nStandard hardware components must be documented including details about the supplier or manufacturer and version number. The correct installation and connections of the components must be checked. THE model, version number and if available and the serial number of the pre-assembled hardware must be registered. Pre-assembled hardware does not have to be disassembled. In such cases the details of the hardware can be purchased from the hardware data sheet or other material specification. Configuration management and change control are applicable.\n\n## 7.4.2 Hardware Category 2 - Custom Built-in Hardware Components\n\nIn addition to the requirements described in the item above, those described in this item are applicable. Custom items from hardware must have a Project Specification (EP / DS) and be subject to acceptance testing. THE approach to supplier assessment should be risk-based and documented. In most cases a Supplier audit must be performed for the development of customized hardware. Systems assembled using custom hardware from different sources requires verification to confirm the compatibility of interconnected hardware components. Any hardware configuration must be defined in the design documentation and verified. Configuration management and change control are applicable.\n\n# 8. INVENTORY LIST\n\nRegulated companies must maintain an inventory of their computerized systems.\n\nThe inventory must present summary information about each system, describing: name of the system; associated equipment or application; impact / criticality; category; ownership (sector, system owner, process owner); current version; provider; validation date and status.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos clasifica el hardware en dos categor\u00edas: componentes de hardware est\u00e1ndar y componentes de hardware personalizados. Se requiere documentaci\u00f3n detallada para ambos tipos, incluyendo informaci\u00f3n sobre proveedores, especificaciones de proyecto y pruebas de aceptaci\u00f3n. Adem\u00e1s, las empresas reguladas deben mantener un inventario de sus sistemas inform\u00e1ticos, que incluya informaci\u00f3n cr\u00edtica sobre cada sistema.\n\n### Preguntas\n\n1. **\u00bfQu\u00e9 informaci\u00f3n espec\u00edfica debe incluirse en la documentaci\u00f3n de los componentes de hardware est\u00e1ndar seg\u00fan la gu\u00eda de ANVISA?**\n   - La documentaci\u00f3n debe incluir detalles sobre el proveedor o fabricante, el n\u00famero de versi\u00f3n, el modelo, el n\u00famero de serie (si est\u00e1 disponible) y la verificaci\u00f3n de la instalaci\u00f3n y conexiones de los componentes.\n\n2. **\u00bfCu\u00e1les son los requisitos adicionales para los componentes de hardware personalizados en comparaci\u00f3n con los componentes est\u00e1ndar?**\n   - Los componentes personalizados deben tener una Especificaci\u00f3n de Proyecto (EP/DS), estar sujetos a pruebas de aceptaci\u00f3n, y se debe realizar una auditor\u00eda del proveedor. Adem\u00e1s, se requiere verificaci\u00f3n de la compatibilidad de los componentes de hardware interconectados.\n\n3. **\u00bfQu\u00e9 informaci\u00f3n debe contener el inventario de sistemas inform\u00e1ticos que deben mantener las empresas reguladas?**\n   - El inventario debe incluir el nombre del sistema, el equipo o aplicaci\u00f3n asociada, el impacto/cr\u00edtica, la categor\u00eda, la propiedad (sector, propietario del sistema, propietario del proceso), la versi\u00f3n actual, el proveedor, la fecha de validaci\u00f3n y el estado.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\nEl contenido presentado proviene de la \"Gu\u00eda para la Validaci\u00f3n de Sistemas Inform\u00e1ticos\" de ANVISA, espec\u00edficamente la Gu\u00eda n\u00b0 33/2020. En esta secci\u00f3n se abordan dos categor\u00edas principales de software:\n\n1. **Software Configurado**:\n   - **Descripci\u00f3n**: Software complejo que puede ser configurado por el usuario para satisfacer necesidades espec\u00edficas sin modificar el c\u00f3digo fuente.\n   - **Ejemplos T\u00edpicos**: \n     - LIMS (Laboratory Information Management Systems)\n     - Sistemas de adquisici\u00f3n de datos\n     - SCADA (Supervisory Control and Data Acquisition)\n     - ERU (Emergency Response Unit)\n     - MRPII (Manufacturing Resource Planning)\n     - DCS (Distributed Control Systems)\n     - CDS (Clinical Data Systems)\n     - EDMS (Electronic Document Management Systems)\n     - BMS (Building Management Systems)\n     - Hojas de c\u00e1lculo\n     - HMI (Interfaz Hombre-M\u00e1quina)\n   - **Enfoque T\u00edpico**: \n     - Ciclo de vida del software\n     - Evaluaci\u00f3n del proveedor basada en riesgos\n     - Demostraci\u00f3n de un sistema de gesti\u00f3n de calidad por parte del proveedor\n     - Mantenimiento de documentaci\u00f3n del ciclo de vida (ej: especificaciones del proyecto)\n     - Registro de versiones y verificaci\u00f3n de instalaci\u00f3n correcta.\n\n2. **Software Personalizado**:\n   - **Descripci\u00f3n**: Software dise\u00f1ado y codificado espec\u00edficamente para satisfacer necesidades particulares.\n   - **Ejemplos T\u00edpicos**: Var\u00edan, pero incluyen aplicaciones de TI.\n   - **Enfoque T\u00edpico**:\n     - Pruebas basadas en riesgos para demostrar que la aplicaci\u00f3n funciona como se dise\u00f1\u00f3, tanto en entornos de prueba como de producci\u00f3n.\n     - Procedimientos para el mantenimiento y gesti\u00f3n de datos.\n     - Se utiliza un enfoque similar al del software configurado, pero con requisitos adicionales.\n\n### Entidades Clave\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil, responsable de la regulaci\u00f3n y supervisi\u00f3n de productos y servicios relacionados con la salud.\n- **Software Configurado**: Categor\u00eda de software que permite configuraciones sin cambios en el c\u00f3digo.\n- **Software Personalizado**: Software dise\u00f1ado espec\u00edficamente para necesidades particulares.\n- **Ejemplos de Software**: LIMS, SCADA, Hojas de c\u00e1lculo, entre otros.\n- **Enfoques de Validaci\u00f3n**: Ciclo de vida, evaluaci\u00f3n de proveedores, pruebas basadas en riesgos, mantenimiento de documentaci\u00f3n.\n\nEste resumen proporciona una visi\u00f3n general de las categor\u00edas de software y sus enfoques de validaci\u00f3n seg\u00fan la gu\u00eda de ANVISA, destacando la importancia de la gesti\u00f3n de calidad y la documentaci\u00f3n en el proceso de validaci\u00f3n.", "excerpt_keywords": "Keywords: ANVISA, hardware categories, validation, inventory list, regulated companies"}}, "66c91d9d-ac86-4430-8fa3-d94b775b57ea": {"node_ids": ["64ba19f4-b70a-44f6-ab1f-53ac04faa227"], "metadata": {"page_label": "24", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# VALIDATION OF COMPUTERIZED SYSTEMS\n\n## 9.1 INTRODUCTION\n\nA strategy will be presented to carry out the computerized system validation, from the definition user requirements, system selection, execution and approval of the validation report.\n\nThis strategy is applicable to systems belonging to categories 3, 4 and 5, which are the vast majority of systems computerized systems in the pharmaceutical and pharmaceutical industries.\n\nThis section will also describe the auxiliary risk management, change and configuration, project review, traceability and documentation management.\n\nTerminologies that are commonly used by the pharmaceutical and chemical industries will be used in this guide. pharmaceutical companies, namely: Validation Policies, Master Validation Plan and Validation Plan.\n\nThe regulated company must include the validation of computerized systems in its validation policy and/or Master Validation Plan. These documents should express the overall corporate or plant approach to company for the activity of validation of computerized systems and for maintaining their situation of validated.\n\nIt is recommended that a Validation Plan be prepared for each computer system that has relevance in GMP, focusing on aspects related to patient quality, product quality and data integrity.\n\nFor automated manufacturing equipment, the validation of the separate computerized system must be avoided. The specification and verification of the computerized system should be part of an approach integrated engineering to ensure compliance and suitability for the intended use of the equipment automated within a whole.\n\n----\n\nPage 23\n\nFigure 4 shows the steps involved in validating the systems that form part of the system's life cycle computerized, from the definition of user requirements, through the acquisition and validation of the system computerized and execution of the pertinent auxiliary processes.\n\nThese steps are also applicable to the design phase and the subsequent changes that occurred during the phase operating system.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas computarizados presenta una estrategia para llevar a cabo la validaci\u00f3n de estos sistemas en la industria farmac\u00e9utica. Se enfoca en la definici\u00f3n de requisitos del usuario, selecci\u00f3n del sistema, ejecuci\u00f3n y aprobaci\u00f3n del informe de validaci\u00f3n. Se aplica a sistemas de categor\u00edas 3, 4 y 5, que son comunes en la industria. Adem\u00e1s, se discuten aspectos como la gesti\u00f3n de riesgos, cambios, trazabilidad y documentaci\u00f3n. Se enfatiza la importancia de incluir la validaci\u00f3n en la pol\u00edtica de la empresa y se recomienda preparar un Plan de Validaci\u00f3n para cada sistema relevante en Buenas Pr\u00e1cticas de Manufactura (GMP).\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfQu\u00e9 categor\u00edas de sistemas computarizados son relevantes para la estrategia de validaci\u00f3n presentada en el documento?**\n   - La estrategia de validaci\u00f3n es aplicable a sistemas pertenecientes a las categor\u00edas 3, 4 y 5, que son las m\u00e1s comunes en la industria farmac\u00e9utica.\n\n2. **\u00bfCu\u00e1l es la recomendaci\u00f3n sobre la validaci\u00f3n de sistemas computarizados en relaci\u00f3n con el equipo de fabricaci\u00f3n automatizado?**\n   - Se recomienda evitar la validaci\u00f3n de sistemas computarizados separados para el equipo de fabricaci\u00f3n automatizado. En su lugar, la especificaci\u00f3n y verificaci\u00f3n del sistema computarizado deben formar parte de un enfoque de ingenier\u00eda integrado.\n\n3. **\u00bfQu\u00e9 documentos deben incluir la validaci\u00f3n de sistemas computarizados seg\u00fan el contexto del documento?**\n   - La validaci\u00f3n de sistemas computarizados debe incluirse en la pol\u00edtica de validaci\u00f3n de la empresa y/o en el Plan Maestro de Validaci\u00f3n, que deben expresar el enfoque general de la empresa hacia la validaci\u00f3n y el mantenimiento del estado validado de los sistemas.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Categor\u00edas de Hardware**:\n   - **Hardware Est\u00e1ndar (Categor\u00eda 1)**:\n     - Documentaci\u00f3n requerida: detalles del proveedor, n\u00famero de versi\u00f3n, modelo, n\u00famero de serie (si est\u00e1 disponible).\n     - Verificaci\u00f3n de instalaci\u00f3n y conexiones.\n     - No es necesario desensamblar hardware preensamblado; se puede obtener informaci\u00f3n de la hoja de datos del hardware.\n     - Aplicaci\u00f3n de gesti\u00f3n de configuraci\u00f3n y control de cambios.\n\n   - **Hardware Personalizado (Categor\u00eda 2)**:\n     - Requisitos adicionales: Especificaci\u00f3n de Proyecto (EP/DS) y pruebas de aceptaci\u00f3n.\n     - Evaluaci\u00f3n del proveedor basada en riesgos y documentaci\u00f3n.\n     - Auditor\u00eda del proveedor para el desarrollo de hardware personalizado.\n     - Verificaci\u00f3n de compatibilidad de componentes de hardware interconectados.\n     - Definici\u00f3n de la configuraci\u00f3n de hardware en la documentaci\u00f3n de dise\u00f1o.\n\n2. **Inventario de Sistemas Inform\u00e1ticos**:\n   - Las empresas reguladas deben mantener un inventario que incluya:\n     - Nombre del sistema.\n     - Equipos o aplicaciones asociadas.\n     - Impacto/cr\u00edtica.\n     - Categor\u00eda.\n     - Propiedad (sector, propietario del sistema, propietario del proceso).\n     - Versi\u00f3n actual.\n     - Proveedor.\n     - Fecha de validaci\u00f3n y estado.\n\n### Entidades Clave:\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil.\n- **Hardware Est\u00e1ndar**: Componentes de hardware com\u00fanmente utilizados.\n- **Hardware Personalizado**: Componentes de hardware dise\u00f1ados espec\u00edficamente para un prop\u00f3sito.\n- **Especificaci\u00f3n de Proyecto (EP/DS)**: Documentaci\u00f3n que detalla los requisitos y dise\u00f1o del hardware personalizado.\n- **Auditor\u00eda del Proveedor**: Evaluaci\u00f3n de los proveedores de hardware personalizado.\n- **Inventario de Sistemas**: Registro de todos los sistemas inform\u00e1ticos utilizados por empresas reguladas.", "excerpt_keywords": "Keywords: validation, computerized systems, pharmaceutical industry, risk management, GMP"}}, "49d7f001-25fa-4f15-8fb5-a3b7cd17f6ef": {"node_ids": ["02820a20-016d-417c-b944-ab6ded78ddcc"], "metadata": {"page_label": "25", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "NO_CONTENT_HERE", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas que podr\u00edan derivarse del contexto proporcionado, junto con un breve resumen del contenido:\n\n### Resumen del Contexto\nEl documento mencionado es la \"Gu\u00eda para la Validaci\u00f3n de Sistemas Inform\u00e1ticos\" de ANVISA, publicada en 2020. Esta gu\u00eda proporciona directrices sobre c\u00f3mo validar sistemas inform\u00e1ticos en el \u00e1mbito de la salud, asegurando que estos sistemas cumplan con los requisitos regulatorios y de calidad necesarios para su uso en la industria farmac\u00e9utica y de dispositivos m\u00e9dicos en Brasil.\n\n### Preguntas\n1. **\u00bfCu\u00e1les son los principales requisitos que deben cumplirse para la validaci\u00f3n de sistemas inform\u00e1ticos seg\u00fan la gu\u00eda de ANVISA?**\n   - Esta pregunta busca detalles espec\u00edficos sobre los criterios y est\u00e1ndares que ANVISA establece para la validaci\u00f3n de sistemas inform\u00e1ticos.\n\n2. **\u00bfQu\u00e9 metodolog\u00edas o enfoques recomienda ANVISA para llevar a cabo la validaci\u00f3n de sistemas inform\u00e1ticos?**\n   - Aqu\u00ed se busca informaci\u00f3n sobre las estrategias o m\u00e9todos que la gu\u00eda sugiere para realizar una validaci\u00f3n efectiva.\n\n3. **\u00bfQu\u00e9 implicaciones tiene la falta de validaci\u00f3n de sistemas inform\u00e1ticos en el cumplimiento regulatorio en Brasil?**\n   - Esta pregunta se enfoca en las consecuencias que pueden surgir si una empresa no sigue las directrices de validaci\u00f3n establecidas por ANVISA, lo que podr\u00eda incluir sanciones o problemas de calidad. \n\nEstas preguntas est\u00e1n dise\u00f1adas para obtener informaci\u00f3n espec\u00edfica que probablemente no se encuentre f\u00e1cilmente en otros documentos o fuentes.", "prev_section_summary": "### Temas Clave\n\n1. **Estrategia de Validaci\u00f3n**: Se presenta un enfoque para llevar a cabo la validaci\u00f3n de sistemas computarizados, que incluye la definici\u00f3n de requisitos del usuario, selecci\u00f3n del sistema, ejecuci\u00f3n y aprobaci\u00f3n del informe de validaci\u00f3n.\n\n2. **Categor\u00edas de Sistemas**: La estrategia es aplicable a sistemas de categor\u00edas 3, 4 y 5, que son comunes en la industria farmac\u00e9utica.\n\n3. **Gesti\u00f3n de Riesgos y Cambios**: Se abordan aspectos auxiliares como la gesti\u00f3n de riesgos, cambios, configuraci\u00f3n, revisi\u00f3n de proyectos, trazabilidad y gesti\u00f3n de documentaci\u00f3n.\n\n4. **Documentaci\u00f3n Requerida**: Se enfatiza la necesidad de incluir la validaci\u00f3n de sistemas computarizados en la pol\u00edtica de validaci\u00f3n de la empresa y/o en el Plan Maestro de Validaci\u00f3n.\n\n5. **Plan de Validaci\u00f3n**: Se recomienda elaborar un Plan de Validaci\u00f3n para cada sistema relevante en Buenas Pr\u00e1cticas de Manufactura (GMP), centr\u00e1ndose en la calidad del paciente, calidad del producto e integridad de los datos.\n\n6. **Integraci\u00f3n con Equipos Automatizados**: Se sugiere evitar la validaci\u00f3n de sistemas computarizados separados para equipos de fabricaci\u00f3n automatizados, promoviendo un enfoque de ingenier\u00eda integrado.\n\n### Entidades\n\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil.\n- **Categor\u00edas de Sistemas**: 3, 4 y 5.\n- **Documentos Clave**: Pol\u00edtica de Validaci\u00f3n, Plan Maestro de Validaci\u00f3n, Plan de Validaci\u00f3n.\n- **Conceptos**: Validaci\u00f3n de sistemas computarizados, Buenas Pr\u00e1cticas de Manufactura (GMP), gesti\u00f3n de riesgos, trazabilidad, documentaci\u00f3n.\n\nEste resumen destaca los elementos esenciales de la secci\u00f3n sobre la validaci\u00f3n de sistemas computarizados, proporcionando una visi\u00f3n clara de los temas tratados y las entidades involucradas.", "excerpt_keywords": "Keywords: ANVISA, validaci\u00f3n, sistemas inform\u00e1ticos, Buenas Pr\u00e1cticas de Manufactura, gesti\u00f3n de riesgos"}}, "b45b42aa-5a09-45d7-96c2-b3d71f97e566": {"node_ids": ["3cf3da5a-c30c-4361-9275-af504462ca0e"], "metadata": {"page_label": "26", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 9.2.1 Introduction\n\nIt is in the validation plan where the project is described, the actions to be carried out for an successful validation and acceptance criteria for clearing the system are clearly defined.\n\nYou must define:\n\n- What activities are needed;\n- How the activities will be carried out and who are responsible;\n- What are the expected results;\n- What are the acceptance criteria;\n- How the compliance situation will be maintained throughout the life of the system.\n\nPlanning should start as soon as possible, ideally during document development describing the specifications of user requirements (ERU / URS).\n\nA similar or generic plan can be generated for similar systems, but one that adequately reflects the characteristics of each system.\n\nRegarding the roles and responsibilities, the validation plan is the responsibility of the Process Owner. It may be delegated to the Project Manager, if applicable, and the Project Owner may also be involved System.\n\n# 9.2.2 Content of the Plan\n\n## 9.2.2.1 Introduction and Scope\n\nIt should contain:\n\n- The scope of the system;\n- The objectives of the validation process;\n- Review, maintenance or update of the plan itself.\n\n## 9.2.2.2 System Overview\n\nThe general description of the system should contain:\n\n- Business purpose and intended use for the system;\n- A high-level description of the system;\n- An overview of the system architecture;\n- System diagrams.\n\n## 9.2.2.3 Organizational Structure\n\nRoles and responsibilities should be described, such as:\n\n----\n\nGuide for Computer Systems Validation\nGuide n\u00b0 33/2020 - version 1, of 03/26/2020\n\nPage 25", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas que pueden proporcionar respuestas espec\u00edficas basadas en el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos establece la importancia de un plan de validaci\u00f3n que defina claramente las actividades necesarias, los responsables, los resultados esperados y los criterios de aceptaci\u00f3n. Se enfatiza que la planificaci\u00f3n debe comenzar lo antes posible, idealmente durante la elaboraci\u00f3n de documentos que describen los requisitos del usuario. Adem\u00e1s, se detalla el contenido que debe incluir el plan, como el alcance del sistema, los objetivos del proceso de validaci\u00f3n y la estructura organizativa.\n\n### Preguntas\n1. **\u00bfCu\u00e1les son los elementos clave que deben incluirse en un plan de validaci\u00f3n seg\u00fan la gu\u00eda de ANVISA?**\n   - Esta pregunta busca una lista detallada de los componentes que deben estar presentes en el plan de validaci\u00f3n, como el alcance del sistema, los objetivos y la estructura organizativa.\n\n2. **\u00bfQui\u00e9n es responsable de la elaboraci\u00f3n del plan de validaci\u00f3n y qu\u00e9 roles pueden estar involucrados en su desarrollo?**\n   - Esta pregunta se centra en identificar las responsabilidades espec\u00edficas en la creaci\u00f3n del plan de validaci\u00f3n y c\u00f3mo pueden ser delegadas a otros roles dentro de la organizaci\u00f3n.\n\n3. **\u00bfPor qu\u00e9 es importante iniciar la planificaci\u00f3n de la validaci\u00f3n durante la fase de desarrollo de los requisitos del usuario?**\n   - Esta pregunta busca explorar la raz\u00f3n detr\u00e1s de la recomendaci\u00f3n de comenzar la planificaci\u00f3n en una etapa temprana y c\u00f3mo esto puede impactar la efectividad del proceso de validaci\u00f3n a largo plazo.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n**Documento:** ANVISA - Gu\u00eda para la Validaci\u00f3n de Sistemas Inform\u00e1ticos 33/2020\n\n**Temas Clave:**\n1. **Validaci\u00f3n de Sistemas Inform\u00e1ticos:** Directrices sobre c\u00f3mo validar sistemas inform\u00e1ticos en el sector salud.\n2. **Cumplimiento Regulatorio:** Aseguramiento de que los sistemas cumplen con los requisitos regulatorios y de calidad.\n3. **Industria Farmac\u00e9utica y Dispositivos M\u00e9dicos:** Enfoque espec\u00edfico en la aplicaci\u00f3n de la validaci\u00f3n en estas \u00e1reas en Brasil.\n\n**Entidades:**\n- **ANVISA:** Agencia Nacional de Vigilancia Sanitaria de Brasil, responsable de la regulaci\u00f3n y supervisi\u00f3n de productos de salud.\n- **Sistemas Inform\u00e1ticos:** Herramientas y software utilizados en la industria de la salud que requieren validaci\u00f3n para garantizar su eficacia y seguridad.\n\nEste resumen destaca la importancia de la validaci\u00f3n de sistemas inform\u00e1ticos en el contexto regulatorio brasile\u00f1o, as\u00ed como el papel de ANVISA en establecer directrices para asegurar la calidad y cumplimiento en la industria de la salud.", "excerpt_keywords": "Keywords: validation plan, acceptance criteria, system overview, roles and responsibilities, compliance situation"}}, "b06664d2-716f-4168-8e50-e517dc380321": {"node_ids": ["45f476a3-b9dc-4651-b69f-a838f188c788"], "metadata": {"page_label": "27", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "- Project manager;\n- Project planning and management;\n- Control of project activities, resources and costs;\n- Monitoring the progress of the work and initiation of CAPA;\n- Ensure that the problems and objectives of the project are resolved and met;\n- Manage quality deviations involving the system:\n- Respond to the sponsor or top management;\n- Ensure system compliance in conjunction with the Quality Unit.\n- Quality Unit;\n- Ensuring system compliance with regulatory, quality and policy requirements company;\n- Provide support for the review and approval of the results generated by the validation work;\n- Evaluation and approval of closing quality deviations;\n- Approval of the system release for use.\n- Process Owner and / or System Owner\n- System deployment and management by the community of system users;\n- Approval of each stage of the validation process.\n\nSubject matter experts (SME) are those individuals with specific *expertise* and responsibility in a particular area or field, for example, chromatographic analysis, quality unit, engineering, automation, development, etc.\n\nThe responsibilities of these experts may include: planning and defining verification strategies of the system; performing reviews; definition of acceptance criteria; selection of method tests appropriate; execution of verification tests and review of the results.\n\n## 9.2.2.4 Quality Risk Management\n\nThe approach used to manage quality risk should be described.\n\nA risk assessment must be performed based on an understanding of the business processes, requirements of the regulatory requirements and known functional areas. The results obtained must include a decision on whether the system is relevant to GMP and a general assessment of the impact of the system.\n\nComplex systems, such as ERP-type systems, may have some features that are relevant to GMP and others that are not. In such cases, the method used to make such a decision should be described and should consider the following points:\n\n- The requirements for deciding on the impact levels on BPx;\n- The procedures for carrying out the assessment;\n- The current status of the process, recognizing that this assessment can be repeated and updated.\n\nAny specific procedures or standards used to perform quality risk management must be defined.\n\n## 9.2.2.5 Validation Strategy\n\nThe strategy to be used for system validation should be described, based on the following considerations:", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos detalla las responsabilidades de los diferentes roles involucrados en un proyecto de validaci\u00f3n, incluyendo al gerente de proyecto, la unidad de calidad y expertos en la materia (SME). Tambi\u00e9n aborda la gesti\u00f3n de riesgos de calidad, enfatizando la necesidad de realizar evaluaciones de riesgo basadas en procesos comerciales y requisitos regulatorios. Adem\u00e1s, se menciona la importancia de definir una estrategia de validaci\u00f3n adecuada para sistemas complejos, como los sistemas ERP.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfCu\u00e1les son las responsabilidades clave del gerente de proyecto en el proceso de validaci\u00f3n de sistemas inform\u00e1ticos seg\u00fan la gu\u00eda de ANVISA?**\n   - Respuesta: El gerente de proyecto es responsable de la planificaci\u00f3n y gesti\u00f3n del proyecto, control de actividades, recursos y costos, monitoreo del progreso, gesti\u00f3n de desviaciones de calidad, y asegurar el cumplimiento del sistema en colaboraci\u00f3n con la unidad de calidad.\n\n2. **\u00bfQu\u00e9 criterios se deben considerar al realizar una evaluaci\u00f3n de riesgo de calidad para sistemas complejos como los ERP?**\n   - Respuesta: Se deben considerar los requisitos para decidir sobre los niveles de impacto en los procesos de negocio, los procedimientos para llevar a cabo la evaluaci\u00f3n y el estado actual del proceso, reconociendo que esta evaluaci\u00f3n puede ser repetida y actualizada.\n\n3. **\u00bfQu\u00e9 papel desempe\u00f1an los expertos en la materia (SME) en el proceso de validaci\u00f3n de sistemas y cu\u00e1les son algunas de sus responsabilidades espec\u00edficas?**\n   - Respuesta: Los SME son individuos con experiencia espec\u00edfica en \u00e1reas como an\u00e1lisis cromatogr\u00e1fico o ingenier\u00eda. Sus responsabilidades incluyen la planificaci\u00f3n y definici\u00f3n de estrategias de verificaci\u00f3n del sistema, realizaci\u00f3n de revisiones, definici\u00f3n de criterios de aceptaci\u00f3n, selecci\u00f3n de m\u00e9todos de prueba apropiados, ejecuci\u00f3n de pruebas de verificaci\u00f3n y revisi\u00f3n de resultados.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\nLa secci\u00f3n del documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos se centra en la importancia de un plan de validaci\u00f3n bien estructurado. A continuaci\u00f3n se presentan los temas clave y las entidades mencionadas:\n\n#### Temas Clave:\n1. **Plan de Validaci\u00f3n**: Es fundamental para describir el proyecto, las acciones necesarias para la validaci\u00f3n y los criterios de aceptaci\u00f3n.\n2. **Elementos a Definir**:\n   - Actividades necesarias.\n   - M\u00e9todos de ejecuci\u00f3n y responsables.\n   - Resultados esperados.\n   - Criterios de aceptaci\u00f3n.\n   - Mantenimiento de la conformidad a lo largo de la vida del sistema.\n3. **Inicio Temprano de la Planificaci\u00f3n**: Se recomienda comenzar la planificaci\u00f3n durante la fase de desarrollo de los requisitos del usuario para asegurar una validaci\u00f3n efectiva.\n4. **Contenido del Plan**:\n   - Introducci\u00f3n y alcance.\n   - Descripci\u00f3n general del sistema.\n   - Estructura organizativa.\n5. **Roles y Responsabilidades**: El Plan de Validaci\u00f3n es responsabilidad del Propietario del Proceso, con posibilidad de delegaci\u00f3n al Gerente de Proyecto.\n\n#### Entidades:\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil, responsable de la regulaci\u00f3n.\n- **Propietario del Proceso**: Principal responsable de la elaboraci\u00f3n del plan de validaci\u00f3n.\n- **Gerente de Proyecto**: Puede ser delegado para ayudar en la creaci\u00f3n del plan.\n- **Propietario del Proyecto**: Puede estar involucrado en el proceso de validaci\u00f3n.\n\nEste resumen destaca la estructura y los componentes esenciales que deben considerarse al desarrollar un plan de validaci\u00f3n para sistemas inform\u00e1ticos, as\u00ed como la importancia de la planificaci\u00f3n anticipada y la claridad en roles y responsabilidades.", "excerpt_keywords": "Keywords: validation, quality risk management, project management, regulatory compliance, subject matter experts"}}, "f582481a-ebdc-4a01-bb07-47b6e4aea29f": {"node_ids": ["ce8294e8-23e5-41b3-ba42-4cb5c9672a7e"], "metadata": {"page_label": "28", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# Guide for Computer Systems Validation\n\n- Risk assessment;\n- Evaluation of the system components and their architecture;\n- Supplier assessment.\n\nThe key conclusions of any evaluation carried out must be formalized.\n\nAny specific procedures or standards used must be defined.\n\nThe validation strategy should include:\n- The life cycle model;\n- The system's *hardware and software* categories;\n- The requirements and results required for each stage of the project;\n- The acceptance criteria for each stage;\n- Approach used to ensure the traceability of data and documents;\n- Approach used to review the project.\n\n## 9.2.2.6 Expected Results\n\nThe results to be produced should be listed, including the responsibility for production (of documents, tests, results), review and approval.\n\n## 9.2.2.7 Acceptance Criteria\n\nThe general acceptance criteria for the system, such as the successful execution of a defined stage of the project, should be described.\n\n## 9.2.2.8 Change Control\n\nThe requirements for project change control should be defined, including reference to the relevant procedures.\n\nThe stage at which operational change control will be applied must be defined.\n\n## 9.2.2.9 Standard Operating Procedures\n\nStandard operating procedures (SOPs) that will be created or updated as a result of the deployment of the system must be defined and the responsibilities for its elaboration, revision and approval defined.\n\n## 9.2.2.10 Auxiliary Processes\n\nDetails of ancillary processes should be defined or referenced, including, but not limited to:\n- Training;\n- Documentation management;", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas que pueden proporcionar respuestas espec\u00edficas basadas en el contexto del documento sobre la validaci\u00f3n de sistemas inform\u00e1ticos de ANVISA:\n\n1. **\u00bfCu\u00e1les son los elementos clave que deben incluirse en la estrategia de validaci\u00f3n seg\u00fan la gu\u00eda de ANVISA?**\n   - Respuesta: La estrategia de validaci\u00f3n debe incluir el modelo de ciclo de vida, las categor\u00edas de hardware y software del sistema, los requisitos y resultados necesarios para cada etapa del proyecto, los criterios de aceptaci\u00f3n para cada etapa, el enfoque para asegurar la trazabilidad de datos y documentos, y el enfoque utilizado para revisar el proyecto.\n\n2. **\u00bfQu\u00e9 se debe considerar al definir los criterios de aceptaci\u00f3n para un sistema en el contexto de la validaci\u00f3n?**\n   - Respuesta: Los criterios de aceptaci\u00f3n deben describir los criterios generales para el sistema, como la ejecuci\u00f3n exitosa de una etapa definida del proyecto, asegurando que se cumplan los requisitos establecidos.\n\n3. **\u00bfQu\u00e9 procedimientos deben ser establecidos en relaci\u00f3n con el control de cambios en un proyecto de validaci\u00f3n de sistemas?**\n   - Respuesta: Se deben definir los requisitos para el control de cambios del proyecto, incluyendo la referencia a los procedimientos relevantes, as\u00ed como la etapa en la que se aplicar\u00e1 el control de cambios operacionales.\n\n### Resumen de nivel superior del contexto:\nEl documento de ANVISA proporciona directrices sobre la validaci\u00f3n de sistemas inform\u00e1ticos, enfatizando la importancia de la evaluaci\u00f3n de riesgos, la arquitectura del sistema y la evaluaci\u00f3n de proveedores. Se detalla la necesidad de formalizar conclusiones de evaluaciones, definir procedimientos espec\u00edficos y establecer una estrategia de validaci\u00f3n que abarque el ciclo de vida del sistema, criterios de aceptaci\u00f3n, control de cambios y procedimientos operativos est\u00e1ndar. Adem\u00e1s, se menciona la importancia de los procesos auxiliares como la capacitaci\u00f3n y la gesti\u00f3n de documentaci\u00f3n.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos aborda varios aspectos fundamentales relacionados con la gesti\u00f3n de proyectos de validaci\u00f3n, la gesti\u00f3n de riesgos de calidad y la estrategia de validaci\u00f3n. A continuaci\u00f3n se presentan los temas clave y las entidades mencionadas:\n\n#### Temas Clave\n\n1. **Roles y Responsabilidades**:\n   - **Gerente de Proyecto**: Encargado de la planificaci\u00f3n, gesti\u00f3n de actividades, recursos y costos, monitoreo del progreso, gesti\u00f3n de desviaciones de calidad y aseguramiento del cumplimiento del sistema.\n   - **Unidad de Calidad**: Asegura el cumplimiento de requisitos regulatorios y de calidad, apoya la revisi\u00f3n y aprobaci\u00f3n de resultados de validaci\u00f3n, y eval\u00faa y aprueba desviaciones de calidad.\n   - **Expertos en la Materia (SME)**: Profesionales con experiencia espec\u00edfica que participan en la planificaci\u00f3n de estrategias de verificaci\u00f3n, realizaci\u00f3n de revisiones, definici\u00f3n de criterios de aceptaci\u00f3n y ejecuci\u00f3n de pruebas de verificaci\u00f3n.\n\n2. **Gesti\u00f3n de Riesgos de Calidad**:\n   - Importancia de realizar evaluaciones de riesgo basadas en procesos comerciales y requisitos regulatorios.\n   - Evaluaci\u00f3n del impacto del sistema en relaci\u00f3n con las Buenas Pr\u00e1cticas de Manufactura (GMP).\n   - Consideraciones para sistemas complejos como los ERP, incluyendo la repetibilidad y actualizaci\u00f3n de las evaluaciones.\n\n3. **Estrategia de Validaci\u00f3n**:\n   - Necesidad de definir una estrategia de validaci\u00f3n adecuada que contemple las caracter\u00edsticas espec\u00edficas del sistema y su relevancia para los procesos de negocio.\n\n#### Entidades\n\n- **Gerente de Proyecto**: Responsable de la gesti\u00f3n del proyecto de validaci\u00f3n.\n- **Unidad de Calidad**: Asegura el cumplimiento normativo y de calidad.\n- **Expertos en la Materia (SME)**: Proporcionan conocimientos especializados en \u00e1reas espec\u00edficas.\n- **Sistemas ERP**: Ejemplo de sistemas complejos que requieren una evaluaci\u00f3n cuidadosa en el contexto de GMP.\n\nEste resumen destaca la estructura organizativa y los procesos necesarios para llevar a cabo una validaci\u00f3n efectiva de sistemas inform\u00e1ticos, enfatizando la colaboraci\u00f3n entre diferentes roles y la importancia de la gesti\u00f3n de riesgos.", "excerpt_keywords": "Keywords: validation, risk assessment, acceptance criteria, change control, standard operating procedures"}}, "e6359bf0-11b9-42e5-9008-8bd9933a81a9": {"node_ids": ["aee154af-6447-48ca-9b55-47fc6442b3d3"], "metadata": {"page_label": "29", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "- Configuration management;\n- Maintaining your validated status.\n\n## 9.2.2.11 Glossary\n\nDefinitions of any terms and abbreviations that may be little known should be included.\n\n## 9.3 DOCUMENT CONTAINING USER REQUIREMENTS SPECIFICATIONS (ERU / URS)\n\n### 9.3.1 Introduction\n\nThe User Requirements Specifications (ERU / URS) document defines the requirements for a system computerized system component.\n\nThe length and detail of this document must be commensurate with risk, innovation and system complexity and must be sufficient to support subsequent risk analysis activities, specification, configuration / design and verification, if necessary.\n\nFor a low risk and commercially available system, it may be appropriate to include this document in the purchase documentation of the system, while for a complex and customized application can be Several levels of specification are required.\n\nThe ERU / URS document is the responsibility of the regulated company, but it can be written by a company outsourced or by the system supplier.\n\nThe User Requirements Specifications (ERU / URS) document clearly and precisely defines what the regulated company wants the system to do. It is driven by the needs of the business process.\n\nFor category 4 and 5 systems the requirements must be developed independently from the solutions available on the market.\n\nFor category 3 systems, in particular, there may be a limited number of suppliers or even a preferred supplier for a particular type of system, which justifies the use of solutions available in the market.\n\nThe requirements must cover the following points, and may include others that are not listed:\n\n- Operational;\n- Functional;\n- Dice;\n- Technical;\n- *Interface*;\n- Environmental;\n- Performance;\n- Availability;", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas basadas en el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas computacionales establece directrices para la creaci\u00f3n de un documento de Especificaciones de Requisitos del Usuario (ERU / URS). Este documento debe definir claramente los requisitos de un componente del sistema computarizado, considerando factores como el riesgo, la innovaci\u00f3n y la complejidad del sistema. La responsabilidad de elaborar este documento recae en la empresa regulada, aunque puede ser redactado por un tercero o el proveedor del sistema. Adem\u00e1s, se especifican diferentes categor\u00edas de sistemas y c\u00f3mo deben desarrollarse los requisitos en funci\u00f3n de estas categor\u00edas.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfQu\u00e9 factores deben considerarse al determinar la longitud y el nivel de detalle del documento ERU / URS?**\n   - La longitud y el detalle del documento deben ser proporcionales al riesgo, la innovaci\u00f3n y la complejidad del sistema, y deben ser suficientes para respaldar actividades posteriores de an\u00e1lisis de riesgos, especificaci\u00f3n, configuraci\u00f3n/dise\u00f1o y verificaci\u00f3n.\n\n2. **\u00bfQui\u00e9n es responsable de la elaboraci\u00f3n del documento ERU / URS y qui\u00e9n puede redactarlo?**\n   - La responsabilidad de elaborar el documento ERU / URS recae en la empresa regulada, pero puede ser redactado por una empresa externa o por el proveedor del sistema.\n\n3. **\u00bfCu\u00e1les son los puntos clave que deben cubrirse en los requisitos del documento ERU / URS?**\n   - Los requisitos deben cubrir aspectos operacionales, funcionales, t\u00e9cnicos, de interfaz, ambientales, de rendimiento y de disponibilidad, entre otros que puedan ser relevantes.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Evaluaci\u00f3n de Riesgos**: Importancia de identificar y evaluar riesgos asociados con el sistema inform\u00e1tico.\n\n2. **Evaluaci\u00f3n de Componentes del Sistema**: An\u00e1lisis de la arquitectura y los componentes del sistema para asegurar su adecuaci\u00f3n.\n\n3. **Evaluaci\u00f3n de Proveedores**: Consideraci\u00f3n de la capacidad y fiabilidad de los proveedores involucrados en el sistema.\n\n4. **Formalizaci\u00f3n de Conclusiones**: Necesidad de documentar y formalizar las conclusiones de las evaluaciones realizadas.\n\n5. **Estrategia de Validaci\u00f3n**:\n   - **Modelo de Ciclo de Vida**: Definici\u00f3n del enfoque a seguir durante el desarrollo del sistema.\n   - **Categor\u00edas de Hardware y Software**: Clasificaci\u00f3n de los componentes del sistema.\n   - **Requisitos y Resultados**: Especificaci\u00f3n de lo que se necesita lograr en cada etapa del proyecto.\n   - **Criterios de Aceptaci\u00f3n**: Establecimiento de los est\u00e1ndares para considerar una etapa como exitosa.\n   - **Trazabilidad**: M\u00e9todos para asegurar que los datos y documentos sean rastreables.\n   - **Revisi\u00f3n del Proyecto**: Enfoque para evaluar el progreso y la calidad del proyecto.\n\n6. **Resultados Esperados**: Listado de los resultados que deben producirse, junto con las responsabilidades de producci\u00f3n, revisi\u00f3n y aprobaci\u00f3n.\n\n7. **Criterios de Aceptaci\u00f3n**: Descripci\u00f3n de los criterios generales que determinan el \u00e9xito de cada etapa del proyecto.\n\n8. **Control de Cambios**: Definici\u00f3n de los requisitos y procedimientos para gestionar cambios en el proyecto, as\u00ed como la etapa en la que se aplicar\u00e1 el control de cambios operacionales.\n\n9. **Procedimientos Operativos Est\u00e1ndar (SOPs)**: Creaci\u00f3n o actualizaci\u00f3n de SOPs como resultado de la implementaci\u00f3n del sistema, incluyendo responsabilidades para su elaboraci\u00f3n, revisi\u00f3n y aprobaci\u00f3n.\n\n10. **Procesos Auxiliares**: Detalles sobre procesos complementarios, como capacitaci\u00f3n y gesti\u00f3n de documentaci\u00f3n, que son esenciales para el \u00e9xito del sistema.\n\n### Entidades Clave\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil.\n- **Sistema Inform\u00e1tico**: Conjunto de hardware y software que requiere validaci\u00f3n.\n- **Proveedores**: Entidades que suministran componentes o servicios para el sistema.\n- **Documentaci\u00f3n**: Registros y documentos que deben ser producidos y gestionados durante el proceso de validaci\u00f3n.", "excerpt_keywords": "Keywords: validation, user requirements, specifications, risk analysis, regulatory compliance"}}, "173bccdd-a95d-433a-b7ba-46be0d9f78db": {"node_ids": ["7251ee91-e46f-4db2-8a48-a07e76aaa196"], "metadata": {"page_label": "30", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# Guide for Computer Systems Validation\n\n- Safety;\n- Maintenance;\n- Regulatory;\n- Migration of any electronic data;\n\n## Page 28\n\n- Restrictions to be observed;\n- Life cycle.\n\nThe requirements should address applicable BPx regulations and highlight aspects that are critical to the patient safety, product quality and data integrity. The ERU document must not include requirements such as \"meets 21CFR Part 11\" or \"meets Anvisa legislation\" and to define what functionality the system must have to manage the risk to patient safety, product quality and integrity of the data.\n\nThe requirements must have the following characteristics:\n\n- Sufficient and adequate (Specific; Measurable, Attainable; Realistic; Testable);\n- Specific enough to carry out tests and verifications (Unequivocal; Clear; Precise; Complete);\n- Able to assist traceability along the requirement chain \u2192 configuration / design \u2192 test;\n- Provide the basis for formal testing and be used for supplier selection;\n- Prioritized with an emphasis on identifying mandatory requirements. The approach can be used three levels of priority, described below:\n- \u2713 Mandatory (high);\n- \u2713 Beneficial (average);\n- \u2713 Good to have (low).\n- Uniquely identified, with controlled version and maintenance of its control; Able to be used as a means of communication and management of critical requirements throughout the life cycle of the system rather than just an exercise;\n- Provide the system supplier with the definitive statement of mandatory and desirable requirements.\n\nThe ownership of the requirements belongs to the regulated company. The operational needs of the business and any associated problems can never be fully understood and captured without the effective participation of system users. Documented requirements form the basis for system acceptance by users.\n\n## 9.3.2 Content of the ERU / URS Document\n\n### 9.3.2.1 Introduction\n\nThe introduction item should provide information on:\n\n- Who produced the document, under what authority and for what purpose;\n- The contractual status of the document (if applicable), such as custom development or outsourced;", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas que pueden proporcionar respuestas espec\u00edficas basadas en el contexto proporcionado, as\u00ed como un resumen de nivel superior del contenido:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos establece directrices sobre c\u00f3mo formular requisitos para sistemas regulados en el \u00e1mbito de la salud. Se enfatiza la importancia de que los requisitos sean espec\u00edficos, medibles y priorizados, y que reflejen aspectos cr\u00edticos para la seguridad del paciente, la calidad del producto y la integridad de los datos. Adem\u00e1s, se menciona que la propiedad de los requisitos recae en la empresa regulada y que la participaci\u00f3n de los usuarios del sistema es esencial para comprender las necesidades operativas.\n\n### Preguntas\n1. **\u00bfCu\u00e1les son las caracter\u00edsticas clave que deben tener los requisitos seg\u00fan el documento de ANVISA?**\n   - Respuesta: Los requisitos deben ser espec\u00edficos, medibles, alcanzables, realistas y verificables; claros y completos; facilitar la trazabilidad; servir como base para pruebas formales y selecci\u00f3n de proveedores; estar priorizados; identificados de manera \u00fanica y controlados; y proporcionar una declaraci\u00f3n definitiva de requisitos obligatorios y deseables al proveedor del sistema.\n\n2. **\u00bfQu\u00e9 aspectos cr\u00edticos deben ser abordados en los requisitos para garantizar la seguridad del paciente y la calidad del producto?**\n   - Respuesta: Los requisitos deben abordar regulaciones aplicables y resaltar aspectos cr\u00edticos para la seguridad del paciente, la calidad del producto y la integridad de los datos, evitando incluir requisitos gen\u00e9ricos como \"cumple con 21CFR Part 11\" o \"cumple con la legislaci\u00f3n de Anvisa\".\n\n3. **\u00bfCu\u00e1l es la importancia de la participaci\u00f3n de los usuarios del sistema en la formulaci\u00f3n de requisitos?**\n   - Respuesta: La participaci\u00f3n efectiva de los usuarios del sistema es crucial para comprender y capturar completamente las necesidades operativas del negocio y los problemas asociados, lo que a su vez forma la base para la aceptaci\u00f3n del sistema por parte de los usuarios.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Especificaciones de Requisitos del Usuario (ERU / URS)**:\n   - Documento que define los requisitos para un componente de sistema computarizado.\n   - Debe ser proporcional al riesgo, innovaci\u00f3n y complejidad del sistema.\n\n2. **Responsabilidad**:\n   - La elaboraci\u00f3n del documento es responsabilidad de la empresa regulada, aunque puede ser redactado por un tercero o el proveedor del sistema.\n\n3. **Categor\u00edas de Sistemas**:\n   - **Categor\u00edas 4 y 5**: Los requisitos deben desarrollarse independientemente de las soluciones disponibles en el mercado.\n   - **Categor\u00eda 3**: Puede haber un n\u00famero limitado de proveedores, lo que justifica el uso de soluciones comerciales.\n\n4. **Puntos Clave a Cubrir en el Documento ERU / URS**:\n   - Requisitos operacionales.\n   - Requisitos funcionales.\n   - Requisitos t\u00e9cnicos.\n   - Requisitos de interfaz.\n   - Requisitos ambientales.\n   - Requisitos de rendimiento.\n   - Requisitos de disponibilidad.\n\n5. **Importancia del Documento**:\n   - Debe ser suficiente para respaldar actividades de an\u00e1lisis de riesgos, especificaci\u00f3n, configuraci\u00f3n/dise\u00f1o y verificaci\u00f3n.\n\n### Entidades Clave\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil.\n- **ERU / URS**: Especificaciones de Requisitos del Usuario.\n- **Categor\u00edas de Sistemas**: Clasificaci\u00f3n de sistemas seg\u00fan su riesgo y complejidad. \n\nEste resumen destaca los aspectos fundamentales y las entidades relevantes en la secci\u00f3n sobre las Especificaciones de Requisitos del Usuario en el contexto de la validaci\u00f3n de sistemas computacionales seg\u00fan ANVISA.", "excerpt_keywords": "Keywords: validation, requirements, patient safety, data integrity, ANVISA"}}, "ee4fc947-9c1b-4654-bdab-6aab89b63f14": {"node_ids": ["05d76d05-cf6a-4b68-a9f9-ea6f174fd999"], "metadata": {"page_label": "31", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 9.3.2.2 Overview\n\nAn overview of the system should be provided, explaining why the system is needed and what is required of the system. The following points should be considered:\n\n- **Contextualization**: describes the general objective of the system in the current context and the desired situation;\n\n## Scope\n\n- The insertion of the system in the company's long-term vision;\n- System boundaries and boundaries: what part of the business process is being automated;\n- Key objectives and benefits;\n- BPx requirements applicable;\n- Other applicable regulations.\n\n# 9.3.2.3 Operational Requirements\n\nOperational requirements include:\n\n- **Functions** - are the functional requirements that enable the system to execute the business process that is being automated, such as:\n- Calculations, including all critical algorithms;\n- Safety against damage;\n- Security including access control;\n- Audit trails;\n- Use of electronic signatures;\n- Outputs (e.g., reports);\n- Clear error messages.\n\n- **Data** - requirements related to data handling, considering its impact on security, patient, product quality and data integrity, covering the following points:\n- Definition of electronic records;\n- Definition of data types, including identification of characteristics, formatting, critical parameters, valid date range and format, limits and accuracy, and so on;\n- Where and how data will be recorded (e.g., relational databases, files encrypted, etc.)\n- Required fields;\n- Data migration (import and export);\n- Data entry and subsequent editing;\n- Backup and recovery;\n- Archiving requirements;", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas que pueden proporcionar respuestas espec\u00edficas basadas en el contexto proporcionado, as\u00ed como un resumen de nivel superior del contenido:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos establece directrices para la creaci\u00f3n de un sistema que cumpla con los requisitos operativos y de datos necesarios para automatizar procesos empresariales en el sector de la salud. Se enfatiza la importancia de contextualizar el sistema dentro de la visi\u00f3n a largo plazo de la empresa, as\u00ed como la necesidad de definir claramente los requisitos funcionales y de manejo de datos para garantizar la seguridad, la integridad de los datos y el cumplimiento normativo.\n\n### Preguntas\n\n1. **\u00bfCu\u00e1les son los elementos clave que deben incluirse en la contextualizaci\u00f3n del sistema para asegurar su alineaci\u00f3n con la visi\u00f3n a largo plazo de la empresa?**\n   - Esta pregunta busca respuestas espec\u00edficas sobre c\u00f3mo se debe articular la relaci\u00f3n entre el sistema y los objetivos estrat\u00e9gicos de la empresa, lo que no se detalla en otros documentos.\n\n2. **\u00bfQu\u00e9 consideraciones espec\u00edficas deben tenerse en cuenta al definir los requisitos de datos para garantizar la integridad y seguridad de la informaci\u00f3n en el sistema?**\n   - Aqu\u00ed se busca profundizar en los aspectos t\u00e9cnicos y normativos que afectan la gesti\u00f3n de datos, lo que puede no estar claramente especificado en otras gu\u00edas o documentos.\n\n3. **\u00bfC\u00f3mo se deben abordar las necesidades de auditor\u00eda y control de acceso en el dise\u00f1o del sistema para cumplir con las regulaciones aplicables?**\n   - Esta pregunta se centra en los requisitos de seguridad y auditor\u00eda, que son cr\u00edticos para la validaci\u00f3n de sistemas en el sector de la salud, y que pueden no estar suficientemente cubiertos en otras fuentes de informaci\u00f3n. \n\nEstas preguntas est\u00e1n dise\u00f1adas para extraer informaci\u00f3n detallada y espec\u00edfica que es crucial para la implementaci\u00f3n y validaci\u00f3n de sistemas inform\u00e1ticos en el contexto regulatorio de Brasil.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos aborda varios temas clave relacionados con la formulaci\u00f3n de requisitos para sistemas regulados en el \u00e1mbito de la salud. A continuaci\u00f3n se presentan los puntos m\u00e1s destacados:\n\n1. **Caracter\u00edsticas de los Requisitos**:\n   - Los requisitos deben ser **espec\u00edficos**, **medibles**, **alcanzables**, **realistas** y **verificables**.\n   - Deben ser **claros**, **precisos** y **completos** para facilitar pruebas y verificaciones.\n   - Es esencial que los requisitos permitan la **trazabilidad** a lo largo de la cadena de requisitos, configuraci\u00f3n, dise\u00f1o y pruebas.\n   - Deben servir como base para **pruebas formales** y ser utilizados en la **selecci\u00f3n de proveedores**.\n   - Los requisitos deben estar **priorizados**, identificando aquellos que son **obligatorios**, **beneficiosos** o **deseables**.\n   - Cada requisito debe tener una **identificaci\u00f3n \u00fanica** y un control de versi\u00f3n adecuado.\n\n2. **Importancia de la Seguridad del Paciente y Calidad del Producto**:\n   - Los requisitos deben abordar regulaciones aplicables y resaltar aspectos cr\u00edticos para la **seguridad del paciente**, **calidad del producto** e **integridad de los datos**.\n   - Se debe evitar incluir requisitos gen\u00e9ricos como \"cumple con 21CFR Part 11\" o \"cumple con la legislaci\u00f3n de Anvisa\".\n\n3. **Participaci\u00f3n de los Usuarios del Sistema**:\n   - La **participaci\u00f3n efectiva** de los usuarios es crucial para entender completamente las necesidades operativas y problemas asociados, lo que forma la base para la **aceptaci\u00f3n del sistema** por parte de los usuarios.\n\n4. **Contenido del Documento ERU / URS**:\n   - La introducci\u00f3n del documento debe incluir informaci\u00f3n sobre qui\u00e9n lo produjo, bajo qu\u00e9 autoridad y con qu\u00e9 prop\u00f3sito, as\u00ed como el estado contractual del documento (desarrollo personalizado o subcontratado).\n\n### Entidades Clave\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil.\n- **BPx**: Regulaciones aplicables en el contexto de la salud.\n- **ERU / URS**: Documentos de requisitos de usuario y requisitos de sistema.\n- **Sistema**: Se refiere a los sistemas inform\u00e1ticos regulados en el \u00e1mbito de la salud.\n\nEste resumen destaca la importancia de establecer requisitos claros y bien definidos para garantizar la seguridad y calidad en los sistemas inform\u00e1ticos utilizados en el sector salud.", "excerpt_keywords": "Keywords: ANVISA, computer systems validation, operational requirements, data integrity, regulatory compliance"}}, "1eede705-799b-4f4e-a048-745494508601": {"node_ids": ["ab407e80-d9c0-4b55-8dd4-29c7589d232b"], "metadata": {"page_label": "32", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "- Data security and integrity.\n\n- **Technical Requirements** - Covers the following points:\n- Changes in system operation (start, stop, test, failures);\n- Disaster recovery;\n- Performance and time requirements. They must be quantitative and unambiguous;\n- Action required in case of failure;\n- Capacity requirements;\n- Access speed requirements for reading and writing data;\n- Hardware requirements (e.g., touch-screen, keyboard type; type of mouse and mouse pad; type and number of physical processors, network card);\n- Portability and remote access;\n\n----\n\n- Efficiency (screen and system loading speeds, screen refresh and generation reporting);\n- Type and version of the platform on which the system will work (Windows, Unix, Linux etc.);\n- Types and versions of the protocols used;\n- Configurability.\n\n- **Interfaces** - must be defined (if applicable), covering the following points:\n- User interface(s) - defined in terms of access levels (operator, administrator, system manager) or roles where appropriate;\n- Interface(s) with other systems;\n- Interface(s) with equipment, such as sensors or actuators. This may include I/O lists (input and output) for systems used for process control;\n- Form of input and output of data by users (e.g., keyboard, barcode reader, printers, etc.).\n\n- **Environment** - involves the environment in which the system will work, covering the following points:\n- Layout - physical layout of the plant or other workplace that may impact the system, such as remote links (remote access) or space limitations;\n- Physical conditions (e.g., temperature; humidity; external interference; protection against radio frequency, electromagnetic and/or UV interference; dust, high vibration);\n- Physical requirements;\n- Power/energy requirements (e.g., voltage, amperage; filtering; frequency; protection of grounding; uninterrupted power supply/UPS);\n- Any physical or logical requirements.\n\n## 9.3.2.4 Restrictions\n\nAny restrictions in the specifications or operation of the system must be identified and documented, covering the following points:\n\n- [Content not provided in the image]", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas que se pueden responder espec\u00edficamente con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos establece requisitos t\u00e9cnicos, de interfaz y ambientales que deben cumplirse para garantizar la seguridad y la integridad de los datos. Se detallan aspectos como la recuperaci\u00f3n ante desastres, requisitos de rendimiento, configurabilidad, y las condiciones f\u00edsicas en las que operar\u00e1 el sistema. Tambi\u00e9n se enfatiza la importancia de documentar cualquier restricci\u00f3n en las especificaciones o en la operaci\u00f3n del sistema.\n\n### Preguntas\n\n1. **\u00bfCu\u00e1les son los requisitos espec\u00edficos que deben cumplirse para garantizar la recuperaci\u00f3n ante desastres en un sistema inform\u00e1tico seg\u00fan la gu\u00eda de ANVISA?**\n   - La gu\u00eda menciona que se deben establecer procedimientos claros para la recuperaci\u00f3n ante desastres, aunque no se detallan en el texto proporcionado. Sin embargo, se espera que estos procedimientos sean documentados y que incluyan acciones espec\u00edficas a seguir en caso de fallos.\n\n2. **\u00bfQu\u00e9 consideraciones f\u00edsicas deben tenerse en cuenta al implementar un sistema inform\u00e1tico en un entorno de trabajo seg\u00fan la gu\u00eda?**\n   - La gu\u00eda destaca la importancia de considerar el dise\u00f1o f\u00edsico del lugar de trabajo, las condiciones ambientales (como temperatura y humedad), y los requisitos de energ\u00eda (como voltaje y frecuencia) para asegurar que el sistema funcione correctamente.\n\n3. **\u00bfC\u00f3mo se deben definir las interfaces de usuario en un sistema inform\u00e1tico seg\u00fan las recomendaciones de ANVISA?**\n   - Las interfaces de usuario deben definirse en t\u00e9rminos de niveles de acceso (como operador, administrador y gestor del sistema) y deben incluir detalles sobre la interacci\u00f3n con otros sistemas y equipos, as\u00ed como los m\u00e9todos de entrada y salida de datos utilizados por los usuarios.", "prev_section_summary": "### Resumen de Temas Clave y Entidades de la Secci\u00f3n\n\n#### Temas Clave\n\n1. **Contextualizaci\u00f3n del Sistema**:\n   - Importancia de explicar el objetivo general del sistema en el contexto actual y la situaci\u00f3n deseada.\n   - Relaci\u00f3n del sistema con la visi\u00f3n a largo plazo de la empresa.\n\n2. **Alcance del Sistema**:\n   - Definici\u00f3n de los l\u00edmites del sistema y el proceso empresarial que se automatiza.\n   - Identificaci\u00f3n de los objetivos clave y beneficios esperados.\n   - Consideraci\u00f3n de requisitos regulatorios aplicables.\n\n3. **Requisitos Operacionales**:\n   - **Funciones**: Requisitos funcionales necesarios para la automatizaci\u00f3n del proceso, incluyendo:\n     - C\u00e1lculos y algoritmos cr\u00edticos.\n     - Seguridad y control de acceso.\n     - Trazabilidad y auditor\u00eda.\n     - Uso de firmas electr\u00f3nicas.\n     - Generaci\u00f3n de informes y mensajes de error claros.\n   \n   - **Datos**: Requisitos relacionados con el manejo de datos, que incluyen:\n     - Definici\u00f3n de registros electr\u00f3nicos y tipos de datos.\n     - Especificaciones sobre el almacenamiento y formato de datos.\n     - Requisitos de migraci\u00f3n, entrada y edici\u00f3n de datos.\n     - Estrategias de respaldo, recuperaci\u00f3n y archivo de datos.\n\n#### Entidades\n\n- **Sistema**: Herramienta o conjunto de herramientas que automatizan procesos empresariales.\n- **Empresa**: Organizaci\u00f3n que implementa el sistema en su estrategia a largo plazo.\n- **Regulaciones**: Normativas que deben cumplirse en el contexto de la validaci\u00f3n de sistemas inform\u00e1ticos, especialmente en el sector de la salud.\n- **Datos**: Informaci\u00f3n que el sistema maneja, incluyendo registros electr\u00f3nicos y su integridad.\n- **Funciones**: Capacidades espec\u00edficas que el sistema debe tener para cumplir con los procesos automatizados.\n\nEste resumen destaca la importancia de una planificaci\u00f3n cuidadosa y la consideraci\u00f3n de requisitos operativos y de datos para asegurar la efectividad y cumplimiento del sistema en el contexto regulatorio.", "excerpt_keywords": "Keywords: validation, data integrity, technical requirements, user interfaces, environmental conditions"}}, "4364c695-55ac-4c09-b882-33be2ff148d2": {"node_ids": ["583850af-1bd9-43e7-a376-d7319e2f881f"], "metadata": {"page_label": "33", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 9.3.2.5 Life Cycle\n\nAny requirements that may impact the development of the cycle should be identified and documented at the supplier and any subsequent verification activities.\n\nThe following points should be covered:\n\n- Development requirements (eg, minimum standards to be met by the provider);\n- Procedures for project management and quality assurance;\n- Mandatory design methods;\n- Special testing requirements;\n- Test data;\n- Loading test;\n- Necessary simulations;\n- Factory Acceptance Test (FAT);\n- How the items to be delivered should be provided (eg, format and media);\n- Documentation to be delivered by the supplier (eg functional specifications; test specifications; minimum hardware and software requirements; design specifications; maintenance guides or manuals and user);\n- Data to be prepared or converted;\n- Testing, maintenance, data and access management tools;\n- Training courses;\n- Archiving facilities;\n- Support and maintenance required after acceptance.\n\n# 9.3.2.6 Glossary\n\nNO_CONTENT_HERE", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas que pueden proporcionar respuestas espec\u00edficas basadas en el contexto proporcionado:\n\n1. **\u00bfCu\u00e1les son los requisitos m\u00ednimos que deben cumplir los proveedores seg\u00fan la gu\u00eda de ANVISA para la validaci\u00f3n de sistemas inform\u00e1ticos?**\n   - Esta pregunta se centra en los \"requisitos de desarrollo\" mencionados en el contexto, que son cruciales para asegurar que los proveedores cumplan con los est\u00e1ndares necesarios.\n\n2. **\u00bfQu\u00e9 tipo de documentaci\u00f3n debe entregar el proveedor al finalizar el ciclo de desarrollo seg\u00fan la gu\u00eda de ANVISA?**\n   - Esta pregunta aborda el punto sobre la \"documentaci\u00f3n a ser entregada por el proveedor\", lo que es esencial para garantizar que se cumplan todas las especificaciones y requisitos necesarios.\n\n3. **\u00bfQu\u00e9 actividades de verificaci\u00f3n se deben realizar despu\u00e9s de la aceptaci\u00f3n del sistema seg\u00fan la gu\u00eda de ANVISA?**\n   - Esta pregunta se refiere a las \"actividades de verificaci\u00f3n\" que deben documentarse y realizarse, lo que es fundamental para asegurar el correcto funcionamiento y mantenimiento del sistema despu\u00e9s de su aceptaci\u00f3n.\n\n### Resumen de nivel superior del contexto circundante:\nLa secci\u00f3n 9.3.2.5 del documento de ANVISA se centra en el ciclo de vida de los sistemas inform\u00e1ticos, destacando la importancia de identificar y documentar requisitos que puedan impactar el desarrollo. Se enumeran varios aspectos clave que deben ser considerados, como los requisitos de desarrollo, procedimientos de gesti\u00f3n de proyectos, m\u00e9todos de dise\u00f1o, pruebas especiales, y la documentaci\u00f3n que debe ser proporcionada por el proveedor. Esto es esencial para asegurar que los sistemas inform\u00e1ticos cumplan con los est\u00e1ndares de calidad y regulaciones pertinentes.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Seguridad e Integridad de los Datos**: Se enfatiza la importancia de proteger la informaci\u00f3n y asegurar su integridad en los sistemas inform\u00e1ticos.\n\n2. **Requisitos T\u00e9cnicos**:\n   - **Operaci\u00f3n del Sistema**: Cambios en el funcionamiento del sistema, recuperaci\u00f3n ante desastres, requisitos de rendimiento y capacidad.\n   - **Requisitos de Hardware**: Especificaciones sobre dispositivos de entrada/salida, procesadores, y conectividad.\n   - **Eficiencia**: Velocidades de carga y actualizaci\u00f3n de pantalla, as\u00ed como la configurabilidad del sistema.\n\n3. **Interfaces**:\n   - **Interfaz de Usuario**: Definici\u00f3n de niveles de acceso y roles.\n   - **Interacci\u00f3n con Otros Sistemas y Equipos**: Detalles sobre c\u00f3mo el sistema se conecta y comunica con otros dispositivos y sistemas.\n\n4. **Entorno**:\n   - **Condiciones F\u00edsicas**: Consideraciones sobre el dise\u00f1o del espacio de trabajo, condiciones ambientales (temperatura, humedad) y requisitos de energ\u00eda.\n   - **Requisitos F\u00edsicos y L\u00f3gicos**: Necesidades espec\u00edficas que deben cumplirse para el correcto funcionamiento del sistema.\n\n5. **Restricciones**: Necesidad de identificar y documentar cualquier limitaci\u00f3n en las especificaciones o en la operaci\u00f3n del sistema.\n\n### Entidades Clave\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil, responsable de la regulaci\u00f3n y validaci\u00f3n de sistemas inform\u00e1ticos en el \u00e1mbito de la salud.\n- **Sistemas Inform\u00e1ticos**: Plataformas y aplicaciones que requieren validaci\u00f3n para garantizar su funcionamiento seguro y efectivo.\n- **Requisitos de Hardware y Software**: Especificaciones t\u00e9cnicas necesarias para la implementaci\u00f3n y operaci\u00f3n de sistemas inform\u00e1ticos.\n- **Interfaz de Usuario**: Componentes que permiten la interacci\u00f3n entre el usuario y el sistema, incluyendo niveles de acceso y m\u00e9todos de entrada/salida.\n\nEste resumen abarca los aspectos fundamentales y las entidades relevantes mencionadas en la secci\u00f3n del documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos.", "excerpt_keywords": "Keywords: ANVISA, Computer Systems Validation, Life Cycle, Development Requirements, Documentation"}}, "cdd7265a-089b-42c9-84ac-beecc831b31d": {"node_ids": ["9a12ea6b-8f72-4c28-8816-5cfe5ea15130"], "metadata": {"page_label": "34", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "Definitions of any little-known terms should be provided.\n\n## 9.3.2.7 Approvals\n\nApprovers must be defined. At a minimum, one of the approvers must be the owner of the process. Others approvers could be the owner of the system and the quality unit.\n\nOnce the ERU document has been approved, any changes must be made through the control of changes.\n\n## 9.3.3 Out of Scope Topics\n\nThis section is intended for systems with multiple levels of specification and verification and may not be applicable to Category 3 systems, low risk and commercially available.\n\nThe following items should not be included in the ERU / URS:\n\n- System configuration / project details;\n- Implementation details;\n\nGuide for Computer Systems Validation\nGuide n\u00b0 33/2020 - version 1, of 03/26/2020\n\n- Project deadlines;\n- Costs;\n- Organizational details of the project.\n\nThe system configuration / project details item is part of the solution of how requirements will be met, being defined in the subsequent specifications. Implementation details are also totally dependent on the solution, not being part of this step.\n\n## 9.3.4 Capture of Requirements\n\nFor category 4 and 5 systems, it is often more difficult and time consuming to prepare the ERU / URS document. The development of this document is one of the most important tasks that the regulated company will undertake within the project to implement a computerized system.\n\nIt is essential that the process to be automated is properly mapped before defining ERP / URS. Thus, it is important to detail the process step by step, defining the input and output information. This activity should be carried out by a multidisciplinary team, including the operational level.\n\nBelow is a list of the different modes that can be used by the regulated company for the capture and refinement of user requirements:\n\n- Discussions and interviews;\n- Observation (understanding of the process as a whole);\n- Workshops - multidisciplinary team;\n- Understanding the pitfalls that can occur when defining requirements.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas basadas en el contexto proporcionado, junto con sus respuestas:\n\n1. **\u00bfQui\u00e9nes deben ser los aprobadores del documento ERU y cu\u00e1l es su rol?**\n   - Los aprobadores deben ser definidos, y al menos uno de ellos debe ser el propietario del proceso. Otros aprobadores pueden incluir al propietario del sistema y a la unidad de calidad. Su rol es garantizar que el documento cumpla con los requisitos necesarios antes de su implementaci\u00f3n y que cualquier cambio posterior se gestione a trav\u00e9s del control de cambios.\n\n2. **\u00bfQu\u00e9 elementos no deben incluirse en el documento ERU/URS para sistemas de categor\u00eda 3?**\n   - Para sistemas de categor\u00eda 3, que son de bajo riesgo y comercialmente disponibles, no se deben incluir en el documento ERU/URS los siguientes elementos: detalles de configuraci\u00f3n del sistema/proyecto, detalles de implementaci\u00f3n, plazos del proyecto, costos y detalles organizacionales del proyecto. Estos elementos son considerados fuera del alcance del documento en esta etapa.\n\n3. **\u00bfCu\u00e1l es la importancia de mapear el proceso antes de definir el ERU/URS?**\n   - Es esencial mapear adecuadamente el proceso que se va a automatizar antes de definir el ERU/URS, ya que esto permite detallar el proceso paso a paso y definir la informaci\u00f3n de entrada y salida. Esta actividad debe ser realizada por un equipo multidisciplinario, incluyendo el nivel operativo, para asegurar que todos los requisitos del usuario sean capturados y refinados de manera efectiva.\n\n### Resumen de nivel superior del contexto:\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos establece directrices sobre la aprobaci\u00f3n de documentos ERU/URS, los elementos que deben excluirse de estos documentos y la importancia de un mapeo adecuado del proceso antes de su definici\u00f3n. Se enfatiza la necesidad de un enfoque multidisciplinario para la captura y refinamiento de requisitos, especialmente en sistemas de categor\u00edas m\u00e1s altas, donde la complejidad y el tiempo de preparaci\u00f3n son mayores.", "prev_section_summary": "### Resumen de la Secci\u00f3n 9.3.2.5 - Ciclo de Vida\n\nLa secci\u00f3n 9.3.2.5 del documento de ANVISA se enfoca en la importancia de identificar y documentar los requisitos que pueden influir en el desarrollo del ciclo de vida de los sistemas inform\u00e1ticos. A continuaci\u00f3n se presentan los temas clave y entidades mencionadas:\n\n1. **Requisitos de Desarrollo**: Se deben establecer est\u00e1ndares m\u00ednimos que los proveedores deben cumplir.\n   \n2. **Gesti\u00f3n de Proyectos y Aseguramiento de Calidad**: Se deben definir procedimientos claros para la gesti\u00f3n del proyecto y la garant\u00eda de calidad.\n\n3. **M\u00e9todos de Dise\u00f1o**: Se especifican m\u00e9todos de dise\u00f1o obligatorios que deben seguirse.\n\n4. **Requisitos de Pruebas Especiales**: Se deben identificar y documentar pruebas espec\u00edficas necesarias para el sistema.\n\n5. **Datos de Prueba**: Se requiere la preparaci\u00f3n de datos que se utilizar\u00e1n en las pruebas.\n\n6. **Pruebas de Carga**: Se deben realizar pruebas para evaluar el rendimiento del sistema bajo condiciones de carga.\n\n7. **Simulaciones Necesarias**: Se deben llevar a cabo simulaciones que sean relevantes para el sistema.\n\n8. **Prueba de Aceptaci\u00f3n en F\u00e1brica (FAT)**: Se debe realizar una prueba de aceptaci\u00f3n antes de la entrega final del sistema.\n\n9. **Formato y Medios de Entrega**: Se debe especificar c\u00f3mo se entregar\u00e1n los elementos (formato y medios).\n\n10. **Documentaci\u00f3n del Proveedor**: El proveedor debe entregar documentaci\u00f3n esencial, que incluye especificaciones funcionales, especificaciones de prueba, requisitos m\u00ednimos de hardware y software, especificaciones de dise\u00f1o, gu\u00edas de mantenimiento y manuales de usuario.\n\n11. **Preparaci\u00f3n o Conversi\u00f3n de Datos**: Se debe planificar la preparaci\u00f3n o conversi\u00f3n de datos necesarios.\n\n12. **Herramientas de Gesti\u00f3n**: Se deben definir herramientas para pruebas, mantenimiento, gesti\u00f3n de datos y acceso.\n\n13. **Cursos de Capacitaci\u00f3n**: Se deben ofrecer cursos de formaci\u00f3n para los usuarios del sistema.\n\n14. **Instalaciones de Archivo**: Se deben establecer instalaciones para el archivo de documentaci\u00f3n y datos.\n\n15. **Soporte y Mantenimiento**: Se debe planificar el soporte y mantenimiento necesarios despu\u00e9s de la aceptaci\u00f3n del sistema.\n\nEste enfoque integral asegura que todos los aspectos del ciclo de vida del sistema inform\u00e1tico sean considerados y documentados, garantizando as\u00ed el cumplimiento de los est\u00e1ndares de calidad y regulaciones pertinentes.", "excerpt_keywords": "Keywords: approvals, ERU, URS, requirements capture, system validation"}}, "850ab2bb-012a-42bc-bd46-6470cc141e7a": {"node_ids": ["cb0ffbae-5b26-4d72-b4bd-9ffc30bf7b3b"], "metadata": {"page_label": "35", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 9.4 SELECTION OF COMPUTER SYSTEMS SUPPLIER\n\n## 9.4.1 Introduction\n\nAfter the construction of the document containing the user's requirements (ERU / URS), the regulated company will select the supplier of the computerized system that meets the requirements established and described previously.\n\nRegulated companies must perform formal assessment of each computer system supplier relevant to GMP and related services. This assessment should be based on the criticality of the system / service to be provided.\n\nThere must be a formal justification for not carrying out the evaluation of system / service providers relevant to GMP.\n\n## 9.4.2 Types of Evaluation\n\nThere are three options for conducting a system / service provider assessment:\n\n- Basic assessment based on available information;\n- Auditing using a questionnaire;\n- Audit with a visit to the supplier by a specialist, auditor or audit team.\n\nNormally, a basic audit is sufficient for low-impact systems, whereas for high-impact systems impact it may be necessary to carry out a more in-depth assessment.\n\nAuditing using a questionnaire may be suitable for suppliers of products and services standard and configurable.\n\n## 9.4.3 Evaluation Process\n\nThe main steps for supplier assessment are as follows:\n\n1. Decision-making based on risk, the most appropriate route for carrying out the assessment;\n2. Performing the basic assessment, if sufficient, or the assessment using a questionnaire or assessment through visiting the supplier, depending on the decision made above;\n3. Evaluation report;\n4. Determination of corrective and follow-up actions, which may involve a visit from monitoring at the supplier's company;\n5. Supplier approval or rejection.\n\nIf the supplier is approved, it must be periodically reassessed by the regulated company, in accordance with the frequency defined in standard operating procedure.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos establece un proceso formal para la selecci\u00f3n y evaluaci\u00f3n de proveedores de sistemas inform\u00e1ticos en empresas reguladas. Este proceso incluye la elaboraci\u00f3n de un documento de requisitos del usuario (ERU/URS) y la evaluaci\u00f3n de proveedores basada en la criticidad del sistema o servicio. Se describen diferentes tipos de evaluaciones (b\u00e1sica, mediante cuestionario o auditor\u00eda en el sitio) y un proceso de evaluaci\u00f3n que incluye la toma de decisiones, la realizaci\u00f3n de la evaluaci\u00f3n, la elaboraci\u00f3n de un informe y la aprobaci\u00f3n o rechazo del proveedor.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfQu\u00e9 criterios se deben considerar al decidir el tipo de evaluaci\u00f3n a realizar para un proveedor de sistemas inform\u00e1ticos?**\n   - La decisi\u00f3n debe basarse en el riesgo y la criticidad del sistema o servicio que el proveedor va a ofrecer.\n\n2. **\u00bfQu\u00e9 acciones deben tomarse si un proveedor es aprobado tras la evaluaci\u00f3n inicial?**\n   - El proveedor aprobado debe ser reevaluado peri\u00f3dicamente por la empresa regulada, de acuerdo con la frecuencia definida en el procedimiento operativo est\u00e1ndar.\n\n3. **\u00bfCu\u00e1l es la justificaci\u00f3n necesaria si una empresa decide no evaluar a un proveedor de sistemas relevantes para GMP?**\n   - Debe haber una justificaci\u00f3n formal para no llevar a cabo la evaluaci\u00f3n de los proveedores de sistemas o servicios relevantes para las Buenas Pr\u00e1cticas de Manufactura (GMP).", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Aprobaciones (9.3.2.7)**:\n   - **Aprobadores**: Se deben definir los aprobadores del documento ERU. Al menos uno debe ser el propietario del proceso, y otros pueden incluir al propietario del sistema y a la unidad de calidad.\n   - **Control de Cambios**: Una vez aprobado el documento ERU, cualquier cambio debe gestionarse a trav\u00e9s de un control de cambios.\n\n2. **Temas Fuera de Alcance (9.3.3)**:\n   - **Exclusiones del ERU/URS**: Para sistemas de categor\u00eda 3 (bajo riesgo y comercialmente disponibles), no se deben incluir:\n     - Detalles de configuraci\u00f3n del sistema/proyecto.\n     - Detalles de implementaci\u00f3n.\n     - Plazos del proyecto.\n     - Costos.\n     - Detalles organizacionales del proyecto.\n   - **Justificaci\u00f3n**: Estos elementos son considerados parte de la soluci\u00f3n que se definir\u00e1 en especificaciones posteriores.\n\n3. **Captura de Requisitos (9.3.4)**:\n   - **Dificultad en la Preparaci\u00f3n**: La preparaci\u00f3n del documento ERU/URS es m\u00e1s compleja y requiere m\u00e1s tiempo para sistemas de categor\u00edas 4 y 5.\n   - **Importancia del Mapeo**: Es crucial mapear adecuadamente el proceso a automatizar antes de definir el ERU/URS, detallando los pasos y la informaci\u00f3n de entrada y salida.\n   - **Equipo Multidisciplinario**: La actividad debe ser realizada por un equipo multidisciplinario, incluyendo personal operativo.\n\n4. **M\u00e9todos para Captura de Requisitos**:\n   - **T\u00e9cnicas**: Se sugieren varias t\u00e9cnicas para la captura y refinamiento de requisitos, tales como:\n     - Discusiones y entrevistas.\n     - Observaci\u00f3n del proceso.\n     - Talleres con un equipo multidisciplinario.\n     - Comprensi\u00f3n de posibles errores al definir requisitos.\n\n### Entidades Clave:\n- **Documentos**: ERU (Especificaci\u00f3n de Requisitos de Usuario) / URS (User Requirements Specification).\n- **Roles**: Aprobadores, propietario del proceso, propietario del sistema, unidad de calidad, equipo multidisciplinario.\n- **Categor\u00edas de Sistemas**: Categor\u00eda 3 (bajo riesgo), Categor\u00eda 4 y 5 (mayor complejidad).\n- **Actividades**: Mapeo de procesos, captura de requisitos, control de cambios. \n\nEste resumen destaca la importancia de la definici\u00f3n clara de roles, la exclusi\u00f3n de ciertos elementos en documentos espec\u00edficos y la necesidad de un enfoque colaborativo en la captura de requisitos para la validaci\u00f3n de sistemas inform\u00e1ticos.", "excerpt_keywords": "Keywords: supplier selection, computer systems validation, GMP assessment, evaluation process, risk-based assessment"}}, "52a74506-6878-42c0-a05a-69933984d353": {"node_ids": ["b87f51bd-ff00-4117-a5e2-6448238b02bf"], "metadata": {"page_label": "36", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 9.5 DOCUMENT CONTAINING FUNCTIONAL SPECIFICATIONS (EF / FS)\n\n## 9.5.1 Introduction\n\nFunctional specifications (EF / FS) define the system that meets the user's needs, described in specifications of user requirements (ERU / URS).\n\nFor some systems, such as those commercially available and low risk, belonging to category 3, a simple approach consisting of a simple level of specification and verification is appropriate and a document containing the functional specifications is not necessary.\n\nA Functional Specifications document defines what the system should do and what functions and facilities will be provided. It provides a list of project objectives for the system. Formal tests will be based on functional specifications.\n\nThe document containing the functional specifications is produced by the supplier and must be reviewed and approved by the regulated company. It is often considered a contract document.\n\nThe following guidelines must be followed when producing the specification:\n\n- All design constraints (e.g., the externally defined limitations that a system must meet, such as hardware / software platform, speed, power, test, environmental and operational conditions) must be explicitly documented;\n- Ambiguity, duplication and contradiction must be avoided;\n- Consistent nomenclature conventions must be adopted;\n- Each function and installation described must be testable;\n- Internal and external interfaces must be clearly defined;\n- The functional specifications must be clear enough to allow the project to proceed without there is frequent need to consult the author of these specifications\n- Both users and programmers must understand the functional specifications;\n\nGuide for Computer Systems Validation\nGuide n\u00b0 33/2020 - version 1, of 03/26/2020\n\n\u2713 The use of diagrams and graphs is recommended when appropriate.\n\nFunctional specifications must be prepared and organized in a way that allows traceability by the entire life cycle, from individual requirements to associated tests.\n\n## 9.5.2 Content of the EF / FS Document\n\nBelow is a list of topics that may be part of the EF / FS document, not intended to be neither exhaustive nor prescriptive.\n\n### 9.5.2.1 Introduction\n\nThe following information must be provided:\n\n- Document ownership;\n- Who produced the document, under what authority and for what purpose;", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos establece la importancia de las especificaciones funcionales (EF/FS) en el desarrollo de sistemas que satisfacen las necesidades del usuario. Estas especificaciones deben ser claras, testables y organizadas para permitir la trazabilidad a lo largo del ciclo de vida del sistema. Se enfatiza que el documento debe ser producido por el proveedor y revisado por la empresa regulada, y se ofrecen directrices sobre c\u00f3mo redactar estas especificaciones para evitar ambig\u00fcedades y asegurar la comprensi\u00f3n tanto por parte de los usuarios como de los programadores.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfCu\u00e1les son las caracter\u00edsticas que deben evitarse al redactar un documento de especificaciones funcionales seg\u00fan ANVISA?**\n   - El documento debe evitar ambig\u00fcedades, duplicaciones y contradicciones, y debe adoptar convenciones de nomenclatura consistentes.\n\n2. **\u00bfQu\u00e9 tipo de sistemas no requieren un documento de especificaciones funcionales seg\u00fan la gu\u00eda de ANVISA?**\n   - Los sistemas comercialmente disponibles y de bajo riesgo, que pertenecen a la categor\u00eda 3, pueden no necesitar un documento de especificaciones funcionales, ya que se puede aplicar un enfoque m\u00e1s simple de especificaci\u00f3n y verificaci\u00f3n.\n\n3. **\u00bfQu\u00e9 se recomienda incluir en el documento de especificaciones funcionales para facilitar la comprensi\u00f3n y la trazabilidad?**\n   - Se recomienda el uso de diagramas y gr\u00e1ficos cuando sea apropiado, y el documento debe estar organizado de manera que permita la trazabilidad desde los requisitos individuales hasta las pruebas asociadas.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n**Temas Clave:**\n\n1. **Selecci\u00f3n de Proveedores de Sistemas Inform\u00e1ticos:**\n   - Importancia de seleccionar un proveedor que cumpla con los requisitos del usuario (ERU/URS).\n   - Evaluaci\u00f3n formal de proveedores relevante a las Buenas Pr\u00e1cticas de Manufactura (GMP).\n\n2. **Criterios de Evaluaci\u00f3n:**\n   - La evaluaci\u00f3n debe basarse en la criticidad del sistema o servicio proporcionado.\n   - Justificaci\u00f3n formal necesaria si se decide no evaluar a un proveedor.\n\n3. **Tipos de Evaluaci\u00f3n:**\n   - Evaluaci\u00f3n b\u00e1sica basada en informaci\u00f3n disponible.\n   - Auditor\u00eda mediante cuestionario.\n   - Auditor\u00eda con visita al proveedor.\n\n4. **Proceso de Evaluaci\u00f3n:**\n   - Toma de decisiones basada en riesgo.\n   - Realizaci\u00f3n de la evaluaci\u00f3n (b\u00e1sica, cuestionario o visita).\n   - Elaboraci\u00f3n de un informe de evaluaci\u00f3n.\n   - Determinaci\u00f3n de acciones correctivas y seguimiento.\n   - Aprobaci\u00f3n o rechazo del proveedor.\n   - Reevaluaci\u00f3n peri\u00f3dica de proveedores aprobados.\n\n**Entidades:**\n\n- **Regulated Company (Empresa Regulada):** Entidad que selecciona y eval\u00faa proveedores.\n- **Supplier (Proveedor):** Entidad que ofrece sistemas inform\u00e1ticos y servicios relacionados.\n- **GMP (Good Manufacturing Practices - Buenas Pr\u00e1cticas de Manufactura):** Normativa que gu\u00eda la evaluaci\u00f3n de proveedores.\n- **ERU/URS (User Requirements Document / User Requirement Specification - Documento de Requisitos del Usuario):** Documento que establece los requisitos que debe cumplir el proveedor.\n- **Auditor / Audit Team (Auditor / Equipo de Auditor\u00eda):** Especialistas que realizan la evaluaci\u00f3n de los proveedores.\n\nEste resumen destaca los aspectos fundamentales del proceso de selecci\u00f3n y evaluaci\u00f3n de proveedores de sistemas inform\u00e1ticos seg\u00fan la gu\u00eda de ANVISA.", "excerpt_keywords": "Keywords: functional specifications, user requirements, validation, traceability, guidelines"}}, "4e9099ba-e104-4ef4-88d0-dc186687db1b": {"node_ids": ["9fc8611f-c591-4572-84a6-ebbff9015309"], "metadata": {"page_label": "37", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "- The contractual status of the document (if applicable);\n- Relationship with other documents (eg ERU / URS).\n\n## 9.5.2.2 Overview\n\nIt should cover the following topics, where appropriate:\n\n- Scope and objectives;\n- Reference to the relevant GMP regulations;\n- Impact on patient safety, product quality and data integrity;\n- High-level description (subdivide into primary system components);\n- The main interfaces between the system and other systems and / or the environment;\n- Assumptions / restrictions;\n- Non-conformities in relation to the specifications of the users' requirements, which must be documented and justified.\n\n## 9.5.2.3 Functions\n\nThe high-level description should be divided into individual functions.\n\nThe following aspects should be addressed, where appropriate:\n\n- The purpose of the function and the details of its use, including interface with other parts of the system. Inputs, outputs, critical calculations, algorithms and the impact on other functions and / or systems and / or environment must be highlighted;\n- Performance: response, scaling, centralized or distributed processing and throughput transfer - These points must be quantitative and unambiguous;\n- Security and protection - Action in case the selected software or hardware fails; self check; verification of input value; redundancy; access restrictions; downtime and data recovery;\n- Functions that are configurable and any limits for configuration;\n- Traceability to the specific requirements of the ERU / URS;\n\nGuide for Computer Systems Validation\nGuide n\u00b0 33/2020 - version 1, of 03/26/2020\n\nPage 35\n\n- Fault conditions, fault actions, log files and diagnostics.\n\n## 9.5.2.4 Data\n\nThe following aspects should be addressed, where appropriate:\n\n- Definition - data must be defined in a hierarchical manner, with complex objects being constructed from simpler objects (eg, log files). Critical parameters must be highlighted;\n- Access;\n- Allowable range for input and output values;\n- Required fields;\n- Verification of data validation;", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas que se pueden formular a partir del contexto proporcionado, junto con sus respuestas espec\u00edficas:\n\n### Preguntas y Respuestas\n\n1. **\u00bfCu\u00e1les son los aspectos clave que deben abordarse en la descripci\u00f3n de alto nivel de un sistema seg\u00fan la gu\u00eda de ANVISA?**\n   - La descripci\u00f3n de alto nivel debe incluir el alcance y objetivos del sistema, referencias a las regulaciones GMP relevantes, el impacto en la seguridad del paciente, la calidad del producto y la integridad de los datos. Tambi\u00e9n debe proporcionar una descripci\u00f3n de los componentes principales del sistema, las interfaces con otros sistemas y el entorno, as\u00ed como las suposiciones y restricciones aplicables.\n\n2. **\u00bfQu\u00e9 elementos se deben considerar al detallar las funciones de un sistema en el contexto de la validaci\u00f3n de sistemas inform\u00e1ticos?**\n   - Al detallar las funciones, se deben considerar el prop\u00f3sito de cada funci\u00f3n, su uso y la interfaz con otras partes del sistema. Adem\u00e1s, se deben resaltar los inputs, outputs, c\u00e1lculos cr\u00edticos, algoritmos, rendimiento (respuesta, escalabilidad, procesamiento centralizado o distribuido), seguridad y protecci\u00f3n, configurabilidad de las funciones, y la trazabilidad a los requisitos espec\u00edficos del ERU/URS.\n\n3. **\u00bfC\u00f3mo se debe definir y validar la data en un sistema seg\u00fan la gu\u00eda de ANVISA?**\n   - La data debe definirse de manera jer\u00e1rquica, construyendo objetos complejos a partir de objetos m\u00e1s simples. Se deben destacar los par\u00e1metros cr\u00edticos, establecer el acceso a los datos, definir los rangos permitidos para los valores de entrada y salida, identificar los campos requeridos y verificar la validaci\u00f3n de los datos.\n\n### Resumen de Nivel Superior\n\nLa gu\u00eda de ANVISA para la validaci\u00f3n de sistemas inform\u00e1ticos establece directrices claras sobre c\u00f3mo documentar y validar sistemas en el contexto de las regulaciones de Buenas Pr\u00e1cticas de Manufactura (GMP). Se enfatiza la importancia de una descripci\u00f3n clara del sistema, sus funciones y la gesti\u00f3n de datos, asegurando que se aborden aspectos cr\u00edticos como la seguridad, la integridad de los datos y la trazabilidad a los requisitos del usuario. La gu\u00eda tambi\u00e9n destaca la necesidad de documentar no conformidades y justificaciones en relaci\u00f3n con los requisitos del usuario, lo que es esencial para garantizar la calidad y la seguridad en el \u00e1mbito de la salud.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n**Temas Clave:**\n\n1. **Especificaciones Funcionales (EF/FS):** Definen el sistema que satisface las necesidades del usuario y se basan en las especificaciones de requisitos del usuario (ERU/URS).\n   \n2. **Documentaci\u00f3n:** Un documento de especificaciones funcionales es esencial para definir las funciones y objetivos del sistema, y debe ser producido por el proveedor y revisado por la empresa regulada.\n\n3. **Directrices para la Redacci\u00f3n:**\n   - Documentar todas las limitaciones de dise\u00f1o.\n   - Evitar ambig\u00fcedades, duplicaciones y contradicciones.\n   - Adoptar convenciones de nomenclatura consistentes.\n   - Asegurar que cada funci\u00f3n sea testable.\n   - Definir claramente las interfaces internas y externas.\n   - Facilitar la comprensi\u00f3n tanto para usuarios como para programadores.\n   - Organizar el documento para permitir la trazabilidad a lo largo del ciclo de vida del sistema.\n\n4. **Sistemas de Bajo Riesgo:** Para sistemas comercialmente disponibles y de bajo riesgo (categor\u00eda 3), puede no ser necesario un documento de especificaciones funcionales.\n\n5. **Uso de Diagramas:** Se recomienda el uso de diagramas y gr\u00e1ficos para mejorar la claridad del documento.\n\n**Entidades:**\n\n- **ANVISA:** Agencia Nacional de Vigilancia Sanitaria de Brasil, responsable de la regulaci\u00f3n.\n- **Proveedor:** Entidad que produce el documento de especificaciones funcionales.\n- **Empresa Regulada:** Entidad que revisa y aprueba el documento.\n- **Sistemas:** Se refiere a los sistemas inform\u00e1ticos que deben cumplir con las especificaciones funcionales.\n\nEste resumen destaca la importancia de las especificaciones funcionales en el desarrollo de sistemas inform\u00e1ticos y las directrices que deben seguirse para su correcta elaboraci\u00f3n y revisi\u00f3n.", "excerpt_keywords": "Keywords: validation, GMP regulations, data integrity, system functions, ANVISA"}}, "13589dfe-4b52-4471-b972-2f62d3f7780a": {"node_ids": ["b8506d63-27cf-4e6a-a53c-c38f26d487f8"], "metadata": {"page_label": "38", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "- Data relationship;\n- Data storage capacity, retention time and details on data archiving;\n- Data integrity and protection;\n- Data migration (import and export).\n\n## 9.5.2.5 Interfaces\n\nThe interfaces between systems should be described, defining how the systems and subsystems interact, which they come and what they need. For systems regulated by BPx, protection of the interfaces is important. The following points should be addressed when appropriate:\n\n- **Interfaces with users.** This should be defined in roles (access profile), such as, operator, administrator, system manager, etc. Topics to be considered: types of peripherals; general format of screens and reports; error handling and reporting and security. User input mode(s) should be set(s), such as, keyboard and mouse, touchscreen; pen calligraphy;\n- **Interfaces with equipment,** such as sensors and plant equipment;\n- **Interfaces with other systems.** This should cover the nature and time of interaction and the methods and rules that govern the interaction between systems. If there are any middleware restrictions, this should be registered.\n\nThe following topics should be considered for any type of interface:\n\n- Data transmitted and received;\n- Data type, format, intervals and meaning of the values;\n- Time;\n- Data transfer fees;\n- Communication protocols: initiation and order of execution;\n- Any data sharing, creation, duplication, use, storage or destruction;\n- Initiation and interruption mechanisms;\n- Communication through parameters, common data areas or messages;\n- Direct access to internal data;\n- Error handling, recovery and reporting;\n- Access and security.\n\n## 9.5.2.6 Non-Functional Attributes\n\nHow the system will meet non-functional requirements should be described. The following items should be addressed when appropriate:\n\n- Availability (reliability, redundancy, error checking, stand-by operation);\n- Maintenance (possibilities for expansion and improvement; extra capacity; probable changes in environment and service life).\n\n## 9.5.2.7 Environment", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas que pueden proporcionar respuestas espec\u00edficas basadas en el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos detalla aspectos cr\u00edticos relacionados con la gesti\u00f3n de datos, interfaces entre sistemas, atributos no funcionales y el entorno en el que operan estos sistemas. Se enfatiza la importancia de la protecci\u00f3n de interfaces, la definici\u00f3n de roles de usuario, y la consideraci\u00f3n de requisitos no funcionales como disponibilidad y mantenimiento.\n\n### Preguntas\n\n1. **\u00bfCu\u00e1les son los roles de usuario espec\u00edficos que deben definirse en las interfaces con los usuarios, y qu\u00e9 consideraciones deben tenerse en cuenta para cada uno?**\n   - Esta pregunta busca respuestas sobre los diferentes perfiles de acceso y las especificaciones que deben cumplirse para cada rol, lo que no se detalla en otros documentos.\n\n2. **\u00bfQu\u00e9 mecanismos de manejo de errores y recuperaci\u00f3n se deben implementar en las interfaces entre sistemas, y c\u00f3mo se deben documentar?**\n   - Esta pregunta se centra en los procedimientos espec\u00edficos para manejar errores y asegurar la continuidad del sistema, lo cual es crucial para la validaci\u00f3n y no se aborda de manera general en otros contextos.\n\n3. **\u00bfQu\u00e9 aspectos de mantenimiento y expansi\u00f3n se deben considerar al dise\u00f1ar un sistema inform\u00e1tico seg\u00fan las directrices de ANVISA?**\n   - Esta pregunta busca informaci\u00f3n sobre las expectativas de mantenimiento y la capacidad de adaptaci\u00f3n del sistema a cambios futuros, lo que es esencial para la planificaci\u00f3n a largo plazo y puede no estar claramente definido en otros documentos.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\nLa secci\u00f3n del documento \"Gu\u00eda de ANVISA para la Validaci\u00f3n de Sistemas Inform\u00e1ticos\" aborda varios aspectos fundamentales relacionados con la validaci\u00f3n de sistemas en el contexto de las Buenas Pr\u00e1cticas de Manufactura (GMP). A continuaci\u00f3n se resumen los temas clave y entidades mencionados:\n\n#### Temas Clave\n\n1. **Estado Contractual del Documento**: Se menciona la importancia de definir el estado contractual del documento y su relaci\u00f3n con otros documentos relevantes, como el ERU (Especificaci\u00f3n de Requisitos del Usuario) y el URS (Especificaci\u00f3n de Requisitos del Usuario).\n\n2. **Descripci\u00f3n General**:\n   - **Alcance y Objetivos**: Definici\u00f3n clara de lo que se pretende lograr con el sistema.\n   - **Regulaciones GMP**: Referencias a las normativas pertinentes que rigen la operaci\u00f3n del sistema.\n   - **Impacto en Seguridad y Calidad**: Evaluaci\u00f3n del impacto del sistema en la seguridad del paciente, la calidad del producto y la integridad de los datos.\n   - **Descripci\u00f3n de Componentes**: Desglose de los componentes principales del sistema y sus interfaces con otros sistemas y el entorno.\n   - **Suposiciones y Restricciones**: Identificaci\u00f3n de las suposiciones y limitaciones que pueden afectar el sistema.\n   - **No Conformidades**: Documentaci\u00f3n y justificaci\u00f3n de cualquier no conformidad respecto a los requisitos del usuario.\n\n3. **Funciones del Sistema**:\n   - **Prop\u00f3sito y Uso**: Detalle del prop\u00f3sito de cada funci\u00f3n y su interacci\u00f3n con otras partes del sistema.\n   - **Rendimiento**: Evaluaci\u00f3n cuantitativa de la respuesta, escalabilidad y procesamiento.\n   - **Seguridad y Protecci\u00f3n**: Medidas de seguridad ante fallos de software o hardware, incluyendo redundancia y recuperaci\u00f3n de datos.\n   - **Configurabilidad**: Identificaci\u00f3n de funciones configurables y sus l\u00edmites.\n   - **Trazabilidad**: Conexi\u00f3n de las funciones a los requisitos espec\u00edficos del ERU/URS.\n   - **Condiciones de Fallo**: Manejo de condiciones de fallo y diagn\u00f3sticos.\n\n4. **Datos**:\n   - **Definici\u00f3n Jer\u00e1rquica**: Los datos deben definirse de manera jer\u00e1rquica, destacando par\u00e1metros cr\u00edticos.\n   - **Acceso y Rango Permitido**: Establecimiento de acceso a los datos y rangos permitidos para valores de entrada y salida.\n   - **Campos Requeridos**: Identificaci\u00f3n de campos que son obligatorios.\n   - **Validaci\u00f3n de Datos**: Verificaci\u00f3n de la validez de los datos ingresados.\n\n#### Entidades\n\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil, responsable de regular y supervisar la salud p\u00fablica.\n- **GMP**: Buenas Pr\u00e1cticas de Manufactura, regulaciones que aseguran la calidad y seguridad en la producci\u00f3n.\n- **ERU/URS**: Documentos que especifican los requisitos del usuario para el sistema.\n\nEste resumen destaca la importancia de una documentaci\u00f3n clara y detallada en la validaci\u00f3n de sistemas inform\u00e1ticos, asegurando que se cumplan los est\u00e1ndares de calidad y seguridad en el \u00e1mbito de la salud.", "excerpt_keywords": "Keywords: validation, interfaces, data integrity, non-functional requirements, ANVISA"}}, "d049c578-fc0a-4eec-ba62-7eba5d500b10": {"node_ids": ["0d196aa7-c82a-4523-be73-ad088e908b69"], "metadata": {"page_label": "39", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 9.5.2.8 Glossary\n\nDefinitions of any little-known terms should be provided.\n\n# 9.5.2.9 Appendices\n\nWhere appropriate, for example, for small systems, appendices should be provided to define the specifications *hardware* and *software*.\n\n# 9.6 DOCUMENT CONTAINING THE CONFIGURATION AND DESIGN\n\n## 9.6.1 Introduction\n\nThis section discusses how to define the required configuration of the system components and the project system.\n\nDepending on the type of system (configurable or customized), the configuration and design specifications provide a detailed technical expansion of the functional specifications. Define the features and flexibility of the system, properties and specifications. The information generated forms the basis for subsequent configuration management activity.\n\nThere is no need to prepare separate documents to define the configuration and the project. An specification hierarchy may be necessary for larger and more complex systems, as for systems smaller ones or considered low-risk specifications can be combined.\n\n## 9.6.2 Overview\n\n### 9.6.2.1 Configuration\n\nFor configurable products, configuration specifications that make up the system must be prepared for that it meets the user's requirements. This includes defining all settings and parameters.\n\nThese configuration specifications are produced by the system supplier and reviewed and approved by regulated company.\n\nIt is possible to maintain this set of configuration specifications on systems that are managed robust configuration (detailed and complete *audit trails*). Such an approach must be well documented.\n\n## 9.6.2.2 Project (*Design*)\n\nFor customized applications, a document containing the *hardware* and software design must be prepared.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos establece directrices sobre c\u00f3mo definir la configuraci\u00f3n y el dise\u00f1o de los sistemas, tanto configurables como personalizados. Se enfatiza la importancia de las especificaciones de configuraci\u00f3n para cumplir con los requisitos del usuario y la necesidad de documentaci\u00f3n adecuada para la gesti\u00f3n de configuraciones. Adem\u00e1s, se menciona que no es necesario crear documentos separados para la configuraci\u00f3n y el proyecto, aunque en sistemas m\u00e1s complejos puede ser \u00fatil establecer una jerarqu\u00eda de especificaciones.\n\n### Preguntas\n\n1. **\u00bfQu\u00e9 tipo de documentaci\u00f3n se requiere para los sistemas configurables y personalizados seg\u00fan el documento de ANVISA?**\n   - El documento establece que para sistemas configurables se deben preparar especificaciones de configuraci\u00f3n que definan todos los ajustes y par\u00e1metros necesarios para cumplir con los requisitos del usuario. Para aplicaciones personalizadas, se debe preparar un documento que contenga el dise\u00f1o del hardware y del software.\n\n2. **\u00bfCu\u00e1l es la importancia de las especificaciones de configuraci\u00f3n en la gesti\u00f3n de sistemas inform\u00e1ticos?**\n   - Las especificaciones de configuraci\u00f3n son fundamentales porque proporcionan una expansi\u00f3n t\u00e9cnica detallada de las especificaciones funcionales, definiendo las caracter\u00edsticas y flexibilidad del sistema. Esta informaci\u00f3n es la base para las actividades posteriores de gesti\u00f3n de configuraciones.\n\n3. **\u00bfC\u00f3mo se debe manejar la documentaci\u00f3n de las especificaciones de configuraci\u00f3n en sistemas con gesti\u00f3n robusta de configuraciones?**\n   - En sistemas que cuentan con una gesti\u00f3n robusta de configuraciones, se debe mantener un conjunto de especificaciones de configuraci\u00f3n bien documentado, que incluya auditor\u00edas detalladas y completas. Esto asegura que todos los cambios y configuraciones sean rastreables y est\u00e9n debidamente aprobados.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos aborda varios aspectos fundamentales que son esenciales para garantizar la integridad y funcionalidad de los sistemas en un entorno regulado. A continuaci\u00f3n se presentan los temas clave y las entidades mencionadas en la secci\u00f3n:\n\n1. **Relaci\u00f3n de Datos**:\n   - Se enfatiza la importancia de definir c\u00f3mo se relacionan los datos dentro del sistema.\n\n2. **Capacidad de Almacenamiento de Datos**:\n   - Detalles sobre la capacidad de almacenamiento, el tiempo de retenci\u00f3n y el archivo de datos.\n\n3. **Integridad y Protecci\u00f3n de Datos**:\n   - Se requiere asegurar la integridad de los datos y su protecci\u00f3n contra accesos no autorizados.\n\n4. **Migraci\u00f3n de Datos**:\n   - Aspectos relacionados con la importaci\u00f3n y exportaci\u00f3n de datos.\n\n5. **Interfaces**:\n   - **Interfaces con Usuarios**: Definici\u00f3n de roles de acceso (operador, administrador, etc.) y consideraciones sobre la interacci\u00f3n del usuario, incluyendo tipos de perif\u00e9ricos y manejo de errores.\n   - **Interfaces con Equipos**: Conexiones con sensores y equipos de planta.\n   - **Interfaces con Otros Sistemas**: Naturaleza de la interacci\u00f3n, m\u00e9todos y reglas que rigen la comunicaci\u00f3n entre sistemas, incluyendo restricciones de middleware.\n\n6. **Atributos No Funcionales**:\n   - **Disponibilidad**: Fiabilidad, redundancia, verificaci\u00f3n de errores y operaci\u00f3n en espera.\n   - **Mantenimiento**: Posibilidades de expansi\u00f3n, mejora y adaptaci\u00f3n a cambios en el entorno.\n\n7. **Entorno**:\n   - Consideraciones sobre el entorno en el que operan los sistemas inform\u00e1ticos.\n\n### Entidades Clave\n- **Roles de Usuario**: Operador, administrador, gerente de sistema.\n- **Tipos de Interfaces**: Interfaces con usuarios, equipos y otros sistemas.\n- **Protocolos de Comunicaci\u00f3n**: M\u00e9todos de interacci\u00f3n y reglas de comunicaci\u00f3n.\n- **Mecanismos de Manejo de Errores**: Procedimientos para la recuperaci\u00f3n y manejo de errores.\n- **Requisitos No Funcionales**: Disponibilidad y mantenimiento del sistema.\n\nEste resumen destaca la importancia de una planificaci\u00f3n cuidadosa y la documentaci\u00f3n detallada en la validaci\u00f3n de sistemas inform\u00e1ticos, asegurando que se cumplan tanto los requisitos funcionales como los no funcionales.", "excerpt_keywords": "Keywords: validation, configuration, specifications, hardware, software"}}, "8634242a-1aa1-4dc4-b36c-aad86e2326a5": {"node_ids": ["04a50fa5-2627-4899-b511-ad46b2091cec"], "metadata": {"page_label": "40", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 9.6.3 General Considerations\n\nThe use of tables and diagrams to illustrate the Configuration and Design Specifications is highly recommended. Standardized tables can help ensure that all parameters and settings have been defined. Diagrams can help within the software project to clarify and explain the data flow, the logical control, data structures and interfaces. Diagrams in hardware design can help understand about architecture and connectivity.\n\nConfiguration and Design must cover both hardware and software aspects. Depending on the risk, size and complexity of the system these points can be covered by a simple specification or can demand a hierarchy of specifications covering hardware and software separately. Each specification must be referenced individually and be traceable to the associated high-level specification.\n\nAll specifications must be structured to support traceability throughout the entire life cycle from the individual application to the test associated with this requirement.\n\n# 9.6.4 Document Content\n\nThe sections described below are not intended to be prescriptive or exhaustive. The level of detail it depends on the risk, complexity and innovation of the system. They can be part of a simple document or of a document hierarchy.\n\n## 9.6.4.1 Introduction\n\nIt should contain the following items:\n\n- Ownership of the document containing the configuration and the project;\n- Who produced the document, under what authority and for what purpose;", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la Validaci\u00f3n de Sistemas Inform\u00e1ticos enfatiza la importancia de las especificaciones de configuraci\u00f3n y dise\u00f1o, tanto para hardware como para software. Se recomienda el uso de tablas y diagramas para ilustrar estos aspectos, asegurando que todos los par\u00e1metros est\u00e9n definidos y que la trazabilidad se mantenga a lo largo del ciclo de vida del sistema. Adem\u00e1s, se menciona que el contenido del documento debe adaptarse al riesgo, complejidad e innovaci\u00f3n del sistema, y se sugiere que la introducci\u00f3n del documento incluya detalles sobre la propiedad y la producci\u00f3n del mismo.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfQu\u00e9 elementos se deben incluir en la introducci\u00f3n del documento de configuraci\u00f3n y dise\u00f1o seg\u00fan la gu\u00eda de ANVISA?**\n   - La introducci\u00f3n debe contener la propiedad del documento, qui\u00e9n lo produjo, bajo qu\u00e9 autoridad y con qu\u00e9 prop\u00f3sito.\n\n2. **\u00bfC\u00f3mo se debe estructurar la documentaci\u00f3n para asegurar la trazabilidad a lo largo del ciclo de vida del sistema?**\n   - Todas las especificaciones deben estar estructuradas para soportar la trazabilidad desde la aplicaci\u00f3n individual hasta las pruebas asociadas con cada requisito.\n\n3. **\u00bfQu\u00e9 factores determinan el nivel de detalle que debe incluirse en las especificaciones de configuraci\u00f3n y dise\u00f1o?**\n   - El nivel de detalle depende del riesgo, la complejidad y la innovaci\u00f3n del sistema, pudiendo ser parte de un documento simple o de una jerarqu\u00eda de documentos.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Documentaci\u00f3n de Configuraci\u00f3n y Dise\u00f1o**:\n   - Se requiere documentaci\u00f3n espec\u00edfica para definir la configuraci\u00f3n y el dise\u00f1o de sistemas inform\u00e1ticos, tanto configurables como personalizados.\n\n2. **Especificaciones de Configuraci\u00f3n**:\n   - Para sistemas configurables, es esencial preparar especificaciones que definan todos los ajustes y par\u00e1metros necesarios para cumplir con los requisitos del usuario. Estas especificaciones son producidas por el proveedor del sistema y deben ser revisadas y aprobadas por la empresa regulada.\n\n3. **Gesti\u00f3n de Configuraciones**:\n   - La informaci\u00f3n generada a partir de las especificaciones de configuraci\u00f3n es fundamental para las actividades de gesti\u00f3n de configuraciones posteriores. En sistemas con gesti\u00f3n robusta de configuraciones, se debe mantener un conjunto bien documentado de especificaciones que incluya auditor\u00edas detalladas.\n\n4. **Dise\u00f1o de Aplicaciones Personalizadas**:\n   - Para aplicaciones personalizadas, es necesario preparar un documento que contenga el dise\u00f1o del hardware y del software.\n\n5. **Jerarqu\u00eda de Especificaciones**:\n   - En sistemas m\u00e1s grandes y complejos, puede ser \u00fatil establecer una jerarqu\u00eda de especificaciones, mientras que en sistemas m\u00e1s peque\u00f1os o de bajo riesgo, las especificaciones pueden combinarse.\n\n### Entidades Clave\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil, responsable de la regulaci\u00f3n de sistemas inform\u00e1ticos en el \u00e1mbito de la salud.\n- **Sistemas Configurables**: Productos que pueden ser ajustados seg\u00fan las necesidades del usuario.\n- **Sistemas Personalizados**: Aplicaciones dise\u00f1adas espec\u00edficamente para cumplir con requisitos particulares.\n- **Especificaciones de Configuraci\u00f3n**: Documentos que detallan los ajustes y par\u00e1metros de un sistema.\n- **Gesti\u00f3n de Configuraciones**: Proceso de mantener y controlar los cambios en los sistemas inform\u00e1ticos. \n\nEste resumen destaca la importancia de la documentaci\u00f3n y la gesti\u00f3n adecuada en la validaci\u00f3n de sistemas inform\u00e1ticos seg\u00fan las directrices de ANVISA.", "excerpt_keywords": "Keywords: ANVISA, Computer Systems Validation, Configuration Specifications, Document Traceability, Hardware and Software Design"}}, "f5116f2a-d1a9-4264-9ea9-400fa804bd27": {"node_ids": ["7f7fad55-48c4-4bba-9877-36a7b76d2480"], "metadata": {"page_label": "41", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 9.6.4.2 Overview\n\nThis section should briefly describe the configuration and/or design. Depending on the complexity of the system, this can cover the complete system, **hardware** and/or **software**. This section can be illustrated using diagrams.\n\n# 9.6.4.3 Configuration\n\nThe necessary configuration of the components must be provided, including, but not limited to:\n\n- Settings, or configuration parameters, needed;\n- Reason for configuration, with reference to the control specification;\n- Tools or methods that will be used to define the necessary configuration options;\n- Dependencies or impacts of/on other modules or systems;\n- Infrastructure items such as operating systems or layered software;\n- Settings security.\n\nFor small systems it may be possible to incorporate this information into the Specifications document Functional.\n\n# 9.6.4.4 Hardware Design\n\n## 9.6.4.4.1 The Computerized System\n\nThe general architecture of the necessary **hardware** must be defined. At a high level this can be illustrated by block diagram showing both the functions of the parties and their functional relationships. The following items should be covered, where appropriate:\n\n- **Main computer system** - Must describe the primary **hardware** components of the system main computer, such as central processing unit (CPU), memory, **bus** type; accuracy clock etc.;\n- **Storage** - Describe all proposed memory devices with their respective maximum storage capacities, such as **hard disk**; **CD writer**, tapes etc.;\n- **Peripherals** - Must describe the necessary peripheral devices, including any requirements specific to your installation;\n- **Interconnections/networks** - Must describe all **hardware** component interconnections and any connections with other equipment, devices and computer systems. This description may contain the following items: cable specifications; connector specifications; shielding requirements; networks or other external connections, etc.;\n- **Configuration**;\n- **Embedded systems** (inside the process equipment) - Must include the following elements: layout diagrams for detailing the control panel and internal and external arrangements; diagrams of\n\n----\n\n*Guide for Computer Systems Validation*\n*Guide n\u00b0 33/2020 - version 1, of 03/26/2020*", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas que pueden proporcionar respuestas espec\u00edficas basadas en el contexto proporcionado, as\u00ed como un resumen de nivel superior del contenido:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos establece directrices para describir la configuraci\u00f3n y dise\u00f1o de sistemas, tanto de hardware como de software. Se enfatiza la importancia de detallar la configuraci\u00f3n necesaria de los componentes, incluyendo par\u00e1metros, razones de configuraci\u00f3n, herramientas utilizadas, y la interconexi\u00f3n de hardware. Adem\u00e1s, se requiere una descripci\u00f3n de la arquitectura del hardware, que incluye el sistema inform\u00e1tico principal, dispositivos de almacenamiento, perif\u00e9ricos, interconexiones y sistemas embebidos.\n\n### Preguntas\n\n1. **\u00bfQu\u00e9 elementos espec\u00edficos deben incluirse en la descripci\u00f3n de la configuraci\u00f3n de un sistema inform\u00e1tico seg\u00fan la gu\u00eda de ANVISA?**\n   - La gu\u00eda menciona que se deben incluir configuraciones necesarias, par\u00e1metros, razones para la configuraci\u00f3n, herramientas utilizadas, dependencias con otros m\u00f3dulos, elementos de infraestructura y seguridad de la configuraci\u00f3n.\n\n2. **\u00bfC\u00f3mo se debe representar la arquitectura del hardware en la documentaci\u00f3n de validaci\u00f3n de sistemas inform\u00e1ticos?**\n   - La arquitectura del hardware debe ser representada a un alto nivel mediante un diagrama de bloques que muestre las funciones de las partes involucradas y sus relaciones funcionales.\n\n3. **\u00bfQu\u00e9 aspectos se deben considerar al describir los dispositivos de almacenamiento en un sistema inform\u00e1tico?**\n   - Se debe describir todos los dispositivos de memoria propuestos junto con sus capacidades m\u00e1ximas de almacenamiento, como discos duros, grabadoras de CD, cintas, etc. Adem\u00e1s, se deben considerar las especificaciones de los dispositivos perif\u00e9ricos y las interconexiones con otros equipos.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Uso de Tablas y Diagramas**: Se recomienda el uso de tablas estandarizadas y diagramas para ilustrar las Especificaciones de Configuraci\u00f3n y Dise\u00f1o, facilitando la definici\u00f3n de par\u00e1metros y la comprensi\u00f3n del flujo de datos, control l\u00f3gico, estructuras de datos e interfaces.\n\n2. **Cobertura de Hardware y Software**: Las especificaciones de configuraci\u00f3n y dise\u00f1o deben abarcar tanto aspectos de hardware como de software. La complejidad y el riesgo del sistema determinar\u00e1n si se requiere una especificaci\u00f3n simple o una jerarqu\u00eda de especificaciones.\n\n3. **Trazabilidad**: Todas las especificaciones deben estar estructuradas para garantizar la trazabilidad a lo largo del ciclo de vida del sistema, desde la aplicaci\u00f3n individual hasta las pruebas asociadas.\n\n4. **Contenido del Documento**: El contenido del documento no es prescriptivo ni exhaustivo; el nivel de detalle debe ajustarse al riesgo, complejidad e innovaci\u00f3n del sistema. La introducci\u00f3n del documento debe incluir informaci\u00f3n sobre la propiedad, producci\u00f3n y prop\u00f3sito del mismo.\n\n### Entidades Clave\n\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria en Brasil, responsable de la regulaci\u00f3n de sistemas inform\u00e1ticos en el \u00e1mbito de la salud.\n- **Especificaciones de Configuraci\u00f3n y Dise\u00f1o**: Documentos que detallan los par\u00e1metros y configuraciones de un sistema inform\u00e1tico.\n- **Hardware y Software**: Componentes que deben ser considerados en las especificaciones de configuraci\u00f3n y dise\u00f1o.\n- **Trazabilidad**: Proceso de seguimiento y verificaci\u00f3n de requisitos a lo largo del ciclo de vida del sistema. \n\nEste resumen destaca la importancia de la documentaci\u00f3n adecuada y la trazabilidad en la validaci\u00f3n de sistemas inform\u00e1ticos, as\u00ed como la necesidad de adaptar el contenido a las caracter\u00edsticas espec\u00edficas del sistema en cuesti\u00f3n.", "excerpt_keywords": "Keywords: ANVISA, Computer Systems Validation, hardware design, configuration, software specifications"}}, "0c6daacb-2fad-43c6-9b94-40496aec89da": {"node_ids": ["411fe2d7-de39-4de5-b410-8a60bcc09248"], "metadata": {"page_label": "42", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "location to indicate where sensors and other devices are installed on the equipment; diagrams of electrical wiring and piping / process drawings and instrumentation diagram (P&ID);\n- Reference to relevant standards / norms.\n\n## 9.6.4.4.2 Inputs and Outputs\n\nThe formats of the inputs and outputs should, when necessary, be specified. These may include the signs digital and / or analog.\n\nFor external equipment the following elements must be considered:\n\n- Accuracy;\n- Isolation;\n- Current and voltage range;\n- Types and number of interface cards;\n- Time.\n\n## 9.6.4.4.3 Environment\n\nThe operating environment for the hardware must be defined. The following topics should be considered:\n\n- Temperature;\n- Moisture;\n- External interference;\n- Physical security;\n- Shielding against radio frequency, electromagnetic and / or UV interference;\n- Protection against physical damage such as dust or vibration.\n\n## 9.6.4.4.4 Power Supply\n\nThe requirements for power supply for the configured hardware must be described. The following elements should be considered:\n\n- Filtration;\n- Loading;\n- Grounding;\n- Stability;\n- Uninterruptible power supplies (UPS);\n- Energy consumption and / or heat emission to calculate the required air conditioning capacity or heating, ventilation and air conditioning (HVAC) system.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "### Resumen del Contexto\n\nEl documento \"ANVISA - Guide for Computer Systems Validation 33/2020\" proporciona directrices sobre la validaci\u00f3n de sistemas inform\u00e1ticos en el contexto de la regulaci\u00f3n de la salud en Brasil. Se enfoca en aspectos t\u00e9cnicos relacionados con la instalaci\u00f3n y operaci\u00f3n de hardware, incluyendo la ubicaci\u00f3n de sensores, diagramas el\u00e9ctricos, especificaciones de entradas y salidas, condiciones ambientales, y requisitos de suministro el\u00e9ctrico. Se enfatiza la importancia de considerar la precisi\u00f3n, la seguridad f\u00edsica, la interferencia externa, y la estabilidad del suministro el\u00e9ctrico, entre otros factores.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfQu\u00e9 consideraciones espec\u00edficas se deben tener en cuenta al definir la precisi\u00f3n de los equipos externos en el contexto de la validaci\u00f3n de sistemas inform\u00e1ticos?**\n   - Esta pregunta busca detalles sobre c\u00f3mo se debe evaluar y documentar la precisi\u00f3n de los equipos, lo cual es crucial para garantizar la fiabilidad de los datos obtenidos.\n\n2. **\u00bfCu\u00e1les son las medidas recomendadas para proteger el hardware contra interferencias externas, y c\u00f3mo se pueden implementar en un entorno de validaci\u00f3n?**\n   - Esta pregunta se centra en las estrategias pr\u00e1cticas que se pueden aplicar para mitigar los efectos de interferencias externas, lo que es vital para mantener la integridad del sistema.\n\n3. **\u00bfQu\u00e9 criterios se deben considerar al seleccionar un sistema de alimentaci\u00f3n ininterrumpida (UPS) para un entorno regulado por ANVISA?**\n   - Esta pregunta busca informaci\u00f3n sobre los aspectos t\u00e9cnicos y normativos que deben guiar la elecci\u00f3n de un UPS, asegurando que cumpla con los requisitos de estabilidad y seguridad en un entorno regulado.\n\nEstas preguntas est\u00e1n dise\u00f1adas para obtener respuestas que son espec\u00edficas y relevantes para el contexto de la validaci\u00f3n de sistemas inform\u00e1ticos seg\u00fan las directrices de ANVISA, y que probablemente no se encuentren en otras fuentes.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Configuraci\u00f3n y Dise\u00f1o del Sistema**:\n   - Se requiere una descripci\u00f3n breve de la configuraci\u00f3n y/o dise\u00f1o del sistema, abarcando tanto hardware como software, dependiendo de la complejidad del sistema.\n\n2. **Configuraci\u00f3n de Componentes**:\n   - Detalles necesarios sobre la configuraci\u00f3n de los componentes, que incluyen:\n     - Par\u00e1metros de configuraci\u00f3n.\n     - Razones para la configuraci\u00f3n, referenciando especificaciones de control.\n     - Herramientas o m\u00e9todos para definir opciones de configuraci\u00f3n.\n     - Dependencias o impactos en otros m\u00f3dulos o sistemas.\n     - Elementos de infraestructura como sistemas operativos.\n     - Seguridad de la configuraci\u00f3n.\n\n3. **Dise\u00f1o de Hardware**:\n   - Se debe definir la arquitectura general del hardware, que puede ser ilustrada mediante un diagrama de bloques. Los elementos a considerar incluyen:\n     - **Sistema inform\u00e1tico principal**: Componentes de hardware como CPU, memoria, tipo de bus, etc.\n     - **Almacenamiento**: Dispositivos de memoria propuestos y sus capacidades m\u00e1ximas.\n     - **Perif\u00e9ricos**: Dispositivos perif\u00e9ricos necesarios y requisitos espec\u00edficos.\n     - **Interconexiones/redes**: Descripci\u00f3n de interconexiones de hardware y conexiones con otros equipos, incluyendo especificaciones de cables y conectores.\n     - **Sistemas embebidos**: Elementos como diagramas de disposici\u00f3n del panel de control y arreglos internos y externos.\n\n### Entidades Clave\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil.\n- **Hardware**: Componentes f\u00edsicos del sistema inform\u00e1tico.\n- **Software**: Programas y aplicaciones que operan en el sistema.\n- **Diagrama de Bloques**: Herramienta visual para representar la arquitectura del hardware.\n- **Par\u00e1metros de Configuraci\u00f3n**: Ajustes necesarios para el funcionamiento del sistema.\n- **Dispositivos de Almacenamiento**: Incluyen discos duros, grabadoras de CD, cintas, etc.\n- **Perif\u00e9ricos**: Dispositivos externos conectados al sistema inform\u00e1tico.\n\nEste resumen proporciona una visi\u00f3n general de los aspectos fundamentales que deben considerarse al documentar la validaci\u00f3n de sistemas inform\u00e1ticos seg\u00fan la gu\u00eda de ANVISA.", "excerpt_keywords": "Keywords: ANVISA, computer systems validation, hardware requirements, environmental conditions, power supply specifications"}}, "172fc6d8-cd1a-4723-ad44-b082b5837f92": {"node_ids": ["0fe90363-d79f-44b6-bf0d-46b9efaa7794"], "metadata": {"page_label": "43", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 9.6.4.5 Software Design\n\nThe software must be designed according to recognized standards for software development, when appropriate.\n\nSoftware design specifications are required for customized applications. These specifications do not are required for configurable systems, as in this case the software project is reviewed or evaluated as part of the computer system supplier's assessment.\n\n## 9.6.4.5.1 Description of the Software\n\nThe modules that will form the computerized system must be described, declaring the purpose of each module. A list detailing all the interfaces between the modules and any interfaces with external systems must be presented. A system diagram is recommended.\n\n## 9.6.4.5.2 System Data\n\nThe system data and the relevant data objects must be defined. The data must be characterized in a hierarchical way, with complex objects being built from simpler objects.\n\nObjects can include the following items:\n\n- Databases and file collections;\n- Files;\n- Records.\n\nA description of the data objects includes, but is not limited to:\n\n- Data types (integers, floating point numbers, characters, Booleans, string (string), objects (images and documents), etc.);\n- Data format (alphanumeric or numeric, field length, dates, etc.);\n- Data accuracy;\n- Data accuracy.\n\nEach file and data structure must be uniquely identified. The use of methods of describing data formats such as \u201cEntity Relationship Model\u201d or similar can be considered.\n\nIt is acceptable for system data to be defined separately as in a dictionary. If this is done therefore, this approach must be clearly explained and documented.\n\n## 9.6.4.5.3 Module Description\n\nFor each module, the following points must be covered:\n\n- Module operation: the description can take the form of a pseudocode or flow chart;\n- Interfaces with other modules: this point can refer to the system diagram, if there is one;", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos establece directrices para el dise\u00f1o de software, enfatizando la necesidad de especificaciones de dise\u00f1o para aplicaciones personalizadas y la descripci\u00f3n detallada de m\u00f3dulos y datos del sistema. Se requiere que cada m\u00f3dulo del sistema est\u00e9 claramente definido, incluyendo su operaci\u00f3n y las interfaces con otros m\u00f3dulos. Adem\u00e1s, se sugiere la utilizaci\u00f3n de diagramas de sistema y modelos de relaci\u00f3n de entidades para describir la estructura de datos.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfQu\u00e9 tipo de especificaciones de dise\u00f1o se requieren para las aplicaciones personalizadas seg\u00fan el documento de ANVISA?**\n   - Las aplicaciones personalizadas requieren especificaciones de dise\u00f1o de software, mientras que para los sistemas configurables no son necesarias, ya que el proyecto de software se eval\u00faa como parte de la evaluaci\u00f3n del proveedor del sistema inform\u00e1tico.\n\n2. **\u00bfC\u00f3mo deben ser descritos los datos del sistema y qu\u00e9 elementos deben incluirse en esta descripci\u00f3n?**\n   - Los datos del sistema deben definirse de manera jer\u00e1rquica, caracterizando objetos complejos construidos a partir de objetos m\u00e1s simples. La descripci\u00f3n debe incluir tipos de datos, formatos de datos, precisi\u00f3n de datos y debe asegurarse que cada archivo y estructura de datos est\u00e9 identificado de manera \u00fanica.\n\n3. **\u00bfQu\u00e9 informaci\u00f3n se debe proporcionar para cada m\u00f3dulo del sistema seg\u00fan las directrices de ANVISA?**\n   - Para cada m\u00f3dulo, se debe cubrir la operaci\u00f3n del m\u00f3dulo (que puede describirse en forma de pseudoc\u00f3digo o diagrama de flujo) y las interfaces con otros m\u00f3dulos, haciendo referencia al diagrama del sistema si existe.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\nEl documento \"ANVISA - Guide for Computer Systems Validation 33/2020\" aborda aspectos fundamentales para la validaci\u00f3n de sistemas inform\u00e1ticos en el \u00e1mbito de la salud en Brasil. A continuaci\u00f3n se resumen los temas clave de la secci\u00f3n:\n\n1. **Instalaci\u00f3n de Equipos**:\n   - Importancia de indicar la ubicaci\u00f3n de sensores y dispositivos en el equipo.\n   - Inclusi\u00f3n de diagramas el\u00e9ctricos y de procesos (P&ID).\n\n2. **Entradas y Salidas (Inputs and Outputs)**:\n   - Especificaci\u00f3n de formatos de entradas y salidas, tanto digitales como anal\u00f3gicas.\n   - Consideraciones para equipos externos: precisi\u00f3n, aislamiento, rango de corriente y voltaje, tipos y n\u00famero de tarjetas de interfaz, y tiempo.\n\n3. **Entorno Operativo**:\n   - Definici\u00f3n del entorno de operaci\u00f3n del hardware, considerando:\n     - Temperatura y humedad.\n     - Interferencias externas.\n     - Seguridad f\u00edsica.\n     - Apantallamiento contra interferencias de radiofrecuencia, electromagn\u00e9ticas y UV.\n     - Protecci\u00f3n contra da\u00f1os f\u00edsicos (polvo, vibraciones).\n\n4. **Suministro El\u00e9ctrico**:\n   - Descripci\u00f3n de los requisitos de suministro el\u00e9ctrico para el hardware configurado, incluyendo:\n     - Filtraci\u00f3n.\n     - Carga.\n     - Puesta a tierra.\n     - Estabilidad.\n     - Sistemas de alimentaci\u00f3n ininterrumpida (UPS).\n     - Consumo de energ\u00eda y emisi\u00f3n de calor para calcular la capacidad necesaria del sistema de climatizaci\u00f3n (HVAC).\n\n### Entidades Clave\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil.\n- **Hardware**: Equipos f\u00edsicos utilizados en sistemas inform\u00e1ticos.\n- **Sensores y Dispositivos**: Elementos que recopilan datos y se integran en el sistema.\n- **Diagramas El\u00e9ctricos y P&ID**: Representaciones gr\u00e1ficas de la instalaci\u00f3n y funcionamiento de los sistemas.\n- **UPS (Sistemas de Alimentaci\u00f3n Ininterrumpida)**: Equipos que proporcionan energ\u00eda continua ante cortes de suministro.\n\nEste resumen destaca la importancia de considerar m\u00faltiples factores t\u00e9cnicos y normativos para garantizar la validaci\u00f3n efectiva de sistemas inform\u00e1ticos en entornos regulados.", "excerpt_keywords": "Keywords: software design, system validation, data objects, module description, ANVISA"}}, "2be94c47-30fd-4311-937b-2227a8d6e06f": {"node_ids": ["f56798e3-7d61-4ed0-8ec4-5c050fd9f440"], "metadata": {"page_label": "44", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "- Error handling and data verification;\n- Data mapping for each module;\n- Software module data.\n\nFor each subprogram of the software module, the following points must be covered:\n\n- Subprogram operation: the description can take the form of a pseudocode;\n- The steps involved in each process to be performed and the inputs and outputs of each step;\n- Parameters: each parameter must be identified as one of the examples below:\n- \u2713 Input parameter;\n- \u2713 Output parameter;\n- \u2713 Input and output parameters.\n- Algorithms;\n- It must be identified how each parameter passes the test, either by value or by reference;\n- Any side effects of the subprogram;\n- Language type, including the \u201ccore\u201d and platform version;\n- Reference to any programming standards;\n- Description or examples of all display screens;\n- Subprogram data.\n- Description or examples of all reports implemented, their meaning and manipulation and when were generated.\n\nThe level of detail can be provided in separate specifications.\n\n### 9.6.4.6 Glossary\n\nDefinitions of any little-known terms should be provided.\n\n### 9.7 TESTING PLAN FOR COMPUTERIZED SYSTEMS\n\n#### 9.7.1 Introduction\n\nThe performance of tests in the system meets the following objectives:\n\n- Identification of defects that can be corrected or removed before use;\n- Failure prevention that can affect patient safety, product quality or integrity of the data;\n- Provision of documented evidence that the system performs its functions as specified;\n- Demonstration that the system meets the intended requirements;\n- Providing confidence that the system is suitable for its intended use;\n- Provision of the basis for user acceptance;\n- Meeting a key regulatory requirement, where appropriate.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas que pueden proporcionar respuestas espec\u00edficas basadas en el contexto proporcionado:\n\n1. **\u00bfCu\u00e1les son los pasos espec\u00edficos que deben seguirse para documentar el funcionamiento de un subprograma en el contexto de la validaci\u00f3n de sistemas inform\u00e1ticos seg\u00fan la gu\u00eda de ANVISA?**\n   - Esta pregunta se centra en los detalles del proceso de documentaci\u00f3n de subprogramas, que incluye la descripci\u00f3n en pseudoc\u00f3digo, los pasos del proceso, y la identificaci\u00f3n de par\u00e1metros, lo cual es fundamental para la validaci\u00f3n.\n\n2. **\u00bfQu\u00e9 objetivos espec\u00edficos se buscan alcanzar al realizar pruebas en sistemas inform\u00e1ticos seg\u00fan la gu\u00eda de ANVISA, y c\u00f3mo se relacionan con la seguridad del paciente y la calidad del producto?**\n   - Esta pregunta aborda los objetivos de las pruebas en sistemas inform\u00e1ticos, destacando su importancia en la prevenci\u00f3n de fallos que puedan afectar la seguridad del paciente y la integridad de los datos.\n\n3. **\u00bfQu\u00e9 tipo de informaci\u00f3n se debe incluir en la secci\u00f3n de \"glosario\" de la documentaci\u00f3n de validaci\u00f3n de sistemas inform\u00e1ticos, y por qu\u00e9 es importante?**\n   - Esta pregunta se enfoca en la necesidad de definir t\u00e9rminos poco conocidos, lo que es crucial para asegurar que todos los involucrados en el proceso de validaci\u00f3n comprendan claramente la documentaci\u00f3n.\n\n### Resumen de nivel superior del contexto circundante:\nLa gu\u00eda de ANVISA para la validaci\u00f3n de sistemas inform\u00e1ticos establece directrices claras sobre c\u00f3mo documentar y probar software en entornos regulados. Se enfatiza la importancia de la identificaci\u00f3n y manejo de errores, la verificaci\u00f3n de datos, y la documentaci\u00f3n detallada de subprogramas, incluyendo su funcionamiento, par\u00e1metros y efectos secundarios. Adem\u00e1s, se destacan los objetivos de las pruebas, que incluyen la identificaci\u00f3n de defectos y la garant\u00eda de que el sistema cumple con los requisitos establecidos, lo que es esencial para la seguridad del paciente y la calidad del producto.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\nLa secci\u00f3n 9.6.4.5 del documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos se centra en el dise\u00f1o de software, estableciendo directrices espec\u00edficas para asegurar que el software se desarrolle de acuerdo con est\u00e1ndares reconocidos. A continuaci\u00f3n se presentan los temas clave y entidades mencionadas:\n\n1. **Especificaciones de Dise\u00f1o de Software**:\n   - **Aplicaciones Personalizadas**: Se requieren especificaciones de dise\u00f1o detalladas.\n   - **Sistemas Configurables**: No se requieren especificaciones, ya que el proyecto se eval\u00faa como parte de la evaluaci\u00f3n del proveedor.\n\n2. **Descripci\u00f3n del Software**:\n   - **M\u00f3dulos del Sistema**: Cada m\u00f3dulo debe ser descrito con su prop\u00f3sito y las interfaces entre ellos, as\u00ed como con sistemas externos. Se recomienda incluir un diagrama del sistema.\n\n3. **Datos del Sistema**:\n   - **Definici\u00f3n de Datos**: Los datos deben caracterizarse de manera jer\u00e1rquica, con objetos complejos derivados de objetos m\u00e1s simples.\n   - **Elementos de Datos**: Incluyen bases de datos, archivos y registros.\n   - **Descripci\u00f3n de Objetos de Datos**: Debe incluir tipos de datos, formatos, precisi\u00f3n y una identificaci\u00f3n \u00fanica para cada archivo y estructura de datos. Se sugiere el uso de modelos como el \"Modelo de Relaci\u00f3n de Entidades\".\n\n4. **Descripci\u00f3n de M\u00f3dulos**:\n   - **Operaci\u00f3n del M\u00f3dulo**: Puede describirse mediante pseudoc\u00f3digo o diagramas de flujo.\n   - **Interfaces con Otros M\u00f3dulos**: Se debe hacer referencia a los diagramas del sistema si est\u00e1n disponibles.\n\n### Entidades Clave\n- **Software**: Aplicaciones personalizadas y sistemas configurables.\n- **M\u00f3dulos**: Componentes del sistema que deben ser descritos y documentados.\n- **Datos**: Objetos de datos que deben ser definidos y caracterizados.\n- **Interfaces**: Conexiones entre m\u00f3dulos y sistemas externos.\n- **Diagramas**: Representaciones visuales recomendadas para la descripci\u00f3n del sistema y sus m\u00f3dulos.\n\nEste resumen proporciona una visi\u00f3n general de los requisitos y directrices para el dise\u00f1o de software en el contexto de la validaci\u00f3n de sistemas inform\u00e1ticos seg\u00fan ANVISA.", "excerpt_keywords": "Keywords: validation, software documentation, testing plan, parameters, regulatory compliance"}}, "6985d1eb-6ef0-41dc-91a0-a1b91c1be8cf": {"node_ids": ["e67d1aa3-cf60-4b55-83f7-2a71e02dc2dc"], "metadata": {"page_label": "45", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 9.7.2 Roles and Responsibilities\n\nThe regulated company must define the roles and responsibilities related to the performance of tests in the system.\n\nThese roles and responsibilities may include:\n\n- User - responsible for the system in question and for the approval of test documents;\n- Subject Specialist (SME) - can act as a test manager, executor, reviewer or authorizer;\n\n----\n\n- Test manager - test planning and test plan writing;\n- Test Analyst - responsible for developing test cases and test scripts;\n- Test runner - this role should be as independent as possible. You must not be the author of the software or test scripts, if possible;\n- Test reviewer - responsible for reviewing test cases, test scripts and test results tests - it should not be the same person who performed the tests;\n- Quality Unit - role defined by the GMP;\n- Supplier - can act as a test planner, performer, reviewer or authorizer for some of the tests.\n\n# 9.7.3 Testing Strategies\n\n## 9.7.3.1 Introduction\n\nThe testing strategy, also known as the test plan, should define an appropriate approach to the testing on a specific computerized system.\n\nThe testing strategy is based on the following points:\n\n- Results of risk assessments;\n- An understanding of the system components (GAMP categories), the complexity and innovation of the system;\n- Results of supplier evaluations, if applicable.\n\nThe testing strategy varies according to the category of the system, ranging from a simple system of the category 3 to a complex category 5 system. The testing strategy must be reviewed and approved by the Specialist on the subject.\n\nThe testing strategy should define:\n\n- What kind of tests are needed;\n- The number and purpose of the test specifications;\n- The use of the supplier's existing documentation according to the assessment carried out in the provider;\n- The testing phases:\n- \u2713 Location and duration of each test phase;\n- \u2713 Resources required for each testing phase;\n- \u2713 Responsibilities for each testing phase.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos establece directrices sobre las roles y responsabilidades en la realizaci\u00f3n de pruebas de sistemas regulados. Se enfatiza la importancia de definir claramente qui\u00e9n es responsable de cada aspecto del proceso de prueba, desde la planificaci\u00f3n hasta la ejecuci\u00f3n y revisi\u00f3n. Adem\u00e1s, se describe la estrategia de pruebas, que debe basarse en evaluaciones de riesgo y en la comprensi\u00f3n de los componentes del sistema, y debe ser revisada y aprobada por un especialista en la materia.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfCu\u00e1les son las responsabilidades espec\u00edficas del \"Test runner\" seg\u00fan el documento de ANVISA?**\n   - El \"Test runner\" debe ser lo m\u00e1s independiente posible y no debe ser el autor del software o de los scripts de prueba, si es posible.\n\n2. **\u00bfQu\u00e9 factores se deben considerar al definir la estrategia de pruebas para un sistema inform\u00e1tico?**\n   - La estrategia de pruebas debe basarse en los resultados de las evaluaciones de riesgo, la comprensi\u00f3n de los componentes del sistema (categor\u00edas GAMP), la complejidad e innovaci\u00f3n del sistema, y los resultados de las evaluaciones de proveedores, si corresponde.\n\n3. **\u00bfQu\u00e9 rol desempe\u00f1a el \"Subject Specialist (SME)\" en el proceso de pruebas seg\u00fan el documento?**\n   - El \"Subject Specialist (SME)\" puede actuar como gerente de pruebas, ejecutor, revisor o autorizador, lo que implica que tiene un papel clave en la supervisi\u00f3n y validaci\u00f3n del proceso de pruebas.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Manejo de Errores y Verificaci\u00f3n de Datos**: Se enfatiza la importancia de implementar mecanismos para manejar errores y verificar la integridad de los datos en los sistemas inform\u00e1ticos.\n\n2. **Documentaci\u00f3n de Subprogramas**: \n   - **Descripci\u00f3n del Funcionamiento**: Se requiere que cada subprograma sea documentado, preferiblemente en forma de pseudoc\u00f3digo.\n   - **Pasos del Proceso**: Detallar los pasos involucrados, as\u00ed como los inputs y outputs de cada uno.\n   - **Identificaci\u00f3n de Par\u00e1metros**: Los par\u00e1metros deben clasificarse como de entrada, salida, o ambos.\n   - **Algoritmos y Efectos Secundarios**: Se debe identificar c\u00f3mo se pasan los par\u00e1metros (por valor o referencia) y cualquier efecto secundario del subprograma.\n   - **Lenguaje y Est\u00e1ndares de Programaci\u00f3n**: Especificar el tipo de lenguaje utilizado y cualquier est\u00e1ndar de programaci\u00f3n relevante.\n   - **Pantallas y Reportes**: Incluir descripciones o ejemplos de las pantallas de visualizaci\u00f3n y los reportes generados por el sistema.\n\n3. **Glosario**: Se debe incluir un glosario que defina t\u00e9rminos poco conocidos para asegurar la comprensi\u00f3n de la documentaci\u00f3n por parte de todos los involucrados.\n\n4. **Plan de Pruebas para Sistemas Inform\u00e1ticos**:\n   - **Objetivos de las Pruebas**: \n     - Identificaci\u00f3n de defectos antes de la implementaci\u00f3n.\n     - Prevenci\u00f3n de fallos que puedan comprometer la seguridad del paciente o la calidad del producto.\n     - Provisi\u00f3n de evidencia documentada de que el sistema cumple con sus funciones especificadas.\n     - Demostraci\u00f3n de que el sistema satisface los requisitos previstos.\n     - Generaci\u00f3n de confianza en la idoneidad del sistema para su uso previsto.\n     - Base para la aceptaci\u00f3n del usuario.\n     - Cumplimiento de requisitos regulatorios clave.\n\n### Entidades Clave\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil, responsable de la regulaci\u00f3n de sistemas inform\u00e1ticos en el \u00e1mbito de la salud.\n- **Subprogramas**: Componentes del software que deben ser documentados y validados.\n- **Par\u00e1metros**: Elementos que se utilizan en los subprogramas, clasificados como de entrada, salida o ambos.\n- **Pruebas**: Actividades realizadas para asegurar la calidad y funcionalidad del sistema inform\u00e1tico.\n\nEste resumen destaca la importancia de la documentaci\u00f3n y las pruebas en la validaci\u00f3n de sistemas inform\u00e1ticos, as\u00ed como la necesidad de claridad en la terminolog\u00eda utilizada.", "excerpt_keywords": "Keywords: validation, testing strategy, roles and responsibilities, risk assessment, computerized systems"}}, "c8573085-049f-4f3c-8628-6902ca8dc188": {"node_ids": ["7b4a6013-aee5-4027-aacd-ed113f9dc1df"], "metadata": {"page_label": "46", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "- The approach used to provide evidence of testing (eg, impressions);\n- Procedures for managing test failures;\n- Test documentation format;\n- The use of test metrics;\n- Use of visual testimony of the tests.\n\n## 9.7.3.2 Test Documentation\n\nFigure 5 below shows a typical structure for testing documentation.\n\n----\n\n**Figure 5. Typical structure for testing documentation.**\nSource: GAMP5\n\nThe use of *templates* to carry out test documentation, such as test specifications, records test results and test reports, helps with consistency, facilitates review and avoids errors in documents.\n\nIn this section, each type of document presented in figure 5 is described.\n\n### 9.7.3.2.1 Testing Strategy\n\nDescribed in item 9.7.3.1.\n\n### 9.7.3.2.2 Test Specifications\n\nThey are a set of test scripts that are suitable for a specific purpose for a specific phase of a project.\n\nThe test specifications should cover the following points, where applicable:", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos establece directrices sobre la documentaci\u00f3n de pruebas en proyectos. Se enfatiza la importancia de utilizar plantillas para asegurar la consistencia y evitar errores. Se describen varios tipos de documentos necesarios para la documentaci\u00f3n de pruebas, incluyendo la estrategia de pruebas y las especificaciones de pruebas, que deben abordar aspectos clave como la evidencia de pruebas, la gesti\u00f3n de fallos y el uso de m\u00e9tricas.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfCu\u00e1l es la importancia de utilizar plantillas en la documentaci\u00f3n de pruebas seg\u00fan el documento de ANVISA?**\n   - Respuesta: El uso de plantillas en la documentaci\u00f3n de pruebas ayuda a garantizar la consistencia, facilita la revisi\u00f3n y evita errores en los documentos.\n\n2. **\u00bfQu\u00e9 aspectos deben cubrir las especificaciones de pruebas seg\u00fan el contexto proporcionado?**\n   - Respuesta: Las especificaciones de pruebas deben cubrir un conjunto de puntos relevantes para un prop\u00f3sito espec\u00edfico en una fase del proyecto, aunque el contexto no detalla cu\u00e1les son esos puntos espec\u00edficos.\n\n3. **\u00bfQu\u00e9 se menciona sobre la gesti\u00f3n de fallos en las pruebas dentro del documento?**\n   - Respuesta: Se menciona que deben existir procedimientos para gestionar las fallas en las pruebas, aunque el contexto no proporciona detalles espec\u00edficos sobre esos procedimientos.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n#### Temas Clave\n1. **Roles y Responsabilidades**: Se establece la necesidad de definir claramente los roles y responsabilidades en el proceso de pruebas de sistemas regulados. Esto incluye diversas funciones como:\n   - **Usuario**: Responsable del sistema y aprobaci\u00f3n de documentos de prueba.\n   - **Especialista en la materia (SME)**: Puede actuar como gerente, ejecutor, revisor o autorizador de pruebas.\n   - **Gerente de Pruebas**: Encargado de la planificaci\u00f3n y redacci\u00f3n del plan de pruebas.\n   - **Analista de Pruebas**: Desarrolla casos y scripts de prueba.\n   - **Ejecutor de Pruebas (Test Runner)**: Debe ser independiente y no autor de software o scripts de prueba.\n   - **Revisor de Pruebas**: Revisa casos, scripts y resultados de pruebas, sin ser la misma persona que realiz\u00f3 las pruebas.\n   - **Unidad de Calidad**: Rol definido por las Buenas Pr\u00e1cticas de Manufactura (GMP).\n   - **Proveedor**: Puede actuar en varias capacidades en el proceso de pruebas.\n\n2. **Estrategias de Pruebas**: La estrategia de pruebas debe ser un enfoque adecuado para el sistema inform\u00e1tico espec\u00edfico y debe basarse en:\n   - Resultados de evaluaciones de riesgo.\n   - Comprensi\u00f3n de los componentes del sistema (categor\u00edas GAMP).\n   - Complejidad e innovaci\u00f3n del sistema.\n   - Resultados de evaluaciones de proveedores, si aplica.\n\n3. **Revisi\u00f3n y Aprobaci\u00f3n**: La estrategia de pruebas debe ser revisada y aprobada por un especialista en la materia.\n\n4. **Definici\u00f3n de la Estrategia de Pruebas**: Debe incluir:\n   - Tipos de pruebas necesarias.\n   - N\u00famero y prop\u00f3sito de las especificaciones de prueba.\n   - Uso de la documentaci\u00f3n existente del proveedor.\n   - Fases de prueba, incluyendo ubicaci\u00f3n, duraci\u00f3n, recursos y responsabilidades.\n\n#### Entidades\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil.\n- **GAMP**: Buenas Pr\u00e1cticas de Manufactura (Good Automated Manufacturing Practice).\n- **Roles**: Usuario, SME, Gerente de Pruebas, Analista de Pruebas, Ejecutor de Pruebas, Revisor de Pruebas, Unidad de Calidad, Proveedor.\n- **Documentaci\u00f3n**: Plan de pruebas, casos de prueba, scripts de prueba, resultados de pruebas.\n\nEste resumen destaca la importancia de la claridad en roles y responsabilidades, as\u00ed como la necesidad de una estrategia de pruebas bien definida y revisada para asegurar la validaci\u00f3n efectiva de sistemas inform\u00e1ticos regulados.", "excerpt_keywords": "Keywords: ANVISA, Computer Systems Validation, Test Documentation, Testing Strategy, GAMP"}}, "b603c7f1-0d4d-490a-8ef6-6fd3e8e3b8fb": {"node_ids": ["f14eb3ea-a08c-4175-9c15-09bbd1610b5d"], "metadata": {"page_label": "47", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# Guide for Computer Systems Validation\n\n- Introduction;\n- Who produced the document, under what authority and for what purpose;\n- The contractual status of the defined document;\n- Relationship to other documents;\n- Scope - must state where the test specification fits into the overall testing strategy;\n- The test scripts / cases to be executed;\n- Software version or configuration under test;\n- Purpose;\n- Resources;\n- Personnel required to carry out each test or group of tests;\n- Methods used;\n- Any grouping or logical ordering of the tests;\n- Prerequisites;\n- Environment;\n- Tools, including automated testing tools;\n- Reference to specifications;\n- Necessary documentation;\n- Necessary reviews and approvals.\n\n## 9.7.3.2.3 Test Cases / Itineraries\n\nThe test cases / roadmaps must contain the details of the tests. The test script should be described in detail enough to allow consistent repeat testing.\n\nEach test script should, where possible, include the following points:\n- Unique test reference;\n- Cross reference to control the specification;\n- Test title;\n- Description of the test, including the purpose of the test;\n- Test steps - a step-by-step description of the actions to be taken by the performers, together with the expected results;\n- Acceptance criteria - Expected result(s) that must be met in order for the parameter specific challenge is considered pass or has passed the test;\n- Pre-test steps - including any test or preparation prerequisites;\n- Data to be recorded - description of the data to be collected and recorded;\n- Post-test actions - optional section that details the actions required to return the system to the state original.\n\n## 9.7.3.2.4 Test Results\n\nThe test results must be available for subsequent review and inspection. The information to be retained should include tests that have passed, those that have failed, records of test failures, test reports and", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento \"Gu\u00eda para la Validaci\u00f3n de Sistemas Inform\u00e1ticos\" de ANVISA establece directrices sobre c\u00f3mo llevar a cabo pruebas de validaci\u00f3n de sistemas inform\u00e1ticos en el \u00e1mbito regulatorio. Incluye secciones sobre la introducci\u00f3n, la producci\u00f3n del documento, su relaci\u00f3n con otros documentos, el alcance de las pruebas, los scripts de prueba, los resultados de las pruebas y los requisitos necesarios para llevar a cabo estas pruebas de manera efectiva. Se enfatiza la importancia de documentar cada paso del proceso de prueba, as\u00ed como los resultados obtenidos.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfQu\u00e9 elementos deben incluirse en un script de prueba seg\u00fan la gu\u00eda de ANVISA?**\n   - La gu\u00eda especifica que un script de prueba debe incluir un identificador \u00fanico, referencia cruzada a la especificaci\u00f3n de control, t\u00edtulo de la prueba, descripci\u00f3n del prop\u00f3sito de la prueba, pasos de prueba detallados, criterios de aceptaci\u00f3n, pasos previos a la prueba, datos a registrar y acciones posteriores a la prueba.\n\n2. **\u00bfCu\u00e1l es la importancia de los resultados de las pruebas y qu\u00e9 informaci\u00f3n debe ser retenida seg\u00fan el documento?**\n   - Los resultados de las pruebas son cruciales para la revisi\u00f3n y la inspecci\u00f3n posterior. La informaci\u00f3n que debe ser retenida incluye los tests que han pasado, aquellos que han fallado, registros de fallos de prueba y los informes de prueba.\n\n3. **\u00bfQu\u00e9 aspectos se deben considerar al definir el alcance de las pruebas en el contexto de la validaci\u00f3n de sistemas inform\u00e1ticos?**\n   - El alcance debe indicar c\u00f3mo la especificaci\u00f3n de prueba se integra en la estrategia general de pruebas, asegurando que se aborden todos los aspectos relevantes del sistema y que se cumplan los requisitos regulatorios establecidos.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos aborda varios aspectos fundamentales relacionados con la documentaci\u00f3n de pruebas en proyectos. A continuaci\u00f3n se presentan los temas clave y las entidades mencionadas en la secci\u00f3n:\n\n#### Temas Clave:\n1. **Evidencia de Pruebas**: Se discute la importancia de proporcionar evidencia de las pruebas realizadas, incluyendo enfoques como impresiones.\n2. **Gesti\u00f3n de Fallos**: Se establecen procedimientos necesarios para manejar las fallas que puedan surgir durante las pruebas.\n3. **Formato de Documentaci\u00f3n de Pruebas**: Se enfatiza la necesidad de un formato estandarizado para la documentaci\u00f3n de pruebas.\n4. **M\u00e9tricas de Pruebas**: Se menciona el uso de m\u00e9tricas para evaluar y reportar los resultados de las pruebas.\n5. **Testimonios Visuales**: Se sugiere el uso de testimonios visuales como parte de la documentaci\u00f3n de pruebas.\n6. **Plantillas para Documentaci\u00f3n**: Se destaca la importancia de utilizar plantillas para asegurar la consistencia y evitar errores en la documentaci\u00f3n de pruebas.\n\n#### Entidades:\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil, responsable de regular la validaci\u00f3n de sistemas inform\u00e1ticos en el \u00e1mbito de la salud.\n- **GAMP5**: Buenas Pr\u00e1cticas de Automatizaci\u00f3n y Validaci\u00f3n de Sistemas, que sirve como referencia para la estructura de la documentaci\u00f3n de pruebas.\n- **Documentos de Pruebas**: Incluyen especificaciones de pruebas, registros de resultados y reportes de pruebas.\n\n### Conclusi\u00f3n\nEl documento proporciona directrices claras sobre c\u00f3mo llevar a cabo la documentaci\u00f3n de pruebas de manera efectiva, resaltando la importancia de la estandarizaci\u00f3n y la gesti\u00f3n adecuada de los procesos de prueba en proyectos de sistemas inform\u00e1ticos.", "excerpt_keywords": "Keywords: validation, testing, documentation, ANVISA, software"}}, "afad6838-9e2b-4d9d-a713-7a39b0e64bb4": {"node_ids": ["2c4bc896-70b7-40a2-8fb4-c51363ebebbd"], "metadata": {"page_label": "48", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "## 9.7.3.2.5 Test Report and Summary Test Report\n\nTest reports must contain:\n\n- Introduction;\n- Scope of tests;\n- Testing organization;\n- Who performed and who reviewed the tests;\n- Summary of test results in tabular form;\n- Summary of test failures;\n- Conclusions;\n- For large or complex projects that have multiple test reports the general conclusions can be documented in a summary test report.\n\n## 9.7.3.3 Components of the Test Strategy\n\nThe following points should be taken into account when developing the testing strategy:\n\n- Company policies and procedures;\n- Results of risk assessments;\n- Results of supplier assessment;\n- GAMP system categories;\n- Other documents, such as: requirements specifications; initial risk assessment; specification functional; configuration specification; design documents; results of other activities carried out in the different stages of software development and traceability matrix.\n\n## 9.7.3.4 Types of Tests\n\nThere are basically two types of testing activities:\n\n- **White Box Testing (White Box Testing)** - also known as a test based on the code or structural tests, where tests are identified based on source code, knowledge of detailed design specifications and other development documents;\n- **Black Box Testing (Black Box Testing)** - testing based on functional specifications, hence known as functional tests.\n\nBlack box tests may be sufficient as long as the supplier's assessment has found adequate evidence of white box testing.\n\nSpecific types of tests should be considered, depending on the complexity and innovation of the system, the associated risk and the assessment of the system supplier to be tested, including:\n\n- Normal Case Tests (Positive Case or Capability Tests) - system skill challenges", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior que puede ayudar a formularlas:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos establece directrices sobre la elaboraci\u00f3n de informes de pruebas, componentes de la estrategia de pruebas y tipos de pruebas que deben realizarse. Se enfatiza la importancia de incluir informaci\u00f3n detallada en los informes de pruebas, as\u00ed como considerar diversos factores al desarrollar una estrategia de pruebas. Adem\u00e1s, se describen dos enfoques principales para las pruebas: pruebas de caja blanca y pruebas de caja negra, junto con ejemplos de pruebas espec\u00edficas que deben realizarse.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfQu\u00e9 elementos son esenciales para incluir en un informe de pruebas seg\u00fan la gu\u00eda de ANVISA?**\n   - La gu\u00eda especifica que un informe de pruebas debe contener una introducci\u00f3n, el alcance de las pruebas, la organizaci\u00f3n de pruebas, qui\u00e9n realiz\u00f3 y revis\u00f3 las pruebas, un resumen de los resultados en forma tabular, un resumen de las fallas en las pruebas y conclusiones. Para proyectos grandes o complejos, se puede documentar un informe de resumen de pruebas.\n\n2. **\u00bfCu\u00e1les son los factores clave que deben considerarse al desarrollar una estrategia de pruebas seg\u00fan ANVISA?**\n   - Al desarrollar una estrategia de pruebas, se deben tener en cuenta las pol\u00edticas y procedimientos de la empresa, los resultados de las evaluaciones de riesgos y de proveedores, las categor\u00edas de sistemas GAMP, y otros documentos relevantes como especificaciones de requisitos, evaluaciones de riesgos iniciales, especificaciones funcionales y matrices de trazabilidad.\n\n3. **\u00bfQu\u00e9 diferencia hay entre las pruebas de caja blanca y las pruebas de caja negra, y cu\u00e1ndo se puede considerar suficiente una prueba de caja negra?**\n   - Las pruebas de caja blanca se basan en el c\u00f3digo y las especificaciones de dise\u00f1o detalladas, mientras que las pruebas de caja negra se basan en las especificaciones funcionales. Las pruebas de caja negra pueden ser suficientes si la evaluaci\u00f3n del proveedor ha encontrado evidencia adecuada de que se han realizado pruebas de caja blanca.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\nEl documento \"Gu\u00eda para la Validaci\u00f3n de Sistemas Inform\u00e1ticos\" de ANVISA aborda varios aspectos fundamentales relacionados con la validaci\u00f3n de sistemas inform\u00e1ticos en un contexto regulatorio. A continuaci\u00f3n se presentan los temas clave y entidades mencionadas en la secci\u00f3n:\n\n#### Temas Clave\n\n1. **Introducci\u00f3n y Prop\u00f3sito**: Se establece el contexto y la finalidad del documento, as\u00ed como la autoridad que lo produce.\n   \n2. **Documentaci\u00f3n y Contratos**: Se discute el estatus contractual del documento y su relaci\u00f3n con otros documentos relevantes.\n\n3. **Alcance de las Pruebas**: Se define c\u00f3mo la especificaci\u00f3n de prueba se integra en la estrategia general de pruebas.\n\n4. **Scripts y Casos de Prueba**: Se detallan los elementos que deben incluirse en los scripts de prueba, asegurando que sean lo suficientemente claros para permitir pruebas repetibles.\n\n5. **Resultados de las Pruebas**: Se enfatiza la importancia de documentar los resultados de las pruebas, incluyendo tanto las pruebas exitosas como las fallidas.\n\n6. **Requisitos de Recursos y Personal**: Se especifican los recursos y el personal necesarios para llevar a cabo las pruebas.\n\n7. **M\u00e9todos y Herramientas**: Se mencionan los m\u00e9todos utilizados en las pruebas y las herramientas, incluidas las herramientas de prueba automatizadas.\n\n8. **Documentaci\u00f3n Necesaria**: Se requiere la documentaci\u00f3n adecuada y las revisiones y aprobaciones necesarias para validar el proceso de prueba.\n\n#### Entidades\n\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil, responsable de la regulaci\u00f3n y supervisi\u00f3n de sistemas inform\u00e1ticos en el \u00e1mbito de la salud.\n- **Documentos Relacionados**: Otros documentos que pueden influir o estar relacionados con la validaci\u00f3n de sistemas inform\u00e1ticos.\n- **Recursos y Personal**: Entidades involucradas en la ejecuci\u00f3n de las pruebas, incluyendo personal t\u00e9cnico y herramientas necesarias.\n- **Especificaciones de Control**: Documentos que sirven como referencia para asegurar que las pruebas se alineen con los requisitos establecidos.\n\nEste resumen proporciona una visi\u00f3n general de los elementos esenciales que se deben considerar al llevar a cabo la validaci\u00f3n de sistemas inform\u00e1ticos, seg\u00fan las directrices de ANVISA.", "excerpt_keywords": "Keywords: validation, testing strategy, test report, white box testing, black box testing"}}, "060263e9-c831-41cd-81ef-1f5bc32356a7": {"node_ids": ["62d167be-3328-49ef-a411-cc7d810784d9"], "metadata": {"page_label": "49", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# Guide for Computer Systems Validation\n\nto do what it was supposed to do, including triggering error and alarm messages, according to specifications:\n\n- **Tests of Invalid Cases (Negative or Resistance Case)** - challenges to the system's ability to not do what you shouldn't do, according to specifications;\n- **Repeatability Tests** - challenges to the system's ability to repeatedly do what it should do or continuously, if associated with real-time control algorithms;\n- **Performance Testing** - challenges to the system's ability to do what it should do as quickly and effectively possible, according to the specifications;\n- **Volume / Load Testing** - challenges the system's ability to manage high loads as it should. Volume/load tests are required when system resources are critical;\n- **Regression Testing** - challenges to the system's ability to:\n1. Maintain functionality after being modified according to specified requirements;\n2. Ensure that software modules not involved in the modifications are not affected adversely.\n- **Structure / Path Tests** - challenges to the program's internal structure to challenge routines/algorithms, variable values, function return values, etc.\n\nThe tests must challenge the system. So, for example, if the system is designed or intended to record the values of the parameters monitored or controlled in a database at an established frequency (e.g., every second, minute, etc.), that condition or worst case should be tested to ensure that data generated during the routine will be recorded correctly.\n\n----\n\n# 9.7.3.5 Test Environments\n\nThe test strategy must consider and define the environments necessary for carrying out the tests. For typical category 3 systems there will be only one environment. For more complex systems, the performance of Testing can take place in different environments during the design phase, which may include:\n\n- **Development environment**, where prototype production or programming takes place;\n- **Test environment**, where tests are formally performed;\n- **Operating environment** where the system is installed in its target environment.\n\nFormal tests, as far as possible, should be performed in an operational environment. To this end, the records must be clearly distinguished from production records or test records can be filed before beginning of the operation. Tests can also be performed in a separate test environment or in two environments.\n\nThe test documents must specify which environment will be used. When using a the test strategy chosen must justify the equivalence of the test results to the results that would be obtained in the operational environment.\n\nFormal tests should only be performed in environments under configuration management.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos detalla los tipos de pruebas que deben realizarse para asegurar que un sistema funcione seg\u00fan las especificaciones. Estas pruebas incluyen casos negativos, pruebas de repetibilidad, rendimiento, carga, regresi\u00f3n y estructura. Adem\u00e1s, se discuten los entornos de prueba necesarios, que pueden incluir entornos de desarrollo, prueba y operaci\u00f3n, y se enfatiza la importancia de realizar pruebas formales en un entorno operativo y bajo gesti\u00f3n de configuraci\u00f3n.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfQu\u00e9 tipo de pruebas se deben realizar para asegurar que un sistema inform\u00e1tico no ejecute acciones no permitidas seg\u00fan las especificaciones?**\n   - Respuesta: Se deben realizar **Tests de Casos Inv\u00e1lidos (Casos Negativos o de Resistencia)**, que desaf\u00edan la capacidad del sistema para no realizar acciones que no deber\u00eda hacer, de acuerdo con las especificaciones.\n\n2. **\u00bfCu\u00e1l es la importancia de realizar pruebas en un entorno operativo en lugar de solo en un entorno de prueba?**\n   - Respuesta: Las pruebas formales deben realizarse en un entorno operativo para asegurar que los resultados sean representativos de c\u00f3mo funcionar\u00e1 el sistema en condiciones reales. Esto ayuda a distinguir claramente entre registros de producci\u00f3n y registros de prueba, garantizando la validez de los resultados obtenidos.\n\n3. **\u00bfQu\u00e9 justificaci\u00f3n se requiere al elegir una estrategia de prueba en relaci\u00f3n con los resultados obtenidos en el entorno operativo?**\n   - Respuesta: La estrategia de prueba elegida debe justificar la equivalencia de los resultados de las pruebas con los resultados que se obtendr\u00edan en el entorno operativo, asegurando que las pruebas realizadas en otros entornos sean relevantes y aplicables a la operaci\u00f3n real del sistema.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Informe de Pruebas**:\n   - Elementos esenciales que deben incluirse:\n     - Introducci\u00f3n\n     - Alcance de las pruebas\n     - Organizaci\u00f3n de pruebas\n     - Identificaci\u00f3n de quienes realizaron y revisaron las pruebas\n     - Resumen de resultados en forma tabular\n     - Resumen de fallas en las pruebas\n     - Conclusiones\n     - Informe de resumen para proyectos grandes o complejos\n\n2. **Estrategia de Pruebas**:\n   - Factores a considerar al desarrollar la estrategia:\n     - Pol\u00edticas y procedimientos de la empresa\n     - Resultados de evaluaciones de riesgos\n     - Resultados de evaluaciones de proveedores\n     - Categor\u00edas de sistemas GAMP\n     - Documentos relevantes (especificaciones de requisitos, evaluaciones de riesgos, especificaciones funcionales, etc.)\n\n3. **Tipos de Pruebas**:\n   - **Pruebas de Caja Blanca**:\n     - Basadas en el c\u00f3digo y especificaciones de dise\u00f1o detalladas.\n   - **Pruebas de Caja Negra**:\n     - Basadas en especificaciones funcionales.\n     - Pueden ser suficientes si hay evidencia adecuada de pruebas de caja blanca.\n\n4. **Tipos Espec\u00edficos de Pruebas**:\n   - Pruebas de Casos Normales (Pruebas Positivas o de Capacidad) que eval\u00faan las habilidades del sistema.\n\n### Entidades Clave\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil.\n- **GAMP**: Buenas Pr\u00e1cticas de Automatizaci\u00f3n de Sistemas.\n- **Documentos de Referencia**: Especificaciones de requisitos, evaluaciones de riesgos, especificaciones funcionales, etc.\n\nEste resumen destaca los elementos esenciales y las consideraciones clave para la validaci\u00f3n de sistemas inform\u00e1ticos seg\u00fan la gu\u00eda de ANVISA.", "excerpt_keywords": "Keywords: validation, testing, environments, specifications, ANVISA"}}, "cec2f0ca-65ca-434a-b41c-d23642da723e": {"node_ids": ["08884b1a-dd94-4fcb-87e9-bb37bbee213f"], "metadata": {"page_label": "50", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 9.7.3.6 Acceptance Tests\n\nAcceptance tests are specific tests performed to meet some contractual needs. These tests are usually part of a predefined group of functional tests performed to demonstrate the adequacy of the system to the intended use and compliance with user requirements. In such situations, take advantage of test results already carried out, thus avoiding duplication of tests.\n\nAcceptance can be carried out in two stages, Acceptance at the Factory (Factory) or the Plant (Site), namely:\n\n- **Acceptance Testing Factory (Factory Acceptance Tests - FAT)** - are performed on the premises of before delivery, to show that the system is working well enough to be installed and tested at the user's premises;\n- **Acceptance Tests in Plant (Site Acceptance Tests - SAT)** - run on the company premises regulated to show that the system is working in its operating environment and that its interface with other systems and peripherals and is working properly.\n\nThis approach is often used for automated equipment and control systems.\n\nThe environment for conducting the acceptance test (test or operational) must be defined.\n\n# 9.7.4 Execution of Tests\n\nAll tests are performed according to specifications and scripts pre-defined and approved and maintained under version control.\n\n----\n\n# 9.7.4.1 Prerequisites\n\nThe following general requirements must be met before formal testing begins:\n\n- Formal configuration management must exist before formal testing begins. All items to be tested (Firmware/software/hardware) that are within the scope of the testing phase specific, should be considered as a baseline and be under change control before execution of tests;\n- All necessary documentation must be available as described in the test specifications;\n- All prerequisites must be available;\n- If there is a need to calibrate any equipment, this must be done and documented. THE calibration equipment must be certified, traceable to national standards and referenced according to customer procedures;\n- All personnel responsible for carrying out the tests, including end users, must be trained in the test procedures and must be able to demonstrate sufficient confidence to operate the system in test. Training must be documented.\n- All employees involved must be trained in Good Documentation Practices.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos establece directrices para la realizaci\u00f3n de pruebas de aceptaci\u00f3n, que son esenciales para garantizar que un sistema cumple con los requisitos del usuario y es adecuado para su uso previsto. Estas pruebas se dividen en dos etapas: las pruebas de aceptaci\u00f3n en f\u00e1brica (FAT) y las pruebas de aceptaci\u00f3n en planta (SAT). Adem\u00e1s, se detallan los requisitos previos que deben cumplirse antes de iniciar las pruebas formales, incluyendo la gesti\u00f3n de configuraci\u00f3n, la disponibilidad de documentaci\u00f3n y la capacitaci\u00f3n del personal involucrado.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfCu\u00e1les son las diferencias clave entre las pruebas de aceptaci\u00f3n en f\u00e1brica (FAT) y las pruebas de aceptaci\u00f3n en planta (SAT)?**\n   - Esta pregunta busca una comparaci\u00f3n directa entre los dos tipos de pruebas de aceptaci\u00f3n mencionadas en el documento, lo que no se encuentra f\u00e1cilmente en otros contextos.\n\n2. **\u00bfQu\u00e9 requisitos de gesti\u00f3n de configuraci\u00f3n deben cumplirse antes de comenzar las pruebas formales?**\n   - Esta pregunta se centra en los aspectos espec\u00edficos de la gesti\u00f3n de configuraci\u00f3n que son cruciales para el proceso de validaci\u00f3n, lo que puede no estar claramente definido en otras gu\u00edas o documentos.\n\n3. **\u00bfQu\u00e9 tipo de capacitaci\u00f3n es necesaria para el personal que realiza las pruebas, y por qu\u00e9 es importante documentarla?**\n   - Esta pregunta aborda la importancia de la capacitaci\u00f3n del personal y la documentaci\u00f3n de la misma, aspectos que son fundamentales para asegurar la calidad y la conformidad en el proceso de pruebas, pero que pueden no ser tratados en detalle en otros contextos.", "prev_section_summary": "### Temas Clave\n\n1. **Tipos de Pruebas**: El documento detalla varios tipos de pruebas que deben realizarse para validar sistemas inform\u00e1ticos, incluyendo:\n   - **Tests de Casos Inv\u00e1lidos**: Verifican que el sistema no realice acciones no permitidas.\n   - **Pruebas de Repetibilidad**: Aseguran que el sistema pueda realizar las mismas acciones de manera consistente.\n   - **Pruebas de Rendimiento**: Eval\u00faan la rapidez y efectividad del sistema.\n   - **Pruebas de Carga/Volumen**: Determinan la capacidad del sistema para manejar altas cargas de trabajo.\n   - **Pruebas de Regresi\u00f3n**: Aseguran que las modificaciones no afecten negativamente la funcionalidad existente.\n   - **Pruebas de Estructura/Camino**: Analizan la estructura interna del programa.\n\n2. **Entornos de Prueba**: Se discuten los diferentes entornos necesarios para realizar pruebas, que incluyen:\n   - **Entorno de Desarrollo**: Para la producci\u00f3n de prototipos y programaci\u00f3n.\n   - **Entorno de Prueba**: Donde se realizan las pruebas formales.\n   - **Entorno Operativo**: Donde el sistema se instala en su entorno objetivo.\n\n3. **Importancia de las Pruebas Formales**: Se enfatiza que las pruebas deben realizarse en un entorno operativo para asegurar la validez de los resultados y la correcta distinci\u00f3n entre registros de producci\u00f3n y de prueba.\n\n4. **Gesti\u00f3n de Configuraci\u00f3n**: Las pruebas formales deben llevarse a cabo en entornos que est\u00e9n bajo gesti\u00f3n de configuraci\u00f3n para asegurar la integridad y trazabilidad de los resultados.\n\n### Entidades\n\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil, responsable de la regulaci\u00f3n de sistemas inform\u00e1ticos en el \u00e1mbito de la salud.\n- **Sistemas Inform\u00e1ticos**: Sistemas que requieren validaci\u00f3n para asegurar su correcto funcionamiento seg\u00fan especificaciones.\n- **Entornos de Prueba**: Incluyen desarrollo, prueba y operaci\u00f3n, cada uno con un prop\u00f3sito espec\u00edfico en el proceso de validaci\u00f3n.\n- **Documentos de Prueba**: Documentaci\u00f3n que especifica las estrategias y entornos utilizados para las pruebas.\n\n### Resumen\n\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos establece la necesidad de realizar diversas pruebas para garantizar que los sistemas funcionen seg\u00fan las especificaciones. Se destacan los tipos de pruebas, la importancia de realizar pruebas en entornos operativos y la necesidad de gesti\u00f3n de configuraci\u00f3n para asegurar la validez de los resultados.", "excerpt_keywords": "Keywords: Acceptance Tests, Factory Acceptance Tests, Site Acceptance Tests, Configuration Management, Good Documentation Practices"}}, "1c54d830-e6ca-4bbb-beaf-cfc2ec0f71b7": {"node_ids": ["1df903e2-7973-4824-a948-3ef861d97f52"], "metadata": {"page_label": "51", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "## 9.7.4.2 Execution\n\nTests should be performed as follows:\n\n- According to a pre-defined and pre-approved specification.\n- Each test must be performed according to the test script and the results must be recorded;\n- Each test must be performed by an appropriately trained person, including Good Practice Practices. Documentation;\n- The results of the tests must be documented directly at the time of their execution and must be maintained;\n- All test results must be recorded immediately and accurately;\n- The identity of the tester must be recorded;\n- Test records made manually must be readable. Shorthand annotations should be avoided and real values should be recorded whenever possible;\n- The test runner must decide whether the acceptance criterion is met and whether the test has passed or not. THE test script must declare whether the test PASSED or FAILED;\n- In the event of a FAIL in the test, the executor must decide whether to continue testing, abort tests or refers to item 9.7.4.4 (Test Review), in accordance with approved testing procedures. All tests that fail must be recorded;\n- Testing procedures must be flexible enough to allow the tester to be able to decide whether to continue testing when you encounter situations such as when the system is found to work correctly, but the test script is incorrect;\n- All tests that fail must be traceable during correction until final closure. At corrections of failed tests may require regression tests to verify that corrections do not introduced new problems in other modules or routines of the system.\n\nThe execution of the tests must be audited periodically, by sampling, by the Quality Unit of the regulated company.\n\n## 9.7.4.3 Test Support Documentation\n\nDocumentation, such as prints, screen prints, notes, photos, etc., are required to give support test results.\n\nMore complex systems require more extensive and complete support documentation than more complex systems simple.\n\nUnnecessary supporting documentation, which does not add any value to the test results, should be avoided.\n\n## 9.7.4.4 Review of Tests\n\nAfter completing the tests, the results should be reviewed to verify:", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas basadas en el contexto proporcionado, junto con sus respuestas:\n\n### Preguntas y Respuestas\n\n1. **\u00bfQu\u00e9 criterios deben cumplirse para que un test se considere aprobado seg\u00fan el documento de ANVISA?**\n   - Un test se considera aprobado si se realiza de acuerdo con una especificaci\u00f3n predefinida y preaprobada, se ejecuta seg\u00fan el script de prueba, y el resultado se documenta de manera inmediata y precisa. Adem\u00e1s, el script de prueba debe declarar expl\u00edcitamente si el test ha PASADO o FALLADO, y el criterio de aceptaci\u00f3n debe ser cumplido.\n\n2. **\u00bfQu\u00e9 debe hacerse en caso de que un test falle durante su ejecuci\u00f3n?**\n   - Si un test falla, el ejecutor debe decidir si continuar con las pruebas, abortarlas o referirse al procedimiento de revisi\u00f3n de pruebas. Todos los fallos deben ser registrados, y es importante que las pruebas fallidas sean trazables hasta su correcci\u00f3n final. Adem\u00e1s, puede ser necesario realizar pruebas de regresi\u00f3n para asegurar que las correcciones no introduzcan nuevos problemas.\n\n3. **\u00bfCu\u00e1l es la importancia de la documentaci\u00f3n de soporte en las pruebas y c\u00f3mo debe ser manejada?**\n   - La documentaci\u00f3n de soporte, como capturas de pantalla, notas y fotos, es crucial para respaldar los resultados de las pruebas. En sistemas m\u00e1s complejos, se requiere una documentaci\u00f3n m\u00e1s extensa y completa. Sin embargo, se debe evitar la documentaci\u00f3n innecesaria que no aporte valor a los resultados de las pruebas, asegurando as\u00ed que la informaci\u00f3n sea relevante y \u00fatil.\n\n### Resumen de Nivel Superior\n\nEl documento de ANVISA establece directrices claras para la ejecuci\u00f3n de pruebas en sistemas inform\u00e1ticos, enfatizando la importancia de seguir especificaciones predefinidas, documentar resultados de manera precisa y mantener la trazabilidad de las pruebas fallidas. Tambi\u00e9n se destaca la necesidad de una documentaci\u00f3n de soporte adecuada y la flexibilidad en los procedimientos de prueba para adaptarse a situaciones imprevistas. La revisi\u00f3n de los resultados de las pruebas es esencial para garantizar la calidad y la conformidad con los est\u00e1ndares establecidos.\n\n### Preguntas Generadas a partir del Resumen\n\n1. **\u00bfPor qu\u00e9 es crucial seguir especificaciones predefinidas en la ejecuci\u00f3n de pruebas seg\u00fan ANVISA?**\n2. **\u00bfQu\u00e9 papel juega la documentaci\u00f3n de soporte en la validaci\u00f3n de sistemas inform\u00e1ticos y c\u00f3mo se debe gestionar?**\n3. **\u00bfC\u00f3mo se debe manejar la trazabilidad de las pruebas fallidas y qu\u00e9 implicaciones tiene para el proceso de correcci\u00f3n?**", "prev_section_summary": "### Temas Clave\n\n1. **Pruebas de Aceptaci\u00f3n**: Se definen como pruebas espec\u00edficas realizadas para cumplir con necesidades contractuales y demostrar la adecuaci\u00f3n del sistema a su uso previsto y el cumplimiento de los requisitos del usuario.\n\n2. **Tipos de Pruebas de Aceptaci\u00f3n**:\n   - **Pruebas de Aceptaci\u00f3n en F\u00e1brica (FAT)**: Realizadas antes de la entrega para asegurar que el sistema funcione adecuadamente antes de ser instalado en las instalaciones del usuario.\n   - **Pruebas de Aceptaci\u00f3n en Planta (SAT)**: Ejecutadas en las instalaciones del cliente para verificar que el sistema opera correctamente en su entorno y se integra adecuadamente con otros sistemas y perif\u00e9ricos.\n\n3. **Ejecuci\u00f3n de Pruebas**: Todas las pruebas deben realizarse de acuerdo con especificaciones y scripts predefinidos, que deben estar aprobados y bajo control de versiones.\n\n4. **Requisitos Previos para las Pruebas**:\n   - Gesti\u00f3n de configuraci\u00f3n formal.\n   - Disponibilidad de documentaci\u00f3n necesaria.\n   - Cumplimiento de todos los requisitos previos.\n   - Calibraci\u00f3n y documentaci\u00f3n de equipos, si es necesario.\n   - Capacitaci\u00f3n del personal involucrado en las pruebas, con documentaci\u00f3n de la misma.\n   - Capacitaci\u00f3n en Buenas Pr\u00e1cticas de Documentaci\u00f3n para todos los empleados implicados.\n\n### Entidades\n\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria en Brasil, responsable de la regulaci\u00f3n de sistemas inform\u00e1ticos en el \u00e1mbito de la salud.\n- **FAT (Factory Acceptance Tests)**: Pruebas de aceptaci\u00f3n en f\u00e1brica.\n- **SAT (Site Acceptance Tests)**: Pruebas de aceptaci\u00f3n en planta.\n- **Firmware, Software, Hardware**: Elementos que deben ser gestionados bajo control de cambios antes de las pruebas.\n- **Calibraci\u00f3n**: Proceso necesario para asegurar que los equipos utilizados en las pruebas est\u00e9n en condiciones adecuadas de funcionamiento.\n- **Capacitaci\u00f3n**: Formaci\u00f3n necesaria para el personal que realiza las pruebas, asegurando que est\u00e9n preparados y documentados.\n\nEste resumen destaca los aspectos fundamentales y las entidades relevantes en la secci\u00f3n sobre pruebas de aceptaci\u00f3n del documento de ANVISA.", "excerpt_keywords": "Keywords: validation, testing, documentation, ANVISA, quality assurance"}}, "f180220c-af47-4d63-b9a2-c94e0f93c150": {"node_ids": ["12317370-c0fe-4965-a79e-3e14ea4656c2"], "metadata": {"page_label": "52", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "- That all tests have been covered;\n- The legibility, accuracy and completeness of the tests;\n- That all relevant documents have been included and that the documentation is complete and correctly filled;\n- That the acceptance criteria have been met;\n- That all records of failed tests have been included;\n- Compliance with procedures.\n\nAlternatively, the tester may request a review of the tests when a failure occurs, in order to decide what actions will be taken and what will be the next steps.\n\nReviews must be performed and documented by a person other than the test runner, such as a test reviewer or a group, or the subject matter expert.\n\nIn the event of test failures, the test reviewer must decide what action to take and what type of retest to take. These decisions must be documented.\n\nTesting failures can result from:\n\n- Error in the way the script was written. Corrective action: update, followed by script approval corrected tests and consider the need for retesting;\n- Error in how the requirement was defined. Corrective action: update the requirement, with possible execution of retest and explanation in the test report;\n- Error in the way the test was performed by the tester. Corrective action: repetition of the test;\n- System error. Corrective action: application of a change control and repetition of the test.\n\n## 9.7.5 Testing Activities Performed by the Supplier\n\nThere are different models of *software* development, including:\n\n- Waterfall;\n- Spiral;\n- Prototyping;\n- V model.\n\nWhichever model is used, the supplier must define the implementation of the model, including the necessary quality controls and describe the method used to demonstrate that the system computerized is suitable for the intended use.\n\nTesting strategies must be properly established, implemented and documented.\n\nThe *hardware* and *software* configuration used in the tests must be documented. This includes: systems underlying systems such as operating system, database and network; *hardware* for networks; servers and clients, when appropriate.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos establece directrices sobre la realizaci\u00f3n de pruebas en software, incluyendo la necesidad de cubrir todas las pruebas, la legibilidad y precisi\u00f3n de los resultados, y la documentaci\u00f3n adecuada de los procesos. Se enfatiza la importancia de que las revisiones de pruebas sean realizadas por personas distintas a quienes ejecutaron las pruebas, y se describen las acciones correctivas a tomar en caso de fallos en las pruebas. Adem\u00e1s, se mencionan diferentes modelos de desarrollo de software y la necesidad de documentar la configuraci\u00f3n de hardware y software utilizada en las pruebas.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfQu\u00e9 acciones correctivas se deben tomar si se identifica un error en la forma en que se escribi\u00f3 el script de prueba?**\n   - La acci\u00f3n correctiva consiste en actualizar el script, seguido de la aprobaci\u00f3n del script corregido y considerar la necesidad de realizar un retest.\n\n2. **\u00bfQui\u00e9n debe realizar y documentar las revisiones de las pruebas en caso de fallos, y por qu\u00e9 es importante esta separaci\u00f3n de funciones?**\n   - Las revisiones deben ser realizadas y documentadas por una persona distinta al ejecutor de la prueba, como un revisor de pruebas o un experto en la materia. Esta separaci\u00f3n es importante para garantizar la objetividad y la imparcialidad en la evaluaci\u00f3n de los resultados de las pruebas.\n\n3. **\u00bfQu\u00e9 aspectos deben ser documentados en relaci\u00f3n con la configuraci\u00f3n de hardware y software utilizada durante las pruebas?**\n   - Debe documentarse la configuraci\u00f3n de hardware y software utilizada, incluyendo los sistemas subyacentes como el sistema operativo, la base de datos y la red, as\u00ed como el hardware para redes, servidores y clientes, cuando sea apropiado.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n#### Temas Clave:\n\n1. **Ejecuci\u00f3n de Pruebas**:\n   - Las pruebas deben realizarse seg\u00fan especificaciones predefinidas y aprobadas.\n   - Es esencial seguir un script de prueba y documentar los resultados de manera inmediata y precisa.\n   - La identidad del probador debe ser registrada y los registros deben ser legibles.\n   - En caso de fallos, se debe decidir si continuar, abortar o revisar las pruebas, y todos los fallos deben ser documentados y trazables.\n\n2. **Documentaci\u00f3n de Soporte**:\n   - Se requiere documentaci\u00f3n adicional (capturas de pantalla, notas, fotos) para respaldar los resultados de las pruebas.\n   - La cantidad y complejidad de la documentaci\u00f3n de soporte deben ser proporcionales a la complejidad del sistema.\n   - Se debe evitar la documentaci\u00f3n innecesaria que no aporte valor.\n\n3. **Revisi\u00f3n de Pruebas**:\n   - Los resultados de las pruebas deben ser revisados tras su finalizaci\u00f3n para verificar su validez y conformidad con los criterios establecidos.\n\n4. **Auditor\u00eda**:\n   - La ejecuci\u00f3n de las pruebas debe ser auditada peri\u00f3dicamente por la Unidad de Calidad de la empresa regulada.\n\n#### Entidades:\n\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil, responsable de regular y supervisar la validaci\u00f3n de sistemas inform\u00e1ticos.\n- **Unidad de Calidad**: Entidad dentro de la empresa regulada encargada de auditar y asegurar la calidad de los procesos de prueba.\n- **Probador**: Persona responsable de ejecutar las pruebas, que debe estar adecuadamente entrenada.\n- **Sistema Inform\u00e1tico**: El objeto de validaci\u00f3n que est\u00e1 siendo probado.\n\nEste resumen destaca la importancia de seguir procedimientos rigurosos en la ejecuci\u00f3n de pruebas, la necesidad de documentaci\u00f3n adecuada y la revisi\u00f3n de resultados para garantizar la calidad y conformidad en la validaci\u00f3n de sistemas inform\u00e1ticos.", "excerpt_keywords": "Keywords: validation, testing, documentation, software development, corrective actions"}}, "0e5a5b83-4c39-45ed-a018-143cfa8d9c89": {"node_ids": ["da55b95f-68a7-4b81-bb5a-a1c22c7b4318"], "metadata": {"page_label": "53", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "## 9.7.5.1 Tests Performed During Development\n\nInternal tests performed by the supplier must be performed according to test specifications defined and approved. Types of tests most commonly performed are:\n\n- **Acceptance testing for hardware and software purchased** - hardware and software purchased must be subjected to acceptance tests before being used for system development;\n- **Module / unit tests** - individual tests on software components, ensuring readiness for later insertion into an integrated system;\n- **Integration and System Tests** - tests of the integrated components of the system, subsystems and the complete system.\n\n## 9.7.5.2 Contractual Tests\n\nTesting and verification activities should be defined for business purposes, between the computerized system supplier and the regulated company.\n\n## 9.7.6 Automated Tests\n\nAutomated verification testing tools can be used to improve effectiveness and efficiency of test execution. They can be used both for the execution of cash tests, black and white box tests.\n\nAny use of these tools must be defined in the testing strategy.\n\nThese tools must be used in accordance with instructions and manuals defined and maintained under Configuration Management. They usually belong to GAMP category 1.\n\nIt is important that responsibilities are defined in relation to the following aspects:\n\n- Ownership (Who owns it), administration and maintenance of the test tool;\n- Maintenance of test data;\n- Maintenance of test documents (including test specifications, test scripts and test results);\n- Instructions and manuals for use.\n\nPreferably, these testing tools should have the capabilities of electronic signatures and electronic records that meet regulatory requirements.\n\n## 9.7.6.1 Examples of Automated Test Execution Tools\n\nBelow are some examples of tools for automated execution (source code debugging and testing tools) for testing the source code:\n\n- Automated test drivers (automatic test execution);\n- Test data generators;", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "### Resumen del Contexto\n\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos detalla los tipos de pruebas que deben realizarse durante el desarrollo de software y hardware, as\u00ed como la importancia de las pruebas automatizadas. Se enfatiza la necesidad de que las pruebas sean definidas y aprobadas, y se menciona la responsabilidad en la administraci\u00f3n de herramientas de prueba. Tambi\u00e9n se destacan ejemplos de herramientas de ejecuci\u00f3n de pruebas automatizadas.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfCu\u00e1les son los tipos de pruebas que deben realizarse antes de utilizar hardware y software en el desarrollo de sistemas, seg\u00fan el documento de ANVISA?**\n   - Respuesta: Los tipos de pruebas incluyen pruebas de aceptaci\u00f3n para hardware y software adquiridos, pruebas de m\u00f3dulo/unidad, y pruebas de integraci\u00f3n y del sistema.\n\n2. **\u00bfQu\u00e9 aspectos deben definirse en relaci\u00f3n con las herramientas de prueba automatizadas seg\u00fan la gu\u00eda de ANVISA?**\n   - Respuesta: Deben definirse aspectos como la propiedad y administraci\u00f3n de la herramienta de prueba, el mantenimiento de los datos de prueba, el mantenimiento de documentos de prueba (especificaciones, scripts y resultados), y las instrucciones y manuales para su uso.\n\n3. **\u00bfQu\u00e9 caracter\u00edsticas deben tener preferiblemente las herramientas de prueba automatizadas para cumplir con los requisitos regulatorios?**\n   - Respuesta: Las herramientas de prueba automatizadas deben tener capacidades de firmas electr\u00f3nicas y registros electr\u00f3nicos que cumplan con los requisitos regulatorios.\n\n### Resumen de Nivel Superior\n\nEl documento de ANVISA establece directrices claras sobre la validaci\u00f3n de sistemas inform\u00e1ticos, enfatizando la importancia de realizar pruebas adecuadas durante el desarrollo y el uso de herramientas automatizadas para mejorar la eficiencia. Se requiere que las pruebas sean definidas y aprobadas, y que se mantenga una gesti\u00f3n adecuada de las herramientas y documentos relacionados.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Pruebas de Software**: Se enfatiza la importancia de cubrir todas las pruebas, asegurando su legibilidad, precisi\u00f3n y completitud. Tambi\u00e9n se requiere que toda la documentaci\u00f3n relevante est\u00e9 completa y correctamente llenada.\n\n2. **Revisi\u00f3n de Pruebas**: Las revisiones deben ser realizadas por personas distintas a quienes ejecutaron las pruebas, como revisores de pruebas o expertos en la materia. Esto es crucial para mantener la objetividad en la evaluaci\u00f3n de los resultados.\n\n3. **Acciones Correctivas ante Fallos**: Se describen las acciones correctivas a tomar en caso de fallos en las pruebas, que pueden incluir:\n   - Actualizaci\u00f3n del script de prueba.\n   - Actualizaci\u00f3n de los requisitos.\n   - Repetici\u00f3n de la prueba.\n   - Aplicaci\u00f3n de control de cambios y repetici\u00f3n de la prueba en caso de errores del sistema.\n\n4. **Modelos de Desarrollo de Software**: Se mencionan diferentes modelos de desarrollo, como Waterfall, Spiral, Prototyping y V model. El proveedor debe definir c\u00f3mo se implementar\u00e1 el modelo elegido y los controles de calidad necesarios.\n\n5. **Documentaci\u00f3n de Configuraci\u00f3n**: Es esencial documentar la configuraci\u00f3n de hardware y software utilizada en las pruebas, incluyendo sistemas operativos, bases de datos, redes, servidores y clientes.\n\n### Entidades Clave\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil, responsable de la regulaci\u00f3n de la validaci\u00f3n de sistemas inform\u00e1ticos.\n- **Modelos de Desarrollo de Software**: Waterfall, Spiral, Prototyping, V model.\n- **Roles**: Tester, Revisor de Pruebas, Experto en la Materia.\n- **Elementos de Documentaci\u00f3n**: Resultados de pruebas, requisitos, configuraciones de hardware y software. \n\nEste resumen destaca la importancia de la validaci\u00f3n y documentaci\u00f3n en el proceso de pruebas de software, as\u00ed como la necesidad de mantener la calidad y la objetividad en las evaluaciones.", "excerpt_keywords": "Keywords: ANVISA, computer systems validation, automated testing, acceptance testing, software development"}}, "9cf4ba71-d35f-43f9-aec0-5645c4c8b8b2": {"node_ids": ["f4e36642-eb32-4bb2-b93e-65aa3fbdf0f9"], "metadata": {"page_label": "54", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "- Environment simulators;\n- Static analyzers;\n- Dynamic performers;\n- Symbolic performers;\n- Volume / load drivers.\n\n## 9.7.6.2 Automated Testing Documentation\n\nThe automated test scripts must be controlled according to approved procedures.\n\nThe records (logs) generated by the computer resulting from the execution of the automated test scripts are normally generated automatically from the execution of the scripts.\n\nThe header record (log) must provide the following information:\n\n- Record identification;\n- Date and time of execution;\n- Test script name and version;\n- Test runner's identity and the name of the test environment.\n\nThe record cannot be edited or deleted. They must be read-only files, and should be maintained for future reviews or audits.\n\nThe automated test documentation must be kept for a minimum for the same period as the records tests performed on paper.\n\nThe use and management of automated testing documentation must be approved in advance by the Quality Unit as part of the development of the testing strategy.\n\n## 9.7.7 Tests Applied to Different Categories of Systems\n\nThis section presents the practical considerations for planning the tests to be performed on the systems belonging to categories 3, 4 and 5.\n\nFor those computerized systems that comprise equipment managed by an application (software), there is a need to also carry out the qualification of this equipment, whose methodology is described in international guides and specific legislation and is not the scope of this guide.\n\nHardware/software IQ and OQ activities are often performed by the supplier of the software, but such activities must have an active participation in the realization and approval by the company regulated.\n\n## 9.7.7.1 Aspects Applicable to All System Categories\n### 9.7.7.1.1 Hardware/Software Installation (IQ) Tests", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas basadas en el contexto proporcionado, junto con un resumen de nivel superior que puede ayudar a formularlas:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos establece directrices para la documentaci\u00f3n y ejecuci\u00f3n de pruebas automatizadas, as\u00ed como para la calificaci\u00f3n de sistemas y equipos. Se enfatiza la importancia de mantener registros inalterables de las pruebas automatizadas y la necesidad de la aprobaci\u00f3n de la Unidad de Calidad para la gesti\u00f3n de dicha documentaci\u00f3n. Adem\u00e1s, se menciona que las actividades de Calificaci\u00f3n de Instalaci\u00f3n (IQ) y Calificaci\u00f3n de Operaci\u00f3n (OQ) son com\u00fanmente realizadas por los proveedores de software, pero requieren la participaci\u00f3n activa de la empresa regulada.\n\n### Preguntas Espec\u00edficas\n1. **\u00bfQu\u00e9 informaci\u00f3n debe incluirse en el registro (log) de las pruebas automatizadas seg\u00fan el documento de ANVISA?**\n   - Esta pregunta busca detalles espec\u00edficos sobre los requisitos de documentaci\u00f3n que no se encuentran f\u00e1cilmente en otras fuentes.\n\n2. **\u00bfCu\u00e1l es el per\u00edodo m\u00ednimo de conservaci\u00f3n de la documentaci\u00f3n de pruebas automatizadas y c\u00f3mo se compara con los registros de pruebas realizadas en papel?**\n   - Esta pregunta se centra en las pol\u00edticas de conservaci\u00f3n de documentos, que pueden ser \u00fanicas para este contexto.\n\n3. **\u00bfQu\u00e9 rol juega la Unidad de Calidad en la gesti\u00f3n de la documentaci\u00f3n de pruebas automatizadas seg\u00fan las directrices de ANVISA?**\n   - Esta pregunta explora el proceso de aprobaci\u00f3n y la importancia de la Unidad de Calidad, un aspecto que puede no estar claramente definido en otras gu\u00edas o documentos.", "prev_section_summary": "### Temas Clave\n\n1. **Tipos de Pruebas Durante el Desarrollo**:\n   - Pruebas de aceptaci\u00f3n para hardware y software adquiridos.\n   - Pruebas de m\u00f3dulo/unidad para componentes de software.\n   - Pruebas de integraci\u00f3n y del sistema para componentes integrados.\n\n2. **Pruebas Contractuales**:\n   - Definici\u00f3n de actividades de prueba y verificaci\u00f3n entre el proveedor del sistema y la empresa regulada.\n\n3. **Pruebas Automatizadas**:\n   - Uso de herramientas de verificaci\u00f3n automatizadas para mejorar la efectividad y eficiencia de la ejecuci\u00f3n de pruebas.\n   - Importancia de definir el uso de estas herramientas en la estrategia de pruebas.\n   - Necesidad de seguir instrucciones y manuales bajo Gesti\u00f3n de Configuraci\u00f3n.\n\n4. **Responsabilidades en el Uso de Herramientas de Prueba**:\n   - Propiedad, administraci\u00f3n y mantenimiento de la herramienta de prueba.\n   - Mantenimiento de datos y documentos de prueba.\n   - Instrucciones y manuales para el uso de las herramientas.\n\n5. **Requisitos Regulatorios**:\n   - Preferencia por herramientas que incluyan capacidades de firmas electr\u00f3nicas y registros electr\u00f3nicos.\n\n6. **Ejemplos de Herramientas de Ejecuci\u00f3n de Pruebas Automatizadas**:\n   - Controladores de prueba automatizados.\n   - Generadores de datos de prueba.\n\n### Entidades\n\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil.\n- **GAMP**: Buenas Pr\u00e1cticas de Automatizaci\u00f3n de Sistemas.\n- **Herramientas de Prueba**: Software utilizado para la ejecuci\u00f3n y gesti\u00f3n de pruebas automatizadas.\n- **Proveedores de Sistemas**: Entidades que suministran software y hardware para el desarrollo de sistemas inform\u00e1ticos.\n- **Empresas Reguladas**: Organizaciones que deben cumplir con normativas espec\u00edficas en el uso de sistemas inform\u00e1ticos. \n\n### Resumen\n\nLa secci\u00f3n del documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos aborda la importancia de realizar pruebas adecuadas durante el desarrollo de software y hardware. Se destacan los tipos de pruebas que deben llevarse a cabo, la necesidad de definir actividades de prueba contractuales, y el uso de herramientas automatizadas para mejorar la eficiencia. Tambi\u00e9n se enfatiza la importancia de la gesti\u00f3n adecuada de estas herramientas y documentos relacionados, as\u00ed como el cumplimiento de requisitos regulatorios.", "excerpt_keywords": "Keywords: validation, automated testing, documentation, quality unit, hardware/software qualification"}}, "28faf88e-7303-49c9-9516-7da7a1273085": {"node_ids": ["3bf391c2-cf68-4bbc-afc4-73188a85c64a"], "metadata": {"page_label": "55", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "Many companies call this Installation Qualification (IQ) activity. The purpose is to verify and document that the system components are installed according to specifications, documentation supplier and local and global requirements.\n\nIt must be evidenced that the documentation together with the system is complete and that the installation requirements and for local and global use are in accordance with specifications.\n\nInstallation tests provide a configuration baseline for subsequent installation activities, verification and validation, allowing to verify the installation methods, the testing tools and/or scripts used. This forms the basis for managing the configuration of the installed system.\n\nInstallation tests should verify that the following documents are available, when appropriate:\n\n- Technical and user guides;\n- Standard operating procedures;\n- Training schedules;\n- Service Level Agreements;\n- Security procedures;\n- Record books;\n- *Hardware* inventory;\n- List of instruments;\n- Spec sheets;\n- Calibration certificates and procedures;\n- Piping/process and instrumentation diagrams (P&ID);\n- Equipment list and specification sheets;\n- *Software* inventory (including installation procedure, system *software* list, application *software*, data list, initial data settings for initialization);\n- Program source code (category 5);\n- Preventive maintenance program;\n- List of critical spare parts.\n\n## 9.7.7.1.2 *Hardware*/*Software* Operations (OQ) Tests\n\nBelow is a general list, applicable to all systems. It should be used to assist in the verification of installed system:\n\n- Power outage test (prevention of loss of critical data or loss of control action; control reset facility);\n- Access to the system and system resources;\n- Audit trails and record of critical actions, including manual interactions;\n- Manual data entry and input validation features;\n- Electronic signature features;\n- Error and alarm messages;\n- Critical calculations;", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos establece que la Calificaci\u00f3n de Instalaci\u00f3n (IQ) es un proceso crucial para verificar que los componentes del sistema se instalan de acuerdo con las especificaciones y requisitos locales y globales. Este proceso implica la revisi\u00f3n de documentaci\u00f3n y la realizaci\u00f3n de pruebas de instalaci\u00f3n que aseguran que todos los documentos necesarios est\u00e9n disponibles y que el sistema est\u00e9 configurado correctamente. Adem\u00e1s, se mencionan pruebas de Operaciones de Hardware/Software (OQ) que ayudan a verificar el funcionamiento del sistema instalado.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfQu\u00e9 tipo de documentaci\u00f3n debe estar disponible y verificada durante la Calificaci\u00f3n de Instalaci\u00f3n (IQ)?**\n   - La documentaci\u00f3n que debe estar disponible incluye gu\u00edas t\u00e9cnicas y de usuario, procedimientos operativos est\u00e1ndar, horarios de capacitaci\u00f3n, acuerdos de nivel de servicio, procedimientos de seguridad, libros de registro, inventarios de hardware y software, certificados de calibraci\u00f3n, diagramas de tuber\u00edas y equipos, y listas de piezas de repuesto cr\u00edticas, entre otros.\n\n2. **\u00bfCu\u00e1les son algunos ejemplos de pruebas que se deben realizar durante la fase de Operaciones de Hardware/Software (OQ)?**\n   - Ejemplos de pruebas OQ incluyen la prueba de corte de energ\u00eda para prevenir la p\u00e9rdida de datos cr\u00edticos, la verificaci\u00f3n del acceso al sistema y recursos, la revisi\u00f3n de auditor\u00edas y registros de acciones cr\u00edticas, la validaci\u00f3n de entrada de datos manual, y la verificaci\u00f3n de caracter\u00edsticas de firma electr\u00f3nica y mensajes de error.\n\n3. **\u00bfCu\u00e1l es el prop\u00f3sito de realizar pruebas de instalaci\u00f3n y c\u00f3mo contribuyen a la gesti\u00f3n del sistema instalado?**\n   - El prop\u00f3sito de las pruebas de instalaci\u00f3n es establecer una l\u00ednea base de configuraci\u00f3n para actividades posteriores de instalaci\u00f3n, verificaci\u00f3n y validaci\u00f3n. Estas pruebas permiten verificar los m\u00e9todos de instalaci\u00f3n y las herramientas o scripts utilizados, lo que es fundamental para la gesti\u00f3n de la configuraci\u00f3n del sistema instalado y asegura que se cumplan los requisitos de instalaci\u00f3n.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Pruebas Automatizadas**:\n   - Se requiere que los scripts de prueba automatizados sean controlados seg\u00fan procedimientos aprobados.\n   - Los registros generados durante la ejecuci\u00f3n de las pruebas deben incluir informaci\u00f3n espec\u00edfica como identificaci\u00f3n del registro, fecha y hora de ejecuci\u00f3n, nombre y versi\u00f3n del script de prueba, identidad del ejecutor y nombre del entorno de prueba.\n   - Los registros deben ser archivos de solo lectura y no pueden ser editados o eliminados, manteni\u00e9ndose para futuras revisiones o auditor\u00edas.\n\n2. **Documentaci\u00f3n de Pruebas Automatizadas**:\n   - La documentaci\u00f3n de pruebas automatizadas debe conservarse por un per\u00edodo m\u00ednimo equivalente al de los registros de pruebas realizadas en papel.\n   - La gesti\u00f3n de esta documentaci\u00f3n debe ser aprobada por la Unidad de Calidad como parte de la estrategia de pruebas.\n\n3. **Calificaci\u00f3n de Sistemas**:\n   - Se presentan consideraciones pr\u00e1cticas para la planificaci\u00f3n de pruebas en sistemas de categor\u00edas 3, 4 y 5.\n   - La calificaci\u00f3n de equipos gestionados por aplicaciones de software es necesaria y debe seguir metodolog\u00edas descritas en gu\u00edas internacionales y legislaci\u00f3n espec\u00edfica.\n   - Las actividades de Calificaci\u00f3n de Instalaci\u00f3n (IQ) y Calificaci\u00f3n de Operaci\u00f3n (OQ) son com\u00fanmente realizadas por el proveedor de software, pero requieren la participaci\u00f3n activa de la empresa regulada.\n\n### Entidades Clave\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil, responsable de la regulaci\u00f3n de sistemas inform\u00e1ticos en el \u00e1mbito de la salud.\n- **Unidad de Calidad**: Entidad responsable de aprobar la gesti\u00f3n de la documentaci\u00f3n de pruebas automatizadas.\n- **Categor\u00edas de Sistemas**: Clasificaci\u00f3n de sistemas que requieren diferentes enfoques de prueba y calificaci\u00f3n (categor\u00edas 3, 4 y 5).\n- **Hardware/Software**: Elementos que requieren calificaci\u00f3n y validaci\u00f3n en el contexto de sistemas inform\u00e1ticos. \n\nEste resumen destaca la importancia de la documentaci\u00f3n y el control en las pruebas automatizadas, as\u00ed como la necesidad de colaboraci\u00f3n entre proveedores y empresas reguladas en la calificaci\u00f3n de sistemas.", "excerpt_keywords": "Keywords: Installation Qualification, system validation, documentation, hardware/software operations, compliance"}}, "4507c7cc-82d3-46d4-ab98-219da0bad8a9": {"node_ids": ["fcc219dd-636a-4d0b-91f2-991df927a3d3"], "metadata": {"page_label": "56", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "- Critical transactions;\n- Transfer of critical data to other packages or systems for further processing;\n- Interfaces and data transfer;\n- Backup and restore;\n- Data archiving and recovery;\n- Ability to handle high volume loads, particularly if the system is accessed by many users or need to register many values of the controlled / monitored parameters at the same time, as part of a networked application, for example.\n\n## 9.7.7.2 Test Activities for an Unconfigured Product\n\nThese computerized systems are those called \u201coff-the-shelf\u201d systems, meaning they are not configured for a specific business process or are used with your default setting (default). They are classified as category 3 of the GAMP.\n\nThe regulated company may decide to make a supplier assessment to verify the quality of the product, depending on the risk. Based on the satisfactory outcome of this assessment and the risks involved, an approach simple consisting of only one level of specification and verification can be applied.\n\nTests should focus on the following points:\n\n- Those related to the installation of the system, described in item 9.7.7.1.1;\n- User Requirements Tests that demonstrate the suitability for the intended use, which may include the conducting system functionality tests against pre-established requirements, depending on the risk involved;\n- User Requirements Tests must also include delivery and acceptance of documentation complete sent by the supplier, including specifications, manuals and drawings, if not yet done;\n- Any subsequent or more rigorous tests depending on the risk and supplier assessments;\n- Any other relevant aspects listed in item 9.7.7.1.2.\n\n## 9.7.7.3 Test Activities for a Configured Product\n\nA configured product involves configuring commercially available software that runs on standard hardware components. These systems that are configured for a specific business process are classified as category 4 of the GAMP.\n\nIn such a situation, based on the satisfactory result of the supplier's assessment and the risks involved, the testing strategy using the three-level approach (configuration, functionality and requirements) is the recommended. The number of test documents needed to cover these three levels will depend on the complexity and impact of the system.\n\nTests should focus on the following points:\n\n- Those related to the installation of the system, described above in item 9.7.7.1.1;\n- Configuration Tests - for each Configuration Specification there must be a Configuration Specification Associated Configuration Test. Tests should verify that the system has been installed according to specifications. Tests can be performed through inspection or verification the supplier's documentation;", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con sus respuestas:\n\n1. **\u00bfQu\u00e9 tipo de sistemas se consideran \"off-the-shelf\" y c\u00f3mo se clasifican seg\u00fan el GAMP?**\n   - Los sistemas \"off-the-shelf\" son aquellos que no est\u00e1n configurados para un proceso de negocio espec\u00edfico y se utilizan con la configuraci\u00f3n predeterminada. Estos sistemas se clasifican como categor\u00eda 3 del GAMP (Good Automated Manufacturing Practice).\n\n2. **\u00bfCu\u00e1les son los enfoques de prueba recomendados para un producto configurado seg\u00fan el GAMP?**\n   - Para un producto configurado, se recomienda una estrategia de prueba que utilice un enfoque de tres niveles: configuraci\u00f3n, funcionalidad y requisitos. La cantidad de documentos de prueba necesarios depender\u00e1 de la complejidad y el impacto del sistema. Las pruebas deben centrarse en la instalaci\u00f3n del sistema, las pruebas de configuraci\u00f3n y la verificaci\u00f3n de que el sistema se ha instalado de acuerdo con las especificaciones.\n\n3. **\u00bfQu\u00e9 aspectos deben considerarse en las pruebas de requisitos del usuario para un sistema no configurado?**\n   - Las pruebas de requisitos del usuario para un sistema no configurado deben demostrar la idoneidad para el uso previsto, lo que puede incluir pruebas de funcionalidad del sistema contra requisitos preestablecidos. Adem\u00e1s, deben incluir la entrega y aceptaci\u00f3n de la documentaci\u00f3n completa enviada por el proveedor, como especificaciones, manuales y dibujos, y cualquier prueba adicional que dependa del riesgo y las evaluaciones del proveedor.\n\n### Resumen de nivel superior del contexto:\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos establece directrices para la prueba de sistemas no configurados (categor\u00eda 3 del GAMP) y configurados (categor\u00eda 4 del GAMP). Para los sistemas no configurados, se sugiere un enfoque simple de especificaci\u00f3n y verificaci\u00f3n, mientras que para los configurados se recomienda un enfoque m\u00e1s detallado que incluye pruebas de configuraci\u00f3n, funcionalidad y requisitos. Las pruebas deben centrarse en aspectos cr\u00edticos como la instalaci\u00f3n del sistema, la transferencia de datos y la capacidad de manejar cargas de alto volumen.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Calificaci\u00f3n de Instalaci\u00f3n (IQ)**:\n   - Proceso para verificar y documentar que los componentes del sistema est\u00e1n instalados seg\u00fan especificaciones y requisitos locales y globales.\n   - Importancia de la documentaci\u00f3n completa y cumplimiento de requisitos de instalaci\u00f3n.\n\n2. **Documentaci\u00f3n Requerida**:\n   - Gu\u00edas t\u00e9cnicas y de usuario.\n   - Procedimientos operativos est\u00e1ndar.\n   - Horarios de capacitaci\u00f3n.\n   - Acuerdos de nivel de servicio.\n   - Procedimientos de seguridad.\n   - Libros de registro.\n   - Inventarios de hardware y software.\n   - Certificados de calibraci\u00f3n.\n   - Diagramas de tuber\u00edas y equipos (P&ID).\n   - Listas de piezas de repuesto cr\u00edticas.\n\n3. **Pruebas de Instalaci\u00f3n**:\n   - Establecen una l\u00ednea base de configuraci\u00f3n para actividades posteriores de verificaci\u00f3n y validaci\u00f3n.\n   - Verifican m\u00e9todos de instalaci\u00f3n y herramientas utilizadas.\n\n4. **Operaciones de Hardware/Software (OQ)**:\n   - Pruebas para verificar el funcionamiento del sistema instalado.\n   - Ejemplos de pruebas incluyen:\n     - Prueba de corte de energ\u00eda.\n     - Verificaci\u00f3n de acceso al sistema.\n     - Auditor\u00edas y registros de acciones cr\u00edticas.\n     - Validaci\u00f3n de entrada de datos manual.\n     - Verificaci\u00f3n de caracter\u00edsticas de firma electr\u00f3nica y mensajes de error.\n\n### Entidades Clave\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria en Brasil.\n- **Documentaci\u00f3n**: Incluye gu\u00edas, procedimientos, acuerdos, certificados, etc.\n- **Sistema**: Se refiere a los componentes de hardware y software que est\u00e1n siendo instalados y validados.\n- **Pruebas**: Actividades realizadas para asegurar que el sistema cumple con los requisitos establecidos. \n\nEste resumen destaca la importancia de la validaci\u00f3n de sistemas inform\u00e1ticos en el contexto regulatorio y los elementos necesarios para asegurar la correcta instalaci\u00f3n y operaci\u00f3n de dichos sistemas.", "excerpt_keywords": "Keywords: validation, GAMP, testing, configuration, documentation"}}, "72821ccf-6662-475b-82db-f8b108bdd182": {"node_ids": ["c3b3ebc5-bceb-47af-84ff-c25f6959c958"], "metadata": {"page_label": "57", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# Functional Tests\n\n- Functionality that supports the specific business process. In this activity, the vendor documentation can be leveraged. Possible types of functional tests: normal case (positive); invalid case (negative); repeatability; performance; volume / charge; regression; structural tests;\n- User Requirements Tests that demonstrate the suitability for the intended use, which may include the conducting system functionality tests against pre-established requirements, depending on the risk involved;\n- The requirements tests must also include the delivery and acceptance of the complete documentation sent by the supplier, including specifications, manuals and drawings, if not yet done;\n- Any subsequent or more stringent tests carried out as a result of risk assessments and provider;\n- Any other relevant aspects listed in item 9.7.7.1.2.\n\n## 9.7.7.4 Testing Activities for a Custom Application\n\nSome computerized systems are developed to meet specific user requirements when there are no commercially available solutions. The *software* developed for such systems is classified as category 5 of the GAMP.\n\nIn such cases and based on the satisfactory assessment of the supplier and the risks involved, a testing based on the four levels (module design (unit); integration; functionality and requirements) is applicable.\n\nThe number of test documents needed to cover these four levels will depend on the complexity and system impact.\n\nTests should focus on the following points:\n\n- Those related to the installation of the system, described in item 9.7.7.1.1;\n- Revision of the new code, required as a result of the risk assessment;\n- Tests of *software* modules to verify that they conform to your design specifications - for each *Software* Module Design Specification, a *Software* Module Test Specification associated product must be produced. The *software* module tests to be performed must ensure that the software module meets specifications;\n- Software integration tests to test whether the modules work correctly when operating together - the Software Integration Test Specification defines those tests that demonstrate that all software modules communicate with each other correctly and that the software system meets the project specification. A Software Integration Test Specification must be produced when more than one software module composes the final system;\n- Configuration test (if applicable) - for each Configuration Specification, a Configuration Specification Associated Configuration test must be produced. Tests should verify that the system has been configured according to specification. Tests can take the form of inspections or verification of the provider;\n- Functional Tests - functionality that supports the specific business process based on risk and supplier assessments (This is an area where supplier documentation can be harnessed);\n- Requirements Tests (URS) - demonstrate that the system is suitable for the intended use; this can include carrying out tests of the system\u2019s functionality against predefined requirements, based on risk;", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas que se pueden formular a partir del contexto proporcionado, junto con respuestas espec\u00edficas que probablemente no se encuentren en otro lugar:\n\n1. **\u00bfQu\u00e9 tipos de pruebas funcionales se mencionan en la gu\u00eda de ANVISA y cu\u00e1l es su prop\u00f3sito?**\n   - La gu\u00eda de ANVISA menciona varios tipos de pruebas funcionales, que incluyen: pruebas de caso normal (positivo), pruebas de caso inv\u00e1lido (negativo), pruebas de repetibilidad, pruebas de rendimiento, pruebas de volumen/carga, pruebas de regresi\u00f3n y pruebas estructurales. El prop\u00f3sito de estas pruebas es asegurar que la funcionalidad del sistema soporte adecuadamente los procesos de negocio espec\u00edficos y que cumpla con los requisitos establecidos.\n\n2. **\u00bfQu\u00e9 se debe incluir en las pruebas de requisitos (URS) seg\u00fan la gu\u00eda?**\n   - Las pruebas de requisitos (URS) deben demostrar que el sistema es adecuado para el uso previsto. Esto incluye la realizaci\u00f3n de pruebas de funcionalidad del sistema contra requisitos preestablecidos, dependiendo del riesgo involucrado. Adem\u00e1s, deben incluir la entrega y aceptaci\u00f3n de la documentaci\u00f3n completa proporcionada por el proveedor, que incluye especificaciones, manuales y dibujos, si no se ha hecho previamente.\n\n3. **\u00bfCu\u00e1les son los niveles de prueba aplicables a una aplicaci\u00f3n personalizada seg\u00fan la gu\u00eda de ANVISA?**\n   - Para aplicaciones personalizadas, la gu\u00eda establece que se aplican pruebas basadas en cuatro niveles: dise\u00f1o del m\u00f3dulo (unidad), integraci\u00f3n, funcionalidad y requisitos. La cantidad de documentos de prueba necesarios para cubrir estos niveles depender\u00e1 de la complejidad y el impacto del sistema. Cada nivel tiene un enfoque espec\u00edfico, como la verificaci\u00f3n de que los m\u00f3dulos de software cumplen con las especificaciones de dise\u00f1o y que se comunican correctamente entre s\u00ed.\n\n### Resumen de nivel superior del contexto:\nLa gu\u00eda de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos establece directrices para realizar pruebas funcionales y de requisitos en sistemas que apoyan procesos de negocio espec\u00edficos. Se enfatiza la importancia de documentar y aceptar la documentaci\u00f3n del proveedor, as\u00ed como la necesidad de realizar pruebas en diferentes niveles para aplicaciones personalizadas. La gu\u00eda tambi\u00e9n destaca la importancia de realizar pruebas basadas en la evaluaci\u00f3n de riesgos y la complejidad del sistema.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Tipos de Sistemas**:\n   - **Sistemas \"off-the-shelf\"**: No configurados para un proceso espec\u00edfico, utilizados con configuraci\u00f3n predeterminada. Clasificados como **categor\u00eda 3 del GAMP**.\n   - **Sistemas Configurados**: Software comercial configurado para un proceso espec\u00edfico. Clasificados como **categor\u00eda 4 del GAMP**.\n\n2. **Actividades de Prueba**:\n   - **Para Productos No Configurados**:\n     - Evaluaci\u00f3n del proveedor para verificar la calidad del producto.\n     - Pruebas de instalaci\u00f3n del sistema.\n     - Pruebas de requisitos del usuario para demostrar la idoneidad para el uso previsto.\n     - Aceptaci\u00f3n de documentaci\u00f3n completa del proveedor (especificaciones, manuales, dibujos).\n     - Pruebas adicionales seg\u00fan el riesgo y evaluaciones del proveedor.\n\n   - **Para Productos Configurados**:\n     - Estrategia de prueba recomendada de tres niveles: **configuraci\u00f3n, funcionalidad y requisitos**.\n     - Pruebas de instalaci\u00f3n del sistema.\n     - Pruebas de configuraci\u00f3n asociadas a cada especificaci\u00f3n de configuraci\u00f3n.\n     - Verificaci\u00f3n de que el sistema se ha instalado de acuerdo con las especificaciones.\n\n3. **Aspectos Cr\u00edticos a Considerar**:\n   - Transacciones cr\u00edticas.\n   - Transferencia de datos cr\u00edticos.\n   - Interfaces y transferencia de datos.\n   - Copia de seguridad y restauraci\u00f3n.\n   - Archivado y recuperaci\u00f3n de datos.\n   - Capacidad para manejar cargas de alto volumen, especialmente en aplicaciones en red.\n\n### Entidades Clave:\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil.\n- **GAMP**: Buenas Pr\u00e1cticas de Automatizaci\u00f3n de Manufactura.\n- **Categor\u00edas de GAMP**: Clasificaci\u00f3n de sistemas seg\u00fan su configuraci\u00f3n y uso.\n\nEste resumen destaca los elementos esenciales sobre la validaci\u00f3n de sistemas inform\u00e1ticos seg\u00fan las directrices de ANVISA, enfoc\u00e1ndose en las diferencias entre sistemas no configurados y configurados, as\u00ed como en las actividades de prueba recomendadas para cada tipo.", "excerpt_keywords": "Keywords: ANVISA, Computer Systems Validation, Functional Tests, User Requirements, GAMP"}}, "2b801409-2af4-46dc-9dce-d78d0eb2d3b7": {"node_ids": ["df98e9a8-f727-4c83-9093-87e3f855b23e"], "metadata": {"page_label": "58", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 9.7.8 Test Report\n\nA test report must be generated that summarizes the activities carried out and the results obtained and that contains the final conclusions.\n\nThe approval of the test report constitutes the formal release of the system to perform the steps subsequent life cycle.\n\nTest reports must meet the requirements of the corresponding test specifications or in the case of a test summary report, must meet the requirements of the test strategy.\n\n# 9.8 COMPLEMENTARY ACTIVITIES\n\n## 9.8.1 System Description\n\n### 9.8.1.1 Introduction\n\nThis section seeks to meet a recurring regulatory requirement:\n\n\"There should be an updated and detailed description of the system, containing the principles, objectives, security, range of the system and its main characteristics of use, and the interface with other systems and procedures.\"\n\nThe need for a system description can be covered by one or more existing specifications or other documents or a separate document can be produced.\n\nThe main use of such a document is to help new users and regulators understand what the system does and how this is written in a non-technical language as far as possible.\n\n### 9.8.1.2 General Considerations\n\nThe System Description must be maintained for the life of the system.\n\nFor complex systems that are used by different departments or plants / sites (e.g., ERU) a separate document may be the most appropriate. For simpler systems it is common practice to include the description of the system in another specification or other document.\n\nA complete description of the system, which meets regulatory expectations, must be established before the system be released for operational use.\n\nThe system description should be subject to change control and periodic review.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos establece directrices sobre la generaci\u00f3n de informes de prueba y la descripci\u00f3n del sistema. Un informe de prueba debe resumir las actividades y resultados, y su aprobaci\u00f3n es necesaria para liberar formalmente el sistema. Adem\u00e1s, se requiere una descripci\u00f3n detallada y actualizada del sistema que cumpla con las expectativas regulatorias, la cual debe mantenerse durante toda la vida del sistema y estar sujeta a control de cambios y revisiones peri\u00f3dicas.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfQu\u00e9 elementos deben incluirse en un informe de prueba seg\u00fan las directrices de ANVISA?**\n   - Un informe de prueba debe resumir las actividades realizadas, los resultados obtenidos y las conclusiones finales. Adem\u00e1s, debe cumplir con los requisitos de las especificaciones de prueba correspondientes o, en el caso de un informe resumen de prueba, con los requisitos de la estrategia de prueba.\n\n2. **\u00bfCu\u00e1l es la importancia de la descripci\u00f3n del sistema en el contexto de la validaci\u00f3n de sistemas inform\u00e1ticos?**\n   - La descripci\u00f3n del sistema es crucial para ayudar a nuevos usuarios y reguladores a entender el funcionamiento del sistema. Debe ser escrita en un lenguaje no t\u00e9cnico y debe contener principios, objetivos, seguridad, alcance y caracter\u00edsticas principales del sistema, as\u00ed como su interfaz con otros sistemas y procedimientos.\n\n3. **\u00bfC\u00f3mo debe ser gestionada la descripci\u00f3n del sistema a lo largo de su ciclo de vida?**\n   - La descripci\u00f3n del sistema debe mantenerse actualizada durante toda la vida del sistema, estar sujeta a control de cambios y ser revisada peri\u00f3dicamente. Para sistemas complejos, puede ser m\u00e1s apropiado tener un documento separado, mientras que para sistemas m\u00e1s simples, es com\u00fan incluir la descripci\u00f3n en otra especificaci\u00f3n o documento.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Pruebas Funcionales**:\n   - Se enfocan en la funcionalidad que respalda procesos de negocio espec\u00edficos.\n   - Tipos de pruebas funcionales: \n     - Pruebas de caso normal (positivo)\n     - Pruebas de caso inv\u00e1lido (negativo)\n     - Pruebas de repetibilidad\n     - Pruebas de rendimiento\n     - Pruebas de volumen/carga\n     - Pruebas de regresi\u00f3n\n     - Pruebas estructurales\n\n2. **Pruebas de Requisitos del Usuario (URS)**:\n   - Demuestran la idoneidad del sistema para el uso previsto.\n   - Incluyen pruebas de funcionalidad contra requisitos preestablecidos, dependiendo del riesgo.\n   - Requieren la entrega y aceptaci\u00f3n de documentaci\u00f3n completa del proveedor (especificaciones, manuales, dibujos).\n\n3. **Actividades de Pruebas para Aplicaciones Personalizadas**:\n   - Aplican a sistemas desarrollados para satisfacer requisitos espec\u00edficos de usuarios.\n   - Clasificaci\u00f3n del software como categor\u00eda 5 de GAMP.\n   - Pruebas basadas en cuatro niveles:\n     - Dise\u00f1o del m\u00f3dulo (unidad)\n     - Integraci\u00f3n\n     - Funcionalidad\n     - Requisitos\n   - La cantidad de documentos de prueba depende de la complejidad y el impacto del sistema.\n\n4. **Enfoque de Pruebas**:\n   - Instalaci\u00f3n del sistema.\n   - Revisi\u00f3n de nuevo c\u00f3digo seg\u00fan evaluaci\u00f3n de riesgos.\n   - Verificaci\u00f3n de m\u00f3dulos de software contra especificaciones de dise\u00f1o.\n   - Pruebas de integraci\u00f3n de software para asegurar la comunicaci\u00f3n correcta entre m\u00f3dulos.\n   - Pruebas de configuraci\u00f3n, si son aplicables.\n   - Pruebas funcionales y de requisitos basadas en evaluaciones de riesgo.\n\n### Entidades Clave:\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria en Brasil.\n- **GAMP**: Buenas Pr\u00e1cticas de Automatizaci\u00f3n de Sistemas.\n- **Documentaci\u00f3n del Proveedor**: Especificaciones, manuales y dibujos necesarios para la validaci\u00f3n.\n- **Sistema Inform\u00e1tico**: Software desarrollado para procesos de negocio espec\u00edficos.\n\nEste resumen destaca los aspectos fundamentales de la gu\u00eda de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos, enfatizando la importancia de las pruebas funcionales y de requisitos, as\u00ed como la documentaci\u00f3n y evaluaci\u00f3n de riesgos en el proceso de validaci\u00f3n.", "excerpt_keywords": "Keywords: test report, system description, validation, regulatory requirements, change control"}}, "b4014e3b-c980-4a13-accb-cfe14b4ac16e": {"node_ids": ["0b0e083f-c19a-4c70-83ca-95b9ce9f4c7d"], "metadata": {"page_label": "59", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 9.8.1.3 Document Content\n\nThe description should cover only the main characteristics of the system. Detailed topic information must be included in other specifications and not repeated.\n\n## 9.8.1.3.1 Introduction\n\nThis part should explain the context of the system within the business process and the regulated company in general. This should be considered from the following perspectives:\n\n- Departmental;\n- Within the plant / site;\n- Within the division;\n- From a global point of view.\n\n## 9.8.1.3.2 Main System Functionality\n\nThis part includes the description of the key functions of the system, both in relation to BPx and non-BPx, many of which can be critical to the business.\n\nThe functions can be grouped to keep the description at a high level. The use of diagrams is encouraged to explain relationships between key functions.\n\n## 9.8.1.3.4 Computational Environment\n\nThis part should be covered by a high level diagram showing the architecture that supports the system, covering, where appropriate:\n\n- The infrastructure that supports the system (e.g., server configurations, storage arrangements etc.);\n- *Interfaces* for users;\n- *Interfaces* for equipment;\n- *Interfaces* for other systems;\n- *Interfaces* outside the company;\n- The flow of data through the *interfaces*;\n- Security features such as *firewalls*.\n\n## 9.8.1.3.5 System Components\n\nAn indication of the main *hardware* and *software components* must be provided. Must include information about servers and storage equipment, as well as operating systems, types of database and applications. You should refer to any configuration documentation relevant to the system.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas que pueden proporcionar respuestas espec\u00edficas basadas en el contexto proporcionado, as\u00ed como un resumen de nivel superior del contenido:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos establece directrices sobre c\u00f3mo describir las caracter\u00edsticas principales de un sistema dentro de un entorno regulado. Se enfatiza la importancia de contextualizar el sistema en el proceso empresarial, describir su funcionalidad clave, detallar el entorno computacional y enumerar los componentes del sistema, tanto de hardware como de software. Se sugiere el uso de diagramas para ilustrar relaciones y flujos de datos, as\u00ed como la inclusi\u00f3n de caracter\u00edsticas de seguridad.\n\n### Preguntas\n\n1. **\u00bfCu\u00e1les son las perspectivas espec\u00edficas desde las cuales se debe considerar el contexto del sistema dentro de la empresa regulada?**\n   - Respuesta: El contexto del sistema debe ser considerado desde las perspectivas departamental, dentro de la planta/sitio, dentro de la divisi\u00f3n y desde un punto de vista global.\n\n2. **\u00bfQu\u00e9 tipo de diagramas se recomienda utilizar para describir la funcionalidad del sistema y por qu\u00e9 son importantes?**\n   - Respuesta: Se recomienda el uso de diagramas para explicar las relaciones entre las funciones clave del sistema. Estos diagramas son importantes porque ayudan a mantener la descripci\u00f3n a un nivel alto y facilitan la comprensi\u00f3n de c\u00f3mo interact\u00faan las diferentes funciones.\n\n3. **\u00bfQu\u00e9 informaci\u00f3n debe incluirse al describir el entorno computacional del sistema y por qu\u00e9 es relevante?**\n   - Respuesta: El entorno computacional debe incluir un diagrama de alto nivel que muestre la arquitectura del sistema, incluyendo la infraestructura que lo soporta, las interfaces para usuarios y equipos, las interfaces con otros sistemas y la seguridad (como firewalls). Esta informaci\u00f3n es relevante porque proporciona una visi\u00f3n clara de c\u00f3mo se estructura el sistema y c\u00f3mo se gestionan los datos y la seguridad.", "prev_section_summary": "### Temas Clave\n\n1. **Informe de Prueba**:\n   - Debe resumir las actividades realizadas, los resultados obtenidos y las conclusiones finales.\n   - La aprobaci\u00f3n del informe es necesaria para la liberaci\u00f3n formal del sistema.\n   - Debe cumplir con los requisitos de las especificaciones de prueba o de la estrategia de prueba.\n\n2. **Descripci\u00f3n del Sistema**:\n   - Se requiere una descripci\u00f3n actualizada y detallada del sistema que incluya principios, objetivos, seguridad, alcance y caracter\u00edsticas principales, as\u00ed como la interfaz con otros sistemas.\n   - La descripci\u00f3n debe ser comprensible para nuevos usuarios y reguladores, utilizando un lenguaje no t\u00e9cnico.\n   - Debe mantenerse durante toda la vida del sistema, estar sujeta a control de cambios y revisiones peri\u00f3dicas.\n\n3. **Consideraciones Generales**:\n   - Para sistemas complejos, puede ser m\u00e1s adecuado tener un documento separado; para sistemas m\u00e1s simples, es com\u00fan incluir la descripci\u00f3n en otra especificaci\u00f3n.\n   - La descripci\u00f3n completa debe establecerse antes de que el sistema se libere para uso operativo.\n\n### Entidades\n\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil.\n- **Informe de Prueba**: Documento que resume las pruebas realizadas en el sistema.\n- **Descripci\u00f3n del Sistema**: Documento que detalla el funcionamiento y caracter\u00edsticas del sistema.\n- **Especificaciones de Prueba**: Requisitos que gu\u00edan la creaci\u00f3n del informe de prueba.\n- **Estrategia de Prueba**: Plan que define c\u00f3mo se llevar\u00e1n a cabo las pruebas del sistema.\n- **Control de Cambios**: Proceso para gestionar modificaciones en la documentaci\u00f3n del sistema.\n- **Revisi\u00f3n Peri\u00f3dica**: Evaluaci\u00f3n regular de la documentaci\u00f3n para asegurar su actualizaci\u00f3n y relevancia.", "excerpt_keywords": "Keywords: validation, system functionality, computational environment, hardware components, regulatory compliance"}}, "2e8ba283-1d95-4faa-ac5f-ed1096860f77": {"node_ids": ["d5ede07b-fd19-4ec4-b750-b1139c2bf665"], "metadata": {"page_label": "60", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# Guide for Computer Systems Validation\n\n## 9.8.1.3.6 System Interfaces\n\nThis part should include an overview of the **key interfaces** for other systems and equipment, as well as the flow of data between the systems involved.\n\n## 9.8.1.3.7 Access Control\n\nThis part should include an overview of the characteristics of access control to the system, both physical (if relevant) and logical.\n\n## 9.8.1.3.8 Security Controls\n\nThis part should include an overview of the established security controls, both physical and logical. These should include **software** to protect data and records, such as, for example, antivirus and anti-malware.\n\n## 9.8.1.3.9 Electronic records and signatures\n\nA description of the types of electronic records created and managed by the system and the types of electronic signatures used, if relevant.\n\n## 9.8.1.3.10 Glossaries\n\nDefinitions of any terms that are unfamiliar must be provided.\n\n## 9.8.2 Configuration and Change Management\n\nProcesses for configuration management must be established so that the system computerized and all its components can be identified and defined at any time.\n\nChange management procedures should also be established. The point or phase at which change management has been introduced must be defined. This management must be applied both for the design phase as well as for the operational phase.\n\nAny involvement of the supplier in these managements must be defined and agreed.\n\n## 9.8.3 Project Review", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "### Resumen del Contexto\n\nEl documento es una gu\u00eda de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos, que incluye secciones espec\u00edficas sobre interfaces del sistema, control de acceso, controles de seguridad, registros y firmas electr\u00f3nicas, gesti\u00f3n de configuraci\u00f3n y cambios, y revisi\u00f3n de proyectos. Cada secci\u00f3n aborda aspectos clave que deben considerarse para garantizar que los sistemas inform\u00e1ticos cumplan con los requisitos regulatorios y de seguridad.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfQu\u00e9 aspectos deben considerarse al describir las interfaces del sistema en el contexto de la validaci\u00f3n de sistemas inform\u00e1ticos?**\n   - La gu\u00eda sugiere que se debe proporcionar una visi\u00f3n general de las interfaces clave con otros sistemas y equipos, as\u00ed como el flujo de datos entre los sistemas involucrados.\n\n2. **\u00bfCu\u00e1les son los elementos esenciales que deben incluirse en los procedimientos de gesti\u00f3n de cambios seg\u00fan la gu\u00eda de ANVISA?**\n   - Los procedimientos de gesti\u00f3n de cambios deben establecerse y definir el punto o fase en la que se introduce la gesti\u00f3n de cambios, aplic\u00e1ndose tanto en la fase de dise\u00f1o como en la fase operativa. Tambi\u00e9n se debe acordar cualquier participaci\u00f3n del proveedor en estas gestiones.\n\n3. **\u00bfQu\u00e9 tipo de software se menciona en la gu\u00eda para proteger los datos y registros dentro de los controles de seguridad?**\n   - La gu\u00eda menciona que los controles de seguridad deben incluir software para proteger datos y registros, como antivirus y anti-malware.\n\n### Resumen de Nivel Superior\n\nLa gu\u00eda de ANVISA para la validaci\u00f3n de sistemas inform\u00e1ticos proporciona directrices sobre c\u00f3mo gestionar y validar sistemas que manejan datos electr\u00f3nicos, asegurando que se cumplan los est\u00e1ndares de seguridad y regulaci\u00f3n. Se enfoca en aspectos como la gesti\u00f3n de interfaces, control de acceso, seguridad de datos, y la importancia de la gesti\u00f3n de cambios y configuraciones en el ciclo de vida del sistema.", "prev_section_summary": "### Resumen de Temas Clave y Entidades de la Secci\u00f3n\n\n1. **Descripci\u00f3n General del Sistema**:\n   - Se debe proporcionar una descripci\u00f3n que abarque solo las caracter\u00edsticas principales del sistema, evitando la repetici\u00f3n de informaci\u00f3n detallada que debe incluirse en otras especificaciones.\n\n2. **Contexto del Sistema**:\n   - La introducci\u00f3n debe explicar el contexto del sistema dentro del proceso empresarial y la empresa regulada, considerando las siguientes perspectivas:\n     - Departamental\n     - Dentro de la planta/sitio\n     - Dentro de la divisi\u00f3n\n     - Desde un punto de vista global\n\n3. **Funcionalidad Principal del Sistema**:\n   - Se debe describir las funciones clave del sistema, tanto en relaci\u00f3n con BPx como con no-BPx, muchas de las cuales son cr\u00edticas para el negocio.\n   - Se sugiere agrupar las funciones para mantener una descripci\u00f3n de alto nivel y utilizar diagramas para ilustrar las relaciones entre las funciones clave.\n\n4. **Entorno Computacional**:\n   - Se debe incluir un diagrama de alto nivel que muestre la arquitectura del sistema, abarcando:\n     - Infraestructura que soporta el sistema (configuraciones de servidores, arreglos de almacenamiento, etc.)\n     - Interfaces para usuarios, equipos, otros sistemas y externas a la empresa\n     - Flujo de datos a trav\u00e9s de las interfaces\n     - Caracter\u00edsticas de seguridad, como firewalls\n\n5. **Componentes del Sistema**:\n   - Se debe proporcionar informaci\u00f3n sobre los principales componentes de hardware y software, incluyendo servidores, equipos de almacenamiento, sistemas operativos, tipos de bases de datos y aplicaciones.\n   - Se debe hacer referencia a cualquier documentaci\u00f3n de configuraci\u00f3n relevante para el sistema.\n\n### Entidades Clave\n- **Sistema**: Entidad central que se describe en t\u00e9rminos de sus caracter\u00edsticas y funcionalidades.\n- **Perspectivas**: Diferentes \u00e1ngulos desde los cuales se analiza el sistema (departamental, planta, divisi\u00f3n, global).\n- **Funciones**: Actividades clave que realiza el sistema, agrupadas para facilitar la comprensi\u00f3n.\n- **Entorno Computacional**: Arquitectura y componentes que soportan el sistema, incluyendo infraestructura y seguridad.\n- **Componentes**: Hardware y software que conforman el sistema, esenciales para su operaci\u00f3n.", "excerpt_keywords": "Keywords: validation, access control, security controls, electronic records, change management"}}, "3cdf8fcf-2031-486b-b62f-ccea0c169673": {"node_ids": ["089d5a2e-c302-430d-b7ea-a78a03b66994"], "metadata": {"page_label": "61", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "At appropriate stages of the life cycle, planned and systematic design reviews of the project specifications design and development must be carried out. This project review should assess the results to be obtained to ensure that they meet the specified requirements. Corrective actions must be defined and developed.\n\nThe rigor of the execution of the design review and the extension of the documentation must be based on risk, complexity and innovation.\n\n## 9.8.4 Documentation Management\n\nDocumentation management includes preparing, reviewing, approving, issuing, changing, withdrawing and archiving.\n\n----\n\n## 9.8.5 Traceability Matrix\n\nTraceability is a process for:\n\n- The requirements are addressed and traceable to the respective design and functional specifications.\n- The requirements are traceable to the respective checks.\n\nIn addition to demonstrating project and verification coverage, traceability helps with assessment and change management.\n\nTraceability should focus on aspects critical to patient safety, product quality and data integrity and is known as the Requirements Traceability Matrix.\n\nFor non-configured products, traceability between user requirements and the verification performed can be enough.\n\nFor configured products, the design specification column (Design Specification - DS) can be replaced by a connection to the configuration items, providing traceability between system requirements user, configuration and verification.\n\nFor customized applications, traceability must be presented from the project specification level, from functional specifications to verification of user requirements.\n\nFigure 6 shows an example of a traceability matrix, where AR stands for Risk Analysis.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos establece la importancia de realizar revisiones de dise\u00f1o sistem\u00e1ticas y planificadas a lo largo del ciclo de vida del proyecto. Estas revisiones deben evaluar si los resultados cumplen con los requisitos especificados y definir acciones correctivas cuando sea necesario. Adem\u00e1s, se aborda la gesti\u00f3n de la documentaci\u00f3n y la importancia de la trazabilidad, que asegura que los requisitos est\u00e9n claramente vinculados a las especificaciones de dise\u00f1o y a las verificaciones realizadas, con un enfoque en la seguridad del paciente, la calidad del producto y la integridad de los datos.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfQu\u00e9 criterios deben considerarse al determinar el rigor de la ejecuci\u00f3n de una revisi\u00f3n de dise\u00f1o seg\u00fan el documento de ANVISA?**\n   - El rigor de la ejecuci\u00f3n de la revisi\u00f3n de dise\u00f1o y la extensi\u00f3n de la documentaci\u00f3n deben basarse en el riesgo, la complejidad y la innovaci\u00f3n del proyecto.\n\n2. **\u00bfCu\u00e1l es la funci\u00f3n principal de la Matriz de Trazabilidad seg\u00fan el contexto del documento?**\n   - La Matriz de Trazabilidad tiene como funci\u00f3n principal asegurar que los requisitos est\u00e9n abordados y sean trazables a las especificaciones de dise\u00f1o y funcionales correspondientes, as\u00ed como a las verificaciones realizadas, lo que ayuda en la gesti\u00f3n de cambios y evaluaci\u00f3n del proyecto.\n\n3. **\u00bfC\u00f3mo se debe presentar la trazabilidad para aplicaciones personalizadas seg\u00fan el documento?**\n   - Para aplicaciones personalizadas, la trazabilidad debe presentarse desde el nivel de especificaci\u00f3n del proyecto, abarcando desde las especificaciones funcionales hasta la verificaci\u00f3n de los requisitos del usuario.", "prev_section_summary": "La secci\u00f3n del documento \"Gu\u00eda para la Validaci\u00f3n de Sistemas Inform\u00e1ticos\" de ANVISA aborda varios temas clave relacionados con la validaci\u00f3n y gesti\u00f3n de sistemas que manejan datos electr\u00f3nicos. A continuaci\u00f3n se resumen los puntos m\u00e1s importantes:\n\n### Temas Clave\n\n1. **Interfaces del Sistema**:\n   - Importancia de describir las interfaces clave con otros sistemas y equipos.\n   - Necesidad de detallar el flujo de datos entre los sistemas involucrados.\n\n2. **Control de Acceso**:\n   - Revisi\u00f3n de las caracter\u00edsticas del control de acceso al sistema, tanto f\u00edsico como l\u00f3gico.\n\n3. **Controles de Seguridad**:\n   - Descripci\u00f3n de los controles de seguridad establecidos, incluyendo software para la protecci\u00f3n de datos y registros, como antivirus y anti-malware.\n\n4. **Registros y Firmas Electr\u00f3nicas**:\n   - Identificaci\u00f3n de los tipos de registros electr\u00f3nicos creados y gestionados por el sistema, as\u00ed como los tipos de firmas electr\u00f3nicas utilizadas.\n\n5. **Glosarios**:\n   - Inclusi\u00f3n de definiciones para t\u00e9rminos que puedan ser desconocidos.\n\n6. **Gesti\u00f3n de Configuraci\u00f3n y Cambios**:\n   - Establecimiento de procesos para la gesti\u00f3n de configuraci\u00f3n, asegurando que todos los componentes del sistema puedan ser identificados y definidos.\n   - Procedimientos de gesti\u00f3n de cambios que deben aplicarse en las fases de dise\u00f1o y operativa, incluyendo la participaci\u00f3n del proveedor.\n\n7. **Revisi\u00f3n de Proyectos**:\n   - Aunque no se detalla en el extracto, se menciona que debe haber un proceso de revisi\u00f3n de proyectos.\n\n### Entidades\n\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil, responsable de la regulaci\u00f3n de sistemas inform\u00e1ticos en el \u00e1mbito de la salud.\n- **Sistemas Inform\u00e1ticos**: Sistemas que manejan datos electr\u00f3nicos y requieren validaci\u00f3n para cumplir con est\u00e1ndares regulatorios.\n- **Controles de Seguridad**: Medidas implementadas para proteger la integridad y confidencialidad de los datos.\n- **Registros Electr\u00f3nicos**: Documentos digitales que son creados y gestionados por el sistema.\n- **Firmas Electr\u00f3nicas**: M\u00e9todos utilizados para autenticar la identidad de los firmantes en documentos electr\u00f3nicos.\n\nEste resumen proporciona una visi\u00f3n general de los aspectos cr\u00edticos que deben considerarse para garantizar la validaci\u00f3n adecuada de los sistemas inform\u00e1ticos seg\u00fan las directrices de ANVISA.", "excerpt_keywords": "Keywords: validation, traceability, documentation management, design review, patient safety"}}, "5e8d9b11-53e2-4e2b-878b-6bf424bf98da": {"node_ids": ["bef21dec-6bab-4dae-93a1-1eeebec9f706"], "metadata": {"page_label": "62", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 9.9 VALIDATION REPORT\n\n## 9.9.1 Introduction\n\nA validation report with a focus on aspects related to patient safety, product quality and data integrity. It should summarize the activities performed, any deviations occurred in relation to what was planned, the most important corrective actions and a statement about the service of the system to the intended use.\n\nThe level of detail in the report should reflect the risk, complexity and innovation of the system.\n\nThe structure of the report should reflect the structure of the corresponding plan.\n\nThe report must be approved by at least the process owner and the Quality Unit. May also it is appropriate that other approvers of the corresponding plan also approve the report, such as the owner of the system.\n\nIt is common to produce a final report. However, there may be other reports (partial or phases of the validation) that feed into this final report or that is created later to supplement it.\n\n## 9.9.2 Contents of the Computerized System Validation Report\n\n### 9.9.2.1 Introduction and Scope\n\nThe introduction should reflect the corresponding plan and highlight what differences may have arisen since the plan was issued. It should contain the following information:\n\n- Purpose and scope of the report;\n- Who drafted the report and under what authority;\n- Summary of the approach used;\n- Cross-reference to the plans, procedures and policies that guided the report.\n\n### 9.9.2.2 Scope Changes\n\nIt may be necessary to change the initial approach. The report must highlight and justify such changes in scope.\n\n### 9.9.2.3 Supplier Evaluation\n\n----\n\n*Figure 6. Example of a Traceability Matrix.*\n*Source: GAMP5*\n\n*Guide for Computer Systems Validation*\n*Guide n\u00b0 33/2020 - version 1, of 03/26/2020*", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas computacionales establece directrices para la elaboraci\u00f3n de un informe de validaci\u00f3n. Este informe debe centrarse en la seguridad del paciente, la calidad del producto y la integridad de los datos. Debe resumir las actividades realizadas, las desviaciones respecto al plan inicial, las acciones correctivas m\u00e1s importantes y una declaraci\u00f3n sobre el uso del sistema. La estructura del informe debe reflejar la del plan correspondiente y debe ser aprobado por el propietario del proceso y la Unidad de Calidad, entre otros.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfQu\u00e9 aspectos deben ser considerados al redactar la introducci\u00f3n del informe de validaci\u00f3n?**\n   - La introducci\u00f3n debe reflejar el plan correspondiente y destacar las diferencias que hayan surgido desde su emisi\u00f3n. Debe incluir el prop\u00f3sito y alcance del informe, qui\u00e9n lo redact\u00f3 y bajo qu\u00e9 autoridad, un resumen del enfoque utilizado y referencias cruzadas a los planes, procedimientos y pol\u00edticas que guiaron el informe.\n\n2. **\u00bfQu\u00e9 se debe hacer si hay cambios en el alcance del informe de validaci\u00f3n?**\n   - Si es necesario cambiar el enfoque inicial, el informe debe resaltar y justificar dichos cambios en el alcance.\n\n3. **\u00bfQui\u00e9nes deben aprobar el informe de validaci\u00f3n y por qu\u00e9 es importante esta aprobaci\u00f3n?**\n   - El informe debe ser aprobado por al menos el propietario del proceso y la Unidad de Calidad. Tambi\u00e9n puede ser apropiado que otros aprobadores del plan correspondiente lo firmen, como el propietario del sistema. Esta aprobaci\u00f3n es importante para garantizar que el informe cumpla con los est\u00e1ndares de calidad y seguridad requeridos.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Revisiones de Dise\u00f1o**: \n   - Importancia de realizar revisiones sistem\u00e1ticas y planificadas a lo largo del ciclo de vida del proyecto.\n   - Evaluaci\u00f3n de resultados para asegurar el cumplimiento de requisitos especificados.\n   - Definici\u00f3n y desarrollo de acciones correctivas.\n\n2. **Criterios para la Ejecuci\u00f3n de Revisiones**:\n   - El rigor y la extensi\u00f3n de la documentaci\u00f3n deben basarse en:\n     - **Riesgo**\n     - **Complejidad**\n     - **Innovaci\u00f3n**\n\n3. **Gesti\u00f3n de Documentaci\u00f3n**:\n   - Incluye procesos de preparaci\u00f3n, revisi\u00f3n, aprobaci\u00f3n, emisi\u00f3n, cambio, retiro y archivo de documentos.\n\n4. **Matriz de Trazabilidad**:\n   - Asegura que los requisitos est\u00e9n vinculados a las especificaciones de dise\u00f1o y funcionales, as\u00ed como a las verificaciones realizadas.\n   - Facilita la gesti\u00f3n de cambios y la evaluaci\u00f3n del proyecto.\n   - Enfoque en aspectos cr\u00edticos como:\n     - **Seguridad del paciente**\n     - **Calidad del producto**\n     - **Integridad de los datos**\n\n5. **Tipos de Productos y Trazabilidad**:\n   - **Productos no configurados**: Trazabilidad entre requisitos del usuario y verificaciones puede ser suficiente.\n   - **Productos configurados**: La columna de especificaci\u00f3n de dise\u00f1o puede conectarse a los elementos de configuraci\u00f3n.\n   - **Aplicaciones personalizadas**: Trazabilidad desde el nivel de especificaci\u00f3n del proyecto hasta la verificaci\u00f3n de requisitos del usuario.\n\n### Entidades Clave\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil.\n- **Matriz de Trazabilidad**: Herramienta para asegurar la conexi\u00f3n entre requisitos y verificaciones.\n- **Documentaci\u00f3n**: Conjunto de documentos que deben ser gestionados a lo largo del ciclo de vida del proyecto.\n- **Riesgo, Complejidad e Innovaci\u00f3n**: Criterios que influyen en la ejecuci\u00f3n de revisiones de dise\u00f1o.\n\nEste resumen destaca la importancia de la planificaci\u00f3n y la sistematizaci\u00f3n en la validaci\u00f3n de sistemas inform\u00e1ticos, as\u00ed como la necesidad de una gesti\u00f3n adecuada de la documentaci\u00f3n y la trazabilidad para garantizar la calidad y seguridad en el desarrollo de productos.", "excerpt_keywords": "Keywords: validation report, patient safety, data integrity, quality assurance, computerized systems"}}, "cde9d584-3ead-480f-9958-8d1ab94189de": {"node_ids": ["4cdb5f35-36f8-4bf1-86ed-8c4c4244da9f"], "metadata": {"page_label": "63", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "Supplier assessment activities should be summarized or referenced to other source documents, such as a Supplier Assessment or Audit Report.\n\nIf the supplier's documentation has been used / used, there should be a discussion about the measures taken to ensure their suitability.\n\nInformation already available in other documents should not be repeated.\n\nContent of audit reports at the supplier should not be included in the validation report.\n\n## 9.9.2.4 Summary of Activities\n\nThe summary must refer to the existing documentation and there should be no duplication of information.\n\nThis section can include subsections relevant to each phase.\n\n## 9.9.2.5 Summary of Results Obtained\n\nThe report must verify that all the results expected in the corresponding validation plan have been obtained and approved. This includes the system development documentation and Operating Procedures Standard (POP) required for operational support.\n\n----\n\n## 9.9.2.6 Summary of Deviations and Corrective Actions\n\nThe report should describe any activities and results that did not meet the specified expectations in the plan and explain its impact and the respective corrective actions. The most important corrective actions should be highlighted and appropriate next steps identified or referenced.\n\n## 9.9.2.7 Declaration of Suitability for Intended Use\n\nThere must be a clear statement about the status of the system and whether it is suitable for its intended use, taking mind any major deviations or corrective actions.\n\n## 9.9.2.8 Training\n\nThe report must verify that the personnel involved with the new processes, equipment or systems have been trained and that this training has been documented.\n\n## 9.9.2.9 Maintenance of Service and Adequacy to the Intended Use\n\nThe report should outline how the system's service situation will be maintained. This can be efficiently achieved by referencing the relevant policies and procedures. See the documents.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas que se pueden formular a partir del contexto proporcionado, junto con sus respuestas espec\u00edficas:\n\n### Preguntas y Respuestas\n\n1. **\u00bfQu\u00e9 debe incluirse en la secci\u00f3n de \"Resumen de Resultados Obtenidos\" del informe de validaci\u00f3n?**\n   - La secci\u00f3n de \"Resumen de Resultados Obtenidos\" debe verificar que todos los resultados esperados en el plan de validaci\u00f3n correspondiente han sido obtenidos y aprobados. Esto incluye la documentaci\u00f3n de desarrollo del sistema y los Procedimientos Operativos Est\u00e1ndar (POP) necesarios para el soporte operativo.\n\n2. **\u00bfC\u00f3mo debe abordarse la capacitaci\u00f3n del personal en el informe de validaci\u00f3n?**\n   - El informe debe verificar que el personal involucrado con los nuevos procesos, equipos o sistemas ha recibido capacitaci\u00f3n y que esta capacitaci\u00f3n ha sido documentada adecuadamente.\n\n3. **\u00bfQu\u00e9 se debe hacer si hay desviaciones en los resultados esperados seg\u00fan el plan de validaci\u00f3n?**\n   - Si hay desviaciones en los resultados esperados, el informe debe describir las actividades y resultados que no cumplieron con las expectativas especificadas en el plan, explicar su impacto y detallar las acciones correctivas correspondientes. Las acciones correctivas m\u00e1s importantes deben ser destacadas y se deben identificar o referenciar los pasos siguientes apropiados.\n\n### Resumen de Nivel Superior\n\nEl contexto se centra en las directrices de ANVISA para la validaci\u00f3n de sistemas inform\u00e1ticos, destacando la importancia de la documentaci\u00f3n y la capacitaci\u00f3n en el proceso de validaci\u00f3n. Se enfatiza que la informaci\u00f3n no debe duplicarse y que los informes deben ser claros sobre la adecuaci\u00f3n del sistema para su uso previsto, as\u00ed como sobre cualquier desviaci\u00f3n y las acciones correctivas tomadas. Adem\u00e1s, se menciona la necesidad de mantener la situaci\u00f3n del servicio del sistema y documentar la capacitaci\u00f3n del personal involucrado.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n**Temas Clave:**\n\n1. **Informe de Validaci\u00f3n:**\n   - Enfocado en la seguridad del paciente, calidad del producto e integridad de los datos.\n   - Debe resumir actividades realizadas, desviaciones del plan, acciones correctivas y declaraci\u00f3n sobre el uso del sistema.\n\n2. **Estructura del Informe:**\n   - Debe reflejar la estructura del plan correspondiente.\n   - Aprobaci\u00f3n requerida por el propietario del proceso y la Unidad de Calidad, con posibilidad de incluir otros aprobadores.\n\n3. **Contenido del Informe:**\n   - Introducci\u00f3n y alcance que refleje el plan y diferencias desde su emisi\u00f3n.\n   - Justificaci\u00f3n de cambios en el alcance si es necesario.\n   - Evaluaci\u00f3n de proveedores como parte del proceso.\n\n4. **Aprobaci\u00f3n del Informe:**\n   - Importancia de la aprobaci\u00f3n para asegurar el cumplimiento de est\u00e1ndares de calidad y seguridad.\n\n**Entidades:**\n\n- **ANVISA:** Agencia Nacional de Vigilancia Sanitaria de Brasil, responsable de la regulaci\u00f3n.\n- **Proceso Owner:** Propietario del proceso que debe aprobar el informe.\n- **Quality Unit:** Unidad de Calidad que tambi\u00e9n debe aprobar el informe.\n- **Sistema Computacional:** El sistema que est\u00e1 siendo validado y evaluado en el informe.\n- **GAMP5:** Referencia a las buenas pr\u00e1cticas en la validaci\u00f3n de sistemas computacionales.\n\nEste resumen destaca los elementos esenciales que deben considerarse al elaborar un informe de validaci\u00f3n de sistemas computacionales seg\u00fan las directrices de ANVISA.", "excerpt_keywords": "Keywords: validation report, supplier assessment, corrective actions, training documentation, system suitability"}}, "bd3d8e62-05ce-492b-9ca6-df5e7f6ba34a": {"node_ids": ["82e2cd1a-7363-451b-87ef-6d62ff681e10"], "metadata": {"page_label": "64", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "9.9.2.10 Glossary\n\nDefinitions of any little-known terms should be provided.\n\n9.9.2.11 Appendices\n\nThere may be a need for the existence of appendices, depending on the purpose, size and complexity of the report, the corporate style of the regulated company and its policies adopted for the preparation of reports.\n\n# 10. INVENTORY LIST\n\nRegulated companies must maintain an inventory of computer systems.\n\nThe inventory must present summary information about each system, describing: name of the system; associated equipment or application; impact / criticality in relation to BPx; GAMP category; ownership (sector, system owner, process owner); current version; provider; validation situation.\n\nAutomated equipment can be listed separately and duplication must be avoided.\n\nThe inventory should cover the level of systems that support business processes and not items individual *hardware* (components) that must be covered by local industry procedures information technology.\n\nThis inventory can be used for planning periodic reviews.\n\n# 11. OPERATIONAL PHASE OF COMPUTERIZED SYSTEMS\n\n## 11.1 INTRODUCTION\n\nThis section deals with the phase of the system's life cycle subsequent to its validation, in which the system validated computer is released for use by the end user.\n\nThe operational phase can take many years and can include changing *software*, *hardware*, business and regulatory requirements. The integrity of the system and its data must be maintained throughout period of use, including when retired, and must be verified when periodic review.\n\nAs experience is gained with the computerized system, improvement opportunities for the process and system, based on periodic review, evaluation of operational and performance data, in the analysis of the root causes of the failures that occurred. Information obtained incident management processes and CAPA's can provide relevant data for the system evaluation.\n\nChange management should provide a mechanism for the immediate adoption of improvements.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas que se pueden responder espec\u00edficamente con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos establece directrices para la gesti\u00f3n y mantenimiento de sistemas inform\u00e1ticos en empresas reguladas. Se enfatiza la importancia de mantener un inventario detallado de los sistemas, que incluya informaci\u00f3n cr\u00edtica como el nombre del sistema, su impacto, la categor\u00eda GAMP, y la situaci\u00f3n de validaci\u00f3n. Adem\u00e1s, se aborda la fase operativa de los sistemas, que sigue a su validaci\u00f3n, destacando la necesidad de mantener la integridad del sistema y sus datos a lo largo de su ciclo de vida, as\u00ed como la importancia de la gesti\u00f3n de cambios y la mejora continua basada en la revisi\u00f3n peri\u00f3dica y el an\u00e1lisis de datos operativos.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfQu\u00e9 informaci\u00f3n debe incluirse en el inventario de sistemas inform\u00e1ticos seg\u00fan la gu\u00eda de ANVISA?**\n   - La gu\u00eda establece que el inventario debe incluir el nombre del sistema, el equipo o aplicaci\u00f3n asociada, el impacto/cr\u00edtica en relaci\u00f3n con BPx, la categor\u00eda GAMP, la propiedad (sector, propietario del sistema, propietario del proceso), la versi\u00f3n actual, el proveedor y la situaci\u00f3n de validaci\u00f3n.\n\n2. **\u00bfC\u00f3mo se debe manejar la integridad de los sistemas inform\u00e1ticos durante su fase operativa?**\n   - La integridad del sistema y sus datos debe mantenerse durante todo el per\u00edodo de uso, incluso cuando el sistema es retirado. Esto incluye la verificaci\u00f3n de la integridad durante las revisiones peri\u00f3dicas y la implementaci\u00f3n de mejoras basadas en la experiencia adquirida y el an\u00e1lisis de datos operativos.\n\n3. **\u00bfCu\u00e1l es el prop\u00f3sito de la gesti\u00f3n de cambios en el contexto de los sistemas inform\u00e1ticos validados?**\n   - La gesti\u00f3n de cambios debe proporcionar un mecanismo para la adopci\u00f3n inmediata de mejoras en el sistema, asegurando que cualquier cambio necesario se implemente de manera eficiente y que se mantenga la conformidad con los requisitos regulatorios y de negocio.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Actividades de Evaluaci\u00f3n de Proveedores**:\n   - Resumen o referencia a documentos de evaluaci\u00f3n o auditor\u00eda de proveedores.\n   - Discusi\u00f3n sobre la idoneidad de la documentaci\u00f3n del proveedor utilizada.\n\n2. **Resumen de Actividades**:\n   - Debe referirse a la documentaci\u00f3n existente sin duplicar informaci\u00f3n.\n   - Puede incluir subsecciones relevantes a cada fase del proceso.\n\n3. **Resumen de Resultados Obtenidos**:\n   - Verificaci\u00f3n de que se han obtenido y aprobado todos los resultados esperados seg\u00fan el plan de validaci\u00f3n.\n   - Incluye documentaci\u00f3n de desarrollo del sistema y Procedimientos Operativos Est\u00e1ndar (POP).\n\n4. **Resumen de Desviaciones y Acciones Correctivas**:\n   - Descripci\u00f3n de actividades y resultados que no cumplieron con las expectativas.\n   - Explicaci\u00f3n del impacto y acciones correctivas, destacando las m\u00e1s importantes.\n\n5. **Declaraci\u00f3n de Idoneidad para el Uso Previsto**:\n   - Declaraci\u00f3n clara sobre el estado del sistema y su idoneidad para el uso previsto, considerando desviaciones y acciones correctivas.\n\n6. **Capacitaci\u00f3n**:\n   - Verificaci\u00f3n de que el personal ha sido capacitado en nuevos procesos, equipos o sistemas, y que esta capacitaci\u00f3n est\u00e1 documentada.\n\n7. **Mantenimiento del Servicio y Adecuaci\u00f3n al Uso Previsto**:\n   - Descripci\u00f3n de c\u00f3mo se mantendr\u00e1 la situaci\u00f3n del servicio del sistema, referenciando pol\u00edticas y procedimientos relevantes.\n\n### Entidades Clave\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil.\n- **Proveedores**: Entidades que suministran productos o servicios.\n- **Documentaci\u00f3n**: Informes, procedimientos y registros relacionados con la validaci\u00f3n.\n- **Personal**: Empleados involucrados en los nuevos procesos o sistemas.\n- **Sistema**: Software o hardware que se est\u00e1 validando para su uso en operaciones. \n\nEste resumen destaca la importancia de la documentaci\u00f3n, la capacitaci\u00f3n y la gesti\u00f3n de desviaciones en el proceso de validaci\u00f3n de sistemas inform\u00e1ticos seg\u00fan las directrices de ANVISA.", "excerpt_keywords": "Keywords: validation, inventory, operational phase, change management, regulatory compliance"}}, "82e0a5f5-c0c5-40f8-bf7a-8087c49d713f": {"node_ids": ["cb8b5958-df63-4c4e-b8cc-5740f607474b"], "metadata": {"page_label": "65", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "Table 3 presents the necessary procedures for the smooth running of the operational phase of the system computerized.\n\n### Table 3. Operating Procedures Associated with the Operating Phase of the System.\n\n| Process Groups                        | Procedures                                                                 | Section |\n|---------------------------------------|----------------------------------------------------------------------------|---------|\n| Delivery                              | \u2022 Delivery Process                                                         | 11.2    |\n| Management of Service and Performance | \u2022 Establishment and Management Services Support                            | 11.3    |\n| of performance                        | \u2022 Monitoring in Performance                                                | 11.4    |\n| Management of Incidents and CAPA      | \u2022 Management in Incidents                                                  | 11.5    |\n|                                       | \u2022 COVER                                                                    | 11.6    |\n| Management of Changes                 | \u2022 Management in Changes and Configuration System                           | 11.7    |\n| Audits and Review                     | \u2022 Repair Activities                                                        | 11.8    |\n|                                       | \u2022 Periodic Review                                                          | 11.9    |\n|                                       | \u2022 Internal Audits                                                          | 11.10   |\n| Management Continuity                 | \u2022 Backup and Restore                                                       |         |\n|                                       | \u2022 Business Continuity and Disaster Recovery                                | 11.11   |\n|                                       | \u2022 Management gives Safety                                                  | 11.12   |\n| Security and Administration of System | \u2022 Administration of System                                                 | 11.13   |\n| Management of Records                 | \u2022 Retention, Archiving and Recovery                                        | 11.14   |\n\n----\n\n### 11.2 SYSTEM DELIVERY\n\n#### 11.2.1 Introduction\n\nSystem delivery is the process of transferring responsibility from the system, the project team or a service group for the end user. It is an important process, as achieving compliance and suitability for the intended use alone are not sufficient to ensure a successful transfer to the operational phase.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos detalla los procedimientos necesarios para garantizar el funcionamiento adecuado de la fase operativa de un sistema. En la Tabla 3, se enumeran diferentes grupos de procesos y procedimientos asociados, que incluyen la entrega del sistema, la gesti\u00f3n del servicio y el rendimiento, la gesti\u00f3n de incidentes, cambios, auditor\u00edas, continuidad del negocio, seguridad y administraci\u00f3n del sistema, as\u00ed como la gesti\u00f3n de registros. Cada uno de estos grupos de procesos tiene secciones espec\u00edficas que abordan aspectos cr\u00edticos para el mantenimiento y la operaci\u00f3n efectiva del sistema.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfCu\u00e1les son los procedimientos asociados con la gesti\u00f3n de incidentes y CAPA seg\u00fan la Tabla 3?**\n   - Respuesta: Los procedimientos asociados con la gesti\u00f3n de incidentes y CAPA son: \"Gesti\u00f3n en Incidentes\" (11.5) y \"COVER\" (11.6).\n\n2. **\u00bfQu\u00e9 se entiende por el proceso de entrega del sistema y por qu\u00e9 es importante?**\n   - Respuesta: El proceso de entrega del sistema es la transferencia de responsabilidad del sistema, el equipo del proyecto o un grupo de servicio al usuario final. Es importante porque, aunque se logre la conformidad y la idoneidad para el uso previsto, esto no es suficiente para garantizar una transferencia exitosa a la fase operativa.\n\n3. **\u00bfQu\u00e9 procedimientos se mencionan en relaci\u00f3n con la continuidad del negocio y la recuperaci\u00f3n ante desastres?**\n   - Respuesta: Los procedimientos mencionados en relaci\u00f3n con la continuidad del negocio y la recuperaci\u00f3n ante desastres son: \"Business Continuity and Disaster Recovery\" (11.11) y \"Backup and Restore\" (sin secci\u00f3n especificada).", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Inventario de Sistemas Inform\u00e1ticos**:\n   - **Requisito**: Las empresas reguladas deben mantener un inventario de sistemas inform\u00e1ticos.\n   - **Contenido del Inventario**: \n     - Nombre del sistema\n     - Equipos o aplicaciones asociadas\n     - Impacto/cr\u00edtica en relaci\u00f3n con BPx\n     - Categor\u00eda GAMP\n     - Propiedad (sector, propietario del sistema, propietario del proceso)\n     - Versi\u00f3n actual\n     - Proveedor\n     - Situaci\u00f3n de validaci\u00f3n\n   - **Objetivo**: Facilitar la planificaci\u00f3n de revisiones peri\u00f3dicas y evitar duplicaciones.\n\n2. **Fase Operativa de Sistemas Inform\u00e1ticos**:\n   - **Definici\u00f3n**: Se refiere a la etapa del ciclo de vida del sistema que sigue a su validaci\u00f3n, donde el sistema se libera para uso por parte del usuario final.\n   - **Duraci\u00f3n**: Puede extenderse por muchos a\u00f1os e incluir cambios en software, hardware, y requisitos de negocio y regulatorios.\n   - **Mantenimiento de la Integridad**: Es crucial mantener la integridad del sistema y sus datos durante todo el per\u00edodo de uso, incluyendo su retiro.\n   - **Revisi\u00f3n Peri\u00f3dica**: Se debe verificar la integridad del sistema durante las revisiones peri\u00f3dicas.\n   - **Mejora Continua**: Se deben identificar oportunidades de mejora basadas en la revisi\u00f3n peri\u00f3dica y el an\u00e1lisis de datos operativos.\n   - **Gesti\u00f3n de Cambios**: Debe facilitar la adopci\u00f3n inmediata de mejoras en el sistema.\n\n### Entidades Clave\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil, responsable de la regulaci\u00f3n.\n- **BPx**: Referencia a un contexto espec\u00edfico de impacto o criticidad en el \u00e1mbito regulatorio.\n- **GAMP**: Buenas Pr\u00e1cticas de Automatizaci\u00f3n y Validaci\u00f3n de Sistemas.\n- **CAPA**: Acciones Correctivas y Preventivas, utilizadas para la gesti\u00f3n de incidentes y mejoras.\n\nEste resumen destaca la importancia de un inventario detallado y la gesti\u00f3n adecuada de la fase operativa para asegurar la conformidad y la mejora continua en los sistemas inform\u00e1ticos regulados.", "excerpt_keywords": "Keywords: ANVISA, Computer Systems Validation, Operational Phase, Management Procedures, System Delivery"}}, "01f24c7d-c222-482c-b65d-76cdf7b38555": {"node_ids": ["f056e0a6-30d6-4501-9f61-5ee7bb05c9f4"], "metadata": {"page_label": "66", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "The delivery process usually involves the project team (development group and/or supplier), the owner of the process, owner of the system and the quality unit.\n\n## 11.2.2 Key requirements\n\nThe regulated company must be able to demonstrate formal acceptance of the system after testing and controlled transfer to the operating environment of the work routine. This activity should be documented.\n\n## 11.2.3 Responsibilities\n\nThe project manager is responsible for preparing the system for delivery. The owner of the process and the owner of the system are responsible for accepting the system for operational use.\n\nResponsibility for completing any exceptional actions at the time of delivery should be agreed between the parts.\n\nConsideration should be given to defining a period for monitoring the system after its delivery and a reversal/return strategy in the event of a significant problem occurring during the monitoring period.\n\n## 11.2.4 Execution of the Delivery Activity\n\nThe company should define the scope, including configuration items, the period for delivery to occur and the acceptance criteria.\n\nThen you must establish a plan for delivery, which can be a separate document or be part of the Validation Plan. A checklist can be used to ensure acceptance and transfer of responsibilities.\n\nThe next step is to carry out the activities to deliver the system to the receiving group.\n\nAn agreement must be established between the parties for the conclusion (justified) or transfer of any open questions and incomplete activities or documentation from the design environment to the environment operational. For the delivery to be successful, critical deviations cannot persist.\n\nA report must be prepared, signed by the transferring group and the receiving group. This document may be part of the System Validation Report.\n\n## 11.3 SUPPORT SERVICE MANAGEMENT\n\n### 11.3.1 Introduction\n\nSupport Services Establishment and Management activities ensure that", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la Validaci\u00f3n de Sistemas Inform\u00e1ticos establece un proceso de entrega que involucra a varios actores, incluyendo el equipo del proyecto, el propietario del proceso, el propietario del sistema y la unidad de calidad. Se enfatiza la importancia de la aceptaci\u00f3n formal del sistema despu\u00e9s de las pruebas y la transferencia controlada al entorno operativo. Tambi\u00e9n se detallan las responsabilidades de los involucrados, la ejecuci\u00f3n de la actividad de entrega y la necesidad de documentaci\u00f3n adecuada para asegurar que no persistan desviaciones cr\u00edticas.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfCu\u00e1les son los pasos clave que deben seguirse para garantizar una entrega exitosa del sistema?**\n   - La entrega exitosa del sistema requiere definir el alcance, establecer un plan de entrega, realizar actividades de entrega, acordar la conclusi\u00f3n de preguntas abiertas y preparar un informe firmado por ambas partes.\n\n2. **\u00bfQu\u00e9 documentaci\u00f3n es necesaria para formalizar la aceptaci\u00f3n del sistema despu\u00e9s de la entrega?**\n   - Es necesario documentar la aceptaci\u00f3n formal del sistema, que puede incluir un informe que sea parte del Sistema de Validaci\u00f3n, as\u00ed como un plan de entrega que contenga criterios de aceptaci\u00f3n y un checklist para asegurar la transferencia de responsabilidades.\n\n3. **\u00bfQu\u00e9 consideraciones deben tenerse en cuenta para el monitoreo del sistema despu\u00e9s de su entrega?**\n   - Se debe definir un per\u00edodo de monitoreo post-entrega y establecer una estrategia de reversi\u00f3n en caso de que surjan problemas significativos durante este per\u00edodo. Adem\u00e1s, es importante acordar la responsabilidad de cualquier acci\u00f3n excepcional que deba completarse en el momento de la entrega.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos aborda procedimientos esenciales para asegurar el funcionamiento efectivo de la fase operativa de un sistema. A continuaci\u00f3n se presentan los temas clave y entidades relevantes:\n\n1. **Procedimientos Operativos**: La Tabla 3 enumera los grupos de procesos y sus procedimientos asociados, que son fundamentales para la operaci\u00f3n del sistema. Los grupos incluyen:\n   - **Entrega**: Proceso de entrega del sistema (Secci\u00f3n 11.2).\n   - **Gesti\u00f3n de Servicio y Rendimiento**: Establecimiento y gesti\u00f3n del soporte de servicios (Secci\u00f3n 11.3) y monitoreo del rendimiento (Secci\u00f3n 11.4).\n   - **Gesti\u00f3n de Incidentes y CAPA**: Manejo de incidentes (Secci\u00f3n 11.5) y procedimientos de \"COVER\" (Secci\u00f3n 11.6).\n   - **Gesti\u00f3n de Cambios**: Manejo de cambios y configuraci\u00f3n del sistema (Secci\u00f3n 11.7).\n   - **Auditor\u00edas y Revisi\u00f3n**: Actividades de reparaci\u00f3n (Secci\u00f3n 11.8), revisi\u00f3n peri\u00f3dica (Secci\u00f3n 11.9) e auditor\u00edas internas (Secci\u00f3n 11.10).\n   - **Continuidad del Negocio**: Procedimientos de respaldo y restauraci\u00f3n, continuidad del negocio y recuperaci\u00f3n ante desastres (Secci\u00f3n 11.11).\n   - **Seguridad y Administraci\u00f3n del Sistema**: Administraci\u00f3n del sistema (Secci\u00f3n 11.13).\n   - **Gesti\u00f3n de Registros**: Retenci\u00f3n, archivo y recuperaci\u00f3n de registros (Secci\u00f3n 11.14).\n\n2. **Proceso de Entrega del Sistema**: Se define como la transferencia de responsabilidad del sistema al usuario final, destacando su importancia para asegurar una transici\u00f3n exitosa a la fase operativa, m\u00e1s all\u00e1 de la conformidad y la idoneidad del uso.\n\n3. **Importancia de la Gesti\u00f3n de Incidentes y Continuidad**: Se enfatiza la necesidad de gestionar incidentes y tener planes de continuidad del negocio para mantener la operatividad del sistema en situaciones adversas.\n\nEste resumen destaca la estructura y los procedimientos necesarios para la validaci\u00f3n y operaci\u00f3n de sistemas inform\u00e1ticos seg\u00fan las directrices de ANVISA.", "excerpt_keywords": "Keywords: delivery process, system validation, formal acceptance, project responsibilities, support service management"}}, "b9331827-a872-41b0-9d25-cb87dbb5570c": {"node_ids": ["ce9faee6-937c-4f6c-817e-a14f4a1cfa9d"], "metadata": {"page_label": "67", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "support, whether internal or external, are properly specified and managed. This process is often managed through the use of **Service Level Agreements** - SLA.\n\nService management and system performance monitoring are related to managing generated records to evidence the proper operation and performance of the system. Additionally, there are potential interactions with incident management, CAPA's and change management when the results of the service or monitoring indicate that there are problems that need to be corrected.\n\nThe necessary support for each system and how it will be provided must be formally established. THE support can be provided by internal and external resources. This process should ensure that agreements for support, maintenance plans and standard operating procedures are established.\n\nService Level Agreements can be established separately for individual systems or to cover groups of similar systems (e.g., equipment in a single laboratory).\n\nIt may be useful to have a standard format for Service Level Agreements and regulated companies, in addition to a standard operating procedure to describe how to prepare an Agreement. An approach based on risk for defining content and details must be considered.\n\nService Level Agreements must be agreed, understood and approved by both the system owner and by the service provider. These agreements must unambiguously define the system whose support will be provided, defining how the service will be provided and the responsibilities of the service provider, service and the system owner.\n\nThe qualification of the service provider must be ensured and monitored through appropriate assessments, there may even be audits at the service provider.\n\n## 11.3.2 Key requirements\n\nThere must be a formal agreement with suppliers, including a clear statement of responsibilities. In this context, it is understood that suppliers, both external outsourced and other departments of the company, belong to other management structures of the company.\n\n## 11.3.3 Responsibilities\n\nIt is the responsibility of the system owner to ensure that the necessary support is identified and that the Agreement Service Level is established, followed, monitored and reported.\n\n----\n\nGuide for Computer Systems Validation\nGuide n\u00b0 33/2020 - version 1, of 03/26/2020\n\nPage 63\n\nIt is the responsibility of the system owner to ensure that the service provider is subject to the assessment of appropriate supplier.\n\nIt is the responsibility of the service provider to ensure the competence of the support staff and that they are properly trained and work in accordance with agreed procedures and the Service Level Agreement Service.\n\nIt is the responsibility of the organization providing the support service, identified in the Service Level Agreement", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos enfatiza la importancia de establecer Acuerdos de Nivel de Servicio (SLA) para la gesti\u00f3n del soporte y el rendimiento de los sistemas. Se destaca la necesidad de formalizar el soporte necesario, ya sea interno o externo, y de definir claramente las responsabilidades de los propietarios del sistema y los proveedores de servicios. Adem\u00e1s, se menciona la importancia de la evaluaci\u00f3n y auditor\u00eda de los proveedores de servicios para asegurar su competencia y el cumplimiento de los procedimientos acordados.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfQu\u00e9 elementos deben incluirse en un Acuerdo de Nivel de Servicio (SLA) para garantizar su efectividad?**\n   - El SLA debe incluir una definici\u00f3n clara del sistema que se va a soportar, c\u00f3mo se proporcionar\u00e1 el servicio, y las responsabilidades tanto del proveedor de servicios como del propietario del sistema.\n\n2. **\u00bfCu\u00e1les son las responsabilidades espec\u00edficas del propietario del sistema en relaci\u00f3n con el soporte y la gesti\u00f3n del SLA?**\n   - El propietario del sistema es responsable de identificar el soporte necesario, establecer el SLA, asegurarse de que se siga, monitorear su cumplimiento y reportar cualquier incidencia relacionada.\n\n3. **\u00bfQu\u00e9 procesos deben implementarse para evaluar la competencia de un proveedor de servicios?**\n   - Se deben llevar a cabo evaluaciones adecuadas del proveedor de servicios, que pueden incluir auditor\u00edas, para garantizar que el personal de soporte est\u00e9 capacitado y trabaje de acuerdo con los procedimientos y el SLA acordados.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\nEl documento de ANVISA sobre la Validaci\u00f3n de Sistemas Inform\u00e1ticos aborda varios aspectos cruciales del proceso de entrega de sistemas. A continuaci\u00f3n se presentan los temas clave y las entidades involucradas:\n\n#### Temas Clave\n\n1. **Proceso de Entrega**: Involucra al equipo del proyecto, el propietario del proceso, el propietario del sistema y la unidad de calidad.\n   \n2. **Requisitos Clave**: La empresa regulada debe demostrar la aceptaci\u00f3n formal del sistema tras las pruebas y la transferencia controlada al entorno operativo, lo cual debe ser documentado.\n\n3. **Responsabilidades**:\n   - **Gerente de Proyecto**: Responsable de preparar el sistema para la entrega.\n   - **Propietario del Proceso y del Sistema**: Responsables de aceptar el sistema para su uso operativo.\n   - Acuerdo sobre acciones excepcionales que deban completarse durante la entrega.\n\n4. **Monitoreo Post-Entrega**: Se debe definir un per\u00edodo de monitoreo y una estrategia de reversi\u00f3n en caso de problemas significativos.\n\n5. **Ejecuci\u00f3n de la Actividad de Entrega**:\n   - Definici\u00f3n del alcance, criterios de aceptaci\u00f3n y un plan de entrega.\n   - Uso de un checklist para asegurar la aceptaci\u00f3n y transferencia de responsabilidades.\n   - Preparaci\u00f3n de un informe firmado por ambas partes, que puede formar parte del Informe de Validaci\u00f3n del Sistema.\n\n#### Entidades Involucradas\n\n- **Equipo del Proyecto**: Grupo de desarrollo y/o proveedor.\n- **Propietario del Proceso**: Persona o entidad responsable del proceso que utiliza el sistema.\n- **Propietario del Sistema**: Persona o entidad responsable del sistema en s\u00ed.\n- **Unidad de Calidad**: Entidad encargada de asegurar la calidad del sistema y del proceso de entrega.\n\nEste resumen destaca la importancia de la documentaci\u00f3n, la claridad en las responsabilidades y la planificaci\u00f3n adecuada para asegurar una entrega exitosa y el funcionamiento del sistema en el entorno operativo.", "excerpt_keywords": "Keywords: Service Level Agreements, system support, performance monitoring, supplier assessment, responsibilities"}}, "66204439-cfae-441a-bd32-67eb98c3eb93": {"node_ids": ["69ed7cb5-c79a-4cae-843d-85114f0db572"], "metadata": {"page_label": "68", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 11.3.4 Execution of Activities\n\nThe support service management activity involves performing the following actions, in this order:\n\n- First, support needs are identified.\n- Following is the evaluation and selection of the support service provider(s).\n- The next step is the establishment of the Service Level Agreement.\n- The next step involves establishing the standard operating procedures to support the system.\n- From then on, the Quality and Performance of the system are monitored, through audits or performance checks.\n\nIf the support contract does not meet expectations, it must be terminated.\n\n# 11.4 MONITORING SYSTEM PERFORMANCE\n\n## 11.4.1 Introduction\n\nThe impact of a computer system failure will vary depending on its criticality. When appropriate, system performance must be monitored so that problems can be detected timely. This activity allows the user to anticipate the occurrence of failures, through the use of monitoring tools and techniques.\n\nPerformance monitoring is part of a general preventive maintenance program that aims to purpose of acquiring performance data that is useful for diagnosing system problems. THE monitoring can indicate trends that can indicate performance problems and that can be used as part of corrective and preventive actions (CAPA) to reduce application downtime or system.\n\nPerformance Monitoring Plans are system specific. However, it may be practical to develop a Standard Operating Procedure on how to prepare these plans and develop some parameters generic monitoring.\n\nThe level of detail of the monitoring plan will depend on the associated risk, the complexity and the system innovation. It may not be necessary to develop monitoring plans for simple and low risk, which may be covered by some other document.\n\nPerformance Monitoring Plans can be integrated with the Service Level Agreements discussed in section 11.3.1.\n\nPerformance monitoring can be an automatic or manual process, or even a combination of both.\n\nPerformance monitoring records should be subject to periodic internal audit.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos detalla los procedimientos para la gesti\u00f3n de servicios de soporte y la monitorizaci\u00f3n del rendimiento del sistema. Se enfatiza la importancia de identificar necesidades de soporte, seleccionar proveedores adecuados, establecer acuerdos de nivel de servicio y desarrollar procedimientos operativos est\u00e1ndar. Adem\u00e1s, se aborda la monitorizaci\u00f3n del rendimiento del sistema como parte de un programa de mantenimiento preventivo, destacando la necesidad de planes de monitorizaci\u00f3n espec\u00edficos y su integraci\u00f3n con los acuerdos de nivel de servicio.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfCu\u00e1les son los pasos espec\u00edficos que se deben seguir para gestionar un servicio de soporte seg\u00fan el documento de ANVISA?**\n   - El documento detalla cinco pasos: identificaci\u00f3n de necesidades de soporte, evaluaci\u00f3n y selecci\u00f3n de proveedores, establecimiento de un Acuerdo de Nivel de Servicio, desarrollo de procedimientos operativos est\u00e1ndar y monitoreo de la calidad y rendimiento del sistema.\n\n2. **\u00bfQu\u00e9 factores determinan el nivel de detalle que debe tener un Plan de Monitoreo del Rendimiento?**\n   - El nivel de detalle del Plan de Monitoreo depende del riesgo asociado, la complejidad del sistema y la innovaci\u00f3n del mismo. Para sistemas simples y de bajo riesgo, puede no ser necesario desarrollar un plan de monitoreo detallado.\n\n3. **\u00bfC\u00f3mo se integran los Planes de Monitoreo del Rendimiento con los Acuerdos de Nivel de Servicio?**\n   - Los Planes de Monitoreo del Rendimiento pueden ser integrados con los Acuerdos de Nivel de Servicio, lo que permite una evaluaci\u00f3n m\u00e1s efectiva del rendimiento del sistema en relaci\u00f3n con las expectativas establecidas en el acuerdo.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Acuerdos de Nivel de Servicio (SLA)**:\n   - Importancia de establecer SLA para la gesti\u00f3n del soporte y rendimiento de sistemas inform\u00e1ticos.\n   - Los SLA deben definir claramente el sistema a soportar, c\u00f3mo se proporcionar\u00e1 el servicio y las responsabilidades de las partes involucradas.\n\n2. **Soporte y Recursos**:\n   - El soporte puede ser interno o externo y debe ser formalmente establecido.\n   - Es necesario contar con planes de mantenimiento y procedimientos operativos est\u00e1ndar.\n\n3. **Responsabilidades**:\n   - **Propietario del Sistema**: Identificar el soporte necesario, establecer y monitorear el SLA, y asegurar que se sigan los procedimientos acordados.\n   - **Proveedor de Servicios**: Asegurar la competencia del personal de soporte y que trabajen conforme a los procedimientos y SLA establecidos.\n\n4. **Evaluaci\u00f3n de Proveedores**:\n   - Se deben realizar evaluaciones y auditor\u00edas para garantizar la competencia del proveedor de servicios.\n\n5. **Interacciones con Otros Procesos**:\n   - Los SLA pueden interactuar con la gesti\u00f3n de incidentes, CAPA (Acciones Correctivas y Preventivas) y gesti\u00f3n de cambios.\n\n### Entidades Clave\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil, responsable de la regulaci\u00f3n.\n- **SLA (Service Level Agreement)**: Acuerdo formal que define el nivel de servicio esperado.\n- **Propietario del Sistema**: Persona o entidad responsable del sistema inform\u00e1tico.\n- **Proveedor de Servicios**: Entidad que proporciona soporte y mantenimiento al sistema.\n- **Auditor\u00edas**: Proceso de evaluaci\u00f3n para asegurar el cumplimiento y competencia del proveedor.\n\nEste resumen destaca la importancia de la formalizaci\u00f3n y gesti\u00f3n de los SLA en el contexto de la validaci\u00f3n de sistemas inform\u00e1ticos, as\u00ed como las responsabilidades y procesos necesarios para asegurar un soporte efectivo.", "excerpt_keywords": "Keywords: ANVISA, Computer Systems Validation, Service Level Agreement, Performance Monitoring, Support Service Management"}}, "7cfc95ef-0d04-4e28-b51e-9bf255e21649": {"node_ids": ["238b9f03-05bb-4db8-a2e5-c6a0d548f413"], "metadata": {"page_label": "69", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 11.4.2 Key requirements\n\nThe need and extent of monitoring activities should be based on the system's risk to patient safety, product quality and data integrity.\n\nThe appropriate performance parameters should be defined based on the identified risks.\n\n# 11.4.3 Responsibilities\n\nIt is the responsibility of the system owner to ensure that the performance of the system is monitored and that appropriate actions are taken when necessary.\n\nIt is the responsibility of the system owner to inform the process owner and the Quality Unit about any performance issues that may impact patient safety, product and data integrity, and must also invoke Incident Management.\n\n# 11.4.4 Execution of Activities\n\nThe performance monitoring activity involves performing the following actions, in this order:\n\n- Conduct risk assessment;\n- Define the monitoring plan;\n- Start monitoring system performance, change control activities, incident and maintenance management;\n- Conduct periodic reviews and evaluations as a source of data for the Periodic Review of the system.\n\n# 11.4.5 Monitored parameters\n\nDepending on the risks to BPx of installed applications / systems and the type of computerized equipment involved, the following conditions should be checked with appropriate tools at appropriate intervals:\n\n- Servers / workstations / PCs / control systems;\n- CPU usage;\n- Use of the cache;\n- Interactive response time;\n- Number of transactions per unit of time;\n- Average waiting time at work;\n- Disk capacity utilization;\n- I / O load (Input / Output);\n- System error messages, including operating system failures and warning messages;\n- Hardware situation;\n- Existence of critical batch jobs;", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos establece directrices sobre la necesidad de monitoreo de sistemas en funci\u00f3n de los riesgos asociados a la seguridad del paciente, la calidad del producto y la integridad de los datos. Se asignan responsabilidades al propietario del sistema para garantizar el monitoreo del rendimiento y la gesti\u00f3n de incidentes. Adem\u00e1s, se detallan las actividades a realizar para el monitoreo y los par\u00e1metros que deben ser verificados en funci\u00f3n de los riesgos identificados.\n\n### Preguntas\n1. **\u00bfCu\u00e1les son las responsabilidades espec\u00edficas del propietario del sistema en relaci\u00f3n con el monitoreo del rendimiento?**\n   - El propietario del sistema es responsable de asegurar que el rendimiento del sistema sea monitoreado y de tomar acciones apropiadas cuando sea necesario. Tambi\u00e9n debe informar al propietario del proceso y a la Unidad de Calidad sobre cualquier problema de rendimiento que pueda afectar la seguridad del paciente, la calidad del producto y la integridad de los datos, adem\u00e1s de invocar la gesti\u00f3n de incidentes.\n\n2. **\u00bfQu\u00e9 pasos deben seguirse en el proceso de monitoreo del rendimiento del sistema?**\n   - El proceso de monitoreo del rendimiento del sistema debe seguir estos pasos: realizar una evaluaci\u00f3n de riesgos, definir un plan de monitoreo, comenzar a monitorear el rendimiento del sistema y las actividades de control de cambios, gestionar incidentes y mantenimiento, y realizar revisiones y evaluaciones peri\u00f3dicas como fuente de datos para la revisi\u00f3n peri\u00f3dica del sistema.\n\n3. **\u00bfQu\u00e9 par\u00e1metros espec\u00edficos deben ser monitoreados y por qu\u00e9 son importantes?**\n   - Los par\u00e1metros que deben ser monitoreados incluyen el uso de CPU, el tiempo de respuesta interactivo, el n\u00famero de transacciones por unidad de tiempo, la utilizaci\u00f3n de la capacidad del disco, y los mensajes de error del sistema, entre otros. Estos par\u00e1metros son importantes porque ayudan a identificar problemas que pueden afectar la seguridad del paciente, la calidad del producto y la integridad de los datos, permitiendo as\u00ed tomar acciones correctivas a tiempo.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n#### Temas Clave\n\n1. **Gesti\u00f3n de Servicios de Soporte**:\n   - Identificaci\u00f3n de necesidades de soporte.\n   - Evaluaci\u00f3n y selecci\u00f3n de proveedores de servicios de soporte.\n   - Establecimiento de Acuerdos de Nivel de Servicio (SLA).\n   - Desarrollo de procedimientos operativos est\u00e1ndar.\n   - Monitoreo de la calidad y rendimiento del sistema.\n\n2. **Monitoreo del Rendimiento del Sistema**:\n   - Importancia de la monitorizaci\u00f3n para detectar problemas a tiempo.\n   - Integraci\u00f3n de la monitorizaci\u00f3n en un programa de mantenimiento preventivo.\n   - Desarrollo de Planes de Monitoreo del Rendimiento espec\u00edficos para cada sistema.\n   - Dependencia del nivel de detalle del plan en el riesgo, complejidad e innovaci\u00f3n del sistema.\n   - Posibilidad de que la monitorizaci\u00f3n sea autom\u00e1tica, manual o una combinaci\u00f3n de ambas.\n   - Sujeci\u00f3n de los registros de monitoreo a auditor\u00edas internas peri\u00f3dicas.\n\n#### Entidades\n\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil, responsable de la regulaci\u00f3n y supervisi\u00f3n de la salud p\u00fablica.\n- **Acuerdo de Nivel de Servicio (SLA)**: Contrato que define el nivel esperado de servicio entre el proveedor y el cliente.\n- **Planes de Monitoreo del Rendimiento**: Documentos que establecen c\u00f3mo se llevar\u00e1 a cabo la monitorizaci\u00f3n del rendimiento del sistema.\n- **CAPA (Corrective and Preventive Actions)**: Acciones correctivas y preventivas para abordar problemas identificados en el rendimiento del sistema.\n\nEste resumen destaca la importancia de una gesti\u00f3n adecuada de los servicios de soporte y la monitorizaci\u00f3n del rendimiento del sistema para garantizar la eficacia y la continuidad operativa en el contexto de la validaci\u00f3n de sistemas inform\u00e1ticos.", "excerpt_keywords": "Keywords: monitoring, system performance, patient safety, data integrity, risk assessment"}}, "6b0aca27-3ab2-41f1-8fe6-2b87e39665db": {"node_ids": ["2eed0715-580b-4181-a143-00769b3b5d95"], "metadata": {"page_label": "70", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "- Existence of critical processes;\n- Availability of printer queues;\n- Alarms;\n- Networks;\n- Component availability (server, router, etc.);\n- Network load (eg, number of collisions);\n- Transmissions;\n- Applications;\n- Monitoring of error messages;\n- Response times;\n- Number of concurrent users;\n- General system availability for users.\n\n**NOTE:** The parameters mentioned above are only examples and not a complete list.\n\n## 11.4.6 Notification Mechanisms\n\nDepending on the risk associated with the monitored parameter, mechanisms such as one or more described below must be used to notify the main stakeholders about the exception conditions that have occurred:\n\n- System console message;\n- E-mail to the system operator;\n- E-mail to external service providers;\n- Printed lists or records;\n- Visual or audible alarms.\n\n## 11.4.7 Structure of the Monitoring Plan\n\nThe monitoring plan should cover the following areas:\n\n- Monitored parameters;\n- Alert limits;\n- Observation frequency;\n- Monitoring tool;\n- Notification mechanism and person / system to be informed;\n- Documentation of monitoring results;\n- Results storage / retention period;\n\nIt is recommended to use a tabular format for plan documentation.\n\n## 11.4.8 Review of the Monitoring Plan\n\nThe following items should be checked during the review of the monitoring plan:\n\n- Whether the appropriate parameters and components are monitored;\n- Whether the risks determined in the risk analysis are adequately addressed;", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos establece directrices para el monitoreo de par\u00e1metros cr\u00edticos en sistemas. Se detallan los mecanismos de notificaci\u00f3n que deben implementarse en funci\u00f3n del riesgo asociado a los par\u00e1metros monitoreados. Adem\u00e1s, se sugiere una estructura para el plan de monitoreo y se indican los elementos que deben revisarse durante su evaluaci\u00f3n.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfCu\u00e1les son algunos ejemplos de par\u00e1metros que deben ser monitoreados seg\u00fan el documento de ANVISA?**\n   - El documento menciona par\u00e1metros como la existencia de procesos cr\u00edticos, disponibilidad de colas de impresi\u00f3n, carga de red, tiempos de respuesta y n\u00famero de usuarios concurrentes, entre otros.\n\n2. **\u00bfQu\u00e9 mecanismos de notificaci\u00f3n se recomiendan para informar a las partes interesadas sobre condiciones excepcionales?**\n   - Se sugieren mecanismos como mensajes en la consola del sistema, correos electr\u00f3nicos al operador del sistema y proveedores de servicios externos, listas impresas, y alarmas visuales o audibles.\n\n3. **\u00bfQu\u00e9 elementos deben ser revisados durante la evaluaci\u00f3n del plan de monitoreo?**\n   - Durante la revisi\u00f3n del plan, se debe verificar si se est\u00e1n monitoreando los par\u00e1metros y componentes adecuados y si los riesgos identificados en el an\u00e1lisis de riesgos est\u00e1n siendo abordados de manera adecuada.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Monitoreo de Sistemas**: La necesidad y el alcance de las actividades de monitoreo deben basarse en los riesgos que el sistema representa para la seguridad del paciente, la calidad del producto y la integridad de los datos.\n\n2. **Responsabilidades del Propietario del Sistema**: \n   - Asegurar el monitoreo del rendimiento del sistema.\n   - Informar sobre problemas de rendimiento que puedan afectar la seguridad del paciente y la calidad del producto.\n   - Invocar la gesti\u00f3n de incidentes cuando sea necesario.\n\n3. **Actividades de Ejecuci\u00f3n**: El monitoreo del rendimiento del sistema implica:\n   - Realizar una evaluaci\u00f3n de riesgos.\n   - Definir un plan de monitoreo.\n   - Iniciar el monitoreo del rendimiento del sistema y gestionar incidentes y mantenimiento.\n   - Realizar revisiones y evaluaciones peri\u00f3dicas.\n\n4. **Par\u00e1metros a Monitorear**: Los par\u00e1metros que deben ser verificados incluyen:\n   - Uso de CPU.\n   - Tiempo de respuesta interactivo.\n   - N\u00famero de transacciones por unidad de tiempo.\n   - Utilizaci\u00f3n de la capacidad del disco.\n   - Mensajes de error del sistema, entre otros.\n\n### Entidades Clave\n- **Sistema**: Se refiere a los sistemas inform\u00e1ticos que requieren monitoreo.\n- **Propietario del Sistema**: La persona o entidad responsable del sistema.\n- **Unidad de Calidad**: Entidad que debe ser informada sobre problemas de rendimiento.\n- **Gesti\u00f3n de Incidentes**: Proceso que debe ser invocado ante problemas de rendimiento.\n- **Par\u00e1metros de Rendimiento**: Indicadores que se deben monitorear para asegurar la integridad y calidad del sistema.\n\nEste resumen destaca la importancia del monitoreo sistem\u00e1tico y la asignaci\u00f3n de responsabilidades para garantizar la seguridad y calidad en el uso de sistemas inform\u00e1ticos en el contexto de la salud y la industria.", "excerpt_keywords": "Keywords: monitoring, notification mechanisms, risk analysis, system validation, performance parameters"}}, "2719f7a0-e9c3-45cc-a0ef-7b3641bc0817": {"node_ids": ["47e1db0f-5738-4dc3-82fe-5f9ae6ab018e"], "metadata": {"page_label": "71", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "- Whether the time intervals and alert limits for the monitored parameters are adequate;\n- Whether notification methods are used and allow for timely alerting;\n- Whether the results of monitoring are safely retained.\n\n## 11.5 INCIDENT MANAGEMENT\n\n### 11.5.1 Introduction\n\nThe incident management process aims to categorize incidents in order to target them for a timely resolution.\n\nThere should be a procedure defining how problems related to *software*, *hardware* and Operational procedures will be captured, reviewed, prioritized, rolled out, sized and completed.\n\nThe primary objective of Incident Management is to ensure that any unplanned deviations that impact on patient safety, product quality or data integrity resolved before causing damage.\n\nIncident Management must be designed so that the system / application / service is returned to the user as quickly as possible. This process / procedure is usually somewhat generic and can be applied to all systems.\n\nIncidents should be assessed taking into account any impact on patient safety, product quality and data integrity. The Quality Unit should be consulted to assist in the definition of the acceptance criteria to be used in this assessment and to assist in the assessment of the incident.\n\n### 11.5.2 Key requirements\n\nThe incident management process should ensure that operational events that are not part of the standard operations (eg, deviations, problems and errors) are identified, evaluated, resolved and completed in a timely manner. These activities must be documented.\n\n### 11.5.3 Responsibilities\n\nIt is the responsibility of the process owner to ensure that the incident management process and the procedure are established to support the system.\n\nIt is the responsibility of the subject matter specialist (SME) to assess incidents and consult the Quality on those that impact patient safety, product quality or data integrity and take appropriate corrective actions.\n\nIt is the responsibility of the system owner to ensure that incidents are resolved and completed when applicable.\n\nIt is the responsibility of the Quality Unit to ensure that the procedures associated with management incidents are followed and that appropriate actions have been taken and documented.\n\n### 11.5.4 Execution of Activities", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas que se pueden responder espec\u00edficamente con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos establece un proceso de gesti\u00f3n de incidentes que tiene como objetivo categorizar y resolver incidentes relacionados con software, hardware y procedimientos operativos. Este proceso es crucial para garantizar la seguridad del paciente, la calidad del producto y la integridad de los datos. Se definen responsabilidades claras para los propietarios de procesos, especialistas en la materia y unidades de calidad, y se enfatiza la necesidad de documentar todas las actividades relacionadas con la gesti\u00f3n de incidentes.\n\n### Preguntas\n1. **\u00bfCu\u00e1les son los criterios de aceptaci\u00f3n que deben considerarse al evaluar un incidente relacionado con la seguridad del paciente?**\n   - El contexto menciona que la Unidad de Calidad debe ser consultada para ayudar en la definici\u00f3n de los criterios de aceptaci\u00f3n utilizados en la evaluaci\u00f3n de incidentes que impactan la seguridad del paciente, la calidad del producto o la integridad de los datos.\n\n2. **\u00bfQu\u00e9 pasos deben seguirse para documentar un incidente en el proceso de gesti\u00f3n de incidentes?**\n   - El documento establece que las actividades relacionadas con la identificaci\u00f3n, evaluaci\u00f3n, resoluci\u00f3n y finalizaci\u00f3n de eventos operativos no est\u00e1ndar deben ser documentadas, aunque no se detallan los pasos espec\u00edficos en el texto proporcionado.\n\n3. **\u00bfQu\u00e9 papel juega la Unidad de Calidad en el proceso de gesti\u00f3n de incidentes?**\n   - La Unidad de Calidad es responsable de asegurar que se sigan los procedimientos asociados con la gesti\u00f3n de incidentes y que se tomen y documenten las acciones apropiadas, lo que resalta su importancia en el proceso de gesti\u00f3n de incidentes.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos aborda varios aspectos cr\u00edticos relacionados con el monitoreo de sistemas. A continuaci\u00f3n se presentan los temas clave y las entidades mencionadas en la secci\u00f3n:\n\n1. **Par\u00e1metros a Monitorear**:\n   - Procesos cr\u00edticos\n   - Disponibilidad de colas de impresi\u00f3n\n   - Alarmas\n   - Redes\n   - Disponibilidad de componentes (servidores, routers, etc.)\n   - Carga de red (n\u00famero de colisiones)\n   - Transmisiones\n   - Aplicaciones\n   - Monitoreo de mensajes de error\n   - Tiempos de respuesta\n   - N\u00famero de usuarios concurrentes\n   - Disponibilidad general del sistema para los usuarios\n\n2. **Mecanismos de Notificaci\u00f3n**:\n   - Mensajes en la consola del sistema\n   - Correos electr\u00f3nicos al operador del sistema\n   - Correos electr\u00f3nicos a proveedores de servicios externos\n   - Listas o registros impresos\n   - Alarmas visuales o audibles\n\n3. **Estructura del Plan de Monitoreo**:\n   - Par\u00e1metros monitoreados\n   - L\u00edmites de alerta\n   - Frecuencia de observaci\u00f3n\n   - Herramienta de monitoreo\n   - Mecanismo de notificaci\u00f3n y personas/sistemas a informar\n   - Documentaci\u00f3n de resultados de monitoreo\n   - Almacenamiento de resultados/per\u00edodo de retenci\u00f3n\n\n4. **Revisi\u00f3n del Plan de Monitoreo**:\n   - Verificaci\u00f3n de par\u00e1metros y componentes adecuados\n   - Evaluaci\u00f3n de si los riesgos identificados en el an\u00e1lisis de riesgos est\u00e1n siendo abordados adecuadamente\n\n### Conclusi\u00f3n\nEl documento establece directrices claras para el monitoreo efectivo de sistemas inform\u00e1ticos, enfatizando la importancia de los par\u00e1metros cr\u00edticos, los mecanismos de notificaci\u00f3n y la estructura del plan de monitoreo, as\u00ed como la necesidad de revisiones peri\u00f3dicas para asegurar la efectividad del sistema.", "excerpt_keywords": "Keywords: incident management, patient safety, data integrity, quality unit, software validation"}}, "33db9069-74e5-4a9d-9e86-a34c6a3907e4": {"node_ids": ["f1e96510-941a-4a2f-a052-606433f5934d"], "metadata": {"page_label": "72", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# Incident management activities involve performing the following actions:\n\n- Identify and record the incident;\n- Assess the incident. The result of this assessment can be one of the following options: there is no need of taking action; taking action according to a pre-established procedure, forward to superior skills;\n- Problem resolution and incident report preparation;\n- Conclusion / closure of the incident.\n\n## 11.6 CORRECTIVE AND PREVENTIVE ACTIONS (COVER)\n\n### 11.6.1 Introduction\n\nCAPA activities involve the process of investigating, understanding and correcting discrepancies based on the analysis of the root cause, in order to avoid its recurrence.\n\nIn the operational environment, CAPA activities related to computerized systems must be part of CAPA's general system of activities for the other areas. When incidents occur, or when opportunities to reduce system failures are identified by other means, corrective actions and preventive measures must be identified and processes must be established to ensure that CAPA's are effectively deployed.\n\nThe CAPA process is strongly associated with the Incident Management process and the Repair.\n\nThe CAPA process is usually generic, that is, a process can be applied to all systems. THE regulated company should assess whether to maintain a CAPA record for all systems or a record for groups of similar systems or a record for each system.\n\nAny corrective or preventive action taken to eliminate the causes of actual or non-compliance potential must have a degree according to the magnitude of the problems and proportional to the risks found.\n\nCAPA's records must be subject to periodic internal audits.\n\n### 11.6.2 Key requirements\n\nThe CAPA process must cover:\n\n- Corrective actions for an identified problem or a potential problem;\n- Determining the root cause and taking corrective action to potentially prevent recurrence of a similar problem;\n- Preventive action to prevent the recurrence of a similar potential problem, when appropriate;\n- Evaluation of the effectiveness of the actions taken.\n\nA procedure should be established to record and analyze incidents and allow corrective action be taken. These activities must be documented.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas computacionales aborda la gesti\u00f3n de incidentes y el proceso de Acciones Correctivas y Preventivas (CAPA). Se describen las actividades involucradas en la gesti\u00f3n de incidentes, que incluyen la identificaci\u00f3n, evaluaci\u00f3n, resoluci\u00f3n y cierre de incidentes. Adem\u00e1s, se detalla el proceso CAPA, que implica investigar y corregir discrepancias mediante el an\u00e1lisis de la causa ra\u00edz para evitar su recurrencia. Se enfatiza la importancia de documentar estas actividades y de realizar auditor\u00edas internas peri\u00f3dicas.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfQu\u00e9 pasos deben seguirse para evaluar un incidente seg\u00fan el documento de ANVISA?**\n   - El documento establece que la evaluaci\u00f3n de un incidente puede resultar en tres opciones: no se necesita tomar acci\u00f3n, tomar acci\u00f3n de acuerdo con un procedimiento preestablecido, o remitir el incidente a habilidades superiores.\n\n2. **\u00bfC\u00f3mo debe una empresa regulada decidir sobre el mantenimiento de registros de CAPA?**\n   - La empresa regulada debe evaluar si mantener un registro de CAPA para todos los sistemas, para grupos de sistemas similares, o un registro para cada sistema individual, dependiendo de la naturaleza y el riesgo asociado a los problemas identificados.\n\n3. **\u00bfCu\u00e1les son los requisitos clave que debe cubrir el proceso CAPA seg\u00fan el documento?**\n   - El proceso CAPA debe incluir acciones correctivas para problemas identificados o potenciales, determinar la causa ra\u00edz y tomar acciones correctivas, implementar acciones preventivas cuando sea apropiado, y evaluar la efectividad de las acciones tomadas. Adem\u00e1s, se debe establecer un procedimiento para registrar y analizar incidentes.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n**Tema Principal: Gesti\u00f3n de Incidentes**\n- El proceso de gesti\u00f3n de incidentes tiene como objetivo categorizar y resolver incidentes relacionados con software, hardware y procedimientos operativos de manera oportuna.\n- Se busca garantizar la seguridad del paciente, la calidad del producto y la integridad de los datos, resolviendo desviaciones no planificadas antes de que causen da\u00f1os.\n\n**Subtemas Clave:**\n1. **Introducci\u00f3n a la Gesti\u00f3n de Incidentes:**\n   - Definici\u00f3n de procedimientos para capturar, revisar, priorizar y resolver problemas.\n   - Importancia de la r\u00e1pida recuperaci\u00f3n del sistema o servicio para el usuario.\n\n2. **Requisitos Clave:**\n   - Identificaci\u00f3n, evaluaci\u00f3n, resoluci\u00f3n y documentaci\u00f3n de eventos operativos no est\u00e1ndar (desviaciones, problemas y errores).\n\n3. **Responsabilidades:**\n   - **Propietario del Proceso:** Asegurar el establecimiento del proceso de gesti\u00f3n de incidentes.\n   - **Especialista en la Materia (SME):** Evaluar incidentes y consultar a la Unidad de Calidad sobre aquellos que impactan la seguridad del paciente, calidad del producto o integridad de datos.\n   - **Propietario del Sistema:** Asegurar la resoluci\u00f3n y finalizaci\u00f3n de incidentes.\n   - **Unidad de Calidad:** Garantizar el cumplimiento de los procedimientos de gesti\u00f3n de incidentes y la documentaci\u00f3n de acciones apropiadas.\n\n**Entidades Clave:**\n- **Unidad de Calidad:** Juega un papel crucial en la definici\u00f3n de criterios de aceptaci\u00f3n y en la evaluaci\u00f3n de incidentes.\n- **Propietario del Proceso:** Responsable de establecer el proceso de gesti\u00f3n de incidentes.\n- **Especialista en la Materia (SME):** Encargado de la evaluaci\u00f3n t\u00e9cnica de los incidentes.\n\nEste resumen destaca la importancia de un proceso estructurado para la gesti\u00f3n de incidentes en sistemas inform\u00e1ticos, enfatizando la colaboraci\u00f3n entre diferentes roles para asegurar la calidad y seguridad en el entorno operativo.", "excerpt_keywords": "Keywords: incident management, corrective actions, preventive actions, root cause analysis, CAPA process"}}, "6c2cad81-9f81-4b21-bfa2-f869f258d9c9": {"node_ids": ["aac2e433-6caf-453d-956e-4ae63fd9e42a"], "metadata": {"page_label": "73", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "## 11.6.3 Responsibilities\n\nIt is the responsibility of the process owner to ensure that a CAPA process is implemented for the system computerized and that responsibilities are delegated to the system owner.\n\nIt is the responsibility of the Quality Unit to ensure that CAPA procedures are followed and actions appropriate measures have been taken and documented.\n\nIt is the responsibility of the subject matter specialist (SME) to ensure that the corrective and preventive actions agreed carried out and completed.\n\n## 11.6.4 Execution of Activities\n\nCAPA activities involve the following actions:\n\n1. Problem identification and registration;\n2. Determination of the emergency action to be taken;\n3. Determination of the probable root cause. This activity can start from the immediate correction of the problem. It usually involves a multidisciplinary team;\n4. Determination of Preventive Action. This action may involve Documentation Management, Change Management, Training, Support and Administration;\n5. Record of the result obtained. A rationale should be written if no action is taken.\n6. Assessment of the success of the Corrective Action and/or Preventive Action performed(s).\n\n## 11.7 MANAGING CHANGES AND SYSTEM CONFIGURATION\n\n### 11.7.1 Introduction\n\nChange management is a critical and fundamental activity for maintaining compliance with systems and processes. All changes proposed during the operational phase of the system, be they related to software, hardware, infrastructure or system usage, should be subject to a process formal change control. This process should ensure that the proposed change is adequately revised to assess the impact and risk of its implementation. The process must ensure that changes are properly evaluated, authorized, documented, tested and approved before their implementation and duly completed.\n\nSome activities such as system replacements and administrative tasks must be covered by repair and system administration processes.\n\nChange management should provide a mechanism for prompt implementation of improvements processes and systems based on periodic review and evaluation, operational and performance and analysis of the root causes of failures that occurred.\n\nConfiguration Management includes those activities necessary for the precise definition of the system computerized at any point in its life cycle, from the initial stage of development to its retirement.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos establece directrices sobre la implementaci\u00f3n de procesos de Acci\u00f3n Correctiva y Preventiva (CAPA) y la gesti\u00f3n de cambios y configuraci\u00f3n del sistema. Se detallan las responsabilidades de los propietarios de procesos, la unidad de calidad y los especialistas en la materia en relaci\u00f3n con la ejecuci\u00f3n de actividades CAPA. Adem\u00e1s, se enfatiza la importancia de un control formal de cambios para asegurar que todas las modificaciones en el sistema sean evaluadas, autorizadas y documentadas adecuadamente.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfCu\u00e1les son las responsabilidades espec\u00edficas del propietario del proceso en relaci\u00f3n con el proceso CAPA?**\n   - El propietario del proceso es responsable de asegurar que se implemente un proceso CAPA para el sistema computarizado y de delegar responsabilidades al propietario del sistema.\n\n2. **\u00bfQu\u00e9 pasos se deben seguir para llevar a cabo las actividades de CAPA seg\u00fan el documento?**\n   - Las actividades de CAPA incluyen la identificaci\u00f3n y registro del problema, determinaci\u00f3n de acciones de emergencia, identificaci\u00f3n de la causa ra\u00edz probable, determinaci\u00f3n de acciones preventivas, registro de resultados y evaluaci\u00f3n del \u00e9xito de las acciones correctivas y/o preventivas realizadas.\n\n3. **\u00bfQu\u00e9 aspectos deben considerarse en la gesti\u00f3n de cambios y configuraci\u00f3n del sistema durante su ciclo de vida?**\n   - La gesti\u00f3n de cambios debe incluir la evaluaci\u00f3n del impacto y riesgo de las modificaciones propuestas, asegurando que sean evaluadas, autorizadas, documentadas, probadas y aprobadas antes de su implementaci\u00f3n. La gesti\u00f3n de configuraci\u00f3n implica definir con precisi\u00f3n el sistema en cualquier punto de su ciclo de vida, desde el desarrollo inicial hasta su retiro.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n**1. Gesti\u00f3n de Incidentes:**\n   - **Actividades Clave:**\n     - Identificaci\u00f3n y registro del incidente.\n     - Evaluaci\u00f3n del incidente con posibles resultados: no se necesita acci\u00f3n, acci\u00f3n seg\u00fan procedimiento preestablecido, o remitir a habilidades superiores.\n     - Resoluci\u00f3n del problema y preparaci\u00f3n del informe del incidente.\n     - Cierre del incidente.\n\n**2. Acciones Correctivas y Preventivas (CAPA):**\n   - **Introducci\u00f3n:**\n     - Proceso de investigar, entender y corregir discrepancias mediante el an\u00e1lisis de la causa ra\u00edz para evitar recurrencias.\n     - Las actividades CAPA deben integrarse en el sistema general de actividades de la empresa regulada.\n     - Importancia de identificar acciones correctivas y preventivas cuando ocurren incidentes o se identifican oportunidades de mejora.\n\n   - **Requisitos Clave del Proceso CAPA:**\n     - Acciones correctivas para problemas identificados o potenciales.\n     - Determinaci\u00f3n de la causa ra\u00edz y acciones correctivas para prevenir recurrencias.\n     - Acciones preventivas para evitar la recurrencia de problemas potenciales.\n     - Evaluaci\u00f3n de la efectividad de las acciones tomadas.\n     - Establecimiento de un procedimiento para registrar y analizar incidentes.\n\n**3. Documentaci\u00f3n y Auditor\u00eda:**\n   - La documentaci\u00f3n de las actividades de gesti\u00f3n de incidentes y CAPA es esencial.\n   - Los registros de CAPA deben ser objeto de auditor\u00edas internas peri\u00f3dicas.\n\n### Entidades Clave:\n- **ANVISA:** Agencia Nacional de Vigilancia Sanitaria de Brasil.\n- **CAPA:** Acciones Correctivas y Preventivas.\n- **Incidentes:** Problemas o fallas en sistemas computacionales que requieren gesti\u00f3n y resoluci\u00f3n. \n\nEste resumen destaca la importancia de la gesti\u00f3n de incidentes y el proceso CAPA en el contexto de la validaci\u00f3n de sistemas computacionales, enfatizando la necesidad de documentaci\u00f3n y auditor\u00eda para asegurar la efectividad de las acciones tomadas.", "excerpt_keywords": "Keywords: CAPA, Change Management, System Configuration, Quality Unit, Root Cause Analysis"}}, "385c48b4-1acd-4629-a46a-25fac43ae31f": {"node_ids": ["702231ac-75ce-4e3c-8ae9-03028151ef2e"], "metadata": {"page_label": "74", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "A configuration item is a component of the system that is not changed as a result of an operation normal system. Configuration items can only be changed through a management process of changes. There must be formal procedures in place to identify, define and establish the items of the initial configuration and to track and record changes and releases of configuration items, including updates and packages.\n\n----\n\nGuide for Computer Systems Validation\nGuide n\u00b0 33/2020 - version 1, of 03/26/2020\n\n----\n\n# Configuration Management and Change Management\n\nConfiguration Management and Change Management are closely related. When changes are proposed, both activities need to be dealt with in parallel, particularly during the assessment of the impact of changes.\n\nBoth activities must be applied to the complete scope of the systems including the *hardware* components and *software* and associated documentation and records, particularly those with an impact on BPx.\n\n## 11.7.2 Key requirements\n\nChange management should continue until the system is retired. If the data is kept after the retired system, the management of this data must be subject to change control.\n\nAll changes must be reviewed, assessed for risk and impact, authorized, documented, tested and approved before deployment.\n\nThe *hardware* and *software* configuration must be documented throughout the system's life cycle. The level of detail should be sufficient to allow the system to be rebuilt in the event of total loss of system.\n\nTests to verify changes must be proportionate to the risk to patient safety, quality product integrity and data integrity.\n\n## 11.7.3 Responsibilities\n\nIt is the responsibility of the Process Owner to ensure that a change management and configuration is deployed.\n\nIt is the responsibility of the Quality Unit to ensure that the existing procedures for these activities followed.\n\nIt is the responsibility of each member of the team associated with each change to play their part in the correct way.\n\n## 11.7.4 Change Management\n\nThis activity follows the same guidelines followed by other areas relevant to Good Manufacturing Practices.\n\nHowever, specific processes or variations of the standard process may be necessary for the following types", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento \"Gu\u00eda para la Validaci\u00f3n de Sistemas Inform\u00e1ticos\" de ANVISA establece directrices sobre la gesti\u00f3n de configuraciones y cambios en sistemas inform\u00e1ticos, enfatizando la importancia de un proceso formal para manejar los elementos de configuraci\u00f3n. Se destaca que la gesti\u00f3n de cambios debe ser continua hasta que el sistema sea retirado, y que todos los cambios deben ser revisados, documentados y aprobados antes de su implementaci\u00f3n. Tambi\u00e9n se asignan responsabilidades espec\u00edficas a los propietarios de procesos y a la unidad de calidad para asegurar el cumplimiento de estas directrices.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfQu\u00e9 procedimientos formales deben implementarse para gestionar los elementos de configuraci\u00f3n en un sistema inform\u00e1tico seg\u00fan la gu\u00eda de ANVISA?**\n   - La gu\u00eda establece que deben existir procedimientos formales para identificar, definir y establecer los elementos de la configuraci\u00f3n inicial, as\u00ed como para rastrear y registrar cambios y versiones de los elementos de configuraci\u00f3n, incluyendo actualizaciones y paquetes.\n\n2. **\u00bfCu\u00e1les son las responsabilidades espec\u00edficas del propietario del proceso y de la unidad de calidad en la gesti\u00f3n de cambios seg\u00fan el documento?**\n   - El propietario del proceso es responsable de asegurar que se implemente la gesti\u00f3n de cambios y configuraciones, mientras que la unidad de calidad debe garantizar que se sigan los procedimientos existentes para estas actividades. Cada miembro del equipo tambi\u00e9n tiene la responsabilidad de participar correctamente en el proceso de gesti\u00f3n de cambios.\n\n3. **\u00bfC\u00f3mo se deben documentar las configuraciones de hardware y software a lo largo del ciclo de vida del sistema?**\n   - La gu\u00eda indica que la configuraci\u00f3n de hardware y software debe ser documentada durante todo el ciclo de vida del sistema, con un nivel de detalle suficiente para permitir la reconstrucci\u00f3n del sistema en caso de p\u00e9rdida total. Adem\u00e1s, las pruebas para verificar cambios deben ser proporcionales al riesgo que representan para la seguridad del paciente, la integridad del producto y la integridad de los datos.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n**1. Responsabilidades en el Proceso CAPA:**\n   - **Propietario del Proceso:** Asegura la implementaci\u00f3n del proceso CAPA y delega responsabilidades al propietario del sistema.\n   - **Unidad de Calidad:** Verifica que se sigan los procedimientos CAPA y que se tomen y documenten las medidas adecuadas.\n   - **Especialista en la Materia (SME):** Se asegura de que las acciones correctivas y preventivas acordadas se lleven a cabo y se completen.\n\n**2. Ejecuci\u00f3n de Actividades CAPA:**\n   - **Identificaci\u00f3n y Registro del Problema:** Primer paso en el proceso.\n   - **Determinaci\u00f3n de Acci\u00f3n de Emergencia:** Acciones inmediatas a tomar.\n   - **Determinaci\u00f3n de la Causa Ra\u00edz:** An\u00e1lisis para identificar la causa subyacente del problema.\n   - **Determinaci\u00f3n de Acci\u00f3n Preventiva:** Acciones que pueden incluir gesti\u00f3n de documentaci\u00f3n, gesti\u00f3n de cambios, capacitaci\u00f3n, soporte y administraci\u00f3n.\n   - **Registro de Resultados:** Documentaci\u00f3n de los resultados obtenidos y justificaci\u00f3n si no se toma ninguna acci\u00f3n.\n   - **Evaluaci\u00f3n del \u00c9xito:** An\u00e1lisis de la efectividad de las acciones correctivas y preventivas implementadas.\n\n**3. Gesti\u00f3n de Cambios y Configuraci\u00f3n del Sistema:**\n   - **Importancia de la Gesti\u00f3n de Cambios:** Fundamental para mantener la conformidad de sistemas y procesos. Todos los cambios deben pasar por un control formal.\n   - **Evaluaci\u00f3n de Impacto y Riesgo:** Asegurar que los cambios propuestos sean revisados adecuadamente.\n   - **Documentaci\u00f3n y Pruebas:** Los cambios deben ser documentados, probados y aprobados antes de su implementaci\u00f3n.\n   - **Gesti\u00f3n de Configuraci\u00f3n:** Actividades necesarias para definir con precisi\u00f3n el sistema en cualquier etapa de su ciclo de vida, desde el desarrollo hasta el retiro.\n\n### Entidades Clave\n- **CAPA (Acci\u00f3n Correctiva y Preventiva)**\n- **Propietario del Proceso**\n- **Unidad de Calidad**\n- **Especialista en la Materia (SME)**\n- **Gesti\u00f3n de Cambios**\n- **Gesti\u00f3n de Configuraci\u00f3n**\n- **Causa Ra\u00edz**\n- **Documentaci\u00f3n**\n- **Evaluaci\u00f3n de Impacto y Riesgo** \n\nEste resumen destaca las responsabilidades, procesos y la importancia de la gesti\u00f3n de cambios y configuraci\u00f3n en el contexto de la validaci\u00f3n de sistemas inform\u00e1ticos seg\u00fan las directrices de ANVISA.", "excerpt_keywords": "Keywords: configuration management, change management, validation, risk assessment, documentation"}}, "f37402a7-6e7b-4fa7-914c-62435d55e6c9": {"node_ids": ["95d39973-156c-4ab7-a7e4-1ee24e7c4886"], "metadata": {"page_label": "75", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# Configuration Management\n\nConfiguration management during the operational phase should begin with the configuration called baseline (initial) and associated configuration management records. This information should be part of the system delivery stage by the validation team for the operational environment (routine).\n\nConfiguration Management consists of the following activities:\n\n- Configuration Identification - WHAT must be kept in control;\n- Configuration Control - HOW to perform the control;\n- Configuration Status - HOW to document the control;\n- Configuration Evaluation - HOW to check the control.\n\nThere should be a standard operating procedure involving the activities, responsibilities, procedures and schedules related to configuration management during the operational phase of the system.\n\nConfiguration management and associated records are an essential part of recovery activity disasters, where the system and its components can be correctly reassembled and integrated for the operational reestablishment of the computerized system.\n\n## Configuration Identification\n\nThe components of the systems subject to configuration management must be clearly established. The system must be broken down into configuration items, which must be identified during the definition of specifications and development.\n\nA configuration item is a component of the system that does not change as a result of an operation normal system. Configuration items should be modified only by applying changes. Examples of configuration items are: application software; embedded software, hardware and system documentation.\n\nThe formally established list of configuration items and their versions are referred to as configuration baseline (*Configuration baseline*).", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos establece la importancia de la gesti\u00f3n de la configuraci\u00f3n durante la fase operativa de un sistema. Se define la gesti\u00f3n de la configuraci\u00f3n como un conjunto de actividades que incluyen la identificaci\u00f3n, control, documentaci\u00f3n y evaluaci\u00f3n de la configuraci\u00f3n. Se enfatiza la necesidad de un procedimiento operativo est\u00e1ndar que detalle las responsabilidades y actividades relacionadas con la gesti\u00f3n de la configuraci\u00f3n, as\u00ed como la importancia de mantener registros para facilitar la recuperaci\u00f3n en caso de desastres.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfCu\u00e1les son las cuatro actividades principales que componen la gesti\u00f3n de la configuraci\u00f3n seg\u00fan el documento de ANVISA?**\n   - Respuesta: Las cuatro actividades principales son: Identificaci\u00f3n de Configuraci\u00f3n, Control de Configuraci\u00f3n, Estado de Configuraci\u00f3n y Evaluaci\u00f3n de Configuraci\u00f3n.\n\n2. **\u00bfQu\u00e9 se entiende por 'elemento de configuraci\u00f3n' y c\u00f3mo se relaciona con la gesti\u00f3n de la configuraci\u00f3n?**\n   - Respuesta: Un elemento de configuraci\u00f3n es un componente del sistema que no cambia como resultado de la operaci\u00f3n normal del sistema. Estos elementos deben ser modificados solo mediante la aplicaci\u00f3n de cambios y son fundamentales para la gesti\u00f3n de la configuraci\u00f3n, ya que deben ser claramente identificados y controlados.\n\n3. **\u00bfPor qu\u00e9 es crucial tener registros de gesti\u00f3n de la configuraci\u00f3n en el contexto de la recuperaci\u00f3n de desastres?**\n   - Respuesta: Los registros de gesti\u00f3n de la configuraci\u00f3n son esenciales para las actividades de recuperaci\u00f3n de desastres porque permiten que el sistema y sus componentes sean correctamente reensamblados e integrados para restablecer la operaci\u00f3n del sistema inform\u00e1tico de manera efectiva.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Gesti\u00f3n de Configuraci\u00f3n y Gesti\u00f3n de Cambios**:\n   - Ambas actividades est\u00e1n interrelacionadas y deben manejarse en paralelo, especialmente al evaluar el impacto de los cambios propuestos.\n   - Se aplican a todos los componentes del sistema, incluyendo hardware, software y documentaci\u00f3n asociada.\n\n2. **Requisitos Clave**:\n   - La gesti\u00f3n de cambios debe ser continua hasta que el sistema sea retirado.\n   - Todos los cambios deben ser revisados, evaluados por riesgo e impacto, autorizados, documentados, probados y aprobados antes de su implementaci\u00f3n.\n   - La configuraci\u00f3n de hardware y software debe ser documentada a lo largo del ciclo de vida del sistema, con suficiente detalle para permitir la reconstrucci\u00f3n en caso de p\u00e9rdida total.\n\n3. **Responsabilidades**:\n   - **Propietario del Proceso**: Asegurar la implementaci\u00f3n de la gesti\u00f3n de cambios y configuraciones.\n   - **Unidad de Calidad**: Garantizar que se sigan los procedimientos existentes para la gesti\u00f3n de cambios.\n   - **Miembros del Equipo**: Cada miembro debe participar correctamente en el proceso de gesti\u00f3n de cambios.\n\n4. **Pruebas y Verificaci\u00f3n**:\n   - Las pruebas para verificar cambios deben ser proporcionales al riesgo que representan para la seguridad del paciente, la integridad del producto y la integridad de los datos.\n\n### Entidades Clave\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil.\n- **Gu\u00eda n\u00b0 33/2020**: Documento que establece directrices para la validaci\u00f3n de sistemas inform\u00e1ticos.\n- **Hardware y Software**: Componentes del sistema que deben ser gestionados y documentados.\n- **BPx**: Referencia a procesos o sistemas que impactan en la calidad y seguridad de productos.\n\nEste resumen destaca la importancia de un enfoque estructurado y responsable en la gesti\u00f3n de configuraciones y cambios dentro de los sistemas inform\u00e1ticos, asegurando la calidad y la seguridad en el contexto de las Buenas Pr\u00e1cticas de Manufactura.", "excerpt_keywords": "Keywords: Configuration Management, Baseline, Configuration Items, Disaster Recovery, Standard Operating Procedure"}}, "d83e698a-0fdd-43fc-a101-995d50708ee4": {"node_ids": ["0f8e54b1-bae0-416a-9f5b-5424a1e2a12e"], "metadata": {"page_label": "76", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 11.7.7 Configuration Control\n\nChanges to the configuration items must be coordinated and controlled. This includes the following activities:\n\n- Version control;\n- Change control;\n- Configuration item storage;\n- Delivery control.\n\nA unique name and version number must be used to identify each configuration item.\n\nChange control must be applied for each configuration item. Changes in _hardware_, _software_ and configuration must be carried out by authorized persons and controls must be maintained.\n\n# 11.7.8 Configuration Status\n\nThere must be documentation showing the status and history of the configuration items. Such documentation it should include: details of the changes made; latest version numbers and release identifiers. This shows that the system specifications are reviewed, updated and approved.\n\nThis activity can be performed in several ways, including through a document with version controlled by describing the baseline configuration or by using automated tools.\n\n# 11.7.9 Configuration Evaluation\n\nAll documented activities must be subject to management to ensure that the situation of the system is accurate and up-to-date and provides a source for auditing system configuration management.\n\nThe periodic review of systems in operation should include checking that current information about the system configuration is correct and accurate.\n\n# 11.7.19 Execution of Activities\n\nChange and configuration management activities involve performing the following actions, only items 2, 4 and 6 are related to configuration management, specifically:\n\n1. Proposal for change - record the details for the motivation of the change and prepare the requirements from the user to the proposed change;\n2. Assessment of the impact of the change - identification of regulatory and record impacts; identification the configuration items (system components) affected;\n3. Decision on the proposal - accept or reject;\n4. Process development - Includes: _software_, _hardware_ and documentation update;", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos establece directrices para el control de configuraci\u00f3n, el estado de configuraci\u00f3n, la evaluaci\u00f3n de configuraci\u00f3n y la ejecuci\u00f3n de actividades relacionadas con la gesti\u00f3n de cambios y configuraciones. Se enfatiza la importancia de la documentaci\u00f3n, el control de cambios, la identificaci\u00f3n de elementos de configuraci\u00f3n y la evaluaci\u00f3n peri\u00f3dica para asegurar que los sistemas operativos mantengan su integridad y cumplimiento normativo.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfQu\u00e9 elementos deben ser considerados en el control de cambios para los \u00edtems de configuraci\u00f3n seg\u00fan el documento de ANVISA?**\n   - El control de cambios debe incluir la identificaci\u00f3n de los \u00edtems de configuraci\u00f3n afectados, la evaluaci\u00f3n de los impactos regulatorios y de registro, y la autorizaci\u00f3n de las personas que realizan los cambios en hardware, software y configuraci\u00f3n.\n\n2. **\u00bfC\u00f3mo se debe documentar el estado y la historia de los \u00edtems de configuraci\u00f3n?**\n   - La documentaci\u00f3n debe incluir detalles de los cambios realizados, los n\u00fameros de versi\u00f3n m\u00e1s recientes y los identificadores de lanzamiento. Esto puede hacerse a trav\u00e9s de un documento controlado por versiones que describa la configuraci\u00f3n base o mediante herramientas automatizadas.\n\n3. **\u00bfQu\u00e9 acciones espec\u00edficas se deben llevar a cabo en la gesti\u00f3n de cambios y configuraciones seg\u00fan el documento?**\n   - Las acciones incluyen la propuesta de cambio (registrar la motivaci\u00f3n y requisitos del usuario), la evaluaci\u00f3n del impacto del cambio (identificaci\u00f3n de impactos regulatorios y de registro), la decisi\u00f3n sobre la propuesta (aceptar o rechazar) y el desarrollo del proceso (actualizaci\u00f3n de software, hardware y documentaci\u00f3n).", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n**Tema Principal: Gesti\u00f3n de la Configuraci\u00f3n**\n- La gesti\u00f3n de la configuraci\u00f3n es un proceso cr\u00edtico durante la fase operativa de un sistema inform\u00e1tico, comenzando con una configuraci\u00f3n inicial conocida como *baseline*.\n\n**Actividades de Gesti\u00f3n de la Configuraci\u00f3n:**\n1. **Identificaci\u00f3n de Configuraci\u00f3n:** Determinar qu\u00e9 elementos deben ser controlados.\n2. **Control de Configuraci\u00f3n:** Establecer c\u00f3mo se llevar\u00e1 a cabo el control.\n3. **Estado de Configuraci\u00f3n:** Documentar c\u00f3mo se realiza el control.\n4. **Evaluaci\u00f3n de Configuraci\u00f3n:** Verificar c\u00f3mo se revisa el control.\n\n**Importancia de la Gesti\u00f3n de la Configuraci\u00f3n:**\n- Se requiere un procedimiento operativo est\u00e1ndar que defina actividades, responsabilidades y cronogramas relacionados con la gesti\u00f3n de la configuraci\u00f3n.\n- Los registros de gesti\u00f3n de la configuraci\u00f3n son esenciales para la recuperaci\u00f3n ante desastres, permitiendo la correcta reensambladura e integraci\u00f3n del sistema y sus componentes.\n\n**Elementos de Configuraci\u00f3n:**\n- Los componentes del sistema deben ser claramente identificados y desglosados en *elementos de configuraci\u00f3n*, que son partes del sistema que no cambian durante la operaci\u00f3n normal.\n- Ejemplos de elementos de configuraci\u00f3n incluyen software de aplicaci\u00f3n, software embebido, hardware y documentaci\u00f3n del sistema.\n- La lista formal de elementos de configuraci\u00f3n y sus versiones se conoce como *baseline de configuraci\u00f3n*.\n\n### Entidades Clave:\n- **Gesti\u00f3n de la Configuraci\u00f3n**\n- **Baseline (Configuraci\u00f3n Inicial)**\n- **Elementos de Configuraci\u00f3n**\n- **Recuperaci\u00f3n ante Desastres**\n- **Procedimiento Operativo Est\u00e1ndar** \n\nEste resumen destaca la estructura y la importancia de la gesti\u00f3n de la configuraci\u00f3n en el contexto de la validaci\u00f3n de sistemas inform\u00e1ticos seg\u00fan el documento de ANVISA.", "excerpt_keywords": "Keywords: configuration control, change management, version control, documentation, system validation"}}, "1e70b5d9-7d70-4c51-9aab-9f5a1d0efba0": {"node_ids": ["743d43df-8b23-430c-89bd-25db18e1189a"], "metadata": {"page_label": "77", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "5. Test of the implanted change;\n6. Approval and implementation - Items to be considered: training; updating processes business and communication;\n7. Closure.\n\nRecords of activities associated with change and configuration management should be subject to periodic internal audits.\n\n## 11.8 SYSTEM REPAIR ACTIVITIES\n\n### 11.8.1 Introduction\n\nSystem Repair is the activity that consists of managing repairs or replacing components failures or defects. The repair object can even be a configuration item. It is a way of change control in which the relevant specifications are not changed.\n\nRepairing or replacing components of computer systems that fail or fail, generally related to *hardware* or infrastructure, must be managed according to a procedure defined. Such activities should be authorized and implemented only within a context of change control management.\n\nMany repair activities are emergency and require quick resolution. Therefore, the incident management and change control should be structured to allow such activities can occur without delay or without increasing the risk to the operational integrity of the system computerized.\n\nThe repair process can be integrated with the change and configuration management process, but it is a more simplified route can be used.\n\nWhen failure (or repair) could impact patient safety, product quality or integrity data, then an incident management process must be initiated.\n\nRepair or replacement records must be subject to periodic internal audits and their review must be form part of the performance management process.\n\n### 11.8.2 Key requirements\n\nThe procedures to be followed in case of system failure or defect must be established, approved and verified.\n\nAny failures and corrective actions taken must be recorded.\n\nA procedure should be established to record and analyze errors and allow corrective actions to be taken. sockets.\n\nThese activities must be documented.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "### Resumen del contexto\n\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos aborda la gesti\u00f3n de cambios y actividades de reparaci\u00f3n de sistemas. Se enfatiza la importancia de seguir procedimientos definidos para la reparaci\u00f3n o reemplazo de componentes defectuosos, asegurando que estas actividades se realicen dentro de un marco de control de cambios. Adem\u00e1s, se menciona que las actividades de reparaci\u00f3n deben ser documentadas y auditadas peri\u00f3dicamente, especialmente si pueden afectar la seguridad del paciente, la calidad del producto o la integridad de los datos.\n\n### Preguntas espec\u00edficas\n\n1. **\u00bfQu\u00e9 procedimientos deben establecerse para gestionar las actividades de reparaci\u00f3n en sistemas inform\u00e1ticos seg\u00fan la gu\u00eda de ANVISA?**\n   - La gu\u00eda establece que deben existir procedimientos aprobados y verificados para manejar fallos o defectos en los sistemas. Estos procedimientos deben incluir la autorizaci\u00f3n de las actividades de reparaci\u00f3n dentro del contexto de gesti\u00f3n de cambios.\n\n2. **\u00bfC\u00f3mo se deben manejar las actividades de reparaci\u00f3n que son consideradas emergencias?**\n   - Las actividades de reparaci\u00f3n de emergencia deben estar estructuradas dentro de la gesti\u00f3n de incidentes y control de cambios para permitir una resoluci\u00f3n r\u00e1pida, sin demoras que puedan comprometer la integridad operativa del sistema.\n\n3. **\u00bfQu\u00e9 tipo de registros deben mantenerse en relaci\u00f3n con las actividades de reparaci\u00f3n y c\u00f3mo deben ser auditados?**\n   - Se deben mantener registros de todas las fallas y las acciones correctivas tomadas. Estos registros deben ser objeto de auditor\u00edas internas peri\u00f3dicas y su revisi\u00f3n debe formar parte del proceso de gesti\u00f3n del rendimiento.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Control de Configuraci\u00f3n**:\n   - Importancia de coordinar y controlar los cambios en los \u00edtems de configuraci\u00f3n.\n   - Actividades clave: control de versiones, control de cambios, almacenamiento de \u00edtems de configuraci\u00f3n y control de entrega.\n   - Identificaci\u00f3n \u00fanica de cada \u00edtem de configuraci\u00f3n mediante un nombre y n\u00famero de versi\u00f3n.\n\n2. **Estado de Configuraci\u00f3n**:\n   - Necesidad de documentaci\u00f3n que muestre el estado y la historia de los \u00edtems de configuraci\u00f3n.\n   - Detalles que deben incluirse: cambios realizados, n\u00fameros de versi\u00f3n m\u00e1s recientes e identificadores de lanzamiento.\n   - M\u00e9todos de documentaci\u00f3n: documentos controlados por versiones o herramientas automatizadas.\n\n3. **Evaluaci\u00f3n de Configuraci\u00f3n**:\n   - Revisi\u00f3n y gesti\u00f3n de todas las actividades documentadas para asegurar la precisi\u00f3n y actualidad de la configuraci\u00f3n del sistema.\n   - Importancia de la revisi\u00f3n peri\u00f3dica de los sistemas en operaci\u00f3n.\n\n4. **Ejecuci\u00f3n de Actividades**:\n   - Acciones espec\u00edficas en la gesti\u00f3n de cambios y configuraciones:\n     - Propuesta de cambio: registro de motivaciones y requisitos del usuario.\n     - Evaluaci\u00f3n del impacto del cambio: identificaci\u00f3n de impactos regulatorios y de registro, as\u00ed como de los \u00edtems de configuraci\u00f3n afectados.\n     - Decisi\u00f3n sobre la propuesta: aceptaci\u00f3n o rechazo.\n     - Desarrollo del proceso: actualizaci\u00f3n de software, hardware y documentaci\u00f3n.\n\n### Entidades Clave\n- **\u00cdtems de Configuraci\u00f3n**: Componentes del sistema que requieren control y gesti\u00f3n.\n- **Documentaci\u00f3n**: Registros que detallan cambios, versiones y estado de los \u00edtems de configuraci\u00f3n.\n- **Autorizaci\u00f3n**: Necesidad de que los cambios sean realizados por personas autorizadas.\n- **Herramientas Automatizadas**: Opciones para facilitar la gesti\u00f3n y documentaci\u00f3n de la configuraci\u00f3n.\n\nEste resumen destaca la importancia de un enfoque sistem\u00e1tico y documentado para la gesti\u00f3n de cambios y configuraciones en sistemas inform\u00e1ticos, asegurando su integridad y cumplimiento normativo.", "excerpt_keywords": "Keywords: validation, change management, system repair, internal audits, incident management"}}, "83e36738-a729-4179-b711-b38e7d1e0ee3": {"node_ids": ["0b328365-eae4-4433-aa33-12a9aeba4033"], "metadata": {"page_label": "78", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "## 11.8.3 Responsibilities\n\nIt is the responsibility of the system owner to identify those components that are eligible for repair or replacement. Relevant information obtained in the design/validation phase may be available before and after delivery of the system, such as a list of spare parts for when the system is to be made operational.\n\nIt is the responsibility of the system owner to ensure that procedures are followed.\n\nIt is the responsibility of the team performing the repair (or replacement) to carry out the procedure complete and accurate, including record updates as needed (e.g., record book).\n\nIt is the responsibility of the Quality Unit to ensure that repair procedures are followed and appropriate actions are taken and documented.\n\n## 11.8.4 Execution of Activities\n\nIncident management activities involve performing the following actions:\n\n1. Fault identification (may be via incident management);\n2. Impact assessment - identification of the impact on regulated processes and records; identification of configuration items (system components) affected; definition of test documents and requirements;\n3. Evaluation and determination of the action to be taken - repair or replacement;\n\n4. Perform repair or replacement - including *hardware* and updating documentation and books of records;\n5. Verification of repair or replacement;\n6. Return to use - communication to users.\n\n**Note:** Items 2 to 6 should include configuration management.\n\n## 11.9 PERIODIC REVIEW\n\n### 11.9.1 Introduction\n\nPeriodic reviews are used throughout the operational life of the computerized system to verify that it remains compatible with regulatory requirements, fit for the intended use and meets the policies and company procedures. Reviews should confirm that, for system components, support necessary and the expected maintenance processes and regulatory controls (plans, procedures and records) are established.\n\nPeriodic reviews should be:\n\n- Scheduled at appropriate intervals consistent with impact and the operational history of the system.\n\nRisk assessments should be used to determine whether systems are in scope and whether the frequency", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos establece responsabilidades claras para los propietarios de sistemas, equipos de reparaci\u00f3n y unidades de calidad en la gesti\u00f3n de incidentes y mantenimiento de sistemas. Se enfatiza la importancia de seguir procedimientos establecidos, realizar evaluaciones de impacto y llevar a cabo revisiones peri\u00f3dicas para asegurar que los sistemas se mantengan en conformidad con los requisitos regulatorios y sean aptos para su uso previsto.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfCu\u00e1les son las responsabilidades espec\u00edficas del propietario del sistema en relaci\u00f3n con la identificaci\u00f3n de componentes elegibles para reparaci\u00f3n o reemplazo?**\n   - El propietario del sistema es responsable de identificar los componentes que pueden ser reparados o reemplazados, asegur\u00e1ndose de que se sigan los procedimientos establecidos y de que se disponga de informaci\u00f3n relevante, como listas de piezas de repuesto.\n\n2. **\u00bfQu\u00e9 pasos deben seguirse en la gesti\u00f3n de incidentes seg\u00fan el documento?**\n   - La gesti\u00f3n de incidentes implica varios pasos: identificaci\u00f3n de fallos, evaluaci\u00f3n del impacto, determinaci\u00f3n de la acci\u00f3n a tomar (reparaci\u00f3n o reemplazo), ejecuci\u00f3n de la reparaci\u00f3n o reemplazo, verificaci\u00f3n de la acci\u00f3n realizada y comunicaci\u00f3n del retorno a uso a los usuarios.\n\n3. **\u00bfC\u00f3mo se deben programar las revisiones peri\u00f3dicas de los sistemas inform\u00e1ticos?**\n   - Las revisiones peri\u00f3dicas deben programarse a intervalos apropiados que sean consistentes con el impacto del sistema y su historial operativo. Adem\u00e1s, se deben utilizar evaluaciones de riesgo para determinar si los sistemas est\u00e1n dentro del alcance y la frecuencia de las revisiones necesarias.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Gesti\u00f3n de Cambios y Reparaciones**:\n   - La secci\u00f3n aborda la importancia de gestionar adecuadamente las actividades de reparaci\u00f3n y reemplazo de componentes defectuosos en sistemas inform\u00e1ticos, dentro de un marco de control de cambios.\n\n2. **Procedimientos Definidos**:\n   - Se deben establecer, aprobar y verificar procedimientos espec\u00edficos para manejar fallos o defectos en los sistemas.\n\n3. **Actividades de Emergencia**:\n   - Las reparaciones de emergencia deben ser gestionadas de manera que se permita una resoluci\u00f3n r\u00e1pida, minimizando el riesgo para la integridad operativa del sistema.\n\n4. **Documentaci\u00f3n y Auditor\u00eda**:\n   - Es esencial mantener registros de todas las fallas y acciones correctivas, los cuales deben ser auditados peri\u00f3dicamente como parte del proceso de gesti\u00f3n del rendimiento.\n\n5. **Impacto en la Seguridad y Calidad**:\n   - Si una falla puede afectar la seguridad del paciente, la calidad del producto o la integridad de los datos, se debe iniciar un proceso de gesti\u00f3n de incidentes.\n\n### Entidades Clave\n\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil, responsable de la regulaci\u00f3n y validaci\u00f3n de sistemas inform\u00e1ticos en el \u00e1mbito de la salud.\n- **Sistema Inform\u00e1tico**: Conjunto de hardware y software que puede requerir reparaciones o cambios.\n- **Control de Cambios**: Proceso que asegura que todas las modificaciones en el sistema se realicen de manera controlada y documentada.\n- **Gesti\u00f3n de Incidentes**: Proceso que permite la r\u00e1pida resoluci\u00f3n de problemas que afectan la operaci\u00f3n del sistema.\n- **Auditor\u00edas Internas**: Evaluaciones peri\u00f3dicas que aseguran el cumplimiento de los procedimientos establecidos y la efectividad de las acciones correctivas. \n\nEste resumen destaca la importancia de la gesti\u00f3n adecuada de cambios y reparaciones en sistemas inform\u00e1ticos, enfatizando la necesidad de procedimientos claros, documentaci\u00f3n y auditor\u00edas para garantizar la seguridad y calidad en el \u00e1mbito de la salud.", "excerpt_keywords": "Keywords: ANVISA, computer systems validation, incident management, repair procedures, periodic review"}}, "0ebd4c0c-1965-4833-bef9-675cef79d75d": {"node_ids": ["af2d3fdd-876b-413e-bfb6-24a924d0f838"], "metadata": {"page_label": "79", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "to perform the periodic review is adequate;\n- Executed according to a pre-defined procedure;\n- Documented and with traceable corrective actions.\n\nThe periodic review process must be generic and applicable to all systems.\n\nIt may be useful to develop checklists for carrying out reviews.\n\n## 11.9.2 Key requirements\n\nA process for defining the time and scheduling periodic reviews must be defined. The periods for review of systems should be based on the impact of the system, its complexity and innovation. At risk-based decisions must be documented.\n\nProblems encountered during the review should be documented, along with corrective actions sockets. The major implications related to these corrective actions should be assessed.\n\nCorrective actions must be resolved and approved.\n\n## 11.9.3 Responsibilities\n\nIt is the responsibility of the process owner to ensure that periodic reviews are conducted and that appropriate responses to the conclusions of the review were given.\n\nIt is the responsibility of Quality Assurance to ensure that periodic reviews are scheduled, executed and documented.\n\n----\n\nGuide for Computer Systems Validation\nGuide n\u00b0 33/2020 - version 1, of 03/26/2020\n\n----\n\n## Page 74\n\nThe review should be conducted by one or more people depending on the scope of the review. Participants can include: Quality Unit; the Subject Specialist; users; Information technology; Engineering; Regulatory Affairs. The conclusions must be documented.\n\n## 11.9.4 Schedule for Review\n\nFrequencies for periodic reviews should be based on the impact of the system, its complexity and innovation.\n\nAcceptable methods include:\n- By systems, the frequency being defined in the respective system validation reports;\n- Based on regular reviews and analysis of the systems inventory;\n- Based on specific events, whether planned or not;\n- Based on the number and complexity of change requests.\n\n----\n\nhttps://translate.googleusercontent.com/translate_f\n79/112", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "### Resumen del Contexto\n\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos establece directrices para la revisi\u00f3n peri\u00f3dica de estos sistemas. Se enfatiza la importancia de que las revisiones sean ejecutadas de acuerdo a procedimientos predefinidos, documentadas y con acciones correctivas trazables. Se menciona que el proceso de revisi\u00f3n debe ser gen\u00e9rico y aplicable a todos los sistemas, y se sugiere el uso de listas de verificaci\u00f3n. Adem\u00e1s, se detallan las responsabilidades del propietario del proceso y del \u00e1rea de Aseguramiento de Calidad en la programaci\u00f3n y ejecuci\u00f3n de estas revisiones. La frecuencia de las revisiones debe basarse en el impacto, complejidad e innovaci\u00f3n del sistema.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfCu\u00e1les son los criterios espec\u00edficos que se deben considerar al definir la frecuencia de las revisiones peri\u00f3dicas de un sistema inform\u00e1tico seg\u00fan el documento de ANVISA?**\n   - Esta pregunta busca obtener detalles sobre los factores que influyen en la programaci\u00f3n de revisiones, que no se encuentran f\u00e1cilmente en otros documentos.\n\n2. **\u00bfQu\u00e9 tipo de problemas deben ser documentados durante el proceso de revisi\u00f3n y c\u00f3mo se deben evaluar las implicaciones de las acciones correctivas?**\n   - Esta pregunta se centra en el manejo de problemas espec\u00edficos que surgen durante las revisiones, proporcionando informaci\u00f3n que puede no estar disponible en otras gu\u00edas.\n\n3. **\u00bfQu\u00e9 roles y responsabilidades espec\u00edficas tienen los diferentes participantes en el proceso de revisi\u00f3n peri\u00f3dica de sistemas inform\u00e1ticos seg\u00fan el documento?**\n   - Esta pregunta busca aclarar las funciones de cada participante en el proceso de revisi\u00f3n, lo que puede no estar claramente definido en otros contextos.\n\n### Resumen de Nivel Superior\n\nEl documento de ANVISA proporciona un marco para la validaci\u00f3n de sistemas inform\u00e1ticos, destacando la importancia de las revisiones peri\u00f3dicas. Se establece que estas revisiones deben ser sistem\u00e1ticas, documentadas y basadas en un an\u00e1lisis de riesgo. Adem\u00e1s, se asignan responsabilidades claras a los propietarios de procesos y a los equipos de calidad, y se sugieren m\u00e9todos para determinar la frecuencia de las revisiones.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Responsabilidades del Propietario del Sistema**:\n   - Identificaci\u00f3n de componentes elegibles para reparaci\u00f3n o reemplazo.\n   - Asegurarse de que se sigan los procedimientos establecidos.\n   - Disponibilidad de informaci\u00f3n relevante, como listas de piezas de repuesto.\n\n2. **Responsabilidades del Equipo de Reparaci\u00f3n**:\n   - Realizar procedimientos de reparaci\u00f3n o reemplazo de manera completa y precisa.\n   - Actualizaci\u00f3n de registros seg\u00fan sea necesario.\n\n3. **Responsabilidades de la Unidad de Calidad**:\n   - Asegurar que se sigan los procedimientos de reparaci\u00f3n.\n   - Documentar las acciones apropiadas tomadas durante el proceso de reparaci\u00f3n.\n\n4. **Gesti\u00f3n de Incidentes**:\n   - Pasos a seguir: identificaci\u00f3n de fallos, evaluaci\u00f3n del impacto, determinaci\u00f3n de acciones (reparaci\u00f3n o reemplazo), ejecuci\u00f3n de la reparaci\u00f3n o reemplazo, verificaci\u00f3n de la acci\u00f3n realizada y comunicaci\u00f3n del retorno a uso a los usuarios.\n   - Importancia de la gesti\u00f3n de configuraci\u00f3n en los pasos 2 a 6.\n\n5. **Revisiones Peri\u00f3dicas**:\n   - Uso de revisiones a lo largo de la vida operativa del sistema para verificar la conformidad con requisitos regulatorios y pol\u00edticas de la empresa.\n   - Programaci\u00f3n de revisiones a intervalos apropiados basados en el impacto y la historia operativa del sistema.\n   - Uso de evaluaciones de riesgo para determinar el alcance y la frecuencia de las revisiones.\n\n### Entidades Clave\n- **Sistema Inform\u00e1tico**: Objeto de validaci\u00f3n y mantenimiento.\n- **Propietario del Sistema**: Entidad responsable de la gesti\u00f3n y mantenimiento del sistema.\n- **Equipo de Reparaci\u00f3n**: Grupo encargado de realizar reparaciones o reemplazos.\n- **Unidad de Calidad**: Entidad que supervisa el cumplimiento de los procedimientos de calidad.\n- **Incidentes**: Eventos que requieren gesti\u00f3n y resoluci\u00f3n.\n- **Revisiones Peri\u00f3dicas**: Evaluaciones programadas para asegurar la conformidad y funcionalidad del sistema. \n\nEste resumen destaca las responsabilidades y procesos clave relacionados con la gesti\u00f3n y mantenimiento de sistemas inform\u00e1ticos seg\u00fan el documento de ANVISA.", "excerpt_keywords": "Keywords: validation, periodic review, corrective actions, quality assurance, risk-based decisions"}}, "7db8007e-74a7-40d3-93b4-1227fc12fc60": {"node_ids": ["fbdeb945-9a6b-4165-a800-7c6a7438a549"], "metadata": {"page_label": "80", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 11.9.5 Reviewing a System\n\n## 11.9.5.1 Preparation\n\nRelevant information should be available for the review, such as:\n\n- System documentation, including: plans, specifications, tests, reports, traceability, risk management documentation, project reviews, user manuals, training materials and records;\n- Standard Operating Procedures for operation and maintenance;\n- Configuration management information;\n- Change management information;\n- Incident records;\n- Security and access control information;\n- Reports of any previous audits of individual systems;\n- Validation Report.\n\nThe objectives, the team and the agenda for carrying out the review must be defined. The review team must ensure that the necessary reference material and people are available and that the process owner is committed to the results of the review.\n\n## 11.9.5.2 Conducting the Review\n\nProblems encountered during the review should be documented, along with corrective actions recommended. Depending on the management process created by the company, an audit of follow-up can be scheduled.\n\nWhen setting the agenda for the review, the following points should be considered:\n\n- The documentation must be complete, up to date and correct, including:\n- \u2713 Specification and verification;\n- \u2713 Operation and maintenance;\n- \u2713 List of configuration items.\n- Records of any changes made to the system;\n- The level of change made to the system and the nature of the change;\n- Exceptional actions required by a Validation Report;\n- Reports of previous audits and the respective actions taken;\n- Any controls implemented to manage risks that are still in place effective;\n- Evidence of unstable or unreliable operation;\n- Changes in the environment, process or business requirements, legislation or accepted best practices;", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos establece directrices para la revisi\u00f3n de sistemas. Se divide en dos secciones principales: la preparaci\u00f3n para la revisi\u00f3n y la conducci\u00f3n de la misma. En la preparaci\u00f3n, se enfatiza la necesidad de tener documentaci\u00f3n relevante y la definici\u00f3n de objetivos, equipo y agenda. Durante la revisi\u00f3n, se deben documentar problemas y acciones correctivas, y se deben considerar varios aspectos de la documentaci\u00f3n y cambios en el sistema.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfQu\u00e9 tipo de documentaci\u00f3n se considera esencial para la preparaci\u00f3n de la revisi\u00f3n de un sistema seg\u00fan el documento de ANVISA?**\n   - La documentaci\u00f3n esencial incluye planes, especificaciones, pruebas, informes, documentaci\u00f3n de gesti\u00f3n de riesgos, revisiones de proyectos, manuales de usuario, materiales de capacitaci\u00f3n, procedimientos operativos est\u00e1ndar, informaci\u00f3n de gesti\u00f3n de configuraci\u00f3n y registros de incidentes.\n\n2. **\u00bfCu\u00e1les son los puntos clave que deben considerarse al establecer la agenda para la revisi\u00f3n de un sistema?**\n   - Al establecer la agenda, se deben considerar la completitud y actualidad de la documentaci\u00f3n, registros de cambios realizados al sistema, el nivel y naturaleza de los cambios, acciones excepcionales requeridas por un informe de validaci\u00f3n, informes de auditor\u00edas previas y controles implementados para gestionar riesgos.\n\n3. **\u00bfQu\u00e9 acciones deben tomarse si se encuentran problemas durante la revisi\u00f3n de un sistema?**\n   - Los problemas encontrados deben ser documentados junto con las acciones correctivas recomendadas. Dependiendo del proceso de gesti\u00f3n de la empresa, se puede programar una auditor\u00eda de seguimiento para asegurar que se aborden los problemas identificados.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Revisi\u00f3n Peri\u00f3dica de Sistemas Inform\u00e1ticos**:\n   - Importancia de realizar revisiones peri\u00f3dicas de los sistemas inform\u00e1ticos de manera sistem\u00e1tica y documentada.\n   - Las revisiones deben seguir procedimientos predefinidos y contar con acciones correctivas trazables.\n\n2. **Requisitos Clave**:\n   - Definici\u00f3n de un proceso para establecer la frecuencia y programaci\u00f3n de las revisiones, basado en el impacto, complejidad e innovaci\u00f3n del sistema.\n   - Documentaci\u00f3n de problemas encontrados durante las revisiones y evaluaci\u00f3n de las implicaciones de las acciones correctivas.\n\n3. **Responsabilidades**:\n   - **Propietario del Proceso**: Asegurar que las revisiones se realicen y que se respondan adecuadamente a las conclusiones.\n   - **Aseguramiento de Calidad**: Programar, ejecutar y documentar las revisiones peri\u00f3dicas.\n\n4. **Participantes en el Proceso de Revisi\u00f3n**:\n   - La revisi\u00f3n puede incluir a miembros de la Unidad de Calidad, Especialistas en la Materia, usuarios, Tecnolog\u00eda de la Informaci\u00f3n, Ingenier\u00eda y Asuntos Regulatorios.\n\n5. **Programaci\u00f3n de Revisiones**:\n   - La frecuencia de las revisiones debe basarse en:\n     - Informes de validaci\u00f3n de sistemas.\n     - An\u00e1lisis regular del inventario de sistemas.\n     - Eventos espec\u00edficos, planificados o no.\n     - N\u00famero y complejidad de solicitudes de cambio.\n\n### Entidades Clave:\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil.\n- **Sistema Inform\u00e1tico**: Cualquier sistema que requiera validaci\u00f3n y revisi\u00f3n peri\u00f3dica.\n- **Propietario del Proceso**: Persona responsable de la gesti\u00f3n del sistema.\n- **Aseguramiento de Calidad**: \u00c1rea encargada de garantizar la calidad y cumplimiento de los procesos.\n- **Participantes**: Incluyen a miembros de diversas \u00e1reas como Calidad, TI, Ingenier\u00eda, etc. \n\nEste resumen destaca la estructura y los elementos esenciales del proceso de revisi\u00f3n peri\u00f3dica seg\u00fan la gu\u00eda de ANVISA para la validaci\u00f3n de sistemas inform\u00e1ticos.", "excerpt_keywords": "Keywords: validation, review, documentation, corrective actions, risk management"}}, "3dc021b5-fabf-4e32-8fe0-abeeb3fce5ef": {"node_ids": ["c716a4f7-919b-4f96-b072-04b27b74bd14"], "metadata": {"page_label": "81", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "- Operational procedures;\n- Business Continuity Planning;\n- Personnel (including qualifications, training, experience and continuity);\n- System security and access control;\n- System maintenance and incident records;\n- Backups of software and data.\n\n## 11.9.6 Execution of Activities\n\nReview activities involve the following actions:\n\n1. Definition of the policy and process for establishing time and scheduling reviews periodic - Can be system specific, defined in the respective Inspection Reports; defined in the List Computerized Systems Inventory, based on triggers or events;\n2. Preparation for conducting the review - Evidence may include plans, records of previous incidents / changes, audits or reviews;\n3. Performing the review;\n4. Documentation of the results of the review;\n5. Execution of Corrective Action, if applicable.\n\n## 11.10 BACKUP AND RESTORATION\n\n### 11.10.1 Introduction\n\nBackup is the process of copying records, data and software to protect against loss of integrity or availability of the original. Restoration is the subsequent restoration of records, data or software when requested / required.\n\nBackup and restore should not be confused with archiving and recovery.\n\n----\n\n## 11.10.2 Key requirements\n\nProcedures must be in place to describe and discriminate against backups of records, data and software, carried out routinely, to a safe storage location and adequately separated from the place of primary storage. The frequency of running the backup procedure should be based on a risk assessment.\n\nWritten procedures must be in place to ensure the restoration and maintenance of records and data relevant to GMP, in the event of failure.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos establece procedimientos operativos esenciales para garantizar la integridad y disponibilidad de los datos en entornos regulados. Se enfoca en la planificaci\u00f3n de continuidad del negocio, la capacitaci\u00f3n del personal, la seguridad del sistema, el mantenimiento y la gesti\u00f3n de copias de seguridad. Adem\u00e1s, detalla los pasos necesarios para llevar a cabo revisiones peri\u00f3dicas y los requisitos clave para la realizaci\u00f3n de copias de seguridad y restauraci\u00f3n de datos.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfCu\u00e1les son los pasos espec\u00edficos que deben seguirse para llevar a cabo una revisi\u00f3n peri\u00f3dica de un sistema inform\u00e1tico seg\u00fan el documento de ANVISA?**\n   - Respuesta: Los pasos incluyen la definici\u00f3n de la pol\u00edtica y proceso para establecer el tiempo y la programaci\u00f3n de revisiones, la preparaci\u00f3n para la revisi\u00f3n, la realizaci\u00f3n de la revisi\u00f3n, la documentaci\u00f3n de los resultados y la ejecuci\u00f3n de acciones correctivas si es necesario.\n\n2. **\u00bfQu\u00e9 diferencias existen entre los procesos de copia de seguridad y restauraci\u00f3n en comparaci\u00f3n con el archivo y la recuperaci\u00f3n, seg\u00fan el documento?**\n   - Respuesta: La copia de seguridad es el proceso de copiar registros, datos y software para protegerse contra la p\u00e9rdida de integridad o disponibilidad, mientras que la restauraci\u00f3n es la recuperaci\u00f3n de esos registros o datos cuando se requiere. Esto se diferencia del archivo, que implica almacenar datos de manera que no se utilicen regularmente, y la recuperaci\u00f3n, que se refiere a la restauraci\u00f3n de datos despu\u00e9s de un evento de p\u00e9rdida.\n\n3. **\u00bfQu\u00e9 requisitos clave se deben cumplir para la realizaci\u00f3n de copias de seguridad de registros y datos seg\u00fan el documento de ANVISA?**\n   - Respuesta: Se deben establecer procedimientos que describan las copias de seguridad de registros, datos y software, que se realicen de manera rutinaria en una ubicaci\u00f3n de almacenamiento segura, separada del almacenamiento primario. La frecuencia de las copias de seguridad debe basarse en una evaluaci\u00f3n de riesgos, y deben existir procedimientos escritos para garantizar la restauraci\u00f3n y el mantenimiento de registros y datos relevantes para las Buenas Pr\u00e1cticas de Manufactura (GMP) en caso de fallo.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n#### Temas Clave:\n1. **Preparaci\u00f3n para la Revisi\u00f3n**:\n   - Importancia de la documentaci\u00f3n relevante para la revisi\u00f3n del sistema.\n   - Definici\u00f3n de objetivos, equipo y agenda para la revisi\u00f3n.\n   - Compromiso del propietario del proceso con los resultados de la revisi\u00f3n.\n\n2. **Documentaci\u00f3n Esencial**:\n   - Tipos de documentaci\u00f3n necesarios: planes, especificaciones, pruebas, informes, documentaci\u00f3n de gesti\u00f3n de riesgos, manuales de usuario, procedimientos operativos est\u00e1ndar, informaci\u00f3n de gesti\u00f3n de configuraci\u00f3n, registros de incidentes, y reportes de auditor\u00edas previas.\n\n3. **Conducci\u00f3n de la Revisi\u00f3n**:\n   - Documentaci\u00f3n de problemas encontrados y acciones correctivas recomendadas.\n   - Consideraciones para establecer la agenda de la revisi\u00f3n, incluyendo la completitud y actualidad de la documentaci\u00f3n, registros de cambios, y controles de gesti\u00f3n de riesgos.\n\n4. **Acciones Correctivas**:\n   - Proceso de seguimiento en caso de problemas identificados durante la revisi\u00f3n.\n\n#### Entidades:\n- **Documentaci\u00f3n**: Planes, especificaciones, pruebas, informes, manuales de usuario, etc.\n- **Equipo de Revisi\u00f3n**: Grupo responsable de llevar a cabo la revisi\u00f3n del sistema.\n- **Propietario del Proceso**: Persona o entidad comprometida con los resultados de la revisi\u00f3n.\n- **Auditor\u00eda**: Proceso de seguimiento para asegurar que se aborden los problemas identificados.\n- **Controles de Riesgo**: Medidas implementadas para gestionar riesgos en el sistema.\n\nEste resumen destaca la importancia de la preparaci\u00f3n y la documentaci\u00f3n en el proceso de revisi\u00f3n de sistemas, as\u00ed como la necesidad de un enfoque sistem\u00e1tico para abordar problemas y asegurar la conformidad con las normativas.", "excerpt_keywords": "Keywords: validation, backup, restoration, compliance, operational procedures"}}, "812a04f9-69bf-4f1b-91c1-bf1e942e3394": {"node_ids": ["519bc754-1312-4f67-830e-516f302b7c80"], "metadata": {"page_label": "82", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "The backup procedure, storage facilities and media used must ensure the integrity of Dice. There should be a record of the backup performed, with references to the media used for storage.\n\nThe storage medium used must be documented and justified as to its reliability.\n\nBackup processes must be verified when they are established. Additionally, there must be procedures and plans for regular testing of the ability to perform backup and restore. These actions must be documented.\n\n## 11.10.3 Responsibilities\n\nThe process owner is responsible for:\n\n- Definition of the data that need backup, including the data relevant to GMP;\n- Definition of availability and access control requirements for GMP-relevant data.\n\nThe system owner is responsible for:\n\n- Ensure that the organization of the backup and restoration of the software for the operating system is defined meet the applicable regulations, in accordance with the Quality Assurance guidelines, when applicable;\n- Ensure proper backup and restore performance of software and data for the system operational;\n- Ensure appropriate access controls.\n\n## 11.10.4 Backup and Restore Process\n\n### 11.10.4.1 Backup Media\n\nThe backup must be performed on suitable media and it must be used according to the recommendation of the manufacturers.\n\nWhen selecting and using storage media, the following points should be considered:\n\n- The average life expectancy;\n- The acceptable environmental conditions for its storage;\n- Requirements for verification, renewal and overwriting.\n\nGuidance on storage, transport and maintenance of various types of media, magnetic and optical, used in data storage are generally available in the documentation provided by the manufacturer of product.\n\n## 11.10.4.2 Backup of the Operating System\n\nThe backups of software are designed to ensure that the latest and correct version of the software is available.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas basadas en el contexto proporcionado, junto con sus respuestas:\n\n### Preguntas y Respuestas\n\n1. **\u00bfCu\u00e1les son las responsabilidades espec\u00edficas del propietario del proceso en relaci\u00f3n con el respaldo de datos relevantes para GMP?**\n   - **Respuesta:** El propietario del proceso es responsable de definir los datos que necesitan respaldo, incluyendo aquellos relevantes para las Buenas Pr\u00e1cticas de Manufactura (GMP), as\u00ed como de establecer los requisitos de disponibilidad y control de acceso para esos datos.\n\n2. **\u00bfQu\u00e9 aspectos deben considerarse al seleccionar y utilizar medios de almacenamiento para respaldos?**\n   - **Respuesta:** Al seleccionar y utilizar medios de almacenamiento para respaldos, se deben considerar la expectativa de vida promedio del medio, las condiciones ambientales aceptables para su almacenamiento, y los requisitos para la verificaci\u00f3n, renovaci\u00f3n y sobrescritura del medio.\n\n3. **\u00bfQu\u00e9 documentaci\u00f3n se requiere para los procesos de respaldo y restauraci\u00f3n?**\n   - **Respuesta:** Se requiere que los procesos de respaldo sean verificados al establecerse, y que existan procedimientos y planes para pruebas regulares de la capacidad de realizar respaldos y restauraciones. Todas estas acciones deben ser documentadas adecuadamente.\n\n### Resumen de Nivel Superior\n\nEl contexto aborda la importancia de los procedimientos de respaldo y restauraci\u00f3n en sistemas inform\u00e1ticos, enfatizando la necesidad de asegurar la integridad de los datos, especialmente aquellos relevantes para las Buenas Pr\u00e1cticas de Manufactura (GMP). Se detallan las responsabilidades de los propietarios de procesos y sistemas, as\u00ed como los criterios para seleccionar medios de almacenamiento adecuados. Adem\u00e1s, se subraya la importancia de la documentaci\u00f3n y verificaci\u00f3n de los procesos de respaldo.\n\n### Preguntas Adicionales Basadas en el Resumen\n\n1. **\u00bfPor qu\u00e9 es crucial documentar los medios de almacenamiento utilizados para los respaldos?**\n   - **Respuesta:** Es crucial documentar los medios de almacenamiento utilizados para los respaldos para justificar su fiabilidad y asegurar que se cumplen los requisitos de calidad y regulaciones aplicables.\n\n2. **\u00bfQu\u00e9 tipo de pruebas deben realizarse regularmente en los procesos de respaldo y restauraci\u00f3n?**\n   - **Respuesta:** Deben realizarse pruebas regulares para verificar la capacidad de realizar respaldos y restauraciones efectivas, asegurando que los datos pueden ser recuperados de manera confiable en caso de p\u00e9rdida.\n\n3. **\u00bfQu\u00e9 se entiende por \"integridad de Dice\" en el contexto de los procedimientos de respaldo?**\n   - **Respuesta:** La \"integridad de Dice\" se refiere a la protecci\u00f3n y conservaci\u00f3n de la informaci\u00f3n y datos almacenados, asegurando que no se pierdan ni se corrompan durante el proceso de respaldo y restauraci\u00f3n.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Procedimientos Operativos**: Se enfatiza la importancia de tener procedimientos operativos bien definidos para garantizar la integridad y disponibilidad de los datos en sistemas inform\u00e1ticos regulados.\n\n2. **Planificaci\u00f3n de Continuidad del Negocio**: Se menciona la necesidad de establecer planes que aseguren la continuidad de las operaciones en caso de incidentes.\n\n3. **Personal**: Se aborda la importancia de contar con personal calificado, capacitado y con experiencia, as\u00ed como la continuidad en su formaci\u00f3n.\n\n4. **Seguridad del Sistema y Control de Acceso**: Se requiere implementar medidas de seguridad para proteger los sistemas y controlar el acceso a los mismos.\n\n5. **Mantenimiento del Sistema y Registros de Incidentes**: Se deben llevar registros de mantenimiento y de incidentes para asegurar la trazabilidad y la mejora continua.\n\n6. **Copias de Seguridad de Software y Datos**: Se establece la necesidad de realizar copias de seguridad de manera rutinaria y en ubicaciones seguras, separadas del almacenamiento primario.\n\n### Ejecuci\u00f3n de Actividades de Revisi\u00f3n\n\n- **Definici\u00f3n de Pol\u00edticas**: Establecer pol\u00edticas y procesos para programar revisiones peri\u00f3dicas.\n- **Preparaci\u00f3n para la Revisi\u00f3n**: Reunir evidencia relevante, como planes y registros de incidentes anteriores.\n- **Realizaci\u00f3n de la Revisi\u00f3n**: Llevar a cabo la revisi\u00f3n seg\u00fan lo planificado.\n- **Documentaci\u00f3n de Resultados**: Registrar los hallazgos de la revisi\u00f3n.\n- **Acciones Correctivas**: Implementar acciones correctivas si se identifican problemas.\n\n### Copias de Seguridad y Restauraci\u00f3n\n\n- **Definici\u00f3n de Copia de Seguridad**: Proceso de copiar datos y software para protegerse contra la p\u00e9rdida de integridad o disponibilidad.\n- **Restauraci\u00f3n**: Proceso de recuperar datos o software cuando sea necesario.\n- **Diferenciaci\u00f3n**: Se aclara que las copias de seguridad y la restauraci\u00f3n no son lo mismo que el archivo y la recuperaci\u00f3n.\n\n### Requisitos Clave para Copias de Seguridad\n\n- **Procedimientos Escritos**: Deben existir procedimientos que describan c\u00f3mo se realizan las copias de seguridad y la restauraci\u00f3n de datos.\n- **Frecuencia Basada en Riesgos**: La frecuencia de las copias de seguridad debe determinarse a partir de una evaluaci\u00f3n de riesgos.\n- **Mantenimiento de Registros**: Asegurar la restauraci\u00f3n y mantenimiento de registros relevantes para las Buenas Pr\u00e1cticas de Manufactura (GMP) en caso de fallos.\n\nEste resumen abarca los aspectos fundamentales del documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos, destacando la importancia de la planificaci\u00f3n, la seguridad y la gesti\u00f3n de datos.", "excerpt_keywords": "Keywords: backup procedure, data integrity, GMP compliance, storage media, system validation"}}, "63a2000e-1fd5-4a74-860f-59a3fe0b7e91": {"node_ids": ["8c01c01b-3a92-41b6-9eb8-869049a840c9"], "metadata": {"page_label": "83", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "and can be restored in a short time and without error, in case of failure or after changes made during development.\n\nAll software components required for the operating system must be included in the scope of the backup to ensure that the entire system can be restored.\n\nThe process backup of the software should be defined and documented. This backup can occur:\n\n- After any modification of the software, in which case backing up the components modified software may be sufficient. This activity should be documented as part of the control of changes;\n- At regular intervals (e.g. annually) as a full backup, based on the risk and nature of the business.\n\nBackup copies must be stored in a safe place.\n\nBackup media must be physically safe and protected from fire, water and other hazards. The process of storage, standards and access must be defined and documented.\n\nAt least two generations of backup copies must be stored: the current one and the one before the last change fulfilled. Based on the risk, it may be advisable to keep more generations to avoid the possibility of propagation of errors in all available backup copies.\n\nThe following data must be clearly associated with the backup media, either on the label or in a record, in a traceable manner:\n\n- Creation date;\n- System designation;\n- Software designation;\n- Model and/or software/firmware build number (build number), if applicable;\n- Current number (generation and possible multiple backups);\n- Reason for backing up the software;\n- Backup date;\n- Identity of the person who performed the backup.\n\nBackups of the software should be performed while the system is operating. Backup logs performed must be maintained. Backup and restore instructions should be stored securely together with the backup media.\n\nRisk-based and process backup, the transactions backup should be reviewed periodically and Backup restoration should be periodically performed to verify that it will work correctly when required.\n\n## 11.10.4.3 Backup of Data\n\nElectronic data relevant to GMP must be kept secure for the defined retention time. While data is often kept on a hard disk using redundancy concepts or mirrored disks, additional backups of GMP-relevant data form a key part of preventing", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos establece directrices sobre la importancia de realizar copias de seguridad de software y datos relevantes para las Buenas Pr\u00e1cticas de Manufactura (GMP). Se enfatiza la necesidad de documentar el proceso de copia de seguridad, almacenar las copias en lugares seguros, y mantener registros claros sobre las copias de seguridad realizadas. Adem\u00e1s, se menciona la importancia de realizar copias de seguridad peri\u00f3dicas y de verificar la restauraci\u00f3n de datos para asegurar su integridad y disponibilidad.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfQu\u00e9 informaci\u00f3n debe estar claramente asociada con los medios de copia de seguridad seg\u00fan el documento de ANVISA?**\n   - El documento especifica que deben estar asociadas las siguientes informaciones: fecha de creaci\u00f3n, designaci\u00f3n del sistema, designaci\u00f3n del software, n\u00famero de modelo y/o n\u00famero de compilaci\u00f3n de software/firmware, n\u00famero actual (generaci\u00f3n y posibles copias m\u00faltiples), raz\u00f3n para la copia de seguridad, fecha de copia de seguridad e identidad de la persona que realiz\u00f3 la copia.\n\n2. **\u00bfCu\u00e1les son las recomendaciones sobre la frecuencia de las copias de seguridad de software y en qu\u00e9 situaciones se deben realizar?**\n   - Se recomienda realizar copias de seguridad despu\u00e9s de cualquier modificaci\u00f3n del software y a intervalos regulares (por ejemplo, anualmente) como una copia de seguridad completa, dependiendo del riesgo y la naturaleza del negocio.\n\n3. **\u00bfQu\u00e9 medidas de seguridad se deben tomar para el almacenamiento de las copias de seguridad?**\n   - Las copias de seguridad deben almacenarse en un lugar seguro, y los medios de copia de seguridad deben estar f\u00edsicamente protegidos contra incendios, agua y otros peligros. Adem\u00e1s, el proceso de almacenamiento, est\u00e1ndares y acceso debe estar definido y documentado.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n**Temas Clave:**\n\n1. **Procedimientos de Respaldo:**\n   - Importancia de asegurar la integridad de los datos durante el proceso de respaldo.\n   - Necesidad de documentar y justificar los medios de almacenamiento utilizados.\n\n2. **Responsabilidades:**\n   - **Propietario del Proceso:** Define los datos que necesitan respaldo y los requisitos de disponibilidad y control de acceso para datos relevantes a las Buenas Pr\u00e1cticas de Manufactura (GMP).\n   - **Propietario del Sistema:** Asegura que los procesos de respaldo y restauraci\u00f3n cumplan con las regulaciones aplicables y las directrices de Aseguramiento de Calidad.\n\n3. **Medios de Respaldo:**\n   - Selecci\u00f3n de medios adecuados considerando la expectativa de vida, condiciones ambientales y requisitos de verificaci\u00f3n.\n   - Uso de medios de almacenamiento de acuerdo con las recomendaciones del fabricante.\n\n4. **Verificaci\u00f3n y Documentaci\u00f3n:**\n   - Los procesos de respaldo deben ser verificados al establecerse.\n   - Se deben tener procedimientos y planes para pruebas regulares de respaldo y restauraci\u00f3n, todos documentados adecuadamente.\n\n5. **Respaldo del Sistema Operativo:**\n   - Asegurar que se disponga de la versi\u00f3n m\u00e1s reciente y correcta del software a trav\u00e9s de respaldos.\n\n**Entidades:**\n\n- **GMP (Buenas Pr\u00e1cticas de Manufactura):** Normativas relevantes para la industria que deben ser consideradas en los procesos de respaldo.\n- **Propietario del Proceso:** Persona responsable de la definici\u00f3n de datos y requisitos de acceso.\n- **Propietario del Sistema:** Persona encargada de la organizaci\u00f3n y cumplimiento de los procesos de respaldo y restauraci\u00f3n.\n- **Medios de Almacenamiento:** Dispositivos utilizados para realizar respaldos, que deben ser seleccionados y utilizados adecuadamente.\n- **Documentaci\u00f3n:** Registros que deben mantenerse para verificar y validar los procesos de respaldo y restauraci\u00f3n.\n\nEste resumen destaca la importancia de los procedimientos de respaldo en sistemas inform\u00e1ticos, enfatizando la necesidad de responsabilidades claras, selecci\u00f3n adecuada de medios y documentaci\u00f3n rigurosa para garantizar la integridad y disponibilidad de los datos.", "excerpt_keywords": "Keywords: backup, software validation, GMP, data security, documentation"}}, "1ec71e0f-34db-4e11-8e7b-07dd594810ec": {"node_ids": ["67088541-d093-471b-a8a6-a237b7cc7f6b"], "metadata": {"page_label": "84", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "loss of data in case of system failure. The data must be recoverable in a short time and without error and copies kept remotely to avoid loss due to some common failure in one location (e.g., fire). The type and frequency of the **backup** should be based on risk.\n\nThe data must be periodically saved on the **backup media**. The system owner must establish and document the organization of data **backups**, covering the following aspects:\n\n- **Backup types** (full or incremental);\n- **Interval**: daily, weekly, monthly, quarterly, annual or non-cyclical (permanent retention);\n- **Number of generations**. The number of generations defines the number of identically performed backups that are maintained. Since **backup** media is often reused, after the number of generations has been reached, subsequent **backups** will be overwritten over the oldest **backup**. For example: if the number of generations set to four, the fifth **backup** will overwrite the first, the sixth will overwrite the second and so on;\n- **Backup failure** - Actions to be taken in case of **backup** failure must be established, such as a repeat **backup** during the day. Actions taken in the event of failure should be documented (e.g., logbook) by the person responsible for the computerized system;\n- **Backup Media Labeling**. The following items must appear on the media label, or registered at record book: system designation; **software / data designation**; version and / or build number the **software / firmware** (if applicable); creation date; date of first use; current number (generations, possible multiple backups); **backup** date; reason for **backup** and operator identity;\n- **Duration of use**. The media should only be used for as long as it is guaranteed;\n- The type of media used must be documented;\n- **Storage Location**. Storage locations must be safe and properly identified and traceable;\n- **Data Backup Tools and Corresponding Procedures**. GMP-relevant data should be stored in an appropriate way that allows their restoration. The location and name of the procedure control must be documented. Procedures must cover restoration, verification activities and restart after system failure;\n- **Data Backup Review**. The process owner, or delegated person, is responsible for ensuring successful **backup**. Faults should be investigated and defective storage media potentials must be discarded and replaced. The actions must be documented in a record book.\n\n## 11.10.4.4 Restoration\n\nWritten and tested procedures must be used to perform the restoration. When the restoration is performed manually, this must be registered and signed.\n\nThe process owner, or delegated person, must authorize the restoration of data. These people are the responsible for ensuring that the restoration procedure is in compliance with the regulations of Good habits.\n\nIf the restoration is motivated by technical reasons, the owner of the process and the owner of the system must make a assessment of the process and possible risks. The restoration method used and the control of the restoration must be documented.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos establece directrices claras sobre la gesti\u00f3n de copias de seguridad (backups) y la restauraci\u00f3n de datos en caso de fallos del sistema. Se enfatiza la importancia de la recuperaci\u00f3n de datos de manera r\u00e1pida y sin errores, as\u00ed como la necesidad de mantener copias de seguridad en ubicaciones remotas para evitar p\u00e9rdidas. Se detallan aspectos como los tipos de copias de seguridad, la frecuencia, la gesti\u00f3n de fallos, el etiquetado de medios de copia de seguridad, y la documentaci\u00f3n necesaria para garantizar la integridad y disponibilidad de los datos.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfCu\u00e1les son los criterios que deben considerarse al establecer el intervalo de copias de seguridad seg\u00fan el documento de ANVISA?**\n   - El intervalo de copias de seguridad debe basarse en el riesgo asociado a la p\u00e9rdida de datos, y puede ser diario, semanal, mensual, trimestral, anual o no c\u00edclico (retenci\u00f3n permanente).\n\n2. **\u00bfQu\u00e9 informaci\u00f3n debe incluirse en la etiqueta de los medios de copia de seguridad seg\u00fan las directrices de ANVISA?**\n   - La etiqueta debe incluir: designaci\u00f3n del sistema, designaci\u00f3n del software/datos, versi\u00f3n y/o n\u00famero de compilaci\u00f3n del software/firmware (si aplica), fecha de creaci\u00f3n, fecha de primer uso, n\u00famero actual (generaciones, posibles copias m\u00faltiples), fecha de copia de seguridad, raz\u00f3n de la copia de seguridad e identidad del operador.\n\n3. **\u00bfQu\u00e9 acciones deben tomarse en caso de fallo en la copia de seguridad y c\u00f3mo deben documentarse?**\n   - Se deben establecer acciones a seguir en caso de fallo, como repetir la copia de seguridad durante el d\u00eda. Las acciones tomadas deben ser documentadas en un libro de registro por la persona responsable del sistema computarizado.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\nEl contenido de la secci\u00f3n se centra en las directrices para la copia de seguridad de software y datos en el contexto de la validaci\u00f3n de sistemas inform\u00e1ticos seg\u00fan ANVISA. A continuaci\u00f3n se presentan los temas clave y entidades relevantes:\n\n#### Temas Clave:\n1. **Importancia de las Copias de Seguridad**: Se enfatiza la necesidad de realizar copias de seguridad para asegurar la recuperaci\u00f3n del sistema en caso de fallos o modificaciones.\n2. **Documentaci\u00f3n del Proceso**: El proceso de copia de seguridad debe ser definido y documentado, incluyendo las circunstancias bajo las cuales se realizan las copias.\n3. **Frecuencia de las Copias de Seguridad**: Se recomienda realizar copias de seguridad despu\u00e9s de modificaciones y a intervalos regulares (por ejemplo, anualmente).\n4. **Almacenamiento Seguro**: Las copias de seguridad deben almacenarse en lugares seguros y los medios de copia deben estar protegidos contra riesgos f\u00edsicos como incendios y agua.\n5. **Generaciones de Copias de Seguridad**: Se deben mantener al menos dos generaciones de copias de seguridad para evitar la propagaci\u00f3n de errores.\n6. **Datos Asociados a las Copias de Seguridad**: Se debe registrar informaci\u00f3n clave como la fecha de creaci\u00f3n, designaci\u00f3n del sistema y software, y la identidad de la persona que realiz\u00f3 la copia.\n7. **Mantenimiento de Registros**: Se deben mantener registros de las copias de seguridad y las instrucciones de restauraci\u00f3n deben almacenarse de manera segura.\n8. **Revisi\u00f3n Peri\u00f3dica**: Las copias de seguridad y su restauraci\u00f3n deben ser revisadas peri\u00f3dicamente para asegurar su efectividad.\n\n#### Entidades:\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil, responsable de la regulaci\u00f3n de la salud p\u00fablica.\n- **GMP**: Buenas Pr\u00e1cticas de Manufactura, que se refiere a las pr\u00e1cticas que aseguran que los productos sean producidos y controlados de acuerdo con est\u00e1ndares de calidad.\n- **Software**: Componentes de software que requieren copias de seguridad.\n- **Datos Electr\u00f3nicos**: Informaci\u00f3n relevante para GMP que debe ser protegida y respaldada.\n\nEste resumen destaca la importancia de un enfoque sistem\u00e1tico y documentado para la gesti\u00f3n de copias de seguridad en sistemas inform\u00e1ticos, asegurando la integridad y disponibilidad de los datos cr\u00edticos.", "excerpt_keywords": "Keywords: backups, data recovery, ANVISA, system validation, documentation"}}, "46739c31-4f45-4c47-ad64-8f751f42fa94": {"node_ids": ["7c20cbe8-9dd8-4c83-91c5-3ec8e51aa9f9"], "metadata": {"page_label": "85", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 11.10.4.5 Long Term Integrity\n\nElectronic storage media degrades over time, therefore, media reuse must be carried out according to the manufacturer's guidelines regarding its useful life.\n\nIn the unlikely event that a backup copy will be kept for a period approaching the end of its life media, the integrity of the backups contained on the media should be reviewed according to the specifications manufacturer. It is preferable to copy the data onto new media rather than review the old media.\n\nThe procedures for backup and restore must be checked periodically. The frequency should be based on risk. This verification can be performed by means of restoring the backup to a backup system, test and verifying its correct operation.\n\nA common and pragmatic approach is to combine verification of the backup process with testing disaster recovery. The restoration of the backup to the system running in production, with the purpose testing is not recommended, as an error in the procedure can result in data loss.\n\nThe procedures backup and restoration should be checked during the periodic review of the system. At conclusions must be documented.\n\n# 11.10.5 Execution of Activities\n\nThe activities backup and restoration involve performing the following actions:\n\n1. Risk assessment, taking into account the probability and risk of damage occurring;\n2. Definition of the strategy for carrying out backup operations, covering: frequency, location of storage, required response times, retention period and storage media;\n3. Development of written backup and restoration procedures, covering: responsibilities, training and documentation;\n4. Definition of test procedures and plans to verify backup and backup operations restoration;\n5. Execution of tests, documenting the results and actions taken;\n6. Execution of backup operations according to established procedure;\n7. Monitoring the system during its operational life.\n\n# 11.11 BUSINESS CONTINUITY PLANNING / DISASTER RECOVERY\n\n## 11.11.1 Introduction\n\nBusiness Continuity Planning consists of a series of activities and related processes with the guarantee that the regulated company is fully prepared to respond effectively when failure and disturbance.\n\nCritical business processes and systems that support these processes must be identified and their associated risks should be assessed. Plans must be established and exercised to ensure the timely and effective resumption of these processes and critical systems for the business.\n\nThe Business Continuity Plan defines how the business can continue to function and how to deal with data after failures occur. Defines the steps required to restore business processes after the occurrence of a disaster and how the data generated during the occurrence of this event should be", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "### Resumen del Contexto\n\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos aborda la importancia de la integridad a largo plazo de los medios de almacenamiento electr\u00f3nico y la planificaci\u00f3n de la continuidad del negocio. Se enfatiza que los medios de almacenamiento se degradan con el tiempo y que deben seguirse las pautas del fabricante para su reutilizaci\u00f3n. Adem\u00e1s, se describen procedimientos para la realizaci\u00f3n de copias de seguridad y restauraci\u00f3n, as\u00ed como la importancia de evaluar riesgos y establecer estrategias adecuadas. La planificaci\u00f3n de la continuidad del negocio se centra en garantizar que una empresa est\u00e9 preparada para responder a fallos y perturbaciones, identificando procesos cr\u00edticos y evaluando riesgos asociados.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfCu\u00e1les son las recomendaciones espec\u00edficas para la verificaci\u00f3n de la integridad de las copias de seguridad en medios que se acercan al final de su vida \u00fatil?**\n   - El documento sugiere que, en caso de que se mantenga una copia de seguridad en medios que se acercan al final de su vida \u00fatil, se debe revisar la integridad de las copias de seguridad de acuerdo con las especificaciones del fabricante. Sin embargo, se prefiere copiar los datos a nuevos medios en lugar de revisar los antiguos.\n\n2. **\u00bfQu\u00e9 acciones deben llevarse a cabo para asegurar la correcta ejecuci\u00f3n de las operaciones de copia de seguridad y restauraci\u00f3n?**\n   - Las acciones incluyen realizar una evaluaci\u00f3n de riesgos, definir una estrategia para las operaciones de copia de seguridad, desarrollar procedimientos escritos, definir procedimientos de prueba, ejecutar pruebas y documentar los resultados, llevar a cabo las operaciones de copia de seguridad seg\u00fan el procedimiento establecido y monitorear el sistema durante su vida operativa.\n\n3. **\u00bfC\u00f3mo se define un Plan de Continuidad del Negocio y qu\u00e9 aspectos clave debe incluir?**\n   - Un Plan de Continuidad del Negocio define c\u00f3mo la empresa puede seguir funcionando y c\u00f3mo manejar los datos despu\u00e9s de que ocurran fallos. Debe incluir la identificaci\u00f3n de procesos cr\u00edticos, la evaluaci\u00f3n de riesgos asociados, y los pasos necesarios para restaurar los procesos comerciales despu\u00e9s de un desastre, as\u00ed como el manejo de los datos generados durante dicho evento.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Importancia de las Copias de Seguridad**:\n   - Se enfatiza la necesidad de realizar copias de seguridad para garantizar la recuperaci\u00f3n de datos en caso de fallos del sistema. Las copias deben ser recuperables r\u00e1pidamente y sin errores.\n\n2. **Organizaci\u00f3n de las Copias de Seguridad**:\n   - **Tipos de Copias**: Se deben definir si ser\u00e1n completas o incrementales.\n   - **Intervalo de Copias**: Debe basarse en el riesgo y puede ser diario, semanal, mensual, trimestral, anual o no c\u00edclico.\n   - **N\u00famero de Generaciones**: Se establece cu\u00e1ntas copias se mantendr\u00e1n antes de sobrescribir las m\u00e1s antiguas.\n\n3. **Manejo de Fallos en las Copias de Seguridad**:\n   - Se deben establecer acciones a seguir en caso de fallo, como repetir la copia de seguridad, y documentar estas acciones.\n\n4. **Etiquetado de Medios de Copia de Seguridad**:\n   - La etiqueta debe incluir informaci\u00f3n clave como la designaci\u00f3n del sistema, versi\u00f3n del software, fechas relevantes y la identidad del operador.\n\n5. **Duraci\u00f3n y Tipo de Medios**:\n   - Los medios de copia de seguridad deben ser utilizados solo durante el tiempo garantizado y su tipo debe ser documentado.\n\n6. **Ubicaci\u00f3n de Almacenamiento**:\n   - Las ubicaciones de almacenamiento deben ser seguras, identificadas y trazables.\n\n7. **Herramientas y Procedimientos de Copia de Seguridad**:\n   - Se deben documentar las herramientas utilizadas y los procedimientos para la restauraci\u00f3n y verificaci\u00f3n de datos.\n\n8. **Revisi\u00f3n de Copias de Seguridad**:\n   - El propietario del proceso es responsable de asegurar el \u00e9xito de las copias de seguridad y debe documentar cualquier fallo y las acciones tomadas.\n\n9. **Restauraci\u00f3n de Datos**:\n   - Se deben seguir procedimientos escritos y probados para la restauraci\u00f3n, que deben ser autorizados y documentados por el propietario del proceso o una persona delegada.\n\n### Entidades Clave\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil.\n- **Sistema Computarizado**: Referido en el contexto de la gesti\u00f3n de datos y copias de seguridad.\n- **Datos**: Informaci\u00f3n que debe ser respaldada y restaurada.\n- **Medios de Copia de Seguridad**: Dispositivos o soportes donde se almacenan las copias de seguridad.\n- **Procedimientos**: Documentaci\u00f3n que gu\u00eda las acciones de copia y restauraci\u00f3n de datos. \n\nEste resumen proporciona una visi\u00f3n general de los aspectos cr\u00edticos relacionados con la gesti\u00f3n de copias de seguridad y la restauraci\u00f3n de datos seg\u00fan las directrices de ANVISA.", "excerpt_keywords": "Keywords: backup, data integrity, business continuity, disaster recovery, risk assessment"}}, "ff54a2c8-ba1e-4a51-a97c-fb26576f326b": {"node_ids": ["d39c41e3-0a18-4cb7-901a-d83078ba53c8"], "metadata": {"page_label": "86", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# Guide for Computer Systems Validation\n\n## 11.11.2 Key requirements\n\nPatient safety, product quality and data integrity cannot be compromised by computer system crashes or crashes.\n\nThe regulated company must carry out business continuity planning to actively protect its ability to supply their products to the public and meet regulatory requirements.\n\nThe Business Continuity Plan must provide alternative procedures or processes to be implemented to replace functionality missing from some system and allow for safe continuity during the failure.\n\nBusiness Continuity Plans should include provision for testing. Alternative processes defined by the Business Continuity Plan must be properly documented and staff involved properly trained.\n\nRegulated companies must be able to demonstrate that they can ensure that critical and processes can continue and that there is a timely resumption of essential business functions.\n\nBusiness Continuity Plans and their tests must be subject to periodic internal audits.\n\n## 11.11.3 Responsibilities\n\nIt is the responsibility of the company's top management, including process owners, system owners and the Quality Unit, ensure that appropriate Business Continuity Plans are in place, periodically tested and once started, be followed, documented and communicated.\n\nIt is the responsibility of the process owner and the system owner to ensure that recovery plans are appropriate disaster systems are in place for the systems to support the Plans for Business Continuity.\n\n## 11.11.4 Execution of Activities\n\nPlanning for Business Continuity and Disaster Recovery activities involve carrying out the following actions:\n\n1. Establishing the need for planning and management for business continuity,", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la Validaci\u00f3n de Sistemas Inform\u00e1ticos establece requisitos clave para garantizar la continuidad del negocio en empresas reguladas. Se enfatiza la importancia de la planificaci\u00f3n de la continuidad del negocio para proteger la seguridad del paciente, la calidad del producto y la integridad de los datos. Se requiere que las empresas desarrollen un Plan de Continuidad del Negocio que incluya procedimientos alternativos, pruebas documentadas y capacitaci\u00f3n del personal. Adem\u00e1s, se asignan responsabilidades a la alta direcci\u00f3n y a los propietarios de procesos y sistemas para asegurar que estos planes sean efectivos y se mantengan actualizados.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfQu\u00e9 elementos deben incluirse en un Plan de Continuidad del Negocio seg\u00fan la gu\u00eda de ANVISA?**\n   - La gu\u00eda establece que el Plan de Continuidad del Negocio debe incluir procedimientos alternativos para reemplazar la funcionalidad perdida, provisiones para pruebas, documentaci\u00f3n adecuada de los procesos alternativos y capacitaci\u00f3n del personal involucrado.\n\n2. **\u00bfQui\u00e9nes son responsables de asegurar la implementaci\u00f3n y el seguimiento de los Planes de Continuidad del Negocio en una empresa regulada?**\n   - La responsabilidad recae en la alta direcci\u00f3n de la empresa, incluidos los propietarios de procesos, los propietarios de sistemas y la Unidad de Calidad, quienes deben asegurarse de que los planes sean apropiados, se prueben peri\u00f3dicamente y se sigan adecuadamente.\n\n3. **\u00bfQu\u00e9 acciones se deben llevar a cabo para planificar la continuidad del negocio y la recuperaci\u00f3n ante desastres?**\n   - Las acciones incluyen establecer la necesidad de planificaci\u00f3n y gesti\u00f3n para la continuidad del negocio, lo que implica identificar riesgos, definir procedimientos alternativos y asegurar que se realicen pruebas y auditor\u00edas internas peri\u00f3dicas.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Integridad a Largo Plazo de Medios de Almacenamiento Electr\u00f3nico**:\n   - La degradaci\u00f3n de los medios de almacenamiento con el tiempo requiere seguir las pautas del fabricante para su reutilizaci\u00f3n.\n   - Se recomienda copiar datos a nuevos medios en lugar de revisar medios antiguos que se acercan al final de su vida \u00fatil.\n\n2. **Procedimientos de Copia de Seguridad y Restauraci\u00f3n**:\n   - Es esencial verificar peri\u00f3dicamente los procedimientos de copia de seguridad y restauraci\u00f3n, bas\u00e1ndose en una evaluaci\u00f3n de riesgos.\n   - La verificaci\u00f3n puede incluir la restauraci\u00f3n de copias de seguridad en un sistema de respaldo para probar su correcto funcionamiento.\n   - No se recomienda restaurar copias de seguridad en sistemas en producci\u00f3n para evitar la p\u00e9rdida de datos.\n\n3. **Ejecuci\u00f3n de Actividades de Copia de Seguridad**:\n   - Las actividades incluyen: evaluaci\u00f3n de riesgos, definici\u00f3n de estrategias de copia de seguridad, desarrollo de procedimientos escritos, definici\u00f3n de procedimientos de prueba, ejecuci\u00f3n de pruebas y monitoreo del sistema.\n   - Documentaci\u00f3n de resultados y acciones tomadas es crucial.\n\n4. **Planificaci\u00f3n de Continuidad del Negocio / Recuperaci\u00f3n ante Desastres**:\n   - La planificaci\u00f3n de continuidad del negocio implica preparar a la empresa para responder a fallos y perturbaciones.\n   - Identificaci\u00f3n de procesos cr\u00edticos y evaluaci\u00f3n de riesgos asociados son fundamentales.\n   - El Plan de Continuidad del Negocio debe detallar c\u00f3mo la empresa puede seguir operando y manejar datos tras un desastre, incluyendo pasos para restaurar procesos comerciales.\n\n### Entidades Clave:\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil.\n- **Medios de Almacenamiento Electr\u00f3nico**: Dispositivos utilizados para almacenar datos.\n- **Copia de Seguridad**: Proceso de crear una copia de los datos para su recuperaci\u00f3n.\n- **Plan de Continuidad del Negocio**: Estrategia para mantener operaciones durante y despu\u00e9s de un desastre.\n- **Evaluaci\u00f3n de Riesgos**: Proceso de identificar y analizar riesgos potenciales.", "excerpt_keywords": "Keywords: Business Continuity, Disaster Recovery, Data Integrity, Regulatory Compliance, ANVISA"}}, "8aa247cd-101d-437e-ad40-679a3d96127b": {"node_ids": ["2116a15e-3afe-4c29-b1a4-3cdc56847cd6"], "metadata": {"page_label": "87", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# Guide for Computer Systems Validation\n\nincluding Disaster Recovery Planning, identifying key processes and services for the business. Obtaining support from senior management;\n\n## Guide for Computer Systems Validation\n### Guide n\u00b0 33/2020 - version 1, of 03/26/2020\n\n----\n\n2. **Risk assessment and analysis.** Determination of adverse events and damages that may adversely affect the organization. Evaluation of the severity of each event and the probability of its occurrence;\n\n3. **Definition of strategies for Business Continuity.** Selection of alternative strategies for recovery, while maintaining the organization's ability to perform its critical functions;\n\n4. **Development of the Business Continuity Plan.** Identification of roles and responsibilities, organizational resources and the triggers that can cause the use of the Plan and its escalation;\n\n5. **Implementation of the Business Continuity Plan;**\n\n6. **Maintenance and Testing.** Pre-planning and coordination of trials, documenting and evaluating the results of each test, incorporating the lessons learned within the Business Continuity Plan. Maintenance of the Plan's timeliness and its capability according to the company's strategy and requirements regulatory requirements. Publication of test results to key stakeholders.\n\n## 11.12 SYSTEM SECURITY MANAGEMENT\n\n### 11.12.1 Introduction\n\nSystem security management is the process of ensuring reliability, integrity and availability of the regulated company's systems, records and processes.\n\nEffective security management protects the company's computer systems so that minimize business impacts caused by security vulnerabilities and incidents.\n\n### 11.12.2 Key requirements\n\nMeasures must be put in place to ensure that the computerized systems of regulated companies and your data is adequate and protected against accidental or intentional loss, damage or unintended changes authorized.\n\nSuch measures should ensure continuous control, integrity and availability and, where appropriate, confidentiality of regulated data.\n\nThis process should include:\n\n- Establishment and maintenance of roles and responsibilities, policies, standards and procedures security-related;\n- Periodic safety monitoring and testing, for example, manual book verification system access, automated notifications of system access locks, token testing and so on onwards;\n- Implementation of corrective actions for identified weaknesses and security incidents;\n- Ensure that there is a list of people authorized to access the system.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento \"Gu\u00eda para la Validaci\u00f3n de Sistemas Inform\u00e1ticos\" de ANVISA (Gu\u00eda n\u00b0 33/2020) aborda la importancia de la planificaci\u00f3n de la continuidad del negocio y la gesti\u00f3n de la seguridad de los sistemas. Se destacan procesos clave como la evaluaci\u00f3n de riesgos, la definici\u00f3n de estrategias de recuperaci\u00f3n, el desarrollo e implementaci\u00f3n de un Plan de Continuidad del Negocio, y la gesti\u00f3n de la seguridad del sistema para proteger la integridad y disponibilidad de los datos regulados.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfCu\u00e1les son los pasos clave en el desarrollo de un Plan de Continuidad del Negocio seg\u00fan la Gu\u00eda de ANVISA?**\n   - La gu\u00eda detalla varios pasos, incluyendo la identificaci\u00f3n de roles y responsabilidades, la selecci\u00f3n de estrategias de recuperaci\u00f3n, y la coordinaci\u00f3n de pruebas para evaluar la efectividad del plan.\n\n2. **\u00bfQu\u00e9 medidas se deben implementar para garantizar la seguridad de los sistemas inform\u00e1ticos en empresas reguladas?**\n   - Se deben establecer roles y responsabilidades, pol\u00edticas y procedimientos de seguridad, realizar monitoreos y pruebas peri\u00f3dicas, implementar acciones correctivas para debilidades identificadas, y mantener una lista de personas autorizadas para acceder al sistema.\n\n3. **\u00bfC\u00f3mo se eval\u00faa el riesgo en el contexto de la validaci\u00f3n de sistemas inform\u00e1ticos seg\u00fan el documento?**\n   - La evaluaci\u00f3n de riesgos implica determinar eventos adversos y da\u00f1os potenciales que puedan afectar a la organizaci\u00f3n, as\u00ed como evaluar la gravedad de cada evento y la probabilidad de su ocurrencia.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n**Temas Clave:**\n\n1. **Seguridad del Paciente y Calidad del Producto:** La gu\u00eda enfatiza que la seguridad del paciente, la calidad del producto y la integridad de los datos no deben verse comprometidas por fallos en los sistemas inform\u00e1ticos.\n\n2. **Planificaci\u00f3n de la Continuidad del Negocio:** Se requiere que las empresas reguladas desarrollen un Plan de Continuidad del Negocio que incluya procedimientos alternativos para mantener la funcionalidad durante fallos del sistema.\n\n3. **Documentaci\u00f3n y Capacitaci\u00f3n:** Los planes deben estar debidamente documentados y el personal involucrado debe recibir capacitaci\u00f3n adecuada.\n\n4. **Auditor\u00edas Internas:** Los Planes de Continuidad del Negocio y sus pruebas deben ser objeto de auditor\u00edas internas peri\u00f3dicas.\n\n5. **Responsabilidades de la Alta Direcci\u00f3n:** La alta direcci\u00f3n, incluidos los propietarios de procesos y sistemas, es responsable de asegurar la implementaci\u00f3n y el seguimiento de los planes.\n\n6. **Actividades de Ejecuci\u00f3n:** La planificaci\u00f3n para la continuidad del negocio y la recuperaci\u00f3n ante desastres implica establecer la necesidad de gesti\u00f3n y planificaci\u00f3n.\n\n**Entidades:**\n\n- **ANVISA:** Agencia Nacional de Vigilancia Sanitaria de Brasil, responsable de la regulaci\u00f3n.\n- **Alta Direcci\u00f3n:** Incluye a los propietarios de procesos, propietarios de sistemas y la Unidad de Calidad.\n- **Personal Involucrado:** Empleados que deben ser capacitados en los procedimientos del Plan de Continuidad del Negocio.\n\nEste resumen destaca la importancia de la planificaci\u00f3n y gesti\u00f3n de la continuidad del negocio en empresas reguladas, as\u00ed como las responsabilidades y acciones necesarias para garantizar su efectividad.", "excerpt_keywords": "Keywords: validation, business continuity, risk assessment, system security, regulatory compliance"}}, "3c7a0786-30de-476b-8c7f-c875d20ca060": {"node_ids": ["10444ab2-5ff5-4d2f-ad76-9aaf8c736c8e"], "metadata": {"page_label": "88", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 11.12.3 Responsibilities\n\nResponsibility for the security of the system, including access control, should be agreed between the owner of the process and the system owner.\n\nIt is the responsibility of the Quality Unit to ensure that safety procedures are followed.\n\nThe computer system user is responsible for meeting the security requirements defined while using the computerized system.\n\n# 11.12.4 Principles\n\nSecurity management measures should be planned and implemented based on the following considerations:\n\n- System impact - assessment of the risks associated with the system;\n- Awareness of employees - training of users;\n- Incident management - records and actions taken to resolve incidents;\n- Information security policy - physical security; security of access to the system; access by the 3rd; electronic messaging systems; shared network resources; internet access and use; use of mobile computing resources; connectivity to external computer systems; policies antivirus and intrusion detection.\n\n# 11.13 SYSTEM ADMINISTRATION\n\n## 11.13.1 Introduction\n\nSystem administration involves routine systems management and support to ensure that they are operating efficiently and effectively.\n\n## 11.13.2 Key requirements\n\nSystem administration tasks must be identified, documented and supported by control procedures.\n\nSystem administrators must be trained and have their competence evidenced in the execution of the", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos establece directrices sobre la responsabilidad de la seguridad del sistema, la gesti\u00f3n de la seguridad y la administraci\u00f3n del sistema. Se enfatiza la importancia de la colaboraci\u00f3n entre el propietario del proceso y el propietario del sistema para garantizar la seguridad, as\u00ed como la necesidad de formaci\u00f3n y documentaci\u00f3n adecuada para los administradores del sistema. Tambi\u00e9n se abordan principios clave para la gesti\u00f3n de la seguridad, incluyendo la evaluaci\u00f3n de riesgos, la formaci\u00f3n de empleados y la gesti\u00f3n de incidentes.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfQu\u00e9 papel desempe\u00f1a la Unidad de Calidad en la seguridad del sistema seg\u00fan el documento?**\n   - La Unidad de Calidad es responsable de garantizar que se sigan los procedimientos de seguridad establecidos para el sistema.\n\n2. **\u00bfCu\u00e1les son algunos de los elementos que deben considerarse al planificar y aplicar medidas de gesti\u00f3n de seguridad?**\n   - Los elementos incluyen la evaluaci\u00f3n del impacto del sistema, la formaci\u00f3n de los empleados, la gesti\u00f3n de incidentes y la implementaci\u00f3n de pol\u00edticas de seguridad de la informaci\u00f3n, que abarcan aspectos como la seguridad f\u00edsica, el acceso al sistema y el uso de recursos inform\u00e1ticos m\u00f3viles.\n\n3. **\u00bfQu\u00e9 requisitos clave se mencionan para la administraci\u00f3n del sistema en el documento?**\n   - Las tareas de administraci\u00f3n del sistema deben ser identificadas, documentadas y respaldadas por procedimientos de control, y los administradores del sistema deben estar capacitados y demostrar competencia en la ejecuci\u00f3n de sus funciones.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n**1. Planificaci\u00f3n de la Continuidad del Negocio:**\n   - **Evaluaci\u00f3n de Riesgos:** Identificaci\u00f3n de eventos adversos y evaluaci\u00f3n de su gravedad y probabilidad de ocurrencia.\n   - **Definici\u00f3n de Estrategias de Recuperaci\u00f3n:** Selecci\u00f3n de estrategias alternativas para asegurar la continuidad de funciones cr\u00edticas.\n   - **Desarrollo del Plan de Continuidad del Negocio:** Identificaci\u00f3n de roles, responsabilidades y recursos organizacionales necesarios.\n   - **Implementaci\u00f3n y Mantenimiento del Plan:** Coordinaci\u00f3n de pruebas, documentaci\u00f3n de resultados y actualizaci\u00f3n del plan seg\u00fan lecciones aprendidas.\n\n**2. Gesti\u00f3n de la Seguridad del Sistema:**\n   - **Introducci\u00f3n a la Gesti\u00f3n de Seguridad:** Asegurar la fiabilidad, integridad y disponibilidad de los sistemas y datos regulados.\n   - **Requisitos Clave de Seguridad:**\n     - Establecimiento de roles y pol\u00edticas de seguridad.\n     - Monitoreo y pruebas peri\u00f3dicas de seguridad.\n     - Implementaci\u00f3n de acciones correctivas ante vulnerabilidades.\n     - Mantenimiento de una lista de personas autorizadas para acceder a los sistemas.\n\n### Entidades Clave\n- **ANVISA:** Agencia Nacional de Vigilancia Sanitaria de Brasil, responsable de la regulaci\u00f3n y supervisi\u00f3n de sistemas inform\u00e1ticos en el sector salud.\n- **Plan de Continuidad del Negocio:** Documento que detalla c\u00f3mo una organizaci\u00f3n mantendr\u00e1 sus funciones cr\u00edticas durante y despu\u00e9s de un evento adverso.\n- **Sistema de Seguridad:** Conjunto de medidas y procedimientos dise\u00f1ados para proteger la integridad y disponibilidad de los datos y sistemas inform\u00e1ticos.\n\nEste resumen destaca la importancia de la planificaci\u00f3n y gesti\u00f3n de la seguridad en el contexto de la validaci\u00f3n de sistemas inform\u00e1ticos, enfatizando la necesidad de un enfoque estructurado para mitigar riesgos y asegurar la continuidad operativa.", "excerpt_keywords": "Keywords: security management, system administration, quality unit, risk assessment, incident management"}}, "cd043f06-2b14-49aa-843f-77b0b1b5ad5b": {"node_ids": ["b9da006e-fca6-4aa1-9009-0406ebb55197"], "metadata": {"page_label": "89", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 11.13.3 Responsibilities\n\nThe process owner has overall responsibility for ensuring that the system is used and maintained in a through detailed work instructions and procedures.\n\nIt is the responsibility of the system owner to ensure that tasks delegated to the system administrator are clearly identified and documented. The system owner and the system administrator can be the same person.\n\n# 11.13.4 Execution of Activities\n\nSystem administration activities involve performing the following actions:\n\n1. Establishing the needs and scope of system administration activities computerized;\n2. Establishment of the support schedule for regular activities (daily, weekly, monthly, etc.);\n3. Identification of tasks related to system administration, which can be motivated by the Incident Management process;\n4. Establishment of standard operating procedures for system administration.\n\n# 11.14 RECORD MANAGEMENT (RETENTION, ARCHIVING AND RECOVERY)\n\n## 11.14.1 Introduction\n\nRecords retention policies should be established, based on a clear understanding of the regulatory requirements, corporate policies and existing guides. Archiving requirements are relevant to any registry that needs to be removed from operating systems before the end of its defined retention period.\n\nArchiving is the process of removing records and data from the computerized system and placing them in a different location or system, often protecting them from further changes. Can also be it is necessary to retain on file the applications that support records and data.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos establece responsabilidades claras para los propietarios y administradores de sistemas, as\u00ed como directrices para la ejecuci\u00f3n de actividades de administraci\u00f3n del sistema. Tambi\u00e9n aborda la gesti\u00f3n de registros, enfatizando la importancia de las pol\u00edticas de retenci\u00f3n y el proceso de archivo, que implica la eliminaci\u00f3n de registros de los sistemas operativos y su almacenamiento en ubicaciones seguras.\n\n### Preguntas\n\n1. **\u00bfCu\u00e1les son las responsabilidades espec\u00edficas del propietario del sistema en relaci\u00f3n con la administraci\u00f3n del sistema?**\n   - El propietario del sistema es responsable de garantizar que el sistema se utilice y mantenga de acuerdo con instrucciones de trabajo detalladas y procedimientos. Adem\u00e1s, debe asegurarse de que las tareas delegadas al administrador del sistema est\u00e9n claramente identificadas y documentadas.\n\n2. **\u00bfQu\u00e9 pasos se deben seguir para establecer un programa de soporte para las actividades de administraci\u00f3n del sistema?**\n   - Se debe establecer un cronograma de soporte para las actividades regulares de administraci\u00f3n del sistema, que puede incluir actividades diarias, semanales, mensuales, etc. Esto es parte de la ejecuci\u00f3n de actividades de administraci\u00f3n del sistema.\n\n3. **\u00bfQu\u00e9 implica el proceso de archivo de registros y por qu\u00e9 es importante?**\n   - El proceso de archivo implica la eliminaci\u00f3n de registros y datos del sistema inform\u00e1tico y su colocaci\u00f3n en una ubicaci\u00f3n o sistema diferente, protegi\u00e9ndolos de cambios adicionales. Es importante porque asegura que los registros se mantengan de acuerdo con las pol\u00edticas de retenci\u00f3n y se gestionen adecuadamente antes de que finalice su per\u00edodo de retenci\u00f3n definido.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Responsabilidades de Seguridad del Sistema**:\n   - La responsabilidad de la seguridad del sistema, incluyendo el control de acceso, debe ser acordada entre el propietario del proceso y el propietario del sistema.\n   - La Unidad de Calidad tiene la responsabilidad de asegurar que se sigan los procedimientos de seguridad.\n   - Los usuarios del sistema inform\u00e1tico son responsables de cumplir con los requisitos de seguridad establecidos.\n\n2. **Principios de Gesti\u00f3n de Seguridad**:\n   - Las medidas de gesti\u00f3n de seguridad deben planificarse e implementarse considerando:\n     - **Impacto del Sistema**: Evaluaci\u00f3n de riesgos asociados.\n     - **Conciencia de los Empleados**: Capacitaci\u00f3n de los usuarios.\n     - **Gesti\u00f3n de Incidentes**: Registro y acciones para resolver incidentes.\n     - **Pol\u00edtica de Seguridad de la Informaci\u00f3n**: Incluye seguridad f\u00edsica, control de acceso, uso de recursos compartidos, acceso a internet, uso de dispositivos m\u00f3viles, y pol\u00edticas de antivirus e intrusi\u00f3n.\n\n3. **Administraci\u00f3n del Sistema**:\n   - La administraci\u00f3n del sistema implica la gesti\u00f3n y soporte rutinario para asegurar un funcionamiento eficiente y efectivo.\n   - Las tareas de administraci\u00f3n deben ser identificadas, documentadas y respaldadas por procedimientos de control.\n   - Los administradores del sistema deben estar capacitados y demostrar competencia en sus funciones.\n\n### Entidades Clave:\n- **Unidad de Calidad**: Responsable de la supervisi\u00f3n de procedimientos de seguridad.\n- **Propietario del Proceso**: Parte que colabora en la seguridad del sistema.\n- **Propietario del Sistema**: Parte que colabora en la seguridad del sistema.\n- **Usuarios del Sistema**: Responsables de cumplir con los requisitos de seguridad.\n- **Administradores del Sistema**: Encargados de la gesti\u00f3n y soporte del sistema, deben estar capacitados y documentar sus tareas. \n\nEste resumen destaca la importancia de la colaboraci\u00f3n y la capacitaci\u00f3n en la gesti\u00f3n de la seguridad y la administraci\u00f3n de sistemas inform\u00e1ticos seg\u00fan las directrices de ANVISA.", "excerpt_keywords": "Keywords: responsibilities, system administration, records management, archiving, validation"}}, "05b33809-a719-4040-bc9f-ff84b5ed5bc7": {"node_ids": ["1d67c12a-2ae6-45e9-8bff-e9e88c669d41"], "metadata": {"page_label": "90", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "Archiving and retrieval procedures should be established on the basis of a clear understanding of regulatory requirements.\n\nArchiving and recovery should not be confused with backup and restore.\n\nArchiving must be subject to periodic internal audits.\n\n## 11.14.2 Key requirements\n\nGMP-relevant records and data must be physically and electronically insured against accidental damage or willful, for the entire required retention period.\n\nThe roles, responsibilities and procedures for filing and retrieval must be defined, and there should be a standard operating procedure that describes the archiving strategy.\n\nRecords and stored data should be initially and then periodically checked for their accessibility, durability, accuracy and completeness, based on a risk analysis, taking into account considering the type of storage, the media and the method of access.\n\nArchiving processes must ensure that the content is preserved. Records with approvals required by GMP regulations must ensure that the validity of approval is maintained throughout the archiving period.\n\nRegulatory agencies must have access to GMP records during an inspection, within a specified period. Readable copies of archived records must be available on request.\n\n## 11.14.3 Responsibilities\n\nIt is the responsibility of the process owner to ensure that a filing process/procedure is established.\n\nIt is the responsibility of the Quality Unit to ensure that the filing process/procedure is followed.\n\nThe person performing the archiving is responsible for receiving from users the records to be archived, keeping these records in the state in which they were received and returning them in the same state.\n\nThe system owner is responsible for maintaining or updating the systems necessary to access the records.\n\n## 11.14.4 Archiving and Retention\n\nThe filing procedure should provide controls for:\n\n- Ensure secure storage facilities;\n- Check and maintain archived records for the entire retention period, that is, to manage the aging of storage media;", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "### Resumen del contexto\n\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos establece procedimientos claros para el archivo y recuperaci\u00f3n de registros relevantes para las Buenas Pr\u00e1cticas de Manufactura (GMP). Se enfatiza la importancia de diferenciar entre archivo y respaldo, as\u00ed como la necesidad de auditor\u00edas internas peri\u00f3dicas. Se detallan las responsabilidades de los propietarios de procesos, la unidad de calidad y el personal encargado del archivo, as\u00ed como los requisitos clave para asegurar la integridad y accesibilidad de los registros durante su per\u00edodo de retenci\u00f3n.\n\n### Preguntas espec\u00edficas\n\n1. **\u00bfCu\u00e1les son los criterios que deben considerarse al realizar un an\u00e1lisis de riesgo para la accesibilidad y durabilidad de los registros archivados?**\n   - Esta pregunta busca informaci\u00f3n sobre los factores espec\u00edficos que se deben evaluar en un an\u00e1lisis de riesgo, que no se detalla expl\u00edcitamente en el texto.\n\n2. **\u00bfQu\u00e9 procedimientos espec\u00edficos deben seguirse para garantizar que los registros archivados mantengan la validez de las aprobaciones requeridas por las regulaciones GMP durante el per\u00edodo de archivo?**\n   - Esta pregunta se centra en los pasos concretos que deben implementarse para asegurar la validez de las aprobaciones, un aspecto cr\u00edtico que podr\u00eda no estar ampliamente documentado en otras fuentes.\n\n3. **\u00bfQu\u00e9 tipo de auditor\u00edas internas se recomiendan para el proceso de archivo y con qu\u00e9 frecuencia deben llevarse a cabo?**\n   - Esta pregunta busca detalles sobre la naturaleza y frecuencia de las auditor\u00edas internas, que son esenciales para garantizar el cumplimiento, pero que pueden no estar claramente especificadas en otros documentos.\n\nEstas preguntas est\u00e1n dise\u00f1adas para extraer informaci\u00f3n espec\u00edfica y detallada que podr\u00eda no estar disponible en otras fuentes, bas\u00e1ndose en el contenido del documento de ANVISA.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Responsabilidades del Propietario del Sistema**:\n   - El propietario del sistema es responsable de asegurar el uso y mantenimiento del sistema mediante instrucciones de trabajo detalladas.\n   - Debe documentar claramente las tareas delegadas al administrador del sistema, quien puede ser la misma persona que el propietario.\n\n2. **Ejecuci\u00f3n de Actividades de Administraci\u00f3n del Sistema**:\n   - Implica establecer las necesidades y el alcance de las actividades de administraci\u00f3n.\n   - Se debe crear un cronograma de soporte para actividades regulares (diarias, semanales, mensuales).\n   - Identificaci\u00f3n de tareas relacionadas con la administraci\u00f3n del sistema, que pueden surgir del proceso de gesti\u00f3n de incidentes.\n   - Establecimiento de procedimientos operativos est\u00e1ndar para la administraci\u00f3n del sistema.\n\n3. **Gesti\u00f3n de Registros (Retenci\u00f3n, Archivo y Recuperaci\u00f3n)**:\n   - Las pol\u00edticas de retenci\u00f3n de registros deben basarse en requisitos regulatorios y pol\u00edticas corporativas.\n   - El archivo implica la eliminaci\u00f3n de registros del sistema y su almacenamiento en una ubicaci\u00f3n diferente, protegi\u00e9ndolos de cambios adicionales.\n   - Es esencial mantener aplicaciones que soporten registros y datos.\n\n### Entidades Clave\n- **Propietario del Sistema**: Responsable de la administraci\u00f3n y mantenimiento del sistema.\n- **Administrador del Sistema**: Persona encargada de ejecutar tareas espec\u00edficas de administraci\u00f3n.\n- **Actividades de Administraci\u00f3n del Sistema**: Acciones necesarias para mantener el sistema operativo.\n- **Pol\u00edticas de Retenci\u00f3n de Registros**: Normativas que dictan c\u00f3mo y cu\u00e1ndo se deben conservar los registros.\n- **Proceso de Archivo**: M\u00e9todo para mover registros a un lugar seguro, fuera del sistema operativo principal. \n\nEste resumen destaca las responsabilidades, procesos y pol\u00edticas clave relacionadas con la administraci\u00f3n de sistemas inform\u00e1ticos y la gesti\u00f3n de registros seg\u00fan el documento de ANVISA.", "excerpt_keywords": "Keywords: archiving, GMP, records management, internal audits, regulatory compliance"}}, "a1591ff5-f46a-4980-8e52-cf32c0330994": {"node_ids": ["a8a75fc7-7f9a-4db4-b6c3-675448b4a18c"], "metadata": {"page_label": "91", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "- Provide indexing capabilities;\n- Detect the end of the intended retention period for specified records and notify management when appropriate;\n- Provide management with the option of extending the retention period;\n- Ensure that any changes to the records are carried out under change control;\n- Destroy records securely when proper authorization is given;\n- Ensure that the technology for reading archived records remains available throughout the retention period.\n\nIf the archiving process is computerized, the system must be validated. This system of automated archiving of records should:\n\n- Ensure that data is backed up at regular intervals. The data from the backup files must be stored for the retention period, in a separate secure location;\n- Ensure that the system and its content are secure;\n- Allow verification of the accessibility, accuracy and completeness of the records, after the making changes related to hardware and software;\n- Have the ability to keep track of changes in records;\n\n----\n\nGuide for Computer Systems Validation\nGuide n\u00b0 33/2020 - version 1, of 03/26/2020\n\n----\n\n- Ensure that the system and its contents are safe, keeping its meaning preserved;\n- Consider the continuous availability of devices and software needed to access the records.\n\n## 11.14.5 Recovery\n\nRetained records must be readily recoverable for business and regulatory purposes. The process recovery should be documented and consideration should be given to the following points:\n\n- There must be formal authorization to access the retained records;\n- There must be the ability to access online and offline electronic data, if applicable;\n- There must be an ability to obtain hard copies and readable electronic copies of the data electronically stored;\n- There should be a means to recover any registration required by regulation after retirement from a system regulated by GMP;\n- There should be a periodic recovery exercise or verification process to check your continuous operation.\n\n## 11.14.6 Execution of Activities\n\nArchiving and Recovery activities involve the following actions:\n\n1. Identification of records and data relevant to GMP;\n2. Definition of the retention policy for these records and data;\n- Definition of the archiving strategy, covering frequency, location, time required for", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento \"Gu\u00eda para la Validaci\u00f3n de Sistemas Inform\u00e1ticos\" de ANVISA establece directrices sobre el archivo y recuperaci\u00f3n de registros en el contexto de Buenas Pr\u00e1cticas de Manufactura (GMP). Se enfatiza la importancia de la validaci\u00f3n de sistemas automatizados de archivo, la seguridad de los datos, la accesibilidad y la recuperaci\u00f3n de registros para cumplir con requisitos regulatorios. Se detallan las acciones necesarias para la identificaci\u00f3n, definici\u00f3n de pol\u00edticas de retenci\u00f3n y estrategias de archivo.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfQu\u00e9 medidas deben implementarse para garantizar la seguridad de los datos en un sistema de archivo automatizado?**\n   - El sistema debe asegurar que los datos est\u00e9n respaldados a intervalos regulares, que el contenido del sistema sea seguro y que se pueda verificar la accesibilidad, precisi\u00f3n y completitud de los registros tras cambios en hardware y software.\n\n2. **\u00bfCu\u00e1les son los requisitos para la recuperaci\u00f3n de registros retenidos seg\u00fan la gu\u00eda de ANVISA?**\n   - La recuperaci\u00f3n de registros debe estar documentada y requiere autorizaci\u00f3n formal para acceder a los registros retenidos, as\u00ed como la capacidad de acceder a datos electr\u00f3nicos en l\u00ednea y fuera de l\u00ednea, y obtener copias impresas y electr\u00f3nicas legibles.\n\n3. **\u00bfQu\u00e9 acciones se deben llevar a cabo para la ejecuci\u00f3n de actividades de archivo y recuperaci\u00f3n en el contexto de GMP?**\n   - Las acciones incluyen la identificaci\u00f3n de registros y datos relevantes para GMP, la definici\u00f3n de la pol\u00edtica de retenci\u00f3n para estos registros y datos, y la definici\u00f3n de la estrategia de archivo, que abarca la frecuencia, ubicaci\u00f3n y tiempo requerido para el archivo.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Procedimientos de Archivo y Recuperaci\u00f3n**:\n   - Establecimiento de procedimientos claros basados en requisitos regulatorios.\n   - Diferenciaci\u00f3n entre archivo y respaldo.\n   - Auditor\u00edas internas peri\u00f3dicas para el proceso de archivo.\n\n2. **Requisitos Clave (Secci\u00f3n 11.14.2)**:\n   - Protecci\u00f3n f\u00edsica y electr\u00f3nica de registros y datos relevantes para GMP contra da\u00f1os accidentales o intencionados durante el per\u00edodo de retenci\u00f3n.\n   - Definici\u00f3n de roles, responsabilidades y procedimientos para el archivo y recuperaci\u00f3n.\n   - Verificaci\u00f3n inicial y peri\u00f3dica de la accesibilidad, durabilidad, precisi\u00f3n y completitud de los registros, basada en un an\u00e1lisis de riesgo.\n   - Preservaci\u00f3n del contenido durante el archivo, asegurando la validez de las aprobaciones requeridas por GMP.\n   - Acceso de agencias regulatorias a registros GMP durante inspecciones, con copias legibles disponibles a solicitud.\n\n3. **Responsabilidades (Secci\u00f3n 11.14.3)**:\n   - Propietario del proceso: Asegurar el establecimiento de un procedimiento de archivo.\n   - Unidad de Calidad: Garantizar el cumplimiento del procedimiento de archivo.\n   - Personal de archivo: Recibir, mantener y devolver registros en el estado en que fueron recibidos.\n   - Propietario del sistema: Mantener o actualizar los sistemas necesarios para acceder a los registros.\n\n4. **Archivo y Retenci\u00f3n (Secci\u00f3n 11.14.4)**:\n   - Provisi\u00f3n de controles para asegurar instalaciones de almacenamiento seguras.\n   - Verificaci\u00f3n y mantenimiento de registros archivados durante todo el per\u00edodo de retenci\u00f3n, gestionando el envejecimiento de los medios de almacenamiento.\n\n### Entidades Clave\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil.\n- **GMP**: Buenas Pr\u00e1cticas de Manufactura.\n- **Unidad de Calidad**: Entidad responsable de asegurar el cumplimiento de los procedimientos.\n- **Propietario del Proceso**: Persona encargada de establecer procedimientos de archivo.\n- **Personal de Archivo**: Encargado de la gesti\u00f3n de registros archivados.\n- **Agencias Regulatorias**: Entidades que supervisan el cumplimiento de las normativas. \n\nEste resumen destaca los aspectos fundamentales del documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos, centr\u00e1ndose en los procedimientos de archivo y las responsabilidades asociadas.", "excerpt_keywords": "Keywords: archiving, recovery, data security, GMP, validation"}}, "cd6a5d36-8e26-45a7-b612-dcf0a4e586d5": {"node_ids": ["d0396dc4-95c0-4bb3-a79c-7cd1ae457c18"], "metadata": {"page_label": "92", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 12 DATA MIGRATION\n\n## 12.1 INTRODUCTION\n\nThis section covers procedures related to the planning, execution and verification of data migration.\n\nIt does not cover the transfer of data from one system to another, within a business process in progress. Such a situation must be addressed through typical specification and verification activities.\n\nData migration is an activity that can often occur during the life cycles of systems computerized systems used by regulated companies.\n\n----\n\nData migration is the activity of transporting electronic data from one system to another, or simply the transition of data from one system to another.\n\nSome examples of data migration are:\n\n- An update to an existing version of a database or application;\n- Data conversion (e.g., from a supplier's database to another);\n- Migration within the same system (e.g., transporting data from an application on a server to another);\n- Migration from a source system to a target system;\n- Migration from multiple source systems to a target system.\n\nThe complexity and risk involved in the data migration effort can increase significantly if rules are used to select a subset of data from the source system or if data is transformed (e.g., data type conversion; filtering; cleaning; aggregation; normalization) before being inserted into the target system. The ultimate goal of any data migration is to obtain data that remain usable and retain their contextual meaning. Quality management controls must exist to ensure that data migration efforts are successful, compatible and repeatable.\n\nEach data migration activity must be managed through a plan and report.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas que se pueden responder espec\u00edficamente con el contexto proporcionado sobre la migraci\u00f3n de datos seg\u00fan la gu\u00eda de ANVISA:\n\n1. **\u00bfCu\u00e1les son los principales riesgos asociados con la migraci\u00f3n de datos y c\u00f3mo se pueden mitigar?**\n   - La complejidad y el riesgo en la migraci\u00f3n de datos pueden aumentar significativamente si se aplican reglas para seleccionar un subconjunto de datos o si se realizan transformaciones en los datos antes de insertarlos en el sistema de destino. Para mitigar estos riesgos, es esencial implementar controles de gesti\u00f3n de calidad que aseguren que los esfuerzos de migraci\u00f3n sean exitosos, compatibles y repetibles.\n\n2. **\u00bfQu\u00e9 tipo de actividades de migraci\u00f3n de datos se consideran dentro del ciclo de vida de los sistemas utilizados por empresas reguladas?**\n   - Las actividades de migraci\u00f3n de datos que pueden ocurrir durante el ciclo de vida de los sistemas incluyen actualizaciones de versiones existentes de bases de datos o aplicaciones, conversiones de datos entre diferentes bases de datos, migraciones dentro del mismo sistema y migraciones desde m\u00faltiples sistemas de origen a un sistema de destino.\n\n3. **\u00bfQu\u00e9 documentaci\u00f3n es necesaria para gestionar adecuadamente una actividad de migraci\u00f3n de datos?**\n   - Cada actividad de migraci\u00f3n de datos debe ser gestionada a trav\u00e9s de un plan y un informe, lo que implica que se debe documentar el proceso de migraci\u00f3n, los datos involucrados, las transformaciones realizadas y los resultados obtenidos para asegurar la trazabilidad y la verificaci\u00f3n del proceso.\n\n### Resumen de nivel superior:\nLa secci\u00f3n sobre migraci\u00f3n de datos en la gu\u00eda de ANVISA destaca la importancia de planificar, ejecutar y verificar las actividades de migraci\u00f3n de datos en sistemas utilizados por empresas reguladas. Se enfatiza que la migraci\u00f3n de datos no solo implica el traslado de datos, sino que tambi\u00e9n puede incluir transformaciones complejas que requieren un manejo cuidadoso para garantizar la calidad y la integridad de los datos. Adem\u00e1s, se subraya la necesidad de documentaci\u00f3n adecuada para gestionar estos procesos de manera efectiva.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\nEl documento \"Gu\u00eda para la Validaci\u00f3n de Sistemas Inform\u00e1ticos\" de ANVISA aborda aspectos fundamentales relacionados con el archivo y recuperaci\u00f3n de registros en el contexto de Buenas Pr\u00e1cticas de Manufactura (GMP). A continuaci\u00f3n se presentan los temas clave y entidades mencionadas en la secci\u00f3n:\n\n#### Temas Clave:\n1. **Validaci\u00f3n de Sistemas de Archivo Automatizado**: Se requiere que los sistemas de archivo automatizados sean validados para garantizar su eficacia y seguridad.\n2. **Seguridad de los Datos**: Es esencial que los datos est\u00e9n respaldados regularmente y que el sistema y su contenido sean seguros.\n3. **Accesibilidad y Recuperaci\u00f3n de Registros**: Los registros deben ser f\u00e1cilmente recuperables para fines comerciales y regulatorios, con procesos documentados y autorizaciones formales para el acceso.\n4. **Pol\u00edticas de Retenci\u00f3n**: Se debe definir una pol\u00edtica de retenci\u00f3n clara para los registros y datos relevantes, as\u00ed como una estrategia de archivo que contemple frecuencia, ubicaci\u00f3n y tiempo de archivo.\n5. **Control de Cambios**: Cualquier modificaci\u00f3n a los registros debe realizarse bajo control de cambios para mantener la integridad de los datos.\n6. **Ejercicios de Recuperaci\u00f3n**: Se deben llevar a cabo ejercicios peri\u00f3dicos de recuperaci\u00f3n para verificar la operatividad continua del sistema.\n\n#### Entidades:\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil, responsable de la regulaci\u00f3n y supervisi\u00f3n de la salud p\u00fablica.\n- **GMP (Buenas Pr\u00e1cticas de Manufactura)**: Conjunto de normas y directrices que aseguran que los productos se fabriquen de manera consistente y controlada seg\u00fan est\u00e1ndares de calidad.\n- **Registros**: Documentos y datos que deben ser archivados y recuperados de acuerdo con las regulaciones establecidas.\n- **Sistema de Archivo Automatizado**: Tecnolog\u00eda utilizada para el almacenamiento y recuperaci\u00f3n de registros de manera digital.\n\nEste resumen destaca la importancia de la validaci\u00f3n, seguridad y accesibilidad de los registros en el contexto de la regulaci\u00f3n sanitaria y las buenas pr\u00e1cticas de manufactura.", "excerpt_keywords": "Keywords: data migration, quality management, regulated companies, data transformation, migration planning"}}, "f2f0eeb7-ecab-4410-9846-c73c93acbe7b": {"node_ids": ["7795c406-c3e7-474d-bb7f-45490cd7c9e5"], "metadata": {"page_label": "93", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 12.2 QUALITY MANAGEMENT\n\n## 12.2.1 System Life Cycle\n\nData migration can occur many times during the life cycle of a computer system, in the following situations:\n\n- During the development and initial deployment of the system;\n- During application updates;\n- During the retirement of the system.\n\nAs with other life cycle phases and activities, data migration activities will be more consistent and successful if the life cycle contains procedures, tools, *templates* and examples of data migration.\n\nA complete life cycle should provide guidance for all aspects related to data migration, including:\n\n- Roles and responsibilities;\n- Documentation requirements;\n- Quality and compliance controls;\n- Technical and verification activities;\n- Project management.\n\nA standard operating procedure is the best method for describing and documenting the process, including quality and compliance requirements.\n\n## 12.2.2 Risk Management\n\nThe life cycle should include an established risk management process for assessing risks that are specific to activities related to computerized systems. In addition to the risks normally found in technological projects, the following items should be evaluated when carrying out the migration of regulated data:\n\n- The risk inherent in the quality and compliance associated with data migration, such as: the impact on patient safety, product quality and integrity;\n- The risk related to the business processes associated with the computer system involved;\n- The risk to the business due to the system becoming unavailable or the migrated data is not reliable;\n- The level of complexity (e.g., multiple sources or target systems; multiple phases; a lot of transformation data);\n- Technological risk due to the use of complex or cutting edge systems or tools.\n\n## 12.2.3 Configuration Management and Change Control", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior del contenido:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos destaca la importancia de la gesti\u00f3n de calidad a lo largo del ciclo de vida de un sistema. Se enfatiza la necesidad de procedimientos, herramientas y plantillas para la migraci\u00f3n de datos, as\u00ed como la gesti\u00f3n de riesgos asociados a esta actividad. Se identifican varios tipos de riesgos que deben ser evaluados, incluyendo aquellos relacionados con la calidad de los datos, la disponibilidad del sistema y la complejidad tecnol\u00f3gica. Adem\u00e1s, se menciona la importancia de la gesti\u00f3n de configuraci\u00f3n y el control de cambios.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfCu\u00e1les son las etapas del ciclo de vida de un sistema inform\u00e1tico en las que puede ocurrir la migraci\u00f3n de datos?**\n   - Respuesta: La migraci\u00f3n de datos puede ocurrir durante el desarrollo y la implementaci\u00f3n inicial del sistema, durante actualizaciones de la aplicaci\u00f3n y durante la jubilaci\u00f3n del sistema.\n\n2. **\u00bfQu\u00e9 elementos deben incluirse en un ciclo de vida completo para garantizar una migraci\u00f3n de datos exitosa?**\n   - Respuesta: Un ciclo de vida completo debe proporcionar orientaci\u00f3n sobre roles y responsabilidades, requisitos de documentaci\u00f3n, controles de calidad y cumplimiento, actividades t\u00e9cnicas y de verificaci\u00f3n, y gesti\u00f3n de proyectos.\n\n3. **\u00bfQu\u00e9 tipos de riesgos deben evaluarse espec\u00edficamente durante la migraci\u00f3n de datos regulados?**\n   - Respuesta: Los riesgos a evaluar incluyen el riesgo inherente a la calidad y cumplimiento de la migraci\u00f3n de datos (impacto en la seguridad del paciente, calidad del producto e integridad), riesgos relacionados con los procesos de negocio, riesgos por la falta de disponibilidad del sistema o la fiabilidad de los datos migrados, la complejidad del proceso de migraci\u00f3n y riesgos tecnol\u00f3gicos asociados al uso de sistemas o herramientas complejas.", "prev_section_summary": "### Resumen de la Secci\u00f3n sobre Migraci\u00f3n de Datos\n\n**Temas Clave:**\n\n1. **Definici\u00f3n de Migraci\u00f3n de Datos:**\n   - La migraci\u00f3n de datos implica el transporte de datos electr\u00f3nicos de un sistema a otro, lo que puede incluir actualizaciones, conversiones y migraciones dentro del mismo sistema o entre m\u00faltiples sistemas.\n\n2. **Ejemplos de Migraci\u00f3n de Datos:**\n   - Actualizaci\u00f3n de versiones de bases de datos o aplicaciones.\n   - Conversi\u00f3n de datos entre diferentes bases de datos.\n   - Migraci\u00f3n de datos dentro del mismo sistema.\n   - Migraci\u00f3n de un sistema de origen a un sistema de destino.\n   - Migraci\u00f3n desde m\u00faltiples sistemas de origen a un sistema de destino.\n\n3. **Complejidad y Riesgos:**\n   - La complejidad y el riesgo aumentan si se aplican reglas para seleccionar subconjuntos de datos o si se realizan transformaciones en los datos (como conversi\u00f3n de tipos, filtrado, limpieza, agregaci\u00f3n y normalizaci\u00f3n) antes de la inserci\u00f3n en el sistema de destino.\n\n4. **Objetivo de la Migraci\u00f3n de Datos:**\n   - Asegurar que los datos migrados sean utilizables y mantengan su significado contextual.\n\n5. **Controles de Gesti\u00f3n de Calidad:**\n   - Es esencial implementar controles de calidad para garantizar que los esfuerzos de migraci\u00f3n sean exitosos, compatibles y repetibles.\n\n6. **Documentaci\u00f3n:**\n   - Cada actividad de migraci\u00f3n debe ser gestionada mediante un plan y un informe, asegurando la trazabilidad y verificaci\u00f3n del proceso.\n\n**Entidades:**\n\n- **Sistemas Computarizados:** Utilizados por empresas reguladas.\n- **Datos Electr\u00f3nicos:** Elemento central de la migraci\u00f3n.\n- **Controles de Calidad:** Mecanismos necesarios para asegurar la integridad de la migraci\u00f3n.\n- **Plan y Reporte:** Documentaci\u00f3n requerida para gestionar la migraci\u00f3n de datos.\n\nEste resumen destaca la importancia de una planificaci\u00f3n cuidadosa, la gesti\u00f3n de riesgos y la documentaci\u00f3n adecuada en el proceso de migraci\u00f3n de datos, especialmente en el contexto de empresas reguladas.", "excerpt_keywords": "Keywords: data migration, quality management, risk management, system life cycle, compliance controls"}}, "d59decc2-e47b-46c0-a1a9-4fb2a49f429d": {"node_ids": ["fb2617cc-25ae-4f3c-b6bd-5349bd3d28da"], "metadata": {"page_label": "94", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 12.3 IMPORTANT POINTS\n\n## 12.3.1 Suitability of the Software Tools to the Intended Use\n\nData migration typically involves using *software* tools to automate some or all extraction, transformation, loading and verification activities. These tools tend to belong to GAMP category 1 - infrastructure tools (e.g., database migrators and verifiers purchased from a *software* vendor) or category 5 - custom applications (e.g., SQL scripts, data migration robots, internally developed programs).\n\nInfrastructure tools must be suitable for the intended use. The rigor of the activities of related specification and verification must be proportionate to the associated risks. Depending on the scope, complexity and customization of the *software* tools used, validation requirements may vary from obtaining evidence of basic testing to preparing full *software* and its formal verification.\n\nThe Subject Specialist (SME) should ensure that appropriate life cycle activities and objectives are reached are identified and executed.\n\nThe Quality Unit must review and approve the key documentation, in accordance with the procedures of the company.\n\nFor *software* tools that move or transform data, there are three main areas of risk:\n\n1. The data is moved or transformed incorrectly or incompletely;\n2. The data already existing in the target system is damaged;\n3. In case only part of the data is migrated, the residual data from the source system is adversely affected by the removal of the migrated data.\n\nIt is important that a data mapping table (i.e., fields in the model source system data mapped to the target system data model), when using *software* tools for migration.\n\n## 12.3.2 Verification of Data\n\nThe data must be verified whenever they are moved or transformed. There are two general types of post-migration verification of data: verification in a test environment and verification in an environment.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos destaca la importancia de la adecuaci\u00f3n de las herramientas de software para la migraci\u00f3n de datos. Se menciona que estas herramientas pueden clasificarse en categor\u00edas de GAMP y que su validaci\u00f3n debe ser proporcional a los riesgos asociados. Adem\u00e1s, se identifican \u00e1reas de riesgo en la migraci\u00f3n de datos y se enfatiza la necesidad de verificar los datos despu\u00e9s de su movimiento o transformaci\u00f3n.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfCu\u00e1les son las categor\u00edas de GAMP a las que pertenecen las herramientas de software utilizadas en la migraci\u00f3n de datos y qu\u00e9 ejemplos se dan para cada categor\u00eda?**\n   - Respuesta: Las herramientas de software utilizadas en la migraci\u00f3n de datos pertenecen a GAMP categor\u00eda 1 (herramientas de infraestructura, como migradores y verificadores de bases de datos) y categor\u00eda 5 (aplicaciones personalizadas, como scripts SQL y robots de migraci\u00f3n de datos).\n\n2. **\u00bfQu\u00e9 tres \u00e1reas de riesgo se identifican en el uso de herramientas de software para mover o transformar datos?**\n   - Respuesta: Las tres \u00e1reas de riesgo son: 1) el movimiento o transformaci\u00f3n incorrecta o incompleta de los datos; 2) el da\u00f1o a los datos existentes en el sistema de destino; y 3) el efecto adverso en los datos residuales del sistema de origen si solo se migra parte de los datos.\n\n3. **\u00bfQu\u00e9 tipo de verificaci\u00f3n se debe realizar despu\u00e9s de la migraci\u00f3n de datos y en qu\u00e9 entornos se puede llevar a cabo?**\n   - Respuesta: Se debe realizar una verificaci\u00f3n de los datos despu\u00e9s de su movimiento o transformaci\u00f3n, que puede llevarse a cabo en un entorno de prueba y en un entorno de producci\u00f3n.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Gesti\u00f3n de Calidad**: Se enfatiza la importancia de una gesti\u00f3n de calidad efectiva a lo largo del ciclo de vida de un sistema inform\u00e1tico, especialmente en las actividades de migraci\u00f3n de datos.\n\n2. **Ciclo de Vida del Sistema**:\n   - **Etapas de Migraci\u00f3n de Datos**: La migraci\u00f3n de datos puede ocurrir en tres momentos clave: durante el desarrollo y la implementaci\u00f3n inicial, durante actualizaciones de la aplicaci\u00f3n y al retirar el sistema.\n   - **Elementos de un Ciclo de Vida Completo**: Debe incluir roles y responsabilidades, requisitos de documentaci\u00f3n, controles de calidad y cumplimiento, actividades t\u00e9cnicas y de verificaci\u00f3n, y gesti\u00f3n de proyectos.\n\n3. **Gesti\u00f3n de Riesgos**:\n   - **Proceso de Evaluaci\u00f3n de Riesgos**: Se debe establecer un proceso de gesti\u00f3n de riesgos para evaluar los riesgos espec\u00edficos asociados con la migraci\u00f3n de datos regulados.\n   - **Tipos de Riesgos a Evaluar**:\n     - Riesgos relacionados con la calidad y cumplimiento de los datos migrados (impacto en la seguridad del paciente, calidad del producto e integridad).\n     - Riesgos asociados con los procesos de negocio del sistema.\n     - Riesgos por la falta de disponibilidad del sistema o la fiabilidad de los datos migrados.\n     - Complejidad del proceso de migraci\u00f3n (m\u00faltiples fuentes o sistemas de destino, m\u00faltiples fases, gran cantidad de datos transformados).\n     - Riesgos tecnol\u00f3gicos derivados del uso de sistemas o herramientas complejas.\n\n4. **Gesti\u00f3n de Configuraci\u00f3n y Control de Cambios**: Aunque no se detalla en esta secci\u00f3n, se menciona la importancia de estos aspectos en el contexto de la gesti\u00f3n de calidad y la migraci\u00f3n de datos.\n\n### Entidades Clave\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil, responsable de la regulaci\u00f3n de sistemas inform\u00e1ticos en el \u00e1mbito de la salud.\n- **Sistemas Inform\u00e1ticos**: Sistemas que requieren validaci\u00f3n y gesti\u00f3n de calidad en su ciclo de vida.\n- **Migraci\u00f3n de Datos**: Proceso cr\u00edtico que debe ser gestionado cuidadosamente para asegurar la calidad y cumplimiento.\n- **Riesgos**: Elementos que deben ser evaluados y gestionados durante la migraci\u00f3n de datos, incluyendo riesgos tecnol\u00f3gicos y de negocio.", "excerpt_keywords": "Keywords: data migration, software validation, GAMP categories, risk management, verification processes"}}, "8e951baf-e356-4a4e-810c-eebb3fbacc7c": {"node_ids": ["e9d6862b-5ea6-435a-827f-9e23f2e831f7"], "metadata": {"page_label": "95", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "In testing in a test environment, a target test system is initially filled with data, then a migration test is performed and finally the data on the target system is verified to demonstrate that all the data migrated successfully and without adversely affecting the existing data. This check provides objective evidence that the software tool is suitable for its intended use and provides a level of confidence about the migration process in general.\n\nThe intention of verification in the operating environment is the same: to verify the result of the migration process both migrated data and existing data. The amount of data involved, however, is usually much larger and therefore more difficult to verify. There are two general approaches to solving this problem: data sampling and automated data verification tools.\n\nIn data sampling, a statistical sample of the population of migrated and/or existing data is verified on the target or target system. Standards such as ANSI / ASQ Z1.4 and ISO 2859, can be used to determine the appropriate sample size to verify the compliance of the entire data population at the desired confidence level.\n\nAutomated software tools can be used to verify 100% of the data on the target system or destination. However, these tools have a higher level of risk and consequently their suitability must be strictly determined.\n\nAn important part of data migration is the confirmation that all necessary data has been migrated. Verification techniques, such as checksum, can be used to corroborate the transmission complete data.\n\nObjective evidence of data verification must be generated. Check scripts and data sheets, copies screens, error logs and paper reports should be created when appropriate and feasible.\n\n## 12.3.3 Reliability of Source Data\n\nIf the source system is maintained in compliance with regulatory requirements, then the combination of controls of the source system with the controls performed during the migration process should provide sufficient guarantee of the accuracy and integrity of the migrated data.\n\nTo document this, the data migration plan must reference the appropriate system documentation source.\n\nIf the situation of the source system is unknown, then there are two problems: first, the veracity of the data migrated from the source system may not be reliable; and second, the migrated data will mix with the trusted data already in the controlled target system. After migration, existing data that is trusted and unreliable data will be mixed and difficult to distinguish unless actions are taken to identify the migrated data, such as: differences in registration dates and notes in defined fields by the user. If this is not possible, then the possible data inconsistencies should be documented, explaining the existing controls in the source system and the justification of why the migrated data should be reliable.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con res\u00famenes de nivel superior que pueden ayudar a formularlas:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos detalla los procedimientos para garantizar la integridad y precisi\u00f3n de los datos durante el proceso de migraci\u00f3n. Se enfatiza la importancia de la verificaci\u00f3n tanto en entornos de prueba como en entornos operativos, y se discuten m\u00e9todos como el muestreo de datos y herramientas de verificaci\u00f3n automatizadas. Tambi\u00e9n se aborda la fiabilidad de los datos de origen y las implicaciones de mezclar datos migrados con datos existentes en el sistema de destino.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfCu\u00e1les son las implicaciones de no poder verificar la fiabilidad del sistema de origen antes de realizar una migraci\u00f3n de datos?**\n   - Respuesta: Si la situaci\u00f3n del sistema de origen es desconocida, la veracidad de los datos migrados puede no ser confiable, lo que resulta en la mezcla de datos confiables y no confiables en el sistema de destino. Esto puede dificultar la identificaci\u00f3n de datos migrados y generar inconsistencias que deben ser documentadas.\n\n2. **\u00bfQu\u00e9 est\u00e1ndares se pueden utilizar para determinar el tama\u00f1o de la muestra en el muestreo de datos durante la verificaci\u00f3n de la migraci\u00f3n?**\n   - Respuesta: Se pueden utilizar est\u00e1ndares como ANSI / ASQ Z1.4 y ISO 2859 para determinar el tama\u00f1o de la muestra apropiado que permita verificar la conformidad de toda la poblaci\u00f3n de datos al nivel de confianza deseado.\n\n3. **\u00bfQu\u00e9 tipo de evidencia objetiva se debe generar para documentar la verificaci\u00f3n de datos durante el proceso de migraci\u00f3n?**\n   - Respuesta: Se debe generar evidencia objetiva que puede incluir scripts de verificaci\u00f3n, hojas de datos, capturas de pantalla, registros de errores y reportes en papel, siempre que sea apropiado y factible. Esto es crucial para demostrar que el proceso de migraci\u00f3n se realiz\u00f3 correctamente y que los datos son precisos y completos.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n#### Temas Clave:\n1. **Adecuaci\u00f3n de Herramientas de Software**: La migraci\u00f3n de datos requiere herramientas de software que se clasifiquen en categor\u00edas GAMP, espec\u00edficamente categor\u00eda 1 (herramientas de infraestructura) y categor\u00eda 5 (aplicaciones personalizadas). La adecuaci\u00f3n de estas herramientas debe ser evaluada en funci\u00f3n de su uso previsto.\n\n2. **Rigor en la Validaci\u00f3n**: La validaci\u00f3n de las herramientas de software debe ser proporcional a los riesgos asociados, variando desde pruebas b\u00e1sicas hasta verificaciones formales completas.\n\n3. **\u00c1reas de Riesgo en la Migraci\u00f3n de Datos**:\n   - Movimiento o transformaci\u00f3n incorrecta o incompleta de datos.\n   - Da\u00f1o a los datos existentes en el sistema de destino.\n   - Efectos adversos en los datos residuales del sistema de origen si solo se migra parte de los datos.\n\n4. **Verificaci\u00f3n de Datos**: Es esencial verificar los datos despu\u00e9s de su movimiento o transformaci\u00f3n, lo que puede realizarse en entornos de prueba y producci\u00f3n.\n\n5. **Documentaci\u00f3n y Revisi\u00f3n**: La Unidad de Calidad debe revisar y aprobar la documentaci\u00f3n clave, siguiendo los procedimientos de la empresa.\n\n#### Entidades:\n- **GAMP**: Grupo de trabajo que clasifica herramientas de software en diferentes categor\u00edas.\n- **Herramientas de Infraestructura**: Ejemplos incluyen migradores y verificadores de bases de datos.\n- **Aplicaciones Personalizadas**: Ejemplos incluyen scripts SQL y robots de migraci\u00f3n de datos.\n- **Subject Specialist (SME)**: Especialista responsable de asegurar que se cumplan las actividades y objetivos del ciclo de vida.\n- **Quality Unit**: Unidad encargada de la revisi\u00f3n y aprobaci\u00f3n de la documentaci\u00f3n relacionada con la migraci\u00f3n de datos.\n\nEste resumen destaca la importancia de la adecuaci\u00f3n y validaci\u00f3n de las herramientas de software en la migraci\u00f3n de datos, as\u00ed como los riesgos asociados y la necesidad de verificaci\u00f3n post-migraci\u00f3n.", "excerpt_keywords": "Keywords: data migration, verification, source data reliability, automated tools, data sampling"}}, "115072f6-6ef1-4403-bd3d-c292803ffe5f": {"node_ids": ["61820dbb-7f35-4787-a429-e6c0eb10bbcb"], "metadata": {"page_label": "96", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "### 12.3.4 Usability of Migrated Data on the Target System\n\nThere are three main problems to be considered, related to the usability of the data migrated to the target system:\n\n1. The functionality of the target system does not allow the performance of tasks previously performed in the source system;\n2. Lack of completeness of the migrated data affects the usability of the data;\n3. It may not be enough to migrate the data. Separate migration of metadata or system configuration destination may be required. For example, the source data has some access rights defined for it, such as user groups and user rights. Data migration may not migrate this metadata, which are normally separated from the data. However, these groups and user rights can also be required on the target system.\n\n### 12.3.5 Audit Trails (Audit trails)\n\nAudit trails can be problematic for the data migration process. If the target system has an audit trail, but the source system does not, a document must be created reflecting that the Auditing of migrated records started when they were transferred to the target system. If possible, these records must be distinguishable from the records that were generated in the target system.\n\nIf both systems have audit trails and migration is feasible, the audit trail should be migrated along with the audited data. If it is technically impossible to migrate the audit trail or doing this would be a very big risk, the original audit trail should be archived in a format that can be recovered over time.\n\nWhenever possible, an audit trail created by the computer should be created during movement and transformation associated with data migration, as this audit trail serves not only as a verification tool, but also as a historical record of changes in data and should be archived in a format that can be retrieved over time.\n\n### 12.4 DATA MIGRATION PLAN\n\nDifferent types of data migration require different activities and objectives. Each migration process must have a data migration plan. This plan serves as a high-level roadmap that guides the team that performs the migration to execute it properly.\n\nThis plan should describe the entire migration process, including:\n\n- Purpose and scope of the migration project;\n- Description of the system(s);\n- Roles and responsibilities;\n- Objectives to be achieved;\n- Risk management strategy;", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que pueden ser respondidas por el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos aborda la migraci\u00f3n de datos, destacando problemas relacionados con la usabilidad de los datos migrados, la importancia de los registros de auditor\u00eda y la necesidad de un plan de migraci\u00f3n de datos. Se identifican problemas como la falta de funcionalidad en el sistema de destino, la incompletitud de los datos migrados y la posible necesidad de migrar metadatos. Adem\u00e1s, se discute c\u00f3mo manejar los registros de auditor\u00eda durante la migraci\u00f3n y se enfatiza la importancia de tener un plan de migraci\u00f3n bien definido.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfCu\u00e1les son las implicaciones de no migrar los metadatos junto con los datos en un proceso de migraci\u00f3n?**\n   - La falta de migraci\u00f3n de metadatos puede resultar en la p\u00e9rdida de configuraciones cr\u00edticas, como derechos de acceso y grupos de usuarios, lo que podr\u00eda afectar la funcionalidad y la seguridad del sistema de destino.\n\n2. **\u00bfQu\u00e9 pasos deben seguirse si el sistema de origen no tiene un registro de auditor\u00eda y el sistema de destino s\u00ed?**\n   - En este caso, se debe crear un documento que indique que la auditor\u00eda de los registros migrados comenz\u00f3 en el momento de la transferencia al sistema de destino, y se deben distinguir estos registros de los generados en el nuevo sistema.\n\n3. **\u00bfQu\u00e9 elementos clave debe incluir un plan de migraci\u00f3n de datos seg\u00fan el documento de ANVISA?**\n   - Un plan de migraci\u00f3n de datos debe incluir el prop\u00f3sito y el alcance del proyecto de migraci\u00f3n, una descripci\u00f3n de los sistemas involucrados, roles y responsabilidades, objetivos a alcanzar y una estrategia de gesti\u00f3n de riesgos.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Verificaci\u00f3n de Datos en Migraci\u00f3n**:\n   - La verificaci\u00f3n de datos es crucial tanto en entornos de prueba como en entornos operativos para asegurar que los datos migrados no afecten negativamente a los datos existentes.\n   - Se utilizan m\u00e9todos como el muestreo de datos y herramientas de verificaci\u00f3n automatizadas para validar la migraci\u00f3n.\n\n2. **Muestreo de Datos**:\n   - Se recomienda el uso de est\u00e1ndares como ANSI / ASQ Z1.4 y ISO 2859 para determinar el tama\u00f1o de la muestra necesaria para verificar la conformidad de la poblaci\u00f3n de datos migrados y existentes.\n\n3. **Herramientas de Verificaci\u00f3n Automatizadas**:\n   - Estas herramientas pueden verificar el 100% de los datos, pero conllevan un mayor riesgo, por lo que su idoneidad debe ser evaluada cuidadosamente.\n\n4. **Evidencia Objetiva**:\n   - Es fundamental generar evidencia objetiva de la verificaci\u00f3n de datos, que puede incluir scripts de verificaci\u00f3n, hojas de datos, capturas de pantalla, registros de errores y reportes en papel.\n\n5. **Fiabilidad de los Datos de Origen**:\n   - La fiabilidad de los datos migrados depende de que el sistema de origen cumpla con los requisitos regulatorios. Si la situaci\u00f3n del sistema de origen es desconocida, puede haber problemas de veracidad y mezcla de datos confiables y no confiables en el sistema de destino.\n\n6. **Documentaci\u00f3n del Proceso de Migraci\u00f3n**:\n   - El plan de migraci\u00f3n de datos debe referirse a la documentaci\u00f3n del sistema de origen para garantizar la precisi\u00f3n e integridad de los datos migrados.\n\n### Entidades Clave\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil, responsable de la regulaci\u00f3n de sistemas inform\u00e1ticos en el \u00e1mbito de la salud.\n- **Est\u00e1ndares ANSI / ASQ Z1.4 y ISO 2859**: Normas utilizadas para determinar el tama\u00f1o de la muestra en el muestreo de datos.\n- **Herramientas de Verificaci\u00f3n Automatizadas**: Software utilizado para verificar la integridad de los datos migrados.\n- **Checksum**: T\u00e9cnica de verificaci\u00f3n utilizada para corroborar la integridad de los datos transmitidos.\n- **Datos de Origen y Datos de Destino**: Conceptos que se refieren a los datos que se migran desde un sistema (origen) a otro (destino). \n\nEste resumen abarca los aspectos esenciales de la secci\u00f3n, destacando la importancia de la verificaci\u00f3n de datos y la documentaci\u00f3n en el proceso de migraci\u00f3n.", "excerpt_keywords": "Keywords: data migration, usability, audit trails, metadata, migration plan"}}, "0eca79aa-00fd-4c30-b48b-482fb9240a7b": {"node_ids": ["8ab25a81-9050-4799-b072-11e5656908a9"], "metadata": {"page_label": "97", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "- Configuration management strategy, including source, stationary and destiny;\n- Overview and strategy of the software tool to ensure compliance and suitability for use intended;\n- Migration steps and technical activities;\n- Mapping and data modeling activities;\n- Transformation rules;\n- Data verification strategy and acceptance criteria;\n- Transition plan;\n- Reversal strategy.\n\nThe migration plan must be approved by the process owner, system owner, Quality Unit and Subject matter expert where appropriate.\n\nThere may be situations where the migration plan can be used more than once. When this occurs, a data migration report must be generated.\n\n## 12.5 DATA MIGRATION REPORT\n\nThe data migration report summarizes the activities that were conducted during the migration process. Describes any anomalies or deviations that have occurred and lists the results of the verification activities, including objective evidence, where appropriate.\n\nBecause the report is used to establish the reliability of the migrated data, it must declare clearly the result of the migration activity.\n\nThe data migration report must be approved by the process owner, system owner, Quality and subject matter expert, when appropriate.\n\nIn the event that the data migration activity is carried out as part of a system design computerized, such as replacement or update, the report can be registered within the project documentation and there needs to be a separate document.\n\n## 13 RETIREMENT OF COMPUTERIZED SYSTEMS\n\n### 13.1 INTRODUCTION\n\nThe system's retirement process must be documented through a retirement plan, which usually receives contributions from the following actors: owner of the process, Quality Unit, owner of the system and Information Technology.\n\nProcess planning content can include:\n-", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos establece directrices para la gesti\u00f3n de la migraci\u00f3n de datos y el retiro de sistemas inform\u00e1ticos. Se enfatiza la importancia de un plan de migraci\u00f3n que debe ser aprobado por varias partes interesadas y la necesidad de un informe de migraci\u00f3n de datos que documente las actividades realizadas, anomal\u00edas y resultados de verificaci\u00f3n. Adem\u00e1s, se menciona que el proceso de retiro de sistemas debe ser documentado adecuadamente, involucrando a actores clave como el propietario del proceso y la unidad de calidad.\n\n### Preguntas Espec\u00edficas\n1. **\u00bfQu\u00e9 actores deben aprobar el plan de migraci\u00f3n de datos y por qu\u00e9 es importante su aprobaci\u00f3n?**\n   - El plan de migraci\u00f3n debe ser aprobado por el propietario del proceso, el propietario del sistema, la Unidad de Calidad y el experto en la materia, cuando sea apropiado. Esta aprobaci\u00f3n es crucial para garantizar que todas las partes interesadas est\u00e9n de acuerdo con el enfoque y los procedimientos de migraci\u00f3n, lo que ayuda a asegurar la integridad y la fiabilidad de los datos migrados.\n\n2. **\u00bfQu\u00e9 informaci\u00f3n debe incluirse en el informe de migraci\u00f3n de datos y cu\u00e1l es su prop\u00f3sito?**\n   - El informe de migraci\u00f3n de datos debe resumir las actividades realizadas durante el proceso de migraci\u00f3n, describir cualquier anomal\u00eda o desviaci\u00f3n que haya ocurrido y listar los resultados de las actividades de verificaci\u00f3n, incluyendo evidencia objetiva cuando sea apropiado. Su prop\u00f3sito es establecer la fiabilidad de los datos migrados y proporcionar un registro claro de los resultados de la actividad de migraci\u00f3n.\n\n3. **\u00bfCu\u00e1les son los componentes clave que deben documentarse en un plan de retiro de sistemas inform\u00e1ticos?**\n   - El plan de retiro de sistemas inform\u00e1ticos debe documentar el proceso de retiro y generalmente incluye contribuciones de actores como el propietario del proceso, la Unidad de Calidad, el propietario del sistema y el departamento de Tecnolog\u00eda de la Informaci\u00f3n. Los contenidos del plan pueden abarcar aspectos como la estrategia de gesti\u00f3n de la configuraci\u00f3n y las actividades necesarias para asegurar un retiro ordenado y conforme a las regulaciones.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Usabilidad de los Datos Migrados**:\n   - **Problemas Identificados**:\n     - Funcionalidad del sistema de destino que puede no permitir tareas previamente realizadas en el sistema de origen.\n     - Incompletitud de los datos migrados que afecta su usabilidad.\n     - Necesidad de migrar metadatos o configuraciones del sistema de destino, como derechos de acceso y grupos de usuarios.\n\n2. **Registros de Auditor\u00eda**:\n   - **Desaf\u00edos**:\n     - Si el sistema de origen no tiene un registro de auditor\u00eda y el de destino s\u00ed, se debe documentar el inicio de la auditor\u00eda de los registros migrados.\n     - Si ambos sistemas tienen registros de auditor\u00eda, estos deben ser migrados junto con los datos auditados, a menos que sea t\u00e9cnicamente inviable o arriesgado.\n     - Importancia de crear un registro de auditor\u00eda durante el proceso de migraci\u00f3n para servir como herramienta de verificaci\u00f3n y registro hist\u00f3rico.\n\n3. **Plan de Migraci\u00f3n de Datos**:\n   - **Elementos Clave**:\n     - Prop\u00f3sito y alcance del proyecto de migraci\u00f3n.\n     - Descripci\u00f3n de los sistemas involucrados.\n     - Roles y responsabilidades del equipo de migraci\u00f3n.\n     - Objetivos a alcanzar durante la migraci\u00f3n.\n     - Estrategia de gesti\u00f3n de riesgos para abordar posibles problemas.\n\n### Entidades Clave\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil, responsable de la regulaci\u00f3n y validaci\u00f3n de sistemas inform\u00e1ticos en el \u00e1mbito de la salud.\n- **Sistemas de Origen y Destino**: Sistemas entre los cuales se realiza la migraci\u00f3n de datos.\n- **Metadatos**: Informaci\u00f3n adicional sobre los datos que puede ser crucial para la funcionalidad y seguridad del sistema de destino.\n- **Registros de Auditor\u00eda**: Documentaci\u00f3n que rastrea las acciones realizadas sobre los datos, esencial para la trazabilidad y cumplimiento normativo. \n\nEste resumen destaca la importancia de considerar la usabilidad, la gesti\u00f3n de registros de auditor\u00eda y la planificaci\u00f3n adecuada en los procesos de migraci\u00f3n de datos.", "excerpt_keywords": "Keywords: migration plan, data verification, retirement process, quality assurance, system validation"}}, "2f0329c3-19b8-4c80-8bd9-0ceb09d80315": {"node_ids": ["1f838a5d-cfd5-4f54-925e-d747a78caf77"], "metadata": {"page_label": "98", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "- Destruction and retention requirements for historical data or records;\n- Identification of the current hardware and software configuration, as well as the systems they have interface, equipment or instruments;\n- Identification of any external systems that depend on the system's data or records.\n\nThe extent and accuracy of planning depends on the impact of the system and the risks associated with loss of Dice.\n\nThe system's retirement plan must be approved by the process owner and quality unit.\n\n## 13.2 SYSTEM RETIREMENT PLAN\n\n### 13.2.1 Introduction\n\nThe introduction should include:\n\n- Who produced the document, under what authority and for what purpose;\n- Reference to policies, procedures, standards, guides and other documents.\n\n### 13.2.2 Roles and Responsibilities\n\nThe roles and responsibilities associated with the retirement process must be documented in the plan, and must include the owner of the process, the Quality Unit, the owner of the system, the retirement team and its members and any other actors that contribute to the process.\n\n### 13.2.3 Overview and Implications\n\nConsideration should be given to the retirement effect of the system in some aspects, such as:\n\n- **Strategy** - document the impact on the overall technology strategy and initiate any updates to the documentation or other necessary actions;\n- **Process** - describe the impact on supporting the business process after retirement;\n- **Technology** - the scope and boundaries of the system to be retired must be determined and documented, as well as the justification for retirement. Identify other systems, instruments or equipment that has interfaces with the system that will retire. Data or information sources can be located on multiple systems. Identify the infrastructure components (network, etc.) that will need to be decoupled from the system;\n- **Personnel** - describe the impact on users of the system.\n\n### 13.2.4 Description of the Business Process\n\nThe pre-retirement business process must be documented and understood from the perspective of the process, user and data / records. This helps to ensure that all impacts are identified and all support and automation angles are translated into a post-retirement scenario.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos establece directrices para la planificaci\u00f3n de la jubilaci\u00f3n de sistemas. Se enfatiza la importancia de documentar los roles y responsabilidades en el proceso de jubilaci\u00f3n, as\u00ed como las implicaciones estrat\u00e9gicas, de proceso, tecnol\u00f3gicas y de personal. Tambi\u00e9n se menciona la necesidad de un plan de jubilaci\u00f3n aprobado por el propietario del proceso y la unidad de calidad, y se destaca la importancia de entender el proceso de negocio previo a la jubilaci\u00f3n para identificar todos los impactos.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfQu\u00e9 elementos deben incluirse en la introducci\u00f3n del plan de jubilaci\u00f3n del sistema seg\u00fan el documento de ANVISA?**\n   - La introducci\u00f3n debe incluir qui\u00e9n produjo el documento, bajo qu\u00e9 autoridad y con qu\u00e9 prop\u00f3sito, as\u00ed como referencias a pol\u00edticas, procedimientos, est\u00e1ndares, gu\u00edas y otros documentos relevantes.\n\n2. **\u00bfCu\u00e1les son las consideraciones clave que deben tenerse en cuenta al evaluar el impacto de la jubilaci\u00f3n de un sistema en la estrategia tecnol\u00f3gica de una organizaci\u00f3n?**\n   - Se debe documentar el impacto en la estrategia tecnol\u00f3gica general, iniciar actualizaciones necesarias en la documentaci\u00f3n y considerar c\u00f3mo la jubilaci\u00f3n afectar\u00e1 el soporte de los procesos comerciales.\n\n3. **\u00bfQu\u00e9 pasos deben seguirse para identificar los sistemas externos que dependen de los datos o registros del sistema que se va a jubilar?**\n   - Es necesario identificar otros sistemas, instrumentos o equipos que tengan interfaces con el sistema que se jubilar\u00e1, as\u00ed como determinar y documentar el alcance y los l\u00edmites del sistema a jubilar, justificando su jubilaci\u00f3n y localizando fuentes de datos en m\u00faltiples sistemas.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos aborda dos temas principales: la migraci\u00f3n de datos y el retiro de sistemas inform\u00e1ticos.\n\n#### Temas Clave\n\n1. **Plan de Migraci\u00f3n de Datos**:\n   - Se requiere un plan de migraci\u00f3n que incluya estrategias de gesti\u00f3n de configuraci\u00f3n, pasos de migraci\u00f3n, actividades de mapeo y modelado de datos, reglas de transformaci\u00f3n, y criterios de verificaci\u00f3n de datos.\n   - La aprobaci\u00f3n del plan es necesaria por parte del propietario del proceso, el propietario del sistema, la Unidad de Calidad y el experto en la materia.\n\n2. **Informe de Migraci\u00f3n de Datos**:\n   - Debe resumir las actividades realizadas, describir anomal\u00edas y listar resultados de verificaci\u00f3n.\n   - Su prop\u00f3sito es establecer la fiabilidad de los datos migrados y debe ser aprobado por las mismas partes interesadas que el plan de migraci\u00f3n.\n\n3. **Retiro de Sistemas Inform\u00e1ticos**:\n   - El proceso de retiro debe ser documentado a trav\u00e9s de un plan de retiro que involucre a actores clave como el propietario del proceso, la Unidad de Calidad, el propietario del sistema y el departamento de Tecnolog\u00eda de la Informaci\u00f3n.\n   - El contenido del plan puede incluir estrategias y actividades necesarias para un retiro ordenado y conforme a las regulaciones.\n\n#### Entidades Involucradas\n\n- **Propietario del Proceso**: Responsable de la supervisi\u00f3n del proceso de migraci\u00f3n y retiro.\n- **Propietario del Sistema**: Encargado de la gesti\u00f3n del sistema inform\u00e1tico en cuesti\u00f3n.\n- **Unidad de Calidad**: Asegura que los procesos cumplan con los est\u00e1ndares de calidad requeridos.\n- **Experto en la Materia**: Proporciona conocimientos especializados relevantes para el proceso.\n- **Departamento de Tecnolog\u00eda de la Informaci\u00f3n**: Apoya en la implementaci\u00f3n t\u00e9cnica de los procesos de migraci\u00f3n y retiro.\n\nEste resumen destaca la importancia de la planificaci\u00f3n y documentaci\u00f3n en la migraci\u00f3n y retiro de sistemas inform\u00e1ticos, asegurando la integridad y fiabilidad de los datos a lo largo del proceso.", "excerpt_keywords": "Keywords: system retirement, data retention, roles and responsibilities, technology strategy, business process documentation"}}, "de5593e2-4ffc-4114-ba8c-cbc70b3c89be": {"node_ids": ["aab4728c-037c-4724-82df-647e50078b59"], "metadata": {"page_label": "99", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "This future scenario must be documented and understood, especially with regard to changes in the process and/or user and the location or effect on the data/records.\n\n## 13.2.5 Approach to Retirement\n\nThe decision on whether to replace the system should be documented. If the system is replaced, the retirement planning should be referenced and synchronized with the substitute system. The approach for decoupling the *interface*, disconnecting the infrastructure, finalizing or transition from technical support and any assumptions, exclusions, limitations or dependencies must be documented.\n\n## 13.2.6 Migration, Archiving and Destruction of Data and Records\n\nThe plan must identify what data should be migrated, archived or destroyed and the approval process associated.\n\nThe approach to data migration and archiving should be determined based on the history of access to data, the need for reprocessing, the risk level of registration and the robustness of the media used. Controls should be established to ensure that data and records remain secure, complete, accurate and that the signature/registration relationship is preserved, when applicable.\n\nThe approach must take into account the following aspects:\n\n- If data are to be maintained, they must be **backed up** and stored, in accordance with company data retention schedules and procedures;\n- Before data is moved or archived from the system, the appropriate data recovery must be available and tested;\n- The archived data media must be stored and maintained in accordance with the recommendations of the manufacturer and under the necessary environmental conditions;\n- If data and records are migrated to a replacement system, the migration must be planned, conducted and verified to ensure data integrity. Migration procedures should be tested or confirmed before data is completely transferred out of the system;\n- The methods to be used for migration/conversion and verification of data records must be defined. This may include performing pilot work before actual data migration occurs, or temporary parallel operation of both systems (new system and the system to be retired);\n- If the data is going to be migrated to the replacement system, the testing strategy for verifying the migration must be defined. If an automated migration or conversion is used, the approach to ensuring their suitability for the intended use must be documented.\n\n## 13.2.7 Approach to Verification\n\nVerification documentation, necessary as part of the employee's retirement process, must be identified.\n\n## 13.2.8 System Maintenance and Discontinuation of Support\n\nThe necessary actions associated with (s) must be planned:", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior del contenido:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos aborda la planificaci\u00f3n y ejecuci\u00f3n de la jubilaci\u00f3n de sistemas, la migraci\u00f3n, archivo y destrucci\u00f3n de datos y registros, as\u00ed como la verificaci\u00f3n y mantenimiento de sistemas. Se enfatiza la importancia de documentar decisiones, establecer controles de seguridad y asegurar la integridad de los datos durante el proceso de migraci\u00f3n y archivo.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfCu\u00e1les son los pasos clave que deben seguirse al planificar la jubilaci\u00f3n de un sistema inform\u00e1tico seg\u00fan el documento de ANVISA?**\n   - La planificaci\u00f3n de la jubilaci\u00f3n debe incluir la documentaci\u00f3n de la decisi\u00f3n de reemplazo, la sincronizaci\u00f3n con el sistema sustituto, el desacoplamiento de interfaces, la desconexi\u00f3n de la infraestructura y la finalizaci\u00f3n del soporte t\u00e9cnico, as\u00ed como la identificaci\u00f3n de cualquier suposici\u00f3n o limitaci\u00f3n.\n\n2. **\u00bfQu\u00e9 consideraciones deben tenerse en cuenta al migrar datos a un nuevo sistema seg\u00fan las directrices de ANVISA?**\n   - La migraci\u00f3n de datos debe planificarse y verificarse para asegurar la integridad de los datos. Esto incluye realizar pruebas de los procedimientos de migraci\u00f3n, definir m\u00e9todos de conversi\u00f3n y verificaci\u00f3n, y establecer una estrategia de prueba para validar la migraci\u00f3n, especialmente si se utiliza un proceso automatizado.\n\n3. **\u00bfQu\u00e9 controles se deben establecer para garantizar la seguridad y precisi\u00f3n de los datos durante el proceso de archivo y destrucci\u00f3n?**\n   - Se deben establecer controles para asegurar que los datos y registros se mantengan seguros, completos y precisos. Esto incluye realizar copias de seguridad de los datos, probar la recuperaci\u00f3n de datos antes de moverlos, y almacenar los medios de datos archivados de acuerdo con las recomendaciones del fabricante y las condiciones ambientales necesarias.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos aborda la planificaci\u00f3n de la jubilaci\u00f3n de sistemas, destacando varios aspectos esenciales que deben considerarse para garantizar un proceso efectivo y controlado. A continuaci\u00f3n se presentan los temas clave y las entidades relevantes:\n\n#### Temas Clave\n\n1. **Requisitos de Destrucci\u00f3n y Retenci\u00f3n**: Se deben establecer requisitos claros para la destrucci\u00f3n y retenci\u00f3n de datos o registros hist\u00f3ricos.\n\n2. **Configuraci\u00f3n Actual**: Es fundamental identificar la configuraci\u00f3n actual de hardware y software, as\u00ed como los sistemas, equipos o instrumentos que interfieren con el sistema en cuesti\u00f3n.\n\n3. **Sistemas Externos Dependientes**: Se debe identificar cualquier sistema externo que dependa de los datos o registros del sistema que se va a jubilar.\n\n4. **Plan de Jubilaci\u00f3n del Sistema**: Este plan debe ser aprobado por el propietario del proceso y la unidad de calidad, y debe incluir:\n   - Introducci\u00f3n que detalle la producci\u00f3n del documento y su prop\u00f3sito.\n   - Roles y responsabilidades de los actores involucrados en el proceso de jubilaci\u00f3n.\n   - Consideraciones sobre el impacto estrat\u00e9gico, de proceso, tecnol\u00f3gico y en el personal tras la jubilaci\u00f3n del sistema.\n\n5. **Descripci\u00f3n del Proceso de Negocio**: Es crucial documentar y entender el proceso de negocio previo a la jubilaci\u00f3n para identificar todos los impactos y asegurar una transici\u00f3n adecuada.\n\n#### Entidades Relevantes\n\n- **Propietario del Proceso**: Persona o entidad responsable de la gesti\u00f3n del proceso relacionado con el sistema.\n- **Unidad de Calidad**: Entidad encargada de asegurar que el proceso de jubilaci\u00f3n cumpla con los est\u00e1ndares de calidad.\n- **Equipo de Jubilaci\u00f3n**: Grupo de personas que participan en la planificaci\u00f3n y ejecuci\u00f3n del proceso de jubilaci\u00f3n.\n- **Usuarios del Sistema**: Personas que utilizan el sistema y que se ver\u00e1n afectadas por su jubilaci\u00f3n.\n\nEste resumen proporciona una visi\u00f3n general de los elementos cr\u00edticos que deben considerarse al planificar la jubilaci\u00f3n de un sistema inform\u00e1tico, asegurando que se aborden adecuadamente los riesgos y se mantenga la integridad de los datos.", "excerpt_keywords": "Keywords: retirement planning, data migration, system validation, archiving, data integrity"}}, "2b4a3677-8d19-4249-9741-d342ff5a6f13": {"node_ids": ["0762d9d8-1db4-4896-9590-c9f733cf55e1"], "metadata": {"page_label": "100", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "- Modification or termination of internal or external support agreements;\n- Operations, *backup* and restoration, disaster recovery and business continuity plans;\n- Security, technical support and user administration and configuration management programs.\n\n## 13.2.9 Change Management\n\nFormal change management procedures must be followed for retirement from a system computerized to ensure that the retirement process is controlled and managed.\n\nChanges resulting from the retirement of the system must be addressed, such as changes in roles support (technical support, super-users, etc.) and associated training.\n\nThe approach for communicating the impact of the system's retirement to the people involved should be documented.\n\n## 13.2.10 Timetable\n\nThe schedule should be documented and include individual retirement activities and responsibilities, associated due dates and any other tasks, critical milestones and verification.\n\n## 13.2.11 Execution of Retirement\n\nThe timing of retirement execution must be carefully considered.\n\nThere should be plans for business continuity in case any problems occur during the retirement or migration work. In addition, a backup plan is recommended and should include steps detailed instructions or references to procedures for configuration and reinstallation to make the system retired operational again if necessary.\n\n## 13.2.12 System Documentation and *Software*\n\nSystem and *software documentation*, including source code (Category 5), such as life cycle, validation documentation, change history, standard operating procedures related to the system and other system documents, must be defined. The documentation to be retained must have a responsible owner and a designated safe location. Affected inventories, procedures and others documents must be updated.\n\nDecisions regarding the retention of specific *software* and documents should be based on their potential for future use and in an assessment of the risk associated with its destruction.\n\n## 13.3 SYSTEM RETIREMENT REPORT\n\nAfter executing the system's retirement plan, a summary report should be generated to describe execution and results obtained. If testing or verification activities are performed, the results of these tests should be summarized and any deviations that have occurred should be discussed together with your", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos establece procedimientos y consideraciones para la gesti\u00f3n del retiro de sistemas. Se enfatiza la importancia de seguir procedimientos formales de gesti\u00f3n de cambios, documentar el impacto del retiro, planificar la continuidad del negocio y mantener la documentaci\u00f3n del sistema y del software. Adem\u00e1s, se requiere la generaci\u00f3n de un informe de resumen tras la ejecuci\u00f3n del plan de retiro.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfQu\u00e9 procedimientos deben seguirse para garantizar que el proceso de retiro de un sistema inform\u00e1tico est\u00e9 controlado y gestionado?**\n   - El documento establece que deben seguirse procedimientos formales de gesti\u00f3n de cambios para el retiro del sistema, lo que incluye abordar cambios en roles de soporte y la capacitaci\u00f3n asociada.\n\n2. **\u00bfQu\u00e9 elementos deben incluirse en el cronograma del retiro de un sistema?**\n   - El cronograma debe documentar las actividades individuales de retiro, responsabilidades, fechas de vencimiento, tareas cr\u00edticas y hitos de verificaci\u00f3n.\n\n3. **\u00bfQu\u00e9 tipo de documentaci\u00f3n se debe conservar tras el retiro de un sistema y c\u00f3mo se debe gestionar?**\n   - Se debe conservar la documentaci\u00f3n del sistema y del software, incluyendo el c\u00f3digo fuente, documentaci\u00f3n de validaci\u00f3n, historia de cambios y procedimientos operativos est\u00e1ndar. Esta documentaci\u00f3n debe tener un propietario responsable y un lugar seguro designado, y las decisiones sobre su retenci\u00f3n deben basarse en su potencial para uso futuro y en una evaluaci\u00f3n del riesgo asociado con su destrucci\u00f3n.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Documentaci\u00f3n y Comprensi\u00f3n del Escenario Futuro**: Es fundamental documentar y entender los cambios en los procesos, usuarios y el impacto en los datos y registros.\n\n2. **Enfoque para la Jubilaci\u00f3n del Sistema**:\n   - Documentar la decisi\u00f3n de reemplazo del sistema.\n   - Sincronizar la planificaci\u00f3n de la jubilaci\u00f3n con el sistema sustituto.\n   - Desacoplar interfaces y desconectar la infraestructura.\n   - Finalizar el soporte t\u00e9cnico y documentar suposiciones, exclusiones y limitaciones.\n\n3. **Migraci\u00f3n, Archivo y Destrucci\u00f3n de Datos y Registros**:\n   - Identificar qu\u00e9 datos se migrar\u00e1n, archivar\u00e1n o destruir\u00e1n.\n   - Establecer controles para asegurar la seguridad, integridad y precisi\u00f3n de los datos.\n   - Realizar copias de seguridad y pruebas de recuperaci\u00f3n de datos.\n   - Almacenar medios de datos archivados seg\u00fan recomendaciones del fabricante.\n   - Planificar y verificar la migraci\u00f3n de datos a un sistema de reemplazo, incluyendo pruebas y validaci\u00f3n de procedimientos.\n\n4. **Enfoque para la Verificaci\u00f3n**:\n   - Identificar la documentaci\u00f3n de verificaci\u00f3n necesaria como parte del proceso de jubilaci\u00f3n de empleados.\n\n5. **Mantenimiento del Sistema y Descontinuaci\u00f3n del Soporte**:\n   - Planificar las acciones necesarias relacionadas con el mantenimiento y la discontinuaci\u00f3n del soporte del sistema.\n\n### Entidades Clave\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil, responsable de la regulaci\u00f3n de sistemas inform\u00e1ticos en el \u00e1mbito de la salud.\n- **Sistemas Inform\u00e1ticos**: Herramientas y plataformas que requieren validaci\u00f3n y gesti\u00f3n adecuada durante su ciclo de vida.\n- **Datos y Registros**: Informaci\u00f3n que debe ser gestionada con controles de seguridad y procedimientos de archivo adecuados.\n- **Migraci\u00f3n de Datos**: Proceso de trasladar datos de un sistema a otro, que debe ser cuidadosamente planificado y verificado.\n\nEste resumen destaca la importancia de la planificaci\u00f3n, documentaci\u00f3n y control en la gesti\u00f3n de sistemas inform\u00e1ticos, especialmente en lo que respecta a su jubilaci\u00f3n y manejo de datos.", "excerpt_keywords": "Keywords: system retirement, change management, documentation, business continuity, data migration"}}, "d97c5be0-06bc-490e-9cc9-ca19a09b799d": {"node_ids": ["3b3c33e2-87ce-415c-aef9-0e69e649fd63"], "metadata": {"page_label": "101", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 14. VALIDATION OF SHEETS\n\n## 14.1 INTRODUCTION\n\nTools are available for creating a wide variety of applications for the end user, including custom statistical analysis, local databases, filtering, data manipulation and analysis multivariate. These applications can be used to carry out regulated activities, however these applications tend to be the most under-documented within a GMP environment.\n\nThis Guide will emphasize spreadsheets as they are most often used in companies for treatment of some data regulated by GMP.\n\nThe level and rigor of the specification and verification (validation) used in these applications will depend on the risk involved, its complexity and degree of innovation. The guidelines described here are directed to spreadsheets, but the same principles can be used for other types of applications for the end user.\n\n## 14.2 TYPES OF APPLICATIONS FOR END-USER\n\n### 14.2.1 Disposable Spreadsheets\n\nThey are spreadsheets used in the same way as a calculator, to perform calculations, and it is not An electronic copy of this operation is maintained.\n\nThis activity must be documented in the same way that the calculator would be used, that is, the values and results would be recorded and signed. Results can be printed, labeled and signed. It should be clear on the record sheet exactly which arithmetic operation was performed. This can be facilitated by printing a copy of the spreadsheet showing the calculation formula used. This copy becomes part of the GMP record.\n\nThe calculations used for processing GMP data must be verified. This does not mean that algorithms used by the spreadsheet's native functions need to be checked for accuracy, but rather demonstrate that the correct formulas are being used. Ex: (a + b) * c is different from a + (b * c), and this it is a possible error to occur.\n\nThe verification of the algorithms can be carried out by printing the formula (cell formulae) or by third party review.\n\n### 14.2.2 Spreadsheets Retained as Documents\n\nThere are spreadsheets that are used as a word processor and not as a traditional application. The main difference is that the spreadsheet can be used both to record BPF data and to manipulate it. Of that Therefore, it is advisable to manage them as documents and not as applications. It is extremely difficult establish that all copies saved later are the same as the originals. Calculations, therefore, they should be checked and explained in detail, when they exist in a text document. This includes", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "### Preguntas y Respuestas\n\n1. **\u00bfCu\u00e1l es la principal diferencia entre las hojas de c\u00e1lculo desechables y las hojas de c\u00e1lculo retenidas como documentos seg\u00fan la gu\u00eda de ANVISA?**\n   - Las hojas de c\u00e1lculo desechables se utilizan como calculadoras para realizar c\u00e1lculos sin mantener una copia electr\u00f3nica de la operaci\u00f3n, y su uso debe ser documentado de manera similar a un c\u00e1lculo manual. En cambio, las hojas de c\u00e1lculo retenidas como documentos se utilizan para registrar y manipular datos, y es recomendable gestionarlas como documentos, lo que implica que es dif\u00edcil asegurar que todas las copias guardadas sean id\u00e9nticas a las originales.\n\n2. **\u00bfQu\u00e9 tipo de verificaci\u00f3n se requiere para las hojas de c\u00e1lculo utilizadas en el procesamiento de datos regulados por BPF?**\n   - La verificaci\u00f3n de las hojas de c\u00e1lculo implica demostrar que se est\u00e1n utilizando las f\u00f3rmulas correctas, en lugar de verificar la precisi\u00f3n de los algoritmos de las funciones nativas de la hoja de c\u00e1lculo. Esto puede hacerse imprimiendo las f\u00f3rmulas utilizadas o mediante una revisi\u00f3n por parte de un tercero.\n\n3. **\u00bfPor qu\u00e9 se considera que las hojas de c\u00e1lculo son las aplicaciones m\u00e1s subdocumentadas en un entorno de BPF?**\n   - Las hojas de c\u00e1lculo son consideradas subdocumentadas porque, a menudo, se utilizan para actividades reguladas sin la debida documentaci\u00f3n y validaci\u00f3n, lo que puede llevar a errores en el procesamiento de datos cr\u00edticos. La gu\u00eda de ANVISA enfatiza la necesidad de un enfoque m\u00e1s riguroso en la especificaci\u00f3n y verificaci\u00f3n de estas herramientas.\n\n### Resumen de Nivel Superior\n\nLa gu\u00eda de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos destaca la importancia de las hojas de c\u00e1lculo en el contexto de las Buenas Pr\u00e1cticas de Fabricaci\u00f3n (BPF). Se identifican dos tipos de hojas de c\u00e1lculo: desechables, que se utilizan para c\u00e1lculos simples sin mantener registros electr\u00f3nicos, y aquellas que se retienen como documentos, que permiten tanto el registro como la manipulaci\u00f3n de datos. La gu\u00eda subraya la necesidad de documentar adecuadamente el uso de estas herramientas y de verificar las f\u00f3rmulas utilizadas para garantizar la integridad de los datos regulados. Esto es crucial en un entorno donde la precisi\u00f3n y la trazabilidad son esenciales para cumplir con las normativas de calidad.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Gesti\u00f3n del Cambio**:\n   - Se deben seguir procedimientos formales para gestionar el retiro de sistemas inform\u00e1ticos, asegurando que el proceso sea controlado y documentado.\n   - Es importante abordar los cambios en roles de soporte y proporcionar capacitaci\u00f3n asociada.\n\n2. **Cronograma de Retiro**:\n   - El cronograma debe incluir actividades individuales de retiro, responsabilidades, fechas de vencimiento, tareas cr\u00edticas y hitos de verificaci\u00f3n.\n\n3. **Ejecuci\u00f3n del Retiro**:\n   - La ejecuci\u00f3n del retiro debe planificarse cuidadosamente, considerando la continuidad del negocio y estableciendo un plan de respaldo.\n   - Se deben incluir instrucciones detalladas para la reconfiguraci\u00f3n y reinstalaci\u00f3n del sistema si es necesario.\n\n4. **Documentaci\u00f3n del Sistema y Software**:\n   - Se debe conservar la documentaci\u00f3n del sistema y del software, incluyendo el c\u00f3digo fuente, documentaci\u00f3n de validaci\u00f3n, historia de cambios y procedimientos operativos est\u00e1ndar.\n   - La documentaci\u00f3n debe tener un propietario responsable y un lugar seguro, y las decisiones sobre su retenci\u00f3n deben basarse en su posible uso futuro y en la evaluaci\u00f3n de riesgos.\n\n5. **Informe de Retiro del Sistema**:\n   - Tras la ejecuci\u00f3n del plan de retiro, se debe generar un informe resumen que describa la ejecuci\u00f3n y los resultados obtenidos, incluyendo cualquier actividad de prueba o verificaci\u00f3n realizada.\n\n### Entidades Clave\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil.\n- **Sistema Inform\u00e1tico**: Cualquier sistema que se est\u00e9 retirando o migrando.\n- **Documentaci\u00f3n**: Incluye manuales, procedimientos, c\u00f3digo fuente y registros de validaci\u00f3n.\n- **Roles de Soporte**: Incluye soporte t\u00e9cnico, superusuarios y otros roles relacionados con el sistema.\n- **Plan de Continuidad del Negocio**: Estrategias para asegurar la operaci\u00f3n continua durante el proceso de retiro. \n\nEste resumen destaca la importancia de la planificaci\u00f3n, documentaci\u00f3n y gesti\u00f3n adecuada en el proceso de retiro de sistemas inform\u00e1ticos, conforme a las directrices de ANVISA.", "excerpt_keywords": "Keywords: validation, spreadsheets, GMP, documentation, data integrity"}}, "d9d483d0-e975-4695-987b-e37c12345373": {"node_ids": ["d7e82b14-c1d4-4801-b968-ef7a0fbd844e"], "metadata": {"page_label": "102", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# Guide for Computer Systems Validation\n\n## Page 95\n\n- Use of the spreadsheet's internal security options, such as cells or tabs protected by passwords;\n- Storing the spreadsheet in a secure directory;\n- Spreadsheet management in an electronic document management system.\n\n### 14.2.3 Spreadsheets Used as Database\n\nThese are spreadsheets used to manage or store GMP data electronically. The data can be updated frequently, which can cause difficulties because spreadsheets don't have the controls intrinsic features of relational databases, necessary to ensure data integrity.\n\nSpreadsheets generally have limited or no capability to control data editing or to support audit trails when needed. When creating a spreadsheet, controls must be developed to overcome these deficiencies.\n\nUsers should therefore be fully aware of the limitations and vulnerabilities of spreadsheets when proposed as an alternative to a database application.\n\nDue to the limitations of spreadsheets, relational databases should be used instead of electronic spreadsheets, since these are limited in terms of data storage and management and the file can be corrupt when it reaches certain data values.\n\nAlthough there are commercially available products designed to provide audit trail capabilities for spreadsheets, as a general rule, the use of spreadsheets in which audit trails are needed should not be used.\n\nSpreadsheet software is generally not designed to provide audit trail functionality. Therefore, the use of a database with this intrinsic capacity is preferable.\n\n### 14.2.4 Template-Type Applications\n\nA very common use of spreadsheets is the development of template-type solutions, where data they can be subject to standard manipulation and the result saved as a single document. Applications for performing statistical analysis or filtering and manipulating data may also belong to this sub-category. The templates can be used for example for the tab and a data processing clinical study or, similarly for tabulation and data processing of control test results before the product is released.\n\nWhen developing such templates, users and developers must fully understand and document the necessary handling. This allows for clear confirmation of design intentions against package features.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "### Res\u00famenes de nivel superior del contexto\n\n1. **Limitaciones de las hojas de c\u00e1lculo**: Las hojas de c\u00e1lculo, aunque son herramientas comunes para la gesti\u00f3n de datos, presentan limitaciones significativas en t\u00e9rminos de control de edici\u00f3n, integridad de datos y capacidad de auditor\u00eda. Se recomienda el uso de bases de datos relacionales para la gesti\u00f3n de datos cr\u00edticos, especialmente en entornos de Buenas Pr\u00e1cticas de Manufactura (GMP).\n\n2. **Uso de plantillas en hojas de c\u00e1lculo**: Las hojas de c\u00e1lculo pueden ser utilizadas para desarrollar soluciones tipo plantilla que permiten la manipulaci\u00f3n est\u00e1ndar de datos. Sin embargo, es crucial que los usuarios y desarrolladores comprendan y documenten adecuadamente el manejo de estos datos para asegurar que las intenciones de dise\u00f1o se alineen con las caracter\u00edsticas del software.\n\n3. **Seguridad y gesti\u00f3n de hojas de c\u00e1lculo**: Para mitigar los riesgos asociados con el uso de hojas de c\u00e1lculo, se deben implementar medidas de seguridad, como la protecci\u00f3n de celdas con contrase\u00f1as y el almacenamiento en directorios seguros. Adem\u00e1s, la gesti\u00f3n de hojas de c\u00e1lculo debe realizarse dentro de un sistema de gesti\u00f3n de documentos electr\u00f3nicos.\n\n### Preguntas espec\u00edficas\n\n1. **\u00bfCu\u00e1les son las principales deficiencias de las hojas de c\u00e1lculo en comparaci\u00f3n con las bases de datos relacionales en el contexto de la gesti\u00f3n de datos GMP?**\n   - Respuesta: Las hojas de c\u00e1lculo tienen limitaciones en el control de edici\u00f3n, carecen de capacidades intr\u00ednsecas para mantener la integridad de los datos y no soportan auditor\u00edas adecuadas, lo que las hace menos adecuadas para la gesti\u00f3n de datos GMP en comparaci\u00f3n con las bases de datos relacionales.\n\n2. **\u00bfQu\u00e9 medidas de seguridad se recomiendan para el manejo de hojas de c\u00e1lculo utilizadas en la gesti\u00f3n de datos cr\u00edticos?**\n   - Respuesta: Se recomienda utilizar opciones de seguridad internas de las hojas de c\u00e1lculo, como proteger celdas o pesta\u00f1as con contrase\u00f1as, almacenar las hojas en directorios seguros y gestionar las hojas de c\u00e1lculo dentro de un sistema de gesti\u00f3n de documentos electr\u00f3nicos.\n\n3. **\u00bfQu\u00e9 consideraciones deben tener en cuenta los desarrolladores al crear plantillas en hojas de c\u00e1lculo para an\u00e1lisis estad\u00edstico?**\n   - Respuesta: Los desarrolladores deben comprender y documentar el manejo necesario de los datos, asegurando que las intenciones de dise\u00f1o se confirmen con las caracter\u00edsticas del paquete de software utilizado, para evitar errores en el an\u00e1lisis y la manipulaci\u00f3n de datos.", "prev_section_summary": "### Resumen de Temas Clave y Entidades de la Secci\u00f3n\n\n1. **Validaci\u00f3n de Hojas de C\u00e1lculo**: La gu\u00eda de ANVISA se centra en la validaci\u00f3n de hojas de c\u00e1lculo dentro del contexto de las Buenas Pr\u00e1cticas de Fabricaci\u00f3n (BPF), destacando su uso com\u00fan en la manipulaci\u00f3n de datos regulados.\n\n2. **Tipos de Hojas de C\u00e1lculo**:\n   - **Hojas de C\u00e1lculo Desechables**: Utilizadas como calculadoras para realizar c\u00e1lculos sin mantener una copia electr\u00f3nica. Su uso debe ser documentado, registrando valores y resultados, y se recomienda imprimir las f\u00f3rmulas utilizadas como parte del registro GMP.\n   - **Hojas de C\u00e1lculo Retenidas como Documentos**: Utilizadas para registrar y manipular datos. Se deben gestionar como documentos, lo que implica un desaf\u00edo en asegurar que las copias guardadas sean id\u00e9nticas a las originales.\n\n3. **Verificaci\u00f3n de C\u00e1lculos**: La verificaci\u00f3n de las hojas de c\u00e1lculo implica demostrar que se est\u00e1n utilizando las f\u00f3rmulas correctas, en lugar de verificar la precisi\u00f3n de los algoritmos de las funciones nativas. Esto puede hacerse imprimiendo las f\u00f3rmulas o mediante revisi\u00f3n por terceros.\n\n4. **Subdocumentaci\u00f3n en Entornos GMP**: Las hojas de c\u00e1lculo son consideradas subdocumentadas en entornos GMP, lo que puede llevar a errores en el procesamiento de datos cr\u00edticos. La gu\u00eda enfatiza la necesidad de un enfoque m\u00e1s riguroso en la documentaci\u00f3n y validaci\u00f3n de estas herramientas.\n\n5. **Importancia de la Documentaci\u00f3n**: La correcta documentaci\u00f3n y verificaci\u00f3n de las hojas de c\u00e1lculo son esenciales para garantizar la integridad y trazabilidad de los datos regulados, cumpliendo as\u00ed con las normativas de calidad.\n\n### Entidades Clave\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil.\n- **BPF (Buenas Pr\u00e1cticas de Fabricaci\u00f3n)**: Normativas que aseguran la calidad en la producci\u00f3n de productos regulados.\n- **Hojas de C\u00e1lculo**: Herramientas utilizadas para c\u00e1lculos y manipulaci\u00f3n de datos en un entorno regulado.", "excerpt_keywords": "Keywords: validation, spreadsheets, data integrity, GMP, audit trails"}}, "87633561-307a-470c-bc73-9b597f68d364": {"node_ids": ["180e9299-9c95-4cc3-ae3b-de9580b4b96b"], "metadata": {"page_label": "103", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "- standards to be established and confirmed.\n\nThe following items should be considered:\n\n- Calculations should be checked for accuracy;\n- The template will run on a single workstation or available for download from a single lease? If not, how can you be sure that all users will use the correct version? The control version must be established, supported by an effective change management process;\n\n----\n\n- How access to the application and data fields by users and the developer will be controlled? Preferably all cells, except those used for data entry, they must be blocked and inaccessible to the user;\n- How will the features be configured? There is a requirement for a custom script when application wizards are used? A \u201cmacro\u201d is customized software. Even when created by key capture, there is a program written in a language such as Visual Basic for Applications\u00ae (VBA) behind each macro;\n- Will there be more than one module? Integration tests are appropriate in these cases. For spreadsheets this may involve direct cell links to other spreadsheets. These links can be affected by changes and should be addressed as part of change control.\n- Will data entry be via keyboard only? External data feeds require configuration and a spreadsheet may not be sophisticated enough to handle unusual entries (eg, a string that is too long can be truncated and only part of that string is imported);\n- Will the output be saved to a file or just printed? Electronic record controls can be necessary if the document is held electronically.\n\n## 14.2.5 Desktop Database\n\nDesktop Databases are those designed and installed on a workstation or computer for routine use. These simple solutions are designed for the storage of small amounts of data (eg MS Access).\n\nThe proprietary and open source desktop database offers solutions for managing large volumes of data when compared to spreadsheets, but they still are generally significantly less secure than more database management systems sophisticated systems designed to run in environments based on dedicated servers and managed by IT sector through DBA (eg Oracle\u00ae, MS SQL Server, etc.).\n\nThe use of these less secure banks can present significant risks to GMP-relevant records. External controls are required to protect these records.\n\n## 14.3 RISK-BASED APPROACH", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "### Resumen del Contexto\n\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos destaca la importancia de establecer est\u00e1ndares y controles en el uso de plantillas y bases de datos de escritorio. Se enfatiza la necesidad de verificar la precisi\u00f3n de los c\u00e1lculos, gestionar el control de versiones, y asegurar que el acceso a las aplicaciones y campos de datos est\u00e9 restringido adecuadamente. Adem\u00e1s, se menciona la importancia de realizar pruebas de integraci\u00f3n cuando hay m\u00faltiples m\u00f3dulos y se discuten los riesgos asociados con el uso de bases de datos menos seguras en comparaci\u00f3n con sistemas de gesti\u00f3n de bases de datos m\u00e1s sofisticados.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfQu\u00e9 medidas espec\u00edficas se pueden implementar para garantizar que todos los usuarios utilicen la versi\u00f3n correcta de una plantilla cuando se distribuye en m\u00faltiples estaciones de trabajo?**\n   - Esta pregunta busca respuestas sobre los procedimientos de control de versiones y gesti\u00f3n de cambios que no se detallan expl\u00edcitamente en el texto.\n\n2. **\u00bfCu\u00e1les son los riesgos espec\u00edficos asociados con el uso de bases de datos de escritorio en comparaci\u00f3n con sistemas de gesti\u00f3n de bases de datos m\u00e1s robustos, y qu\u00e9 controles externos se pueden aplicar para mitigar estos riesgos?**\n   - Esta pregunta se centra en los riesgos mencionados y busca ejemplos concretos de controles externos que podr\u00edan implementarse.\n\n3. **\u00bfQu\u00e9 tipo de pruebas de integraci\u00f3n son recomendadas para hojas de c\u00e1lculo que contienen enlaces directos a otras hojas, y c\u00f3mo se deben documentar estos procesos?**\n   - Esta pregunta busca informaci\u00f3n sobre las mejores pr\u00e1cticas para realizar pruebas de integraci\u00f3n y la documentaci\u00f3n necesaria, que no se aborda en el contexto proporcionado. \n\nEstas preguntas est\u00e1n dise\u00f1adas para extraer informaci\u00f3n m\u00e1s detallada y espec\u00edfica que podr\u00eda no estar disponible en otras fuentes, bas\u00e1ndose en el contenido del documento.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Limitaciones de las Hojas de C\u00e1lculo**:\n   - Las hojas de c\u00e1lculo presentan deficiencias significativas en comparaci\u00f3n con las bases de datos relacionales, especialmente en el contexto de la gesti\u00f3n de datos de Buenas Pr\u00e1cticas de Manufactura (GMP). Estas limitaciones incluyen:\n     - Falta de controles intr\u00ednsecos para mantener la integridad de los datos.\n     - Limitaciones en el control de edici\u00f3n.\n     - Ausencia de capacidades adecuadas para auditor\u00edas.\n\n2. **Uso de Bases de Datos Relacionales**:\n   - Se recomienda el uso de bases de datos relacionales en lugar de hojas de c\u00e1lculo para la gesti\u00f3n de datos cr\u00edticos, ya que ofrecen mejor almacenamiento, gesti\u00f3n y protecci\u00f3n contra la corrupci\u00f3n de archivos.\n\n3. **Medidas de Seguridad para Hojas de C\u00e1lculo**:\n   - Para mitigar riesgos, se sugieren varias medidas de seguridad:\n     - Uso de opciones de seguridad internas, como la protecci\u00f3n de celdas o pesta\u00f1as con contrase\u00f1as.\n     - Almacenamiento de hojas de c\u00e1lculo en directorios seguros.\n     - Gesti\u00f3n de hojas de c\u00e1lculo dentro de un sistema de gesti\u00f3n de documentos electr\u00f3nicos.\n\n4. **Aplicaciones Tipo Plantilla**:\n   - Las hojas de c\u00e1lculo son com\u00fanmente utilizadas para desarrollar soluciones tipo plantilla que permiten la manipulaci\u00f3n est\u00e1ndar de datos. Ejemplos incluyen:\n     - An\u00e1lisis estad\u00edstico.\n     - Procesamiento de datos en estudios cl\u00ednicos.\n     - Tabulaci\u00f3n de resultados de pruebas de control antes de la liberaci\u00f3n de productos.\n   - Es crucial que los desarrolladores comprendan y documenten adecuadamente el manejo de datos en estas plantillas para asegurar la alineaci\u00f3n entre las intenciones de dise\u00f1o y las caracter\u00edsticas del software.\n\n### Entidades Clave\n- **Hojas de C\u00e1lculo**: Herramientas utilizadas para la gesti\u00f3n de datos, pero con limitaciones significativas.\n- **Bases de Datos Relacionales**: Alternativa recomendada para la gesti\u00f3n de datos cr\u00edticos.\n- **Buenas Pr\u00e1cticas de Manufactura (GMP)**: Normativas que regulan la gesti\u00f3n de datos en entornos de producci\u00f3n.\n- **Seguridad de Datos**: Medidas implementadas para proteger la integridad y confidencialidad de los datos en hojas de c\u00e1lculo.\n- **Plantillas**: Soluciones desarrolladas en hojas de c\u00e1lculo para la manipulaci\u00f3n y an\u00e1lisis de datos.", "excerpt_keywords": "Keywords: validation, computer systems, data integrity, risk management, GMP"}}, "31a771be-8937-48cd-9ff9-c9b623bf1b4b": {"node_ids": ["6365050a-ad92-49d1-bd0d-2f3c15be2d74"], "metadata": {"page_label": "104", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "Spreadsheets can vary significantly in risk and complexity. The following points should be considered for this type of end user application:\n\n- Risk assessment and appropriate risk control measures to manage the identified risks;\n- The adoption of the most appropriate strategy to establish the stages of Specification and Verification of spreadsheet, so that it is shown to work as intended. This strategy should be based on:\n- \u2713 System impact on patient safety, product quality and data integrity (risk assessment);\n- \u2713 System complexity and innovation (architecture and categorization of the components of the system).\n\n----\n\n- Proper security to mitigate the risk of unauthorized changes to data and data spreadsheet;\n- Change management application management.\n\nThe regulated company's policies and procedures should define its specific approach to obtaining and maintenance of attendance and adaptation to the intended use of the spreadsheet.\n\n## 14.4 USE OF GAMP CATEGORIES\n\nThe product on which the application (Spreadsheets, templates, etc.) is built must belong to Category 1. The categories for spreadsheets and other end user applications range from Category 3 to 5.\n\nThe definition of the worksheet category depends on its complexity and innovation. It should be noted that a spreadsheet that merely uses its tabular editing power and does not perform calculations should be considered a document.\n\nA spreadsheet that simply uses its original functions (averages, standard deviations) to perform calculations, with no configuration, just acting as a calculator, it belongs to Category 3.\n\nWhen the arithmetic functions of the spreadsheet are used, the calculations must be fully explained. This includes verifying that the formula used has been used properly and that the results obtained are correct. Such verification can be documented through the review and approval of the spreadsheet by a second person. No additional verification is necessary, as there is no need to challenge the accuracy of calculations.\n\nA template-type spreadsheet in which the user inserts data that is automatically sent to another cell where specific calculations are performed, belongs to Category 4, since the template is configured by before use.\n\nA spreadsheet that uses custom macros or other more sophisticated operations (e.g., editing code source) belongs to Category 5.\n\nFor situations other than those mentioned above, consult the bibliographic references in this guide.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos destaca la importancia de evaluar los riesgos y establecer medidas de control adecuadas al utilizar aplicaciones de usuario final como hojas de c\u00e1lculo. Se enfatiza la necesidad de una estrategia de especificaci\u00f3n y verificaci\u00f3n que considere el impacto del sistema en la seguridad del paciente, la calidad del producto y la integridad de los datos. Adem\u00e1s, se presentan las categor\u00edas GAMP para clasificar las hojas de c\u00e1lculo seg\u00fan su complejidad e innovaci\u00f3n, desde documentos simples hasta aplicaciones que utilizan macros personalizadas.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfQu\u00e9 criterios se deben considerar para clasificar una hoja de c\u00e1lculo en una categor\u00eda GAMP espec\u00edfica?**\n   - La clasificaci\u00f3n de una hoja de c\u00e1lculo en una categor\u00eda GAMP depende de su complejidad e innovaci\u00f3n. Por ejemplo, una hoja de c\u00e1lculo que solo utiliza funciones b\u00e1sicas sin configuraci\u00f3n se considera un documento, mientras que una que usa funciones aritm\u00e9ticas simples pertenece a la Categor\u00eda 3. Las hojas de c\u00e1lculo que requieren plantillas configuradas se clasifican en la Categor\u00eda 4, y aquellas que utilizan macros personalizadas o operaciones sofisticadas pertenecen a la Categor\u00eda 5.\n\n2. **\u00bfQu\u00e9 medidas de seguridad se deben implementar para mitigar el riesgo de cambios no autorizados en las hojas de c\u00e1lculo?**\n   - Se deben establecer medidas de seguridad adecuadas para proteger las hojas de c\u00e1lculo contra cambios no autorizados en los datos. Esto incluye la implementaci\u00f3n de controles de acceso, auditor\u00edas de cambios y procedimientos de gesti\u00f3n de cambios que aseguren la integridad de los datos y la funcionalidad de la hoja de c\u00e1lculo.\n\n3. **\u00bfC\u00f3mo se debe documentar la verificaci\u00f3n de c\u00e1lculos en una hoja de c\u00e1lculo seg\u00fan el documento de ANVISA?**\n   - La verificaci\u00f3n de c\u00e1lculos en una hoja de c\u00e1lculo debe incluir una explicaci\u00f3n completa de las f\u00f3rmulas utilizadas y la confirmaci\u00f3n de que se han aplicado correctamente. Esta verificaci\u00f3n puede ser documentada a trav\u00e9s de la revisi\u00f3n y aprobaci\u00f3n de la hoja de c\u00e1lculo por una segunda persona, lo que asegura que no se requiere una verificaci\u00f3n adicional, dado que no hay necesidad de cuestionar la precisi\u00f3n de los c\u00e1lculos.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Establecimiento de Est\u00e1ndares y Controles**:\n   - Importancia de definir y confirmar est\u00e1ndares en el uso de plantillas y bases de datos.\n   - Necesidad de verificar la precisi\u00f3n de los c\u00e1lculos.\n\n2. **Control de Versiones**:\n   - Pregunta sobre c\u00f3mo asegurar que todos los usuarios utilicen la versi\u00f3n correcta de una plantilla, especialmente cuando se distribuye en m\u00faltiples estaciones de trabajo.\n   - Se requiere un proceso de gesti\u00f3n de cambios efectivo.\n\n3. **Control de Acceso**:\n   - Necesidad de restringir el acceso a aplicaciones y campos de datos, bloqueando celdas que no son para entrada de datos.\n\n4. **Configuraci\u00f3n de Funciones**:\n   - Consideraciones sobre la necesidad de scripts personalizados y el uso de macros, que son programas escritos en lenguajes como VBA.\n\n5. **Pruebas de Integraci\u00f3n**:\n   - Importancia de realizar pruebas de integraci\u00f3n cuando hay m\u00faltiples m\u00f3dulos o enlaces directos entre hojas de c\u00e1lculo.\n   - Necesidad de abordar los enlaces en el control de cambios.\n\n6. **Entrada y Salida de Datos**:\n   - Consideraciones sobre la entrada de datos solo a trav\u00e9s del teclado y la gesti\u00f3n de entradas inusuales.\n   - Pregunta sobre c\u00f3mo se guardar\u00e1 la salida (archivo o impresi\u00f3n) y la necesidad de controles de registros electr\u00f3nicos.\n\n7. **Bases de Datos de Escritorio**:\n   - Definici\u00f3n y caracter\u00edsticas de las bases de datos de escritorio, como MS Access.\n   - Comparaci\u00f3n de seguridad entre bases de datos de escritorio y sistemas de gesti\u00f3n de bases de datos m\u00e1s sofisticados (ej. Oracle, MS SQL Server).\n   - Riesgos asociados con el uso de bases de datos menos seguras y la necesidad de controles externos para proteger registros relevantes para GMP.\n\n8. **Enfoque Basado en Riesgos**:\n   - Se menciona un enfoque basado en riesgos, aunque no se detalla en el contenido proporcionado.\n\n### Entidades Clave\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil.\n- **VBA**: Visual Basic for Applications, lenguaje de programaci\u00f3n utilizado para crear macros.\n- **MS Access**: Ejemplo de base de datos de escritorio.\n- **Oracle, MS SQL Server**: Ejemplos de sistemas de gesti\u00f3n de bases de datos m\u00e1s sofisticados.\n- **GMP**: Buenas Pr\u00e1cticas de Manufactura, relevantes para la gesti\u00f3n de registros. \n\nEste resumen destaca los puntos cr\u00edticos y las entidades relevantes en el contexto de la validaci\u00f3n de sistemas inform\u00e1ticos seg\u00fan la gu\u00eda de ANVISA.", "excerpt_keywords": "Keywords: validation, spreadsheets, risk assessment, GAMP categories, data integrity"}}, "de4404b5-5b99-4153-8af1-26528f12228d": {"node_ids": ["470efe3c-bf1f-4423-84b8-9576e96f5a64"], "metadata": {"page_label": "105", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 14.5 RISK-BASED CONTROLS\n\nGMP risks must be assessed. The following aspects must be considered:\n\n- The integrity of the data related to the control of the data files, since most of the developed spreadsheets process data;\n- The complexity of the spreadsheet, based on the assumption that undetected systematic errors are more likely to occur in software not developed under a strict development method and that more complex spreadsheets have more opportunity for errors to occur;\n- The potential impact on patient safety, product quality and data integrity.\n\nBased on these assessments, controls should be established with a focus on:\n\n- Degree of verification;\n- Security control (both for the spreadsheet code and for the BPx records that are in the spreadsheet);\n\nPage 98\n\n- Change control;\n- Control of the infrastructure on which the spreadsheet is built.\n\n## 14.5.1 Degree of Verification\n\nThe extent and rigor of the verification depends on the risk, complexity and innovation of the spreadsheet.\n\nComplex, high-risk spreadsheets require more rigorous testing. The number of logical branches in the spreadsheet is a good indicator of its complexity; if there are many logical functions (IF, AND, OR, etc.) or Lookup tables, the complexity is greater. Although they are native functions, they introduce more paths potentials within the spreadsheet and therefore more ramifications that require a more testing strategy sophisticated.\n\nMacros also increase the complexity of spreadsheets, because they are effectively secondary applications embedded. Even when created using key capture, there is a program with a language for behind the macro, although macros that simply automate a series of actions are less worrying than those that contain logical ramifications. Macros must be challenged through functionality tests. Macros that include logical paths should be subject to a more stringent verification, with due attention to the multiple logic paths.\n\n## 14.5.2 Security Control\n\nSecurity considerations for spreadsheets are similar to those for applications on the network or server, such as: access to the spreadsheet, access to data through the spreadsheet and access to data at the operating system or spreadsheet code. Security within the operating environment must be appropriate to the type of information stored or processed.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos establece la importancia de evaluar los riesgos asociados con las hojas de c\u00e1lculo en el contexto de las Buenas Pr\u00e1cticas de Manufactura (GMP). Se enfatiza la necesidad de considerar la integridad de los datos, la complejidad de las hojas de c\u00e1lculo y su impacto potencial en la seguridad del paciente y la calidad del producto. Se sugieren controles basados en el grado de verificaci\u00f3n, la seguridad, el control de cambios y la infraestructura. Adem\u00e1s, se detalla que la verificaci\u00f3n debe ser m\u00e1s rigurosa para hojas de c\u00e1lculo complejas y de alto riesgo, y se discuten las implicaciones de las macros en la complejidad y seguridad de las hojas de c\u00e1lculo.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfCu\u00e1les son los factores que determinan el grado de verificaci\u00f3n necesario para una hoja de c\u00e1lculo en el contexto de GMP?**\n   - La verificaci\u00f3n depende del riesgo, la complejidad y la innovaci\u00f3n de la hoja de c\u00e1lculo. Hojas de c\u00e1lculo complejas y de alto riesgo requieren pruebas m\u00e1s rigurosas, y la cantidad de ramas l\u00f3gicas es un buen indicador de su complejidad.\n\n2. **\u00bfQu\u00e9 aspectos de seguridad deben considerarse al manejar hojas de c\u00e1lculo en un entorno de GMP?**\n   - Las consideraciones de seguridad incluyen el acceso a la hoja de c\u00e1lculo, el acceso a los datos a trav\u00e9s de la hoja de c\u00e1lculo y el acceso a los datos en el sistema operativo o el c\u00f3digo de la hoja de c\u00e1lculo. La seguridad debe ser adecuada al tipo de informaci\u00f3n almacenada o procesada.\n\n3. **\u00bfC\u00f3mo afectan las macros a la complejidad y la verificaci\u00f3n de las hojas de c\u00e1lculo?**\n   - Las macros aumentan la complejidad de las hojas de c\u00e1lculo, ya que son aplicaciones secundarias integradas. Las macros que contienen ramificaciones l\u00f3gicas deben someterse a pruebas de funcionalidad m\u00e1s estrictas debido a las m\u00faltiples rutas l\u00f3gicas que pueden introducir.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Evaluaci\u00f3n de Riesgos**: Se enfatiza la importancia de realizar una evaluaci\u00f3n de riesgos para identificar y gestionar los riesgos asociados con el uso de hojas de c\u00e1lculo como aplicaciones de usuario final.\n\n2. **Medidas de Control**: Se deben implementar medidas de control adecuadas para mitigar los riesgos identificados, incluyendo la seguridad para prevenir cambios no autorizados en los datos.\n\n3. **Estrategia de Especificaci\u00f3n y Verificaci\u00f3n**: Es crucial adoptar una estrategia que establezca las etapas de especificaci\u00f3n y verificaci\u00f3n de las hojas de c\u00e1lculo, considerando su impacto en la seguridad del paciente, la calidad del producto y la integridad de los datos.\n\n4. **Categor\u00edas GAMP**: Las hojas de c\u00e1lculo se clasifican en categor\u00edas GAMP (Good Automated Manufacturing Practice) que van de la Categor\u00eda 3 a la 5, dependiendo de su complejidad e innovaci\u00f3n:\n   - **Categor\u00eda 1**: Producto base de la aplicaci\u00f3n.\n   - **Categor\u00eda 3**: Hojas de c\u00e1lculo que utilizan funciones aritm\u00e9ticas simples sin configuraci\u00f3n.\n   - **Categor\u00eda 4**: Hojas de c\u00e1lculo tipo plantilla que requieren configuraci\u00f3n previa.\n   - **Categor\u00eda 5**: Hojas de c\u00e1lculo que utilizan macros personalizadas o funciones sofisticadas.\n\n5. **Documentaci\u00f3n de Verificaci\u00f3n**: La verificaci\u00f3n de c\u00e1lculos en las hojas de c\u00e1lculo debe ser documentada a trav\u00e9s de la revisi\u00f3n y aprobaci\u00f3n por una segunda persona, asegurando que las f\u00f3rmulas se apliquen correctamente y que los resultados sean precisos.\n\n6. **Pol\u00edticas y Procedimientos**: Las pol\u00edticas y procedimientos de la empresa regulada deben definir el enfoque espec\u00edfico para la obtenci\u00f3n y mantenimiento de las hojas de c\u00e1lculo, asegurando su adaptaci\u00f3n al uso previsto.\n\n### Entidades Clave\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil.\n- **GAMP**: Buenas Pr\u00e1cticas de Fabricaci\u00f3n Automatizadas.\n- **Hojas de C\u00e1lculo**: Aplicaciones de usuario final que requieren validaci\u00f3n y categorizaci\u00f3n seg\u00fan su complejidad.\n- **Seguridad de Datos**: Medidas para proteger la integridad de los datos en hojas de c\u00e1lculo.\n- **Gesti\u00f3n de Cambios**: Proceso para manejar modificaciones en las hojas de c\u00e1lculo y asegurar su correcto funcionamiento. \n\nEste resumen destaca los aspectos fundamentales de la validaci\u00f3n de sistemas inform\u00e1ticos en el contexto de las hojas de c\u00e1lculo, as\u00ed como las categor\u00edas GAMP que ayudan a clasificar su complejidad y riesgo.", "excerpt_keywords": "Keywords: risk assessment, spreadsheet validation, GMP compliance, data integrity, security controls"}}, "bcfa7345-4346-4ef6-b5d7-f8b12d931c59": {"node_ids": ["7104b48c-9f7d-4219-ad79-f06bd413d1d2"], "metadata": {"page_label": "106", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "For many spreadsheets, a combination of infrastructure controls (eg, restricted access to directories) and controls available on the spreadsheet (eg password protection for spreadsheet cells) can provide some security against unintended changes. However, these controls can be inefficient to prevent the spreadsheet creator makes changes outside of the change control process, particularly if the spreadsheet to be located on an individual workstation. In these situations, the ideal is to place the spreadsheet in a network environment in which the rights of all users, including the author, are limited, also adding a regular scheduled backup process.\n\nOften, data is saved within the spreadsheet itself. Ensuring the integrity of this data requires the use of very strict controls, including any necessary controls on electronic records. In cases where the spreadsheet is subject to some type of editing, proper control may involve the use of a Electronic Document Management (EDMS). Alternatively, controlled copies can be kept in a format that cannot be altered or printed.\n\nGMP-relevant data cannot be saved to a local disk drive that is not secure and is not submitted to performing backups (backup) regularly.\n\nIf the security level of the spreadsheet is not adequate enough for the data managed in it, the company should seek an application that runs in a more robust operating environment.\n\n----\n\n## 14.5.3 Change Control\n\nSpreadsheets that process data relevant to GMP should be subject to change control. The management versioning is difficult in the case of spreadsheets. In some cases, spreadsheet management within an EDMS can be an appropriate solution, since this system maintains an audit trail of the spreadsheet versions.\n\nAnother solution is the use of library tools that are frequently used by developers to manage code. These tools can be used to manage any type files, can be effective, relatively easy to implement and are less expensive than a system like EDMS.\n\nAs with any change control process, changes to the spreadsheet must have a record of change that includes a description of the change and an impact assessment. Where appropriate, tests associated with this function should be documented.\n\n## 15.5.4 Infrastructure Control\n\nEnvironments in which the spreadsheet is installed belong to Software Category 1. These tools provide application environment for spreadsheets, databases, scripts or scripts that are developed by users.\n\nThe installation of the environment must be verified and the environment must be managed for changes and for your configuration.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "### Resumen del Contexto\n\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos destaca la importancia de implementar controles de infraestructura y de cambio para las hojas de c\u00e1lculo que manejan datos relevantes para las Buenas Pr\u00e1cticas de Manufactura (GMP). Se enfatiza la necesidad de restringir el acceso a las hojas de c\u00e1lculo, mantener un entorno de red seguro, y realizar copias de seguridad regulares. Adem\u00e1s, se sugiere el uso de sistemas de gesti\u00f3n de documentos electr\u00f3nicos (EDMS) para mantener un registro de cambios y versiones, as\u00ed como la utilizaci\u00f3n de herramientas de gesti\u00f3n de c\u00f3digo para facilitar el control de versiones. La integridad de los datos y la seguridad son aspectos cr\u00edticos que deben ser abordados para cumplir con las regulaciones.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfCu\u00e1les son las medidas espec\u00edficas que se deben implementar para garantizar la integridad de los datos en hojas de c\u00e1lculo que contienen informaci\u00f3n GMP?**\n   - Respuesta: Se deben utilizar controles estrictos, que incluyan restricciones de acceso, protecci\u00f3n por contrase\u00f1a de celdas, y la posibilidad de utilizar un sistema de gesti\u00f3n de documentos electr\u00f3nicos (EDMS) para mantener un registro de cambios y versiones. Adem\u00e1s, es crucial que los datos no se guarden en unidades de disco locales no seguras y que se realicen copias de seguridad regularmente.\n\n2. **\u00bfQu\u00e9 alternativas se sugieren para la gesti\u00f3n de versiones de hojas de c\u00e1lculo si no se utiliza un sistema EDMS?**\n   - Respuesta: Se pueden utilizar herramientas de biblioteca que son com\u00fanmente empleadas por desarrolladores para gestionar c\u00f3digo. Estas herramientas son efectivas, relativamente f\u00e1ciles de implementar y menos costosas que un sistema EDMS, permitiendo as\u00ed un control adecuado de las versiones de las hojas de c\u00e1lculo.\n\n3. **\u00bfQu\u00e9 criterios se deben considerar al decidir si una hoja de c\u00e1lculo tiene un nivel de seguridad adecuado para los datos que maneja?**\n   - Respuesta: Se debe evaluar si el nivel de seguridad de la hoja de c\u00e1lculo es suficiente para proteger la informaci\u00f3n sensible. Si no es adecuado, la empresa debe considerar la adopci\u00f3n de una aplicaci\u00f3n que funcione en un entorno operativo m\u00e1s robusto, que ofrezca mejores controles de seguridad y gesti\u00f3n de datos.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Evaluaci\u00f3n de Riesgos en GMP**:\n   - Importancia de evaluar los riesgos asociados con las hojas de c\u00e1lculo en el contexto de las Buenas Pr\u00e1cticas de Manufactura (GMP).\n   - Factores a considerar: integridad de los datos, complejidad de la hoja de c\u00e1lculo y su impacto en la seguridad del paciente y la calidad del producto.\n\n2. **Controles Basados en Riesgos**:\n   - Establecimiento de controles enfocados en:\n     - Grado de verificaci\u00f3n.\n     - Control de seguridad (c\u00f3digo de la hoja de c\u00e1lculo y registros BPx).\n     - Control de cambios.\n     - Control de la infraestructura.\n\n3. **Grado de Verificaci\u00f3n**:\n   - La verificaci\u00f3n debe ser proporcional al riesgo, complejidad e innovaci\u00f3n de la hoja de c\u00e1lculo.\n   - Hojas de c\u00e1lculo complejas y de alto riesgo requieren pruebas m\u00e1s rigurosas.\n   - Indicadores de complejidad: n\u00famero de ramas l\u00f3gicas y uso de funciones l\u00f3gicas (IF, AND, OR).\n\n4. **Complejidad de Macros**:\n   - Las macros aumentan la complejidad de las hojas de c\u00e1lculo.\n   - Macros con ramificaciones l\u00f3gicas requieren pruebas de funcionalidad m\u00e1s estrictas.\n\n5. **Control de Seguridad**:\n   - Consideraciones de seguridad similares a las de aplicaciones en red o servidor.\n   - Aspectos a considerar: acceso a la hoja de c\u00e1lculo, acceso a datos a trav\u00e9s de la hoja y acceso a datos en el sistema operativo o c\u00f3digo de la hoja de c\u00e1lculo.\n   - La seguridad debe ser adecuada al tipo de informaci\u00f3n almacenada o procesada.\n\n### Entidades Clave\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil.\n- **GMP**: Buenas Pr\u00e1cticas de Manufactura.\n- **Hojas de C\u00e1lculo**: Herramientas utilizadas para procesar datos que requieren validaci\u00f3n y control de riesgos.\n- **Macros**: Funciones automatizadas que pueden aumentar la complejidad y riesgo de errores en las hojas de c\u00e1lculo.", "excerpt_keywords": "Keywords: ANVISA, GMP, spreadsheets, change control, data integrity"}}, "b592a522-ade0-4abe-ba9a-1103ee3b45f1": {"node_ids": ["7900104b-543a-4836-a9b0-e35df388e2e4"], "metadata": {"page_label": "107", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 14.6 APPROACHES FOR VALIDATION\n\nBelow are 05 (five) different applications for the end user, including the spreadsheet and a summary of potential approaches based on considerations about the impact on GMP and the complexity of application. They are illustrative examples and are not definitive.\n\n## 14.6.1 Type A - Simple Spreadsheets for Calculations\n\n**Assessment:** high impact and low complexity\n\n**Recommended approach:**\n\n- Preparation of the ERU (URS);\n- Documented verification, carried out by a third person, that the calculations are correct;\n- Security to ensure that it is protected from unauthorized change;\n- Security to ensure that users can access only approved versions;\n- Secure storage of the electronic document.\n\n## 14.6.2 Type B - Training Record Worksheet\n\n**Evaluation:** low impact and low complexity.\n\n**Recommended approach:**\n\n- No specific functionality requires specification and verification;\n\n**Standard controls for electronic documents containing evidence to meet GMP.**\n\n## 14.6.3 Type C - Desktop database\n\n**Assessment:** high impact and medium complexity\n\n**Recommended approach:**\n\n- Typical Category 4 approach: validation plan; ERU / URS; Project / Functional Specification (can be combined); traceability; documented tests, with pre-defined acceptance criteria; report of validation;\n- Security to limit access to authorized persons only;\n- Change control.\n\n## 14.6.4 Type D - Worksheets for Statistical Analysis - Clinical Study\n\n**Assessment:** high impact and high complexity", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos presenta diferentes enfoques para la validaci\u00f3n de aplicaciones utilizadas en el \u00e1mbito de las Buenas Pr\u00e1cticas de Manufactura (GMP). Se identifican cinco tipos de aplicaciones, cada una con su evaluaci\u00f3n de impacto y complejidad, as\u00ed como recomendaciones espec\u00edficas para su validaci\u00f3n. Las aplicaciones var\u00edan desde hojas de c\u00e1lculo simples hasta bases de datos de escritorio y hojas de trabajo para an\u00e1lisis estad\u00edsticos en estudios cl\u00ednicos.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfQu\u00e9 medidas de seguridad se recomiendan para las hojas de c\u00e1lculo simples (Tipo A) en t\u00e9rminos de protecci\u00f3n contra cambios no autorizados?**\n   - El documento sugiere implementar seguridad para proteger las hojas de c\u00e1lculo de cambios no autorizados, asegurando que solo se puedan acceder a versiones aprobadas y que el documento electr\u00f3nico est\u00e9 almacenado de manera segura.\n\n2. **\u00bfCu\u00e1l es la diferencia en el enfoque de validaci\u00f3n entre una hoja de registro de entrenamiento (Tipo B) y una base de datos de escritorio (Tipo C)?**\n   - Para la hoja de registro de entrenamiento (Tipo B), no se requiere una funcionalidad espec\u00edfica que necesite especificaci\u00f3n y verificaci\u00f3n, dado que su impacto y complejidad son bajos. En cambio, la base de datos de escritorio (Tipo C) requiere un enfoque m\u00e1s estructurado, incluyendo un plan de validaci\u00f3n, especificaciones funcionales, trazabilidad y pruebas documentadas con criterios de aceptaci\u00f3n predefinidos.\n\n3. **\u00bfQu\u00e9 tipo de documentaci\u00f3n se sugiere para la validaci\u00f3n de aplicaciones de alta complejidad, como las hojas de trabajo para an\u00e1lisis estad\u00edsticos en estudios cl\u00ednicos (Tipo D)?**\n   - Aunque el contexto no proporciona detalles espec\u00edficos para el Tipo D, se puede inferir que, dado su alto impacto y complejidad, se requerir\u00eda una documentaci\u00f3n exhaustiva similar a la del Tipo C, que incluir\u00eda un plan de validaci\u00f3n, especificaciones, pruebas documentadas y controles de cambio, aunque se necesitar\u00edan detalles adicionales para un enfoque espec\u00edfico.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Controles de Infraestructura**:\n   - Importancia de restringir el acceso a las hojas de c\u00e1lculo mediante controles de infraestructura, como acceso restringido a directorios y protecci\u00f3n por contrase\u00f1a de celdas.\n   - Necesidad de ubicar las hojas de c\u00e1lculo en un entorno de red seguro donde los derechos de los usuarios, incluido el autor, est\u00e9n limitados.\n   - Implementaci\u00f3n de un proceso de copias de seguridad programadas para proteger los datos.\n\n2. **Integridad de los Datos**:\n   - Uso de controles estrictos para garantizar la integridad de los datos almacenados en las hojas de c\u00e1lculo.\n   - Recomendaci\u00f3n de utilizar un Sistema de Gesti\u00f3n de Documentos Electr\u00f3nicos (EDMS) para mantener un registro de cambios y versiones.\n   - Alternativa de mantener copias controladas en formatos que no puedan ser alterados o impresos.\n\n3. **Datos Relevantes para GMP**:\n   - Prohibici\u00f3n de guardar datos relevantes para las Buenas Pr\u00e1cticas de Manufactura (GMP) en unidades de disco locales no seguras y sin copias de seguridad regulares.\n   - Evaluaci\u00f3n del nivel de seguridad de las hojas de c\u00e1lculo y la necesidad de adoptar aplicaciones en entornos operativos m\u00e1s robustos si la seguridad es insuficiente.\n\n4. **Control de Cambios**:\n   - Las hojas de c\u00e1lculo que procesan datos relevantes para GMP deben estar sujetas a un control de cambios.\n   - Dificultades en la gesti\u00f3n de versiones de hojas de c\u00e1lculo y la posibilidad de utilizar un EDMS para mantener un historial de versiones.\n   - Uso de herramientas de biblioteca para gestionar archivos como una alternativa menos costosa y efectiva.\n\n5. **Control de Infraestructura**:\n   - Clasificaci\u00f3n de los entornos donde se instalan las hojas de c\u00e1lculo como Software Categor\u00eda 1.\n   - Necesidad de verificar la instalaci\u00f3n del entorno y gestionar los cambios y configuraciones adecuadamente.\n\n### Entidades Clave\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil.\n- **GMP**: Buenas Pr\u00e1cticas de Manufactura.\n- **EDMS**: Sistema de Gesti\u00f3n de Documentos Electr\u00f3nicos.\n- **Controles de Seguridad**: Medidas implementadas para proteger la integridad y confidencialidad de los datos.\n- **Herramientas de Biblioteca**: Herramientas utilizadas por desarrolladores para gestionar versiones de archivos y c\u00f3digo.", "excerpt_keywords": "Keywords: validation, GMP, spreadsheets, electronic documents, ANVISA"}}, "2f2a1d32-3cfe-44a1-a630-245ca34f11dc": {"node_ids": ["4d049284-a173-49da-9276-5987a87815c9"], "metadata": {"page_label": "108", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "Recommended approach:\n\n- Typical Category 5 approach: validation plan; ERU / URS; Project / Functional Specification (can be combined); traceability; documented tests, with pre-defined acceptance criteria; report of validation;\n- Security to limit access to authorized persons only;\n- Change control.\n\n## 14.6.5 Type E - Worksheets for Statistical Analysis - Clinical Study\n\nEvaluation: low impact and high complexity.\n\nRecommended approach:\n\n- Documented verification, carried out by a third person, that the calculations are correct;\n- Change control;\n- Security to ensure that it is protected from unauthorized change;\n- Security to ensure that users can access only approved versions.\n\n## 14.6.6 Type F - Work Area Databases - Traceability of productive materials\n\nExample of using this type of software: layout of printed labels.\n\nEvaluation: medium impact and medium complexity.\n\nRecommended approach:\n\n----\n\nGuide for Computer Systems Validation\nGuide n\u00b0 33/2020 - version 1, of 03/26/2020\n\n----\n\nPage 101\n\n- Typical Category 4 approach: validation plan; ERU / URS; Project / Functional Specification (can be combined); traceability; documented tests, with pre-defined acceptance criteria; report of validation;\n- Security to limit access to authorized persons only;\n- Change control.\n\n## 15 FINAL CONSIDERATIONS\n\nFor systems already installed, the company must decide whether the system can be validated or not.\n\nThe first step to be followed should be the preparation of the ERU / URS document starting from the guidelines described in this Guide, similar to what would be done for the purchase of a new system.\n\nThe next step is the evaluation of this non-validated system using the ERU / URS document to decide\n\n----\n\nhttps://translate.googleusercontent.com/translate_f", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior:\nEl documento \"Gu\u00eda para la Validaci\u00f3n de Sistemas Inform\u00e1ticos\" de ANVISA (Gu\u00eda n\u00b0 33/2020) establece enfoques recomendados para la validaci\u00f3n de diferentes tipos de sistemas inform\u00e1ticos en el \u00e1mbito de la salud. Se clasifican los sistemas en diferentes categor\u00edas seg\u00fan su impacto y complejidad, y se sugieren pasos espec\u00edficos para la validaci\u00f3n, incluyendo la preparaci\u00f3n de documentos como el ERU/URS, la implementaci\u00f3n de controles de cambio y medidas de seguridad para proteger la integridad de los datos.\n\n### Preguntas Espec\u00edficas:\n\n1. **\u00bfQu\u00e9 pasos espec\u00edficos se deben seguir para validar un sistema inform\u00e1tico ya instalado seg\u00fan la Gu\u00eda de ANVISA?**\n   - La gu\u00eda sugiere que el primer paso es la preparaci\u00f3n del documento ERU/URS, seguido de la evaluaci\u00f3n del sistema no validado utilizando dicho documento para decidir sobre su validaci\u00f3n.\n\n2. **\u00bfCu\u00e1les son las medidas de seguridad recomendadas para los sistemas de tipo E y F en la Gu\u00eda de ANVISA?**\n   - Para los sistemas de tipo E, se recomienda asegurar que el sistema est\u00e9 protegido contra cambios no autorizados y que los usuarios solo puedan acceder a versiones aprobadas. Para los sistemas de tipo F, se sugiere implementar medidas similares de seguridad para proteger la trazabilidad de los materiales productivos.\n\n3. **\u00bfQu\u00e9 enfoque se recomienda para la validaci\u00f3n de sistemas de tipo F, como las bases de datos de \u00e1reas de trabajo?**\n   - Se recomienda un enfoque t\u00edpico de categor\u00eda 4, que incluye un plan de validaci\u00f3n, la preparaci\u00f3n de un ERU/URS, especificaciones funcionales del proyecto, trazabilidad, pruebas documentadas con criterios de aceptaci\u00f3n predefinidos y un informe de validaci\u00f3n. Adem\u00e1s, se deben implementar controles de cambio y medidas de seguridad para limitar el acceso a personas autorizadas.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\nEl documento de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos presenta diferentes enfoques para validar aplicaciones en el contexto de las Buenas Pr\u00e1cticas de Manufactura (GMP). Se identifican cinco tipos de aplicaciones, cada una evaluada seg\u00fan su impacto y complejidad, junto con recomendaciones espec\u00edficas para su validaci\u00f3n.\n\n#### Tipos de Aplicaciones y Enfoques de Validaci\u00f3n:\n\n1. **Tipo A - Hojas de C\u00e1lculo Simples**\n   - **Impacto:** Alto\n   - **Complejidad:** Baja\n   - **Enfoque:** Preparaci\u00f3n de ERU (URS), verificaci\u00f3n documentada por terceros, seguridad contra cambios no autorizados, acceso restringido a versiones aprobadas, almacenamiento seguro.\n\n2. **Tipo B - Hoja de Registro de Entrenamiento**\n   - **Impacto:** Bajo\n   - **Complejidad:** Baja\n   - **Enfoque:** No se requiere especificaci\u00f3n y verificaci\u00f3n de funcionalidades espec\u00edficas; controles est\u00e1ndar para documentos electr\u00f3nicos.\n\n3. **Tipo C - Base de Datos de Escritorio**\n   - **Impacto:** Alto\n   - **Complejidad:** Media\n   - **Enfoque:** Plan de validaci\u00f3n, ERU/URS, especificaciones funcionales, trazabilidad, pruebas documentadas con criterios de aceptaci\u00f3n, informe de validaci\u00f3n, seguridad de acceso y control de cambios.\n\n4. **Tipo D - Hojas de Trabajo para An\u00e1lisis Estad\u00edsticos en Estudios Cl\u00ednicos**\n   - **Impacto:** Alto\n   - **Complejidad:** Alta\n   - **Enfoque:** Aunque no se detallan las recomendaciones espec\u00edficas, se infiere que se requerir\u00eda una documentaci\u00f3n exhaustiva similar a la del Tipo C.\n\n### Entidades Clave:\n- **ANVISA:** Agencia Nacional de Vigilancia Sanitaria de Brasil.\n- **GMP:** Buenas Pr\u00e1cticas de Manufactura.\n- **ERU (URS):** Requisitos de Usuario (User Requirements Specification).\n- **Tipo A, B, C, D:** Clasificaci\u00f3n de aplicaciones seg\u00fan impacto y complejidad.\n\nEste resumen destaca la importancia de la validaci\u00f3n de sistemas inform\u00e1ticos en el cumplimiento de las GMP y proporciona un marco para abordar diferentes tipos de aplicaciones seg\u00fan su riesgo y complejidad.", "excerpt_keywords": "Keywords: validation, ANVISA, computer systems, regulatory compliance, statistical analysis"}}, "4025c2d2-71a9-4a49-98f7-1ab0b1575818": {"node_ids": ["021847e4-9e19-4eee-9251-03bae2d59890"], "metadata": {"page_label": "109", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 16 GLOSSARY AND ACRONYMS\n\n**Antivirus** - *Software* used to protect computers against malware. It also has the utility to decontaminate a computer that is infected with viruses, worms, and malicious code. These programs need to be updated frequently to ensure their effectiveness. There are corporate antiviruses, which are more complete and effective, depending on the scenario, than the free antivirus.\n\n**Application** - *Software* that makes use of network services such as file transfer, remote login, and mail electronic.\n\n**Backup** - Security routine used for storage, that is, a copy of data or settings, usually on removable media, all or part of the information on hard drives or the network. IS a solution that can be adapted, according to the needs of the company.\n\n**ERP (Enterprise Resource Planning or \u201cEnterprise resource planning\u201d)** - These are *software* that integrate all the data and processes of an organization in a single system. Examples: Protheus, Focco, EMS, SAP, Sige Cloud, Blue Account.\n\n**Firmware** - Set of operating instructions programmed directly into the hardware of a device electronic.\n\n**Hardware** - Generic designation of all types of computer equipment, that is, it is the physical part of the computer. Examples: microcomputer, hard drives, memory, printer, scanner, among others.\n\n**LAN (Local Area Network)** - It is a set of computers that belong to the same organization and which are linked together in a small geographical area by a network, often through the same technology (the most used is Ethernet).\n\n**Login** - Identification (user name) for access to a specific computer or system.\n\n----\n\n**Data log** - It is an expression used to describe the process of recording relevant events in a computational system.\n\n**Malware (Malicious Software or Software Malicious)** - It is software designed to infiltrate a system illegally using someone else's computer in order to cause some damage or theft of information (confidential or not). Computer viruses, worms, trojan horses, and spyware are considered malware.\n\n**MAN** - Company that has several offices in the same city and wants computers remain interconnected. For this there is the (Metropolitan Area Network), or Metropolitan Network, which connects several Local Area Networks within a few dozen kilometers.\n\n**Oracle** - It is a DBMS (Database Management System) written in C language and available in several electronic.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas que se pueden responder espec\u00edficamente con la informaci\u00f3n proporcionada en el contexto, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento es una gu\u00eda de ANVISA sobre la validaci\u00f3n de sistemas inform\u00e1ticos, que incluye un glosario de t\u00e9rminos y acr\u00f3nimos relevantes en el \u00e1mbito de la inform\u00e1tica y la gesti\u00f3n de datos. Se definen conceptos clave como antivirus, aplicaciones, backup, ERP, firmware, hardware, LAN, login, data log, malware, MAN y Oracle, proporcionando una base de conocimiento esencial para entender la infraestructura y la seguridad de los sistemas inform\u00e1ticos en un entorno organizacional.\n\n### Preguntas\n1. **\u00bfCu\u00e1l es la diferencia entre un antivirus corporativo y un antivirus gratuito seg\u00fan el documento?**\n   - Respuesta: El documento menciona que los antivirus corporativos son m\u00e1s completos y efectivos, dependiendo del escenario, en comparaci\u00f3n con los antivirus gratuitos.\n\n2. **\u00bfQu\u00e9 tipo de software se considera un ERP y cu\u00e1les son algunos ejemplos mencionados en la gu\u00eda?**\n   - Respuesta: Un ERP (Enterprise Resource Planning) es un software que integra todos los datos y procesos de una organizaci\u00f3n en un solo sistema. Ejemplos mencionados incluyen Protheus, Focco, EMS, SAP, Sige Cloud y Blue Account.\n\n3. **\u00bfQu\u00e9 es un MAN y cu\u00e1l es su prop\u00f3sito seg\u00fan el contexto proporcionado?**\n   - Respuesta: Un MAN (Metropolitan Area Network) es una red que conecta varias Local Area Networks (LAN) dentro de una misma ciudad, permitiendo que las computadoras de diferentes oficinas de una empresa permanezcan interconectadas en un \u00e1rea geogr\u00e1fica relativamente peque\u00f1a.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Gu\u00eda de ANVISA**: El documento se titula \"Gu\u00eda para la Validaci\u00f3n de Sistemas Inform\u00e1ticos\" (Gu\u00eda n\u00b0 33/2020) y proporciona directrices sobre la validaci\u00f3n de sistemas inform\u00e1ticos en el sector salud.\n\n2. **Categor\u00edas de Sistemas**: Los sistemas se clasifican en diferentes categor\u00edas (por ejemplo, Tipo E y Tipo F) seg\u00fan su impacto y complejidad, lo que determina el enfoque de validaci\u00f3n a seguir.\n\n3. **Enfoques Recomendados**:\n   - **Tipo E (Hojas de C\u00e1lculo para An\u00e1lisis Estad\u00edstico)**: Se recomienda una verificaci\u00f3n documentada por un tercero, controles de cambio y medidas de seguridad para proteger contra cambios no autorizados.\n   - **Tipo F (Bases de Datos de \u00c1reas de Trabajo)**: Se sugiere un enfoque t\u00edpico de categor\u00eda 4 que incluye un plan de validaci\u00f3n, especificaciones funcionales, trazabilidad, pruebas documentadas y controles de cambio.\n\n4. **Documentaci\u00f3n Clave**: La preparaci\u00f3n del documento ERU/URS es fundamental para la validaci\u00f3n, tanto para sistemas nuevos como para aquellos ya instalados.\n\n5. **Seguridad y Control de Cambios**: Se enfatiza la importancia de implementar medidas de seguridad para limitar el acceso a personas autorizadas y asegurar que solo se puedan acceder a versiones aprobadas de los sistemas.\n\n6. **Consideraciones Finales**: Para sistemas ya instalados, se debe evaluar si pueden ser validados, comenzando con la preparaci\u00f3n del ERU/URS y la evaluaci\u00f3n del sistema existente.\n\n### Entidades Clave\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria de Brasil.\n- **ERU/URS**: Documentos de Requisitos de Usuario y Requisitos de Usuario Espec\u00edficos.\n- **Tipos de Sistemas**: Tipo E (Hojas de C\u00e1lculo) y Tipo F (Bases de Datos de \u00c1reas de Trabajo).\n- **Categor\u00edas de Enfoque**: Categor\u00eda 4 y Categor\u00eda 5 para la validaci\u00f3n de sistemas. \n\nEste resumen destaca los aspectos esenciales de la gu\u00eda y proporciona una visi\u00f3n clara de los enfoques recomendados para la validaci\u00f3n de sistemas inform\u00e1ticos en el \u00e1mbito de la salud.", "excerpt_keywords": "Keywords: Antivirus, ERP, Malware, LAN, Oracle"}}, "9bfcb04a-2f0b-414c-a4ec-eedf1d567126": {"node_ids": ["95862c08-7b54-4591-99cb-83e78f83dc73"], "metadata": {"page_label": "110", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "Patch 1 - Piece of object code inserted in an executable program as a temporary correction of an error.\n\nPatch 2 - Fix with patch 1. Programming consists of repairing a deficiency in the functionality of a existing routine or program, in general, in response to an unforeseen need or set of operating circumstances. The correction by means of patches is a common way to add a feature or function to a program while the next version of the software is not released.\n\nPDF (Portable Document Format) - It is a file format created by Adobe Systems for any document is viewed, regardless of which program originated it.\n\nRAM (Random Access Memory) - It is the memory available for use by applications and processing. Its volatile content is lost whenever the computer is turned off.\n\nNetwork - Generically a set of connected computers that communicate with each other.\n\nDisaster Recovery (DR) - From English Disaster Recovery. It involves a set of policies and procedures to enable the recovery or continuation of vital technology and systems infrastructure following a natural or man-made disaster.\n\nRedundancy - It is a broad term that represents the duplication of critical components, adding system reliability. In information technology the definition is applied more frequently as the duplication of devices that are used for backup.\n\nServer - It is basically a computer more powerful than the average desktop. It was developed specifically to transmit information and provide software products to other computers that connected to it by a network. Servers have the hardware to manage health wireless network and ethernet cable, usually through a router. They were developed to handle with heavier workloads and more applications, taking advantage of hardware to increase productivity and reduce downtime.\n\nSLA (Service Level Agreement) - Consists of a contract between two parties: the entity that intends to provide the service and the customer that wishes to benefit from it. In it are specified, in detail, all aspects of the type of service that will be provided, as well as the contractual terms, the quality of service and the price to be paid for the work.\n\nSoftware - It is a set of codes developed to perform specific functions, normally for the user.\n\nTemplate - It is a model to be followed, with a predefined structure that facilitates the development and creation of content from something constructed.\n\n----\n\nPage 103\n\nViruses - Denomination given to small programs developed to cause damage at different levels, affecting the integrity of data files (removing parts or files completely), a particular computer or the entire company network.\n\nWAN (Wide Area Network) - It is the type of network that allows the interconnection of local, metropolitan and network equipment in a large geographical area (Example: country, continent, etc.).\n\nWireless - Technology capable of joining electronic terminals, usually computers, to each other due to the waves.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "### Res\u00famenes de Nivel Superior\n\n1. **Definiciones T\u00e9cnicas**: El documento proporciona definiciones clave relacionadas con la validaci\u00f3n de sistemas inform\u00e1ticos, incluyendo t\u00e9rminos como \"patch\", \"RAM\", \"SLA\", y \"viruses\". Estas definiciones son esenciales para entender el contexto de la validaci\u00f3n y gesti\u00f3n de sistemas tecnol\u00f3gicos.\n\n2. **Conceptos de Infraestructura y Seguridad**: Se abordan conceptos relacionados con la infraestructura tecnol\u00f3gica, como \"servidores\", \"redes\", \"redundancia\" y \"recuperaci\u00f3n ante desastres\". Estos conceptos son fundamentales para garantizar la continuidad y seguridad de los sistemas inform\u00e1ticos.\n\n3. **Acuerdos y Contratos**: Se menciona la importancia de los acuerdos de nivel de servicio (SLA) en la relaci\u00f3n entre proveedores de servicios y clientes, destacando la necesidad de especificar claramente los t\u00e9rminos del servicio y la calidad esperada.\n\n### Preguntas Espec\u00edficas\n\n1. **\u00bfCu\u00e1l es la diferencia entre un \"patch\" y un \"SLA\" en el contexto de la validaci\u00f3n de sistemas inform\u00e1ticos?**\n   - Esta pregunta busca aclarar dos conceptos que, aunque ambos son importantes en la gesti\u00f3n de software y servicios, cumplen funciones muy diferentes.\n\n2. **\u00bfC\u00f3mo se relacionan los conceptos de \"redundancia\" y \"disaster recovery\" en la planificaci\u00f3n de infraestructura tecnol\u00f3gica?**\n   - Esta pregunta indaga sobre la interconexi\u00f3n de dos conceptos que son cr\u00edticos para la resiliencia de los sistemas inform\u00e1ticos, lo que puede no estar expl\u00edcitamente detallado en otros documentos.\n\n3. **\u00bfQu\u00e9 implicaciones tiene la volatilidad de la RAM en la recuperaci\u00f3n de datos tras un desastre?**\n   - Esta pregunta explora c\u00f3mo la naturaleza vol\u00e1til de la RAM puede afectar los procedimientos de recuperaci\u00f3n de datos, un aspecto que podr\u00eda no ser evidente en discusiones m\u00e1s generales sobre recuperaci\u00f3n ante desastres.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\nLa secci\u00f3n proporcionada es un glosario que define t\u00e9rminos y acr\u00f3nimos relevantes en el contexto de la inform\u00e1tica y la gesti\u00f3n de sistemas. A continuaci\u00f3n se presentan los temas clave y las entidades mencionadas:\n\n1. **Antivirus**: Software dise\u00f1ado para proteger computadoras contra malware y para desinfectar sistemas infectados. Se distingue entre antivirus corporativos (m\u00e1s completos y efectivos) y gratuitos.\n\n2. **Aplicaci\u00f3n**: Software que utiliza servicios de red, como transferencia de archivos y correo electr\u00f3nico.\n\n3. **Backup**: Rutina de seguridad que implica hacer copias de datos o configuraciones, adapt\u00e1ndose a las necesidades de la empresa.\n\n4. **ERP (Enterprise Resource Planning)**: Software que integra todos los datos y procesos de una organizaci\u00f3n. Ejemplos incluyen Protheus, Focco, EMS, SAP, Sige Cloud y Blue Account.\n\n5. **Firmware**: Conjunto de instrucciones operativas programadas en el hardware de un dispositivo electr\u00f3nico.\n\n6. **Hardware**: Parte f\u00edsica de los equipos inform\u00e1ticos, que incluye componentes como microcomputadoras, discos duros, impresoras y esc\u00e1neres.\n\n7. **LAN (Local Area Network)**: Red de computadoras dentro de una misma organizaci\u00f3n, conectadas en un \u00e1rea geogr\u00e1fica peque\u00f1a, com\u00fanmente utilizando tecnolog\u00eda Ethernet.\n\n8. **Login**: Identificaci\u00f3n (nombre de usuario) para acceder a un sistema o computadora espec\u00edfica.\n\n9. **Data log**: Proceso de registro de eventos relevantes en un sistema computacional.\n\n10. **Malware**: Software malicioso dise\u00f1ado para infiltrarse en sistemas y causar da\u00f1o o robo de informaci\u00f3n. Incluye virus, gusanos, caballos de Troya y spyware.\n\n11. **MAN (Metropolitan Area Network)**: Red que conecta varias LAN dentro de una misma ciudad, permitiendo la interconexi\u00f3n de computadoras en diferentes oficinas de una empresa.\n\n12. **Oracle**: Sistema de gesti\u00f3n de bases de datos (DBMS) escrito en lenguaje C, disponible en diversas plataformas electr\u00f3nicas.\n\nEste glosario proporciona una base esencial para comprender la infraestructura y la seguridad de los sistemas inform\u00e1ticos en un entorno organizacional, facilitando la validaci\u00f3n y gesti\u00f3n de sistemas conforme a las directrices de ANVISA.", "excerpt_keywords": "Keywords: validation, infrastructure, redundancy, disaster recovery, service level agreement"}}, "710408db-79f7-4007-bbd2-be01377ddb72": {"node_ids": ["980e5d2c-9cd0-418f-8908-ece75f059086"], "metadata": {"page_label": "111", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "# 17 BIBLIOGRAPHIC REFERENCES\n\n## 17.1 REGULATORY\n\n- Resolution - RDC No. 69 of December 8, 2014;\n- Resolution - RDC n\u00ba 301, of August 21, 2019;\n- Normative Instruction - IN n\u00ba 43, of August 21, 2019;\n- Normative Instruction - IN n\u00ba 47, of August 21, 2019.\n\n## 17.2 TECHNIQUES\n\n- GAMP 5 - A Risk-Based Approach to Compliant GxP Computerized Systems.\n- PIC / S Guidance on Good Practices for Computerized Systems in Regulated \u201cGxP\u201d Environments (PI 011-3) - September 2007 (available on the website http://www.picscheme.org).\n- FDA Guidance for Industry Part 11, Electronic Records / Electronic Signatures - Scope and Application (August 2003).\n- Practical Computer Dictionary, Microsoft, 2000.", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas espec\u00edficas que se pueden responder con el contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior\nEl documento \"ANVISA - Guide for Computer Systems Validation 33/2020\" incluye una secci\u00f3n de referencias bibliogr\u00e1ficas que se divide en dos categor\u00edas: regulaciones y t\u00e9cnicas. En la parte regulatoria, se mencionan resoluciones y normativas de la ANVISA que son relevantes para la validaci\u00f3n de sistemas inform\u00e1ticos. En la secci\u00f3n t\u00e9cnica, se citan gu\u00edas y documentos que ofrecen enfoques y pr\u00e1cticas recomendadas para sistemas inform\u00e1ticos en entornos regulados.\n\n### Preguntas\n\n1. **\u00bfCu\u00e1les son las resoluciones espec\u00edficas de la ANVISA que se mencionan en el documento y en qu\u00e9 fechas fueron emitidas?**\n   - Respuesta: Se mencionan las siguientes resoluciones: RDC No. 69 de diciembre 8, 2014; RDC n\u00ba 301 de agosto 21, 2019; Normativa IN n\u00ba 43 de agosto 21, 2019; y Normativa IN n\u00ba 47 de agosto 21, 2019.\n\n2. **\u00bfQu\u00e9 documento se considera una gu\u00eda de referencia para un enfoque basado en riesgos en sistemas inform\u00e1ticos GxP?**\n   - Respuesta: El documento \"GAMP 5 - A Risk-Based Approach to Compliant GxP Computerized Systems\" es la gu\u00eda de referencia mencionada.\n\n3. **\u00bfD\u00f3nde se puede encontrar la gu\u00eda de PIC/S sobre buenas pr\u00e1cticas para sistemas inform\u00e1ticos en entornos regulados?**\n   - Respuesta: La gu\u00eda de PIC/S est\u00e1 disponible en el sitio web http://www.picscheme.org y se titula \"PIC / S Guidance on Good Practices for Computerized Systems in Regulated 'GxP' Environments (PI 011-3) - September 2007\".", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\n1. **Definiciones T\u00e9cnicas**:\n   - **Patch**: C\u00f3digo objeto insertado temporalmente en un programa para corregir errores.\n   - **PDF**: Formato de archivo creado por Adobe para visualizar documentos independientemente del programa de origen.\n   - **RAM**: Memoria vol\u00e1til utilizada por aplicaciones; su contenido se pierde al apagar el ordenador.\n   - **Red**: Conjunto de computadoras conectadas que se comunican entre s\u00ed.\n   - **Viruses**: Programas da\u00f1inos que afectan la integridad de datos y sistemas.\n   - **WAN**: Red que conecta equipos en grandes \u00e1reas geogr\u00e1ficas.\n\n2. **Conceptos de Infraestructura y Seguridad**:\n   - **Disaster Recovery (DR)**: Pol\u00edticas y procedimientos para la recuperaci\u00f3n de sistemas tras desastres.\n   - **Redundancia**: Duplicaci\u00f3n de componentes cr\u00edticos para aumentar la fiabilidad del sistema.\n   - **Servidor**: Computadora potente dise\u00f1ada para transmitir informaci\u00f3n y gestionar redes.\n   - **Wireless**: Tecnolog\u00eda que conecta dispositivos electr\u00f3nicos a trav\u00e9s de ondas.\n\n3. **Acuerdos y Contratos**:\n   - **SLA (Service Level Agreement)**: Contrato que detalla los t\u00e9rminos del servicio entre proveedor y cliente, incluyendo calidad y precio.\n\n4. **Software y Plantillas**:\n   - **Software**: Conjunto de c\u00f3digos para realizar funciones espec\u00edficas.\n   - **Template**: Modelo con estructura predefinida para facilitar la creaci\u00f3n de contenido.\n\n### Entidades Clave:\n- **ANVISA**: Agencia Nacional de Vigilancia Sanitaria en Brasil, responsable de la regulaci\u00f3n de sistemas inform\u00e1ticos en el \u00e1mbito de la salud.\n- **Adobe Systems**: Empresa creadora del formato PDF.\n- **Tecnolog\u00edas de Red**: Incluyen conceptos como WAN y Wireless, esenciales para la conectividad y comunicaci\u00f3n entre sistemas. \n\nEste resumen proporciona una visi\u00f3n general de los conceptos fundamentales relacionados con la validaci\u00f3n de sistemas inform\u00e1ticos, infraestructura tecnol\u00f3gica y acuerdos de servicio, esenciales para la gesti\u00f3n y seguridad de sistemas en el contexto de ANVISA.", "excerpt_keywords": "Keywords: ANVISA, Computer Systems Validation, GxP, Regulatory References, Risk-Based Approach"}}, "06174fe5-fa05-4b66-bbe0-409cf6f1e649": {"node_ids": ["b6b3eae9-1e38-47d6-98f0-e15580b1878e"], "metadata": {"page_label": "112", "file_name": "[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "file_path": "Brasil/[33] ANVISA Guide for Computer Systems Validation 33-2020.pdf", "image_path": "", "parsed_text_markdown": "NO_CONTENT_HERE", "parsed_text": "", "document_title": "ANVISA - Guide for Computer Systems Validation 33/2020", "questions_this_excerpt_can_answer": "Aqu\u00ed tienes tres preguntas que podr\u00edan derivarse del contexto proporcionado, junto con un resumen de nivel superior:\n\n### Resumen de Nivel Superior:\nEl documento titulado \"ANVISA - Guide for Computer Systems Validation 33/2020\" es una gu\u00eda emitida por la Agencia Nacional de Vigilancia Sanitaria (ANVISA) de Brasil, que aborda los requisitos y procedimientos para la validaci\u00f3n de sistemas inform\u00e1ticos en el \u00e1mbito de la salud. Este tipo de validaci\u00f3n es crucial para garantizar que los sistemas utilizados en la industria farmac\u00e9utica y de salud cumplan con las normativas y est\u00e1ndares de calidad necesarios para asegurar la seguridad y eficacia de los productos y servicios.\n\n### Preguntas:\n1. **\u00bfCu\u00e1les son los principales requisitos establecidos por ANVISA para la validaci\u00f3n de sistemas inform\u00e1ticos en el sector salud seg\u00fan la gu\u00eda 33/2020?**\n   - Esta pregunta busca informaci\u00f3n espec\u00edfica sobre los requisitos normativos que deben cumplirse, que probablemente no se encuentre en otras fuentes.\n\n2. **\u00bfQu\u00e9 metodolog\u00edas de validaci\u00f3n se recomiendan en la gu\u00eda de ANVISA para asegurar la integridad y confiabilidad de los sistemas inform\u00e1ticos?**\n   - Esta pregunta se enfoca en las metodolog\u00edas espec\u00edficas que ANVISA sugiere, lo cual puede no estar ampliamente documentado en otros lugares.\n\n3. **\u00bfC\u00f3mo se debe documentar el proceso de validaci\u00f3n de sistemas inform\u00e1ticos seg\u00fan las directrices de ANVISA en el documento 33/2020?**\n   - Esta pregunta busca detalles sobre la documentaci\u00f3n requerida durante el proceso de validaci\u00f3n, un aspecto cr\u00edtico que puede no estar claramente definido en otras gu\u00edas o documentos.", "prev_section_summary": "### Resumen de Temas Clave y Entidades\n\nLa secci\u00f3n 17 del documento \"ANVISA - Guide for Computer Systems Validation 33/2020\" se centra en las referencias bibliogr\u00e1ficas relevantes para la validaci\u00f3n de sistemas inform\u00e1ticos, organizadas en dos categor\u00edas principales: regulaciones y t\u00e9cnicas.\n\n#### Temas Clave:\n\n1. **Regulaciones**:\n   - Se mencionan varias resoluciones y normativas de la ANVISA que son fundamentales para la validaci\u00f3n de sistemas inform\u00e1ticos en entornos regulados.\n   - Las fechas de emisi\u00f3n de estas regulaciones son importantes para entender su contexto y aplicabilidad.\n\n2. **T\u00e9cnicas**:\n   - Se citan gu\u00edas y documentos que ofrecen enfoques y pr\u00e1cticas recomendadas para la gesti\u00f3n de sistemas inform\u00e1ticos en entornos GxP (buenas pr\u00e1cticas de fabricaci\u00f3n).\n   - Se destaca la importancia de un enfoque basado en riesgos y se proporcionan recursos adicionales para la implementaci\u00f3n de buenas pr\u00e1cticas.\n\n#### Entidades:\n\n- **Regulaciones de ANVISA**:\n  - RDC No. 69 (2014)\n  - RDC n\u00ba 301 (2019)\n  - IN n\u00ba 43 (2019)\n  - IN n\u00ba 47 (2019)\n\n- **Documentos T\u00e9cnicos**:\n  - GAMP 5\n  - PIC/S Guidance (PI 011-3)\n  - FDA Guidance for Industry Part 11\n  - Practical Computer Dictionary (Microsoft, 2000)\n\nEste resumen proporciona una visi\u00f3n general de las referencias clave que gu\u00edan la validaci\u00f3n de sistemas inform\u00e1ticos en el contexto regulatorio brasile\u00f1o.", "excerpt_keywords": "Keywords: ANVISA, validaci\u00f3n, sistemas inform\u00e1ticos, regulaciones, buenas pr\u00e1cticas"}}}}
\ No newline at end of file