Validación de Sistemas Computadorizado y Análisis De Riesgo POR NELSON ESTEVES ECS - Esteves Consulting Services, Inc.
I. PLANEACIÓN ESTRATEGICA EN VALIDACIÓN DE SISTEMAS COMPUTARIZADOS. •
CSV definición y ventajas - Se definira el concepto de "Computer System Validaction" y porque su importancia y en que nos ayuda.
•
SDLC definición y clasificación de sistemas- Se definira el ciclo de vida de un sistema computadorizado, sus partes y la clasificación de sistema y cada requisitos necesario de acuerdo a la clasificación del sistema por cada etapa del ciclo de vida.
•
Preparación efectiva de Requerimientos y Diseño - Definir requisitos de sistemas es ecencial el el desarrollo de un sistema computadorizado, quienes, que y como definir los requerimientos para crear un diseño adecuado que ayuda a la planiación de la validación.
•
Plan de Validación de Sistemas Computadorizados - Definir los componenetes de un plan, definir responsabilidades por area, y como ejecutarla durante todo el ciclo de vida del sistema.
•
Analisis de Riesgo como instrumentos a definir la estrategia de validacionesIntroducción a cuales aspectos consideramos para definir un analisis de riesgo, como generar un analisis efectivo que mitigue el riesgo y nos ayude a reducir las pruebas en la validación.
•
Planeación de la estrategia durante el SDLC- Que se va a validar, como y como subdividir el sistema de acuerdo a su clasificacion. Integrar el análisis de riesgo y la sub-división del sistema clasificado para definir la estrategia de validación.
Metodología: La evaluación sistemática del sistema se comienza en el ciclo de vida del sistema (SDLC) mientras se desarrollan todas sus etapas. Las fases del ciclo de vida del sistema (SDLC) son: ¾ Concepto ¾ Planificación del Proyecto ¾ Definición de requerimiento ¾ Especificación de diseño ¾ Código/Construcción ¾ Pruebas ¾ Implementación ¾ Mantenimiento Es importante que se clasifique el sistema para determinar que fases del ciclo de vida que le aplican. La clasificación del sistema esta categorizada por el software y se sugiere la siguiente clasificación.
Categorias de clasificación de Software Categoría Categoria 1. Sistemas Operativos (OS) Categoria 2. Instrumentos, Microcontroladores Instrumentos programados. Categoria 3. Paquetes Pre-programados
Descripción Establece sistemas operativos (SO) de redes o locales. Por ejemplo; DOS, UNIX, VAX/VMS, Novell and Windows 95/98/NT Firmware, dispositivos electrónicos, preprogramados. Ejemplos, ASIC, ROM.
(COTS) Software comerciales preprogramados,. Ejemplos hojas de cálculos (Excel). Categoria 4. Paquetes de software que son configurables Paquetes Configurables para unas especificaciones ejemplo SCADA,LAS, MRP,HMI Software desarrollados por programación o Categoria 5 Sistemas programables por paquetes pre-programados con una desarollados aplicación determinada y requerida.
Tareas en el Ciclo de Vida del sistema (SDLC) por fase
En la próxima tabla y diagramas se presentan las fases del ciclo de vida de un sistema (SDLC) y las tareas que se deben realizar en cada categoría donde en cada una de ella se consideran los requisitos de Parte 11 una vez evaluado el sistema.
Tareas sugeridas en el Ciclo de Vida del sistema (SDLC) por fase a considerar Fase del SDLC Concepto Planificación del proyecto e Iniciación Definición de Requerimiento Especificaciones de diseño Construcción y codificación
Tareas del SDLC Solicitud de Cambio Análisis de Riesgo y Justificación Plan Maestro Auditoría al Vendedor Plan de Validación Solicitud de Justificación Requerimientos de Usuario Requerimientos Funcionales Matriz de Rastreo Especificación de diseño del sistema Configuración y Línea de Código Unidad de Integración al Plan de Pruebas, Conjunto de Datos y Tipos de Pruebas.
Categoria 1 2 3 4 5 aaa a a aa aaa a a aa aaa a a aaa a a aaa aaa a a aa aa aaa a
Tareas en el Ciclo de Vida del sistema (SDLC) por fase F a se d e l S D L C P ru e ba s
Im p la nta c ió n
M a n te n im ie nto
T a re a s d e l S D L C P ru e ba s a c c e p ta ble s d e l siste m a d e u su a rio , C a so s d e p ru e ba s, C o nju nto d e d a to s, y R e p o rte C a lific a c ió n d e Insta la c ió n y re p o rte s (IQ & R e p o rt) C a lific a c ió n O p e ra c io na l y re p o rte s (O Q & R e p o rt) C a lific a c ió n d e P ro c e so y re p o rte s (P Q & R e p o rt) R e p o rte d e V a lid a c ió n N o tific a c ió n d e R e le vo R e p o rte d e M a nte nim ie nto C o n tro l d e C a m bio s A d m inistra c ió n d e l S iste m a P ro c e d im ie nto s d e S e g u rid a d R e sg u a rd o /R e c u p e ra c ió n P la n d e re c u p e ra c ió n d e d e sa stre L o g s d e M a nte nim ie nto R e visio ne s P e rió d ic a s
C a te g o ria 1 2 3 4 5 a aaa a a aaa a a aaa a a aaa aaa aaa aaa aaa aaa aaa aaa aaa aaa
a a a a a a a a a a
a a a a a a a a a a
Plan de Validación Parte 11 y Plan Maestro
2 Definición
3 Selección
4 Especificación
Funciones Controladas
Requisitos Funcionales
Hardware y Software
Equipo
Selección del Vendedor
Hardware y Software
Funciones Controladas
Especificaciones del Sistema Computadorizado
Hardware y Software
Software Diseño y Construcción del Sistema Computadorizado
5 Desarrollo
Hardware
IQ del Equipo
IQ Sistema Computadorizado
OQ del Equipo
OQ Sistema Computadorizado
6 Integración y Calificación
Calificación de Desempeño
Evaluación Continua
Fases: Fase 1
Definición del concepto del sistema
Fase 2
Planificación del Proyecto
Fase 3
Requerimientos del Sistema
Fase 4
Especificaciones de diseño del Sistema
Fase 5
Construcción y Codificación del Sistema
Fase 6
Definición de Pruebas
Fase 7
Implantación y Calificación
Fase 8
Definición de Mantenimiento del Sistema
Fase 9
Definición del Retiro del sistema
PLAN DE VALIDACIÓN • El Documento debe incluir: – – – – – – –
Descripción del Sistema Computadorizado Responsabilidades Guías Corporativas Procedimientos Estándares de Operación Itinerario de Actividades Filosofías y métodos a utilizarse Criterios de Aceptación
Responsabilidades usuario/proveedor • Responsabilidades del usuario – Validación de los sistemas. – Remediaciones procedurales para el cumplimiento de ERES.
• Responsabilidades del proveedor – Proveer remediaciones técnicas a los usuarios o software para el cumplimiento de ERES.
¿Quiénes conforman el comité de validación? • • • • • • •
Control de Calidad y cumplimiento Ingenieria Servicio Técnico Validación IS/IT, “Automation” Manufactura Compra
Plan Maestro de Validación Enfoque y estrategias • El Plan Maestro define el concepto general del proyecto y los controles y estrategias a utilizarse durante el proceso de validar los sistemas y sus componentes • El Plan Maestro general (VMP) se puede descomponer por areas o por sistemas • Es necesario documentar como proceder en cada evento y como administrar cada etapa del ciclo de validación • Es necesario describir el sistema a ser validado
Aspectos a Considerar para desarrollar el Plan Maestro (VP) • Inventario del sistema • Análisis de Riesgo (Categorización, Impacto, Criticalidad, Prioridad) • Estrategia de Validación • Recursos a utilizarse • Objetivos especificos de alcance • Calendario (Schedules) • “Deliverables”
Plan Maestro • Establecer el plan de acción para las actividades de validacion y los resultados • Definir recursos y calendario de actividades. • Comprometer a todos los componentes del grupo de validaciones • Proveer quías de diseño • Establecer el paso regulatorio • Establecer las estrategias de validaciones • Definir los grupos y sus responsabillidades
Validación efectiva en costo • Garantizar cumplimiento de requerimientos de producto • Prevenir observaciones de las agencias regulatorias y posibles rechazos de productos. • El esfuerzo de validación debe asistir en in assessing product quality; facilitate the transfer of processes and/or technology to operations and identify areas where improved process controls are desirable to assure process reproducibility
Ventajas de Validar – – – – – – – – – – –
Reduce inspecciones Reduce pruebas Reduce duplicidad de trabajo Reduce “trouble-shooting” Reduce scrap Reduce dificultades en el producto Reduce costo asociados con rechazo de lotes Timepo cort de “start-up” Procesos robustos Mejor entendimiento del proceso Los supervisores y gerentes de area adquieren mejor conocimiento y control de los procesos.
REQUISITOS FUNCIONALES Requisitos Funcionales
1
Los Requisitos Funcionales suplen a las Especificaciones y al Diseño Cada elemento de las Especificaciones y del Diseño es rastreable a uno o más elementos de los Requisitos Funcionales
4
Especificaciones y Diseño
3
Las Especificaciones y Cada elemento de prueba en la el Diseño suplen Calificación es rastreable a uno o más la Calificación elementos de las Especificaciones y del Diseño
2
Calificación
REQUISITOS FUNCIONALES Aseguramiento de Calidad
Validación
Cliente / Usuario
s o t i s i u s q e l Re iona c n u F Ingeniería
REQUISITOS FUNCIONALES ¿Qué es lo que el sistema debe hacer?
• Requisitos y Características Distintivas
¿Qué?
– – – – – – – – –
Descripción del Sistema Computadorizado Equipos a Controlar Secuencia de Operación Datos de Entrada Procesamiento de Datos Datos de Salidas Interfaces con el Operador Requisitos de Reportes Restricciones
REQUISITOS FUNCIONALES Entrada
• Fuentes • Cantidades • Unidades • Rangos • Exactitud • Tolerancia
Procesamiento
• Verificación de datos de entrada • Respuestas a condiciones anormales • Desbordamiento • Falla de comunicación • Manejo de errores • Parámetros afectados por la operación • Métodos (ecuaciones, etc..)
Salida • Destino • Cantidades • Unidades • Rangos • Exactitud • Tolerancia • Mensajes • Reportes
Desarrollo de especificaciones de usuarios, funcionales y de diseño • Las especificaciones de un sistemas se definen por el proceso en – Requerimientos de usuarios – Requerimientos funcionales – Especificaciones de Diseno
• Deben de ser: – – – –
Leíbles Claras Identificables Rastreables
ESPECIFICACIONES DEL SISTEMA COMPUTADORIZADO Documento o colección de documentos, que describen de forma clara y completa como es que el Sistema Computadorizado va a operar y como satisface los Requisitos Funcionales.
• Diagramas – Flujogramas del Proceso – Flujogramas de Datos – Secuencia de operación
¿Cómo?
• Interacción con el Usuario • Interacción con otros equipos • Interacción con el Medio Ambiente Operacional • Equipos a Controlar
ESPECIFICACIONES DEL SISTEMA COMPUTADORIZADO (cont.) •
•
Operación del Sistema Computadorizado – Modos de operación – Condiciones irregulares – Parámetros operacionales • Entrada, Salida, Límites • Rango • Alarmas e “Interlocks” – Detalles sobre pantallas – Detalles sobre reportes Niveles de Seguridad
AUDITORÍA AL VENDEDOR – Técnicamente competente y comercialmente calificado para suplir y dar apoyo al sistema – Conocimiento sobre los Requisitos de la Calificación – Proveer un Sistema para aplicaciones GMP – Aseguramiento de Calidad de “Software” • Estándares de Programación de “Software” • Especificaciones sobre Diseño de “Software” • Plan para probar el “Software” • Plan de auditoría de “Software” • Adiestramiento interno al personal – Procedimientos de Control de Cambios – Procedimientos de Documentación
AUDITORÍA AL VENDEDOR (cont.) • Auditoría al Producto – “Software” • Programas de Aplicación – Sistema de Aseguramiento de Calidad
• Programas de Sistema Operacional o Configurable – Historial de satisfacción – Análisis retrospectivo del reporte de problemas y el procedimiento de corrección – Cantidad y tipos de aplicaciones utilizando el programa – Tiempo de la versión en el mercado
AUDITORÍA AL VENDEDOR (cont.) – “Hardware” • • • • •
Reglamentaciones de ingeniería y calidad Historial de uso Durabilidad Contabilidad Exactitud operacional durante condiciones definidas del medio ambiente operacional del sistema
ESPECIFICACIONES DEL SISTEMA COMPUTADORIZADO Documento o colección de documentos, que describen de forma clara y completa como es que el Sistema Computadorizado va a operar y como satisface los Requisitos Funcionales.
• Diagramas – Flujogramas del Proceso – Flujogramas de Datos – Secuencia de operación ¿Cómo?
• Interacción con el Usuario • Interacción con otros equipos • Interacción con el Medio Ambiente Operacional • Equipos a Controlar
ESPECIFICACIONES DEL SISTEMA COMPUTADORIZADO (cont.) •
Operación del Sistema Computadorizado – Modos de operación – Condiciones irregulares – Parámetros operacionales • Entrada, Salida, Límites • Rango • Alarmas e “Interlocks” – Detalles sobre pantallas – Detalles sobre reportes
•
Niveles de Seguridad
Tipos de Software • Programas del Sistema: provee las instrucciones de operación básica de la computadora y control de operaciones • Programa Configurable: el usuario no puede cambiar el código del programa pero le permite definir una serie de condiciones tales como: – parámetros operacionales – parámetros de reportes – condiciones de alarmas • Programa de Aplicación: código que es escrito o modificado para una función específica. Cuando un programa configurable es utilizado, los parámetros y operaciones que son especificados por medio de éste, son tratados como programas de aplicación.
PROGRAMAS DEL SISTEMA •
Sistemas operativos, compiladores, interpretadores, “firmware”, programas de diagnósticos y programas de los periferales no están sujetos a validación. Se recomienda documentación histórica de uso satisfactorio, versión utilizada, fecha de introducción al mercado, órdenes de compra y documentación del vendedor (certificaciones y auditorías).
DISEÑO Y CONSTRUCCIÓN DEL SISTEMA COMPUTADORIZADO •
•
Dibujos de Ingeniería – “P&IDs” – Instalación del Alambrado de Control – Distribución Eléctrica y Alambrado de Tierra Especificaciones – Instrumentos de Campo – “Hardware”
– “Software” •
Asignación de Entrada y Salida de Datos (I/O Address)
DISEÑO Y CONSTRUCCIÓN DEL SISTEMA COMPUTADORIZADO (cont.) •
Codificación
•
Verificación del “Software” – Estructural – Funcional
•
Manuales del Usuario
•
Adiestramiento
•
Calificación
DOCUMENTOS DE CALIFICACIÓN
ión ació c i f i l a IQ) ( C n ó ió i talac s n I e d
ión ció Califica Q) O ( l a n io Operac
CALIFICACIÓN DE INSTALACIÓN (IQ) Definición: Verificación documentada de los aspectos relevantes de la instalación del “Hardware” y el “Software” y su cumplimiento con las especificaciones del sistema.
CALIFICACIÓN DE INSTALACIÓN (IQ) •
Partes del documento – Título – Hoja de aprobaciones – Tabla de contenido – Objetivo – Alcance – Responsabilidades – Descripción del sistema – Procedimientos generales y documentación – Verificación de instalación • Título de la prueba • Objetivo • Procedimiento o metodología • Criterios de aceptación • Anejo
CALIFICACIÓN DE INSTALACIÓN (IQ) •
Verificación de instalación – Verificar que la información requerida esté al día y debidamente aprobada (“Hardware” y “Software”). – Verificación estructural del código fuente para certificar que esté libre de errores, código muerto (“dead code”) e instrucciones redundantes (“Programa de aplicación”).
CALIFICACIÓN DE INSTALACIÓN (IQ) • Verificación de instalación (cont.) – Verificar que las condiciones ambientales (humedad, temperatura,electromagnetismo y radio frecuencia) no afecten los componentes e instrumentos.
– Verificar que el “Software” haya sido debidamente instalado basado en el procedimiento de instalación.
CALIFICACIÓN DE INSTALACIÓN (IQ) •
Verificación de instalación(cont.) – Verificar los cables y conexiones según diagramas y especificaciones.
– Realizar pruebas diagnósticas a los componentes que lo requieran. – Verificar las especificaciones de seguridad física y lógica – Identificar listado de piezas de repuesto
CALIFICACIÓN DE INSTALACIÓN (IQ) •
Verificación de instalación (cont.) – Verificar los procedimientos de: • Operación • Seguridad • Calibración y mantenimiento • Copias de resguardo y recuperación de desastres • Control de cambio • Alarmas y manejo de errores • Retención de documentos
CALIFICACIÓN DE INSTALACIÓN (IQ) •
Verificación de instalación (cont.) – Verificar que los componentes e instrumentos contengan los servicios especificados – Verificar que los instrumentos sean calibrados y haya procedimientos para ello.
CALIFICACIÓN DE INSTALACIÓN (IQ) •
“Hardware” – Información Requerida • Listado de componentes con sus especificaciones • Diagramas – Proceso e instrumentación – Conexión • Utilidades o servicios – Electricidad – Aire comprimido
CALIFICACIÓN DE INSTALACIÓN (IQ) •
“Hardware” – Información Requerida (cont.) • Manuales – Instalación y configuración – Operación y mantenimiento • Órdenes de compra • Documentación del vendedor – Certificaciones – Auditorías
Pruebas de Instalación (IQ) • Pruebas de instalación de sofware o funciones que generan el ‘Audit Trail’, controles de seguridad automatizados para firma electrónicas, adquisición de datos, sincronización de fecha y hora, anti-virus u otro software instalados para remediar aspectos de requisitos tecnológicos. • Verificación de que los procedimientos asociados al sistema estén aprobados por el Departamento de Control de Calidad y que existen en un mecánismo controlado. • Verificación de la evidencia de educación de los usuarios del sistema, capacitaciones, y/o experiencia. • Verificación de toda la documentación de validación de computadora previa a la cualificación. • Verificación de los archivos de desarrollo y configuración del sistema si los sistemas son categoria 4 ó 5.
PROGRAMA CONFIGURABLE •
Información Requerida – Documentación histórica de uso satisfactorio. – Análisis retrospectivo de los reportes de problemas con el programa. – Procedimientos usados por el vendedor para informar y corregir problemas con el programa. – Fecha de introducción al mercado de la versión utilizada del programa.
PROGRAMA CONFIGURABLE •
Información Requerida (cont.) – Número aproximado de usuarios de dicha versión. – Disponibilidad del código fuente (“source code”) para ser revisado en cualquier momento – Órdenes de compra – Documentación del vendedor • Certificaciones • Auditorías
PROGRAMA DE APLICACIÓN • • •
Código fuente (“source code”) en disco y papel, lenguaje utilizado y versión del compilador o interpretador Flujogramas Descripción de módulos y listado de subprogramas, subrutinas o funciones contenidas en dichos módulos
PROGRAMA DE APLICACIÓN (cont.) • •
Estándares y procedimientos utilizados para el desarrollo, pruebas y mantenimiento del programa Descripción de detección de errores y recuperación de los mismos
PROGRAMA DE APLICACIÓN (cont.) • • •
Definición de todas las variables y constantes Especificación de todas las entradas (“inputs”), procesamiento y salidas (“outputs”) Resultados de pruebas realizadas durante la fase de desarrollo del mismo
CALIFICACIÓN OPERACIONAL (OQ) •
Definición: Verificación documentada de que el sistema opera en conformidad con las especificaciones del sistema.
CALIFICACIÓN OPERACIONAL (OQ) •
Partes del documento – Título – Hoja de aprobaciones – Tabla de contenido – Objetivo – Alcance – Responsabilidades – Descripción del sistema – Procedimientos generales y documentación – Pruebas funcionales • Título de la prueba • Objetivo • Procedimiento o metodología • Criterios de aceptación • Anejo
CALIFICACIÓN OPERACIONAL (OQ) •
Pruebas funcionales – Verificación de comunicación • El objetivo de esta prueba es verificar y documentar que el sistema tiene la habilidad de reconocer la pérdida de comunicación entre los componentes críticos y que posee la lógica apropiada para manejar esta situación hasta que la comunicación sea establecida nuevamente. – Verificación de alarmas • El objetivo de esta prueba es verificar y documentar que el sistema tiene la habilidad de alertar al operador de que una condición anormal que pone en peligro la seguridad del personal o compromete la calidad del producto está ocurriendo.
CALIFICACIÓN OPERACIONAL (OQ) •
Pruebas funcionales (cont.) – Verificación de interfaces con el usuario (operador) • El objetivo de esta prueba es verificar y documentar que: – los campos definidos para cada parámetro de operación son los correctos – los datos de entrada cumplen con los rangos de operación – cada menú u opción sigue la secuencia especificada – cada mensaje o reporte sigue el formato especificado
– Verificación de los valores límites o fronteras • El objetivo de esta prueba es verificar y documentar el comportamiento del sistema cuando son recibidos valores justamente sobre o justamente debajo del rango de operación.
CALIFICACIÓN OPERACIONAL (OQ) •
Pruebas funcionales (cont.) – Verificación bajo condiciones extremas (“Worst Case”) • El objetivo de esta prueba es verificar y documentar el comportamiento del sistema cuando: – todos los componentes del sistema o equipos relacionados están trabajando al mismo tiempo – todos los componentes del sistema o equipos relacionados están trabajando un tiempo mayor que el normal – están corriendo dos o más aplicaciones al mismo tiempo
CALIFICACIÓN OPERACIONAL (OQ) •
Pruebas funcionales (cont.) – Verificación de control de operación • El objetivo de esta prueba es verificar y documentar el comportamiento del sistema cuando otros sistemas o mecanismos ejercen control sobre la misma operación.
– Verificación durante falla eléctrica • El objetivo de esta prueba es verificar y documentar que el sistema puede recuperarse efectivamente de una falla eléctrica mediante la retención de los valores de producción y la secuencia del proceso seleccionado o cualquier tarea o información que estaba en progreso cuando ocurrió la falla eléctrica.
– Verificación de operación del sistema • El objetivo de esta prueba es verificar y documentar que el sistema trabaja adecuadamente y de forma integrada.
Pruebas Funcionales y Operacionales en (OQ) • Pruebas de Control de los Archivos, verificar: – – – – – – – – – – – –
Imprimir archivos El contenido se ve en pantalla La entrada (input) al archivo Se transfiere en formatos comunes Acceso al archivo Retención de los archivos Niveles de acceso Secuencia de pasos Data de equipos verificable automaticamente Resguardo y Recuperación Metadata Medios de almacenamientos
Pruebas Funcionales y Operacionales en (OQ) • Pruebas al ‘Audit Trail’, verificar: – Data generada que tenga fecha, hora, nombre de usuario, tipo de cambio – Que la data sea solo para leer (Read Only) y pueda ser impresa – Es automatico para cada entrada – Sincronización de fecha y hora – Valores previos – Transferencia a formato de texto u otro formato que se pueda ver en otro sistema – Protección de acceso – No manejable
Pruebas Funcionales y Operacionales en (OQ) • Seguridad física y lógica, verificar: – – – – – – – –
Controles mecánicos de acceso a cuartos protegidos ID ‘username’ Contraseña ‘Password’ Privilegios específicos por responsabilidad Eventos de terminar connecciones Eventos de bloqueo temporero de acceso Eventos de protecciones por tiempo de inactividad Eventos de control de mensajes por contraseñas de acceso no correctas o falsas
Pruebas Funcionales y Operacionales en (OQ) • Procedimientos operacionales se verifica: – Control de Cambios – Resguardo y Recuperación – Manejo y operaciones en el sistema • • • • •
Pantallas Sequencias Entrada de datos Imprimir Alarmas
– Administración del sistema
Pruebas Funcionales y Operacionales en (OQ) • Firmas electrónicas se verifica: – – – – – – – – –
Nombre del usuario a firmar Combinaciones de ID/Contraseña Fecha y Hora Propósito y significado de la firma Referencia al archivo electrónico firmado Autenticidad de la firma Concordancia de eventos y la firma Archivos se imprimen con la firma electrónica necesaria Firma única y comprobable
EVALUACIÓN CONTINUA Procedimientos Estándares de Operación
Plan de Contingencia / Recuperación de un Desastre
Re-evaluación Periódica de Desempeño
Medidas de Seguridad
Procedimientos de Control de Cambios
Sistema Computadorizado Calificado
Procedimientos de Mantenimiento
Adiestramiento
Sistema de Cambios • El sistema de cambio se da por las siguientes razones: – – – – – – – –
Evaluación del sistema Cambios en versiones del Software Cambios de Hardware Cambios en subsistemas o sistemas alternos Cambios en sequencias operacionales Cambios en recetas o el proceso Reubicación del sistema Retiro del Sistema
Sistema de Cambios • Se evalua el cambio junto al grupo de trabajo y se genera un hoja de cambio. • Se evalua el impacto del cambio y se analisa el riesgo e impacto en la criticalidad del sistema y el contacto del sistema al producto. • El cambio es aprobado por los diferentes componentes del grupo con representaciones de los departamento de ingenieria, ambiental, control de calidad y manufactura. • Se evalua el efecto del cambio, si impacta la validación actual, los documentos del SDLC y los procedimientos operacionales (SOPs) – En cambios de software y hardware impacta todo el SDLC y require validarse el sistema – Todos los cambios asociados a Sistemas Computadorizados en su mayoria afectan el sistema validado y sus documentos del SLDC
Análisis de Riesgo (AR) • Se descompone el sistema en subsistemas para ser evaluado. • Se evalua la criticalidad del sistema dada por la calidad del producto – Impacto directo – Impacto no-directo
• Se evalua el sistema por aspectos de seguridad – Ambiental – Lógica – Física
• Se genera un documento donde se registre todo el proceso de investigación. • El AR debe ser periodico, por cambios y por evaluación del sistema.
Ingenieria-Mantenimiento • Comisionamiento (Comissioning) – Se realiza en etapas de instalaciones del sistema y equipos.
• FAT – La verificación del sistema (software y controles) en las instalaciones del provedor • SAT- La verificación de la integración del sistema en las instalaciones de la planta de manufactura.
Mantenimiento • Es necesario e imprecindible para la operación contiua del sistema. • Deben existir procedimientos que definan los pasos a sequir y consideraciones técnicas para llevar a cabo el mantenimiento y establecer en que periodos de tiempos se realize. • El mantenimiento asegura la calidad del proceso de manufactura y el cumplimiento regulatorio del producto.
R&D
Conceptual Design
Maintenance and Validation Master Plan Detailed Basic Engineering Construction Engineering
Start-up/ Validation KPI’s / Metrics
Criticality Analysis
Dev. Maint. Schedule
FMEA
Maint. Process SU
Maintenance Strategy
Develop Craft Training Deliver Craft Training
Set up Data Mgt. System Pop. MEL Equip Info
Master Plan Develop.
Vendor Manuals
Populate CMMS w. PMs, SOPs, Part IDs
Project Planning Commissioning Plan/Sequence
Validation Input
CMMS Upload Complete
GMP and Design Audits FDA Meetings Engineering Design Review
Validation
Go Forward
PM/PdM Development
Spine
Maintenance
Maintainability Review
Operation
Construction Review Procurement FAT
Protocol Development IQ OQ PQ Val. CMMS Reporting FDA Review
Calidad y Desarrollo • La calidad se debe inicar desde el comienzo del proyecto desde el concepto hasta el proceso de retiro • El ciclo de vida de validacion debe ser evaluado continuamente observando la calidad de los controles establecidos para las distintas etapas. • Los grupos de control de calidad deben tener participación activa en la toma de deciciones y no solamente en la revisión de documentación
Producción y Materiales • • • • • • • • • • •
Recursos Humanos Procedimientos Manuales Especificaciones Dibujos Formulaciones o recetas Control de seguridad Control de documentos Control de Cambios Control de Fallas Acciones Correctivas y Preventivas (CAPA)
RECORDEMOS... Definir bien el sistema a ser evaluado
Lo que no se documentó, no fue realizado
II Guias de GAMP y Analisis de Riesgo Efectivo • • • •
•
GAMP conceptos y definiciones - Que es GAMP, Como nos ayuda y cuando utilizarlo. Guías y sus usos en el GAMP - Definir las distintas guías sugeridas por el GAMP y conocer sus propósito e implementación. Propósito del Análiss de riesgo - Porque es necesario el análisis de riesgo, cuando y como se usa durante el SDLC. Aplicación de Análisis de Riesgo - Cuando aplicar el Análisis de Riesgo para una estrategia adecuadas de validación y en que tipos de sitemas es adecuado y beneficioso. Implementación al Análisis de Riesgo - Como implementar el análisis de riesgo en un sistema validado o por validar para mitigar funcionalidades de alto riesgo que afecten adversamente el proceso de manufactura donde se use el sistema computadorizado.
Estandar GAMP enfocados en los Sistemas de Control de Proceso • Tipos de Equipos y Sistemas. • Desarrollo de especificaciones de usuarios, funcionales y de diseño. • Evaluación del impacto. • Componentes críticos del proceso. • Programa de actividades. • Evaluación crítica de software. • Elementos de validación especificos de los sistemas de control de proceso.
Estandar GAMP enfocados en los Sistemas de Laboratorios • Nueva categorización aplicable a los sistemas de laboratorio. • Desarrollo vs. Implementación del ciclo de vida. • Especificaciones y rastreabilidad. • Codificación y Construcción. • Elementos de validación específicos de los sistemas de laboratorio.
Estandar GAMP enfocados en el control y cumplimiento de la infraestructura de IT • • • • • • •
Plataformas. Proceso y personal. Sistemas de administración de calidad. Calificación de plataformas. Procuramiento e instalación. Aplicación del análisis de riesgo. Reportes y entregas.
Estandar GAMP enfocados en el control y cumplimiento de los Sistemas de Informacion Global • • • • • • • •
Consideraciones en la administración del proyecto. Planeación de la administración de datos. Arquitectura del sistema. Validación y establecimiento. Administración de la rastreabilidad. Seguridad del sistema. Respaldos y recuperaciones. Sistemas locales vs. sistemas globales.
Estandar GAMP basados en el manejo del riesgo de registros y firmas electronicas • • • • • • •
Conceptos claves. Riesgos en registros electronicos. Evaluación del sistema. Peligros. Rigor de los controles. Registros hibridos. Responsabilidades usuario/proveedor
Tipos de Equipo y Sistemas • • • • • •
Sistemas de Manejo de Edificio (BMS Equipos configurables Sistemas Distribuidos de Control (DCS) Sistemas Embedded Controles Logicos Programables (PLC) Control Supervisados y Adquisicion de datos (SCADA) • Sistemas Independientes
BMS • Son sistemas que se utilizan para controlar las condiciones ambientales (ambiente) de un edificio utilizado para la preparación de un producto regulado. • En sus siglas en Ingles “Building Management Systems” • Contienen Sistemas computadorizados – Software (categoría 2,3,4), Hardware – Controles
• Contienen Equipos de medición y de control
Equipos Configurables • Son instrumentación que contienen parámetros que se configuran para el funcionamiento del equipo que realizar la función definida. • Ejemplos; PID, HPLC, Analizadores, Lectores Código de barras, Balanzas. • Estos equipos contienen software internos previamente programados, categoria 2.
DCS • Son sistemas de controles integrados bajo parámetros de control o monitoreo en un solo y único sistema con definiciones especificas únicas y no multiples. • Los Software de estos sistemas se consideran Categoría 4, si no son ‘customizados’ • Son sistemas de controles para operaciones complejas de integración.
Embbeded • Son sistemas con aspectos programables y configurables. • Contienen PLCs, software configurables, e instrumentación. • Por ejemplo sistemas de empaque. • Pueden tener software categoria 2,3,4,y 5
PLC • Sistemas programables de control de procesos. Controlan entradas y salidas para realizar una función según definida en un orden lógico y secuencial (Algorítmico). • Contienen tarjetas análogas o digitales para proveer control/monitoreo a la instrumentación del proceso. • Pueden tener software categoria 2,3,4,y 5.
SCADA • Contienen uno o mas PLCs. • Tienen la capacidad de monitorear, controlar y evaluar decisiones. • La adquisición de data es imprescindible para evaluaciones del proceso y control del mismo. • El Manejo de eventos es determinante en estos sistema para la estructura del mismo.
Standalone • Son sistemas independientes que se proporcionan capacidades de proceso en sistemas antes mencionados como DCS, SCADA. • Tienen sus propias funcionalidades utilizadas por sistemas que se alimentan de ellos para completar el proceso. • Pueden tener software categoria 2, 3, y 4
Evaluación del impacto • Se inicia con la planificación del proyecto al definir los URS. • Se Define el plan a realizar para definir el proceso de evaluación del sistema y sus implicaciones a través de un documento • Se Aprueba el documento de Plan por el equipo de aprobación del proyecto • Se comienza a ejecutar el plan
Análisis de Riesgo (AR) • Ejecución del Plan escrito o por un procedimiento: – Se descompone el sistema en subsistemas para ser evaluado. – Se evalúa lo critico de cada sistema identificado del PCS. • Impacto directo a la calidad del producto • Impacto no-directo a la calidad del producto
– Se evalúa el sistema por aspectos de seguridad • Ambiental • Lógica • Física
Análisis de Riesgo (AR) – Se genera un documento donde se registre todo el proceso de investigación. – El AR debe ser periodico, por cambios y por evaluación del sistema.
Componentes críticos del proceso • Se identifican cada componente/funcional del sistema • Los componentes del sistema ya identificados se evalúan por critico o no critico. • Se identifican cada uno en base a el impacto a la calidad del producto. En contacto físico o implicaciones de datos que identifican la calidad del producto.
Programa de actividades • Se define un programa como antes mencionamos por procedimiento o por plan, este debe contar con un calendario definido de actividades para el análisis de riesgo a ejecutarse. • Se define quienes serán los responsables de ejecutar y en que periodo de tiempo.
Evaluación crítica de software • La evaluación critica de software se realiza al principio del proyecto al definir las especificaciones del sistema y se evalúa lo siguiente: – – – –
GxP GAMP software categoría Seguridad y ambiental Parámetros críticos de PCS
• El propósito es para definir al funcionalidad del software y como afecta los parámetros de la manufactura.
Elementos de validación especificos de los sistemas de control de proceso • Desarrollo de Software GAMP categoría 5 • Ciclo de vida del desarrollo del Software (Aplicación del sistema) – Requerimientos – Diseño – Pruebas Internas del desarrollo • Pruebas estaticas • Pruebas Dinamicas
– Pruebas Funcionales de desarrollo
Calibracion • Desarrollar inventario de instrumentación y equipo del PCS que necesitan calibración • Usar los procedimientos internos de calibración o mantenimientos para instrumentación/equipo ya en la planta. Crearlo para los nuevos. • Plan de mantenimiento actualizado y periódicos • Pruebas de calibración
Procesos • Los siguientes son procesos típicos en IT: – – – – – – – – – –
Manejo de Cambio Manejo de configuración Manejo de seguridad Manejo de problemas Ayuda técnica Resguardo y Recuperación Recuperación en caso de desastre (DRP) Monitoreo de Operaciones Manejo de suplidores Revisiones periódicas
Proceso y Personal • El personal debe tener definidos claramente sus roles y responsabilidades y estar documentados, y aprobados por la gerencia de la empresa. • La necesidad del personal se cuantifica por la cantidad de procesos a mantener, las areas de servicios dentro de IT, la candidad de servidores y redes, entre otros. • No se limita a contar con personal para: – – – –
gerencia administrativas por sistemas Calidad y cumplimiento Infraestructura física Especialistas de sistemas
Sistemas de administración de calidad (QMS) • Garantiza el estado de control y cumplimiento de IT. • Los siguientes elementos se necesitan para cumplir las metas del QMS. – – – – – – – – –
Manual de Calidad Definir Roles y Responsabilidades Manejo de archivo y data Manejo de documentación Documentación de pruebas Procedimientos operacionales Capacitación Periodos de evaluación y revisión del QMS Auditorias por QA
Aplicación del análisis de riesgo • El manejo de riesgo considera los siguientes pasos para el control de riesgo: (ver apéndice #2) – Análisis – Definir los limites de la infraestructura al impacto en el negocio y sus factores, para asignar prioridad a los riesgos. – Evaluación – Determinar cuales de los riesgo analizado serán aceptado y sus consecuencias. – Control – Determinar el plan de reducción del riesgo y como eliminar o minimizar el riesgo. – Revisión y evaluación continua – Determinar con que frecuencia se evaluara el riesgo a los sistemas seleccionados durante su vida.
Calificación de plataformas •
• • •
Si la plataforma es única de una aplicación se valida como parte de la aplicación. Se define si la plataforma es GxP. Se define las categorías de sus elementos. Se definen los componentes críticos para someterlos a análisis de riesgo.
• •
Se crea un plan de proyecto para el sistema de IT a calificar Se define una estrategia en este plan donde establezca las distintas actividades de considerar durante las fases de un ciclo de vida regular.
Consideraciones de diseño • • • • • • • • • •
Certificaciones de Cables de la red Calificación de los Servidores y certificaciones Calificación de los Clientes (PC) Verificación de Comunicación Monitoreo de la Comunicación Dibujos de la Red Topología de la red GxP vs, Non GxP Protocolos de comunicación Sistemas de Almacenamientos de datos Procedimientos
Procuramiento e instalación • Los componentes de las plataforma y sus servicios son identificados como de calidad por los suplidores. • El suplidor es quien conoce y puede demostrar el nivel de calidad, el servicio efectivo y los riesgos asociados en caso de falla de la plataforma. • Realizar un FAT de la plataforma y sus componentes antes de llevar al lugar final. • Una vez la plataforma se recibe se debe: – Verificar la orden de compra y sus elementos – Almacenar en un lugar apropiado de acuerdo a las especificaciones del equipo. – Evaluar una prueba de encender y apagar el equipo.
Evaluación del Suplidor • La compañía debe utilizar el programa de evaluación del suplidor. • El suplidor debe ser evaluado antes de ser seleccionado para determinar: – Aprobado – Aprobado condicionalmente – No Aprobado
• Si la plataforma es GxP, QA debe intervenir desde el principio de la evaluación al suplidor y establecer un plan y documentar los resultados.
Documentación necesaria • • • • • • • • • • •
Especificaciones de diseño Descripción de hardware y software Manuales de operación Manuales técnicos SOPs Topología de la red Diagramas lógicos de la red Sistema de etiquetaje Lista de cables Lista de direcciones lógicas Documentación del suplidor incluyendo la evaluación y sus programas de calidad
Condiciones ambientales • Se verifican las condiciones ambientales para garantizar que la plataforma pueda trabajar adecuadamente según las especificaciones ambientales sugeridas por el suplidor. – Temperatura y humedad – Eléctricas – Conexiones de cables
Servidores • • •
Se verifica la configuración de los componentes de software y hardware del servidor de acuerdo a las especificaciones de diseño aprobadas. Se prepara un CIL (lista de configuraciones requeridas para los servidores), para así ser usada cuando se instale otro servidor nuevo. Hardware CIL – – – – –
•
Modelo y marca Tipo y cantidad de memoria Números de CPUs y discos Controles de discos Información para reconstruir el servidor
Software CIL – – – – –
Sistema Operativo (OS) Programas de comunicación Programas de remediación de otros software (“patches, services packs”) Controles de acceso (seguridad) Configuraciones de la red
Redes • Red física; Verificación: – – – –
De cables y sus certificaciones Factores ambientales Estándares de conexión Configuración de los componentes de comunicación y conexión
• Red lógica; Verificación: – De la configuración del sistema de manejo de la red – Protocolos de comunicación (SNMP para TCP/IP) – Cumplimiento de las especificaciones de la red
Reportes y entregas • Reporte se documentan los resultados de cada actividad del IQ y el OQ. • Puede ser uno o mas reporte de acuerdo a la estrategia utilizada de validación. • Aprobar el reporte • La entrega de la plataforma debe realizarse cuando su Calificación este completada en reporte, al igual que los reporte de la validación de otras aplicaciones de la plataforma.
Entrega para Red en vivo • Se debe realizar una ejecución en paralelo antes de cortar la plataforma vigente por la nueva cualificada. • Este proceso debe llevarse a cabo por un plan, donde se establezca el periodo la data a usarse y la migración de la data ya validada. • Esta etapa de entrega es la mas critica y la de mayor tiempo.
Sistemas Globales • Definir un sistema global – Sistema de información que su requerimientos, procesos y estándares son definidos en la compañía para uso global (mas de un lugar) bajo las misma especificaciones y/o especificaciones locales. Son definidos y estructurados como centralizados y/o distribuidos.
Consideraciones en la administración del proyecto • Organización de proyecto global – Jerarquía de proyecto global con representates por localidades.
• Efectividad del manejo de proyecto. – Gerente de proyecto global • Gerentes locales
– – – – – – – –
Elemento de manejo globales y estándares Elementos de manejo locales y estándares Diversidad cultural Aspectos regulatorios globales y locales Planificación del manejo de data Arquitectura del sistema Procedimientos Fondos y gastos
Planeación de la administración de datos • • • • • • • • • •
Crear estadandares de manejo de dato globales Establecer y conocer los aspectos regulatorios globales y locales que afecten el manejo de dato. Aplicar a nivel local regulaciones globales del manejo de datos (Ex. Parte 11). Definir Roles y responsabilidades. Definir objetivos. Definir estrategias y metodologías. Definir la necesidad de la data por regiones y localidades. Definir requisitos de la administración de la data y las herramientas a utilizarse desde el concepto de las aplicaciones de manejo y administración hasta el almacenamiento. Definir el modelo de dato y la base de datos. Definir y considerar aspectos legales del manejo de la data.
Requisitos especificos de usuarios (URS) para el ciclo de vida de la data •
Estos requisitos de el ciclo de vida de la data deben definirse en el URS. – – – – – – – – – – – – – – –
Creación y/o migración Definiciones de meta data Validación y/o verificación Políticas para creación y eliminación o modificación de dato. Obtener y usar la data Autoridad de la data Dueño de data Técnicas de acceso de datos Manejo de copia de dato Control de versión de dato Almacenaje y/o migración Arquitectura de dato central o distribuida Definición de data critica Definir todos los elementos de datos y enlaces en sus elementos Auditoria de datos
Políticas, estándares, guías • Definir el uso de la data y su calidad requerida. • Crear políticas, guías o estándares específicos combinados con los existentes por agencias y/o instituciones. • Crear capacitación para la aplicación de estas políticas, guías y estándares
Base de Datos y Modelo de dato • Administrador de datos debe: – Control de calidad del modelo de data global o local. – Mantener consistencia de administración y sus herramientas a nivel global o local. – Mantener estabilidad, seguridad, coherencia en la data a nivel global y local. – Manejo de copia de datos – Infraestructura controlada
Arquitectura del Sistema • Definir la aplicación de la data a nivel global y/o local • Definir la centralizacion y/o distribucin de la data. • Definir sistemas centralizados y/o distribuidos.
Ventajas y Desventajas de Sistemas Centralizados • Ventajas: – Fácil manejo de cambio – Fácil aplicación de estándares – Fácil análisis de sistema – Fácil implementación de seguridad.
• Desventajas: – Difícil determinar fallas o errores de datos. – Potencial impacto de cambio
Ventajas y desventajas de sistemas distribuidos • Ventajas: – Incrementas el mantener las aplicaciones con sus últimos cambios al día. – Acceso a compartir recursos. – Mayor reproducibilidad de la data. – Fácil de implementar aspectos locales de leyes sobre datos, aspectos regulatorio.
• Desventajas: – Difícil de probar y manejar fallas. – Difícil de incorporar mejoras y controlar cambios. – Aspectos de seguridad mas complejos. – Sincronización de tiempo. – Incompatibilidad de infraestructura de redes y sistemas.
Administración • Administrar ayuda de Infraestructura: – Definir y considerar “Help Desk” local. – Definir y considerar “Help Desk” global.
• Administrar planes de recuperación en casos de desastres para la continuidad del negocio. – El plan se debe de retar (hacer pruebas) una vez terminado y aprobado. – Capacitación sobre los que implementaran el plan – Tomar en cuenta consideraciones globales y locales a la hora de desarrollar el plan.
Ambiente • El desarrollo, pruebas, y ambiente de producción y su sincronización y relación es mas complejo cuando se tiene disponible para sistemas globales. Por esta razón consideramos lo siguiente: – El nivel de programación de localidad especifica del software. – Manejar el ambiente de producción y sus similitudes. – Coordinar y manejar el ambiente de prueba en el ambiente de producción. – Establecer procesos de control que ayudan a resolver problemas potenciales de comunicación entre el software global y el local en la interacción de los mismos en momentos de pruebas en paralelos.
Plan de desempeño y capacidad • Los requisitos de desempeño debe establecer el tiempo de respuesta adecuado del sistema global en la localidad donde se efectúa el proceso. Esto se debe de retar (probar). • Definir, especificar cada aspecto de mejora del sistema global su infraestructura sus aplicaciones y como afecta al proceso local. • Definir requisitos de licencias.
Validación y establecimiento • Aspectos a tomar en consideración a la validación e implementación de sistemas globales de información; – – – – – – –
Propietario del sistema Plan de validación URS Manejo de riesgo SDS, revisión del diseño y manejo de rastreo Pruebas Reportes
Propietario del sistema • Definir el dueño del Sistema – Sistemas globales centralizados – Sistemas locales
• Definir el grupo dueño del sistema – Sistemas globales distribuidos
• Definir roles y responsabilidades en ambos casos • Responsables de mantener el sistema validado, y en cumplimiento de ley.
Plan de validación • Definir calendario de actividades • Definir roles y responsabilidades • Definir estrategias de validación basadas en categorías y definiciones de sistemas o su complejidad. • Revisar los aspectos de: – – – –
Cultura Regulatorios locales Arquitectura de sistemas y bases de datos Procedimientos
• Definir su administracion – Local – Global
URS • Definir el alcance del sistema en la unidad de negocio. • Definir los requisitos de datos del sistema • Definir especificaciones funcionales globales compartidas y especificas de la localidad. • Definir los requisitos basados en el proceso de negocio y su necesidad. • Definir seguridad de los sistemas de forma global y local.
Manejo de Riesgo • Será definido en el plan de validacion • Se definirá en que etapa realizarse y con que frecuencia • Se utilizara una guía de manejo de riesgo • Se realizara independientemente de los aspectos globales como de los aspectos locales
Administración de la rastreabilidad ™ • Mantener rastreo por separado de los requisitos globales y los locales. • El TM puede separarse por documentos de acuerdo a los requisitos ya establecidos por el proceso, redes, aplicaciones, aspectos funcionales y/o sub-sistemas. • Definir el plan de cómo mantener el TM a través de la vida útil del sistema global. • Ver ejemplo pag. 3.1 de la guía de SGI
Seguridad del sistema • Establecer procedimiento de la seguridad del sistema para usuarios globales y locales • Establecer la metodología de cambio de la seguridad del sistema. • Definir los roles y responsabilidades del administrador del sistema en aspectos de seguridad en la red, aplicaciones, bases de datos, infraestructura y servicios externos. • Definir la seguridad física en los sistemas distribuidos o centralizados.
Respaldos y recuperaciones • Establecer un procedimiento de resguardo y recuperación global y local. • Definir la política a seguir • Definir los aspectos regulatorios de de ley de la localidad que afecten las medidas de resguardo y recuperación de data. • Definir la frecuencia con que se debe verificar estos procedimientos. • Definir la estructura de resguardo en la infraestructura del sistema global.
Conceptos claves • • • • • • • •
ERES – “Electronic Records Electronic Signature” Archivos electrónicos - Conjunto de caracteres, resultado de una acción procesada, almacenado en un medio durable. Se puede manipular para ser modificado o eliminado de su medio de almacenamiento. Firmas electrónicas – Componente único de la combinación de usuario y su contraseña con el propósito de verificar, revisar y aprobar. Riesgos – Danos a los recursos (personas, equipo, utilidades, ambiente) “Audit Trail” – Sistema de rastreo electrónico donde se registra el cambio al archivo, la fecha de cambio y la hora, el tipo de cambio y quien realizo el cambio. “Legacy System” – Sistemas implementados y en operación antes de 1997 a ser aplicado la regulación 21 CFR parte 11. Septiembre del 2003 – FDA publica su nueva interpretación de la implementación de 21 CFR part 11. Sistemas Híbridos – Sistemas que contienen archivos electrónicos pero no almacenan en un medio durable la información ni registran firmas electrónicas.
Riesgos en registros electronicos • Identificar y manejar los riesgos: – Identificar los archivos electrónicos GxP y las firmas electrónicas GxP. • Iniciar un inventario de todos los sistemas, sus archivos, sus firmas electrónicas y su aplicabilidad en GxP.
– Determinar el impacto a través de la calidad del producto y la seguridad del paciente • Como impacta ese archivo la calidad del producto y la seguridad del paciente.
Evaluación de Impacto a ER • Archivos de Impacto directo – Archivos usados para dar alza a un producto – Archivos que registran eventos.
• Archivos de Impacto medio – Archivos usados como evidencia de algun informe regulatorio, registros de capacitacion, documentos de validación.
• Archivos de Impacto bajo – Registros de mantenimineto de equipo y calibracion, registros de alarmas.
• Ver ejemplos pag. 17 a 19.
Evaluación del Sistema • El riesgo debe evaluarse de acuerdo al proceso que se realice en la planta y por el sistema. • Sistemas con contacto directo a la calidad del producto o la seguridad del paciente producen registros de impacto. – Estos son sistemas críticos.
Peligros • Los peligros deben ser identificados con prioridad al diseño, para establecer remediaciones. • Los peligros se clasifican como: – Relacionados a personas – Relacionados a computadoras – Relacionados al ambiente o físicos
• Los peligros asociados a registros y firmas en sus consecuencia es perdida parcial (corrupta) o completa del registro o firma.
Rigor de los controles • Eliminar los peligros – – – –
Por modificación de proceso Diseño Técnicas de control Procedimiento
• Establecer medidas de control rastreables • Identificar sistemas automatizados para eliminar los peligros a la perdida de dato o corrupción de data • Implementar sistemas de seguridad y resguardo de datos validados y periódicamente evaluados en estos fines.
Registros híbridos • Registros que pueden mantenerse electrónicamente y su firma es a manuscrito • Registros producidos por medios electrónicos con firmas electrónicas pero se mantiene de forma de papel. • Los registros híbridos se deben evaluar por la intención de uso del registro y cual representaría la forma oficial y legal, el impreso o el electrónico.
