Cuando ningún sistema comercial encaja, lo construimos con usted.
Señales de que un desarrollo a la medida es el camino
Del problema al requerimiento
Usted detecta una necesidad
Un proceso que ningún sistema comercial resuelve, o que hoy se sostiene con hojas de cálculo y no resistiría una auditoría. Nos escribe y agendamos una primera reunión.
Entregable · Reunión de diagnóstico
Nos reunimos con quien opera el proceso
No con un intermediario: con las personas que capturan, revisan y firman. Recorremos el proceso tal como ocurre, con sus excepciones y sus registros reales.
Entregable · Mapa del proceso y de los datos
Analizamos y evaluamos el riesgo
Determinamos qué partes del proceso tienen impacto GxP y cuáles no. Ese análisis decide el alcance del sistema y, sobre todo, cuánta verificación exige cada función.
Entregable · Análisis de riesgos y alcance
Definimos los requerimientos de usuario
Escribimos qué debe lograr el sistema, en el lenguaje de quien lo usa y con criterios que se puedan probar. Usted la revisa y la aprueba antes de que exista una línea de código.
Entregable · URS aprobada por usted
La URS aprobada es la bisagra del proyecto: nada se construye antes de tenerla, y todo lo que viene después se rastrea hasta ella.
Qué implica que el software sea validable
Categoría 5 de GAMP 5
Un desarrollo a la medida es la categoría más exigente de la guía: al ser único, no hay historial de proveedor en el que apoyarse. Se documenta y se verifica el ciclo de vida completo.
Enfoque basado en riesgo
La guía no pide probarlo todo con la misma profundidad, sino concentrar el esfuerzo donde el impacto en la calidad del producto, la seguridad del paciente y la integridad de los datos es real.
21 CFR Parte 11 y ALCOA+
Firmas y registros electrónicos, rastro de auditoría y control de acceso se construyen desde el primer día. Añadirlos después obliga a rehacer el sistema y su documentación.
Trazabilidad de punta a punta
Una matriz liga cada requerimiento con la especificación que lo desarrolla y con la prueba que lo demuestra. Es lo que permite responder, en una auditoría, por qué el sistema hace lo que hace.
De los requerimientos a la evidencia
Especificación
Verificación
Qué debe lograr el sistema en su operación, escrito por y para quien lo usa.
Demuestra que el sistema cumple esos requerimientos en producción, con sus datos, sus usuarios y sus procedimientos.
Qué hace el sistema para cumplir cada requerimiento: funciones, reglas de negocio, cálculos y perfiles de acceso.
Demuestra que cada función opera como se especificó, incluidos los límites del rango de trabajo y los casos de error.
Cómo se construye: arquitectura, modelo de datos, interfaces con otros sistemas y requisitos de la plataforma.
Demuestra que el sistema quedó instalado y configurado conforme al diseño, en el entorno real donde va a operar.
Revisión documentada de que el diseño propuesto satisface la URS. Cierra la rama de especificación antes de empezar a construir.
Construcción, revisión de código y pruebas unitarias, con control de versiones
El paquete documental completo
Mantener el estado validado
Control de cambios
Toda modificación se evalúa por su impacto, se documenta y se vuelve a verificar en la medida que ese impacto exige.
Revisión periódica
Se revisa que el sistema siga haciendo lo que su documentación dice, y que la documentación siga describiendo al sistema.
Mantenimiento del estado validado
Soporte funcional y acompañamiento a lo largo del ciclo de vida, para que el sistema llegue a la siguiente auditoría en regla.
¿Tiene un proceso que ningún sistema resuelve?
Cuéntenos su reto. La primera reunión sirve para entender el proceso y decirle con franqueza si necesita un desarrollo a la medida o le basta con uno de nuestros sistemas.