Registro de eventos del sistema clínico: qué se guarda y para qué

1. Qué es un evento del sistema

Este artículo trata los eventos del sistema clínico en sentido amplio. Los accesos a la historia clínica —quién abre el expediente de qué paciente— viven aparte en trazabilidad de accesos internos. Aquí se decide qué otros eventos del sistema se registran y para qué sirven.

1.1. La operación técnica del sistema, no del contenido

Los eventos del sistema son operaciones técnicas del propio funcionamiento: inicios de sesión, cambios de configuración, errores devueltos por la aplicación, operaciones de administración, actividad de servicios internos. No son operaciones sobre el contenido clínico del expediente sino sobre el propio sistema que lo aloja.

1.2. La granularidad técnica

Cada evento se registra con la información técnica que permite reconstruir después la operación: fecha y hora exactas con precisión mínima al segundo, identificador único del evento, componente del sistema que lo generó, usuario responsable cuando aplique, contexto técnico relevante. La granularidad es distinta de la del registro de accesos y sirve a fines distintos.

1.3. Lo que este artículo no cubre

Este artículo no ofrece asesoría técnica sobre configuración concreta ni sustituye la valoración del responsable técnico. Cuenta qué se guarda en el registro de eventos y para qué sirve. La decisión sobre la política concreta de retención y uso corresponde al centro con asesoramiento cualificado.

2. Los cuatro tipos que se guardan

El registro de eventos del sistema clínico incorpora cuatro tipos principales de evento. Cada tipo cumple una función distinta y su granularidad se ajusta al uso previsto del propio tipo.

2.1. Eventos de autenticación

Inicio y cierre de sesión de cada usuario del sistema, intentos fallidos de autenticación, bloqueo de cuentas por intentos repetidos, cambio de contraseña, acceso desde dispositivo o ubicación no habitual. Los eventos de autenticación son la primera línea de detección de accesos anómalos al propio sistema clínico.

2.2. Eventos de configuración y administración

Cambios en la configuración del sistema, alta y baja de usuarios, modificación de roles y permisos, activación o desactivación de módulos, cambios en la política de acceso, actualizaciones del sistema. Los eventos de administración son la trazabilidad de las decisiones técnicas del centro sobre el propio sistema.

2.3. Eventos de error de la aplicación

Errores devueltos por la aplicación durante su operación normal, fallos de proceso interno, incidencias de rendimiento significativas, alertas técnicas generadas por el propio sistema. Los eventos de error orientan la investigación de incidencias técnicas y sostienen la mejora continua del sistema.

2.4. Eventos de operación de servicios internos

Actividad de servicios automatizados —copias periódicas ejecutadas por la infraestructura, sincronización con sistemas externos, procesos programados—, con la fecha, la duración y el resultado de cada ejecución. Los eventos de servicios sostienen el propio funcionamiento continuado del sistema.

3. Retención del registro

El registro de eventos se conserva durante plazo específico definido por la política del centro. La retención de este registro es distinta de la retención del expediente clínico y puede aplicar plazos más cortos o más largos según la naturaleza del evento.

3.1. La retención por tipo de evento

Los eventos de autenticación y de acceso se conservan durante plazo alineado con la política de seguridad del centro, típicamente varios años para responder a investigaciones posteriores. Los eventos de error de la aplicación pueden conservarse durante plazo más corto —meses en lugar de años— salvo cuando corresponden a incidencias con implicación específica que exige conservación prolongada.

3.2. La rotación de registros antiguos

Los registros antiguos se rotan a almacenamiento de menor coste sin salir del sistema, para mantener la accesibilidad reduciendo el coste operativo. La rotación es transparente para el uso y no compromete la disponibilidad ante requerimiento posterior.

3.3. La destrucción al agotar el plazo

Al agotar el plazo aplicable, el registro se destruye con las mismas garantías técnicas que cualquier otro dato del sistema, con constancia del acto de destrucción. La destrucción prematura antes de agotar el plazo compromete la capacidad de investigación posterior y expone al centro cuando aparece requerimiento específico sobre eventos antiguos.

4. Volcado para auditoría

La entrega ante requerimiento externo se prepara con huella criptográfica y sello de tiempo cualificado.

El registro de eventos puede exportarse para auditoría externa o para investigación forense específica. El volcado se ejecuta con las medidas técnicas correspondientes a la sensibilidad del contenido incluido.

4.1. La exportación para auditoría interna

La dirección clínica puede solicitar exportación periódica de los eventos del sistema para revisión interna. La exportación se ejecuta en formato estructurado que permita el análisis posterior con herramientas específicas y queda registrada como acto del propio sistema.

4.2. La entrega ante requerimiento externo

Cuando aparece requerimiento de la AEPD, judicial o de auditor cualificado externo, la entrega del registro se prepara con el alcance específico solicitado. La política del centro sobre volcado ante requerimientos externos define el procedimiento operativo y las autorizaciones necesarias, tratado en auditoría RGPD para clínicas.

4.3. La cadena de custodia del volcado

El volcado se prepara con cadena de custodia técnica —huella criptográfica del propio volcado, sello de tiempo, identificación del responsable que lo preparó— para que el receptor pueda verificar posteriormente que la entrega corresponde con el original del sistema en el momento del volcado.

5. Qué NO se guarda aquí

El registro de eventos del sistema tiene su propio alcance y no incluye lo que ya vive en otras trazabilidades específicas del propio sistema. La delimitación es importante para evitar duplicación y confusión sobre qué registro consulta qué información.

5.1. Los accesos al expediente clínico van al otro registro

Cuando un profesional abre la historia clínica de un paciente concreto, ese acceso se registra en el propio registro de accesos internos a la historia clínica, no en el registro general de eventos del sistema. La distinción es de arquitectura: cada registro cumple su función específica y la consulta se hace en el registro correspondiente según lo que se busque.

5.2. Las modificaciones del dato clínico van al histórico del dato

Cuando el profesional modifica el contenido del expediente —corrige una anotación, actualiza un dato clínico, retira una entrada anterior— la modificación se registra en el histórico específico del propio dato del expediente, no en el registro de eventos del sistema. La trazabilidad del contenido clínico vive integrada en el propio expediente con las medidas de integridad correspondientes.

5.3. La consulta cruzada cuando corresponde

En investigación posterior sobre un incidente concreto, los tres registros —accesos al expediente, histórico del dato, eventos del sistema— pueden consultarse cruzadamente para reconstruir la secuencia completa del propio caso. La política del centro sobre acceso a los distintos registros define quién puede consultar cada uno y en qué condiciones.

6. Uso en investigación forense

El registro de eventos del sistema aporta información técnica imprescindible en cualquier investigación forense sobre incidente que afecte al propio sistema clínico. Su valor real aparece cuando la investigación necesita reconstruir la secuencia técnica del propio incidente.

6.1. La reconstrucción cronológica del incidente

Cuando aparece un incidente técnico —caída del sistema, comportamiento anómalo de la aplicación, patrón sospechoso de autenticación— la investigación forense reconstruye la secuencia cronológica desde los eventos del sistema con el detalle suficiente para identificar la causa técnica del propio incidente.

6.2. La correlación con el registro de accesos

Cuando el incidente puede tener implicación sobre accesos indebidos al expediente clínico, la investigación forense combina los eventos del sistema con la propia trazabilidad de accesos, cada registro aportando la parte que le corresponde de la reconstrucción. La combinación de ambos registros es la que permite responder preguntas complejas sobre el propio incidente.

6.3. La preservación durante la investigación

Durante una investigación forense abierta, el registro de eventos correspondientes al periodo del incidente se preserva con medidas específicas para evitar cualquier alteración posterior. La preservación forense forma parte del propio proceso de investigación y su documentación es parte de la cadena de custodia del propio análisis.

7. Anonimización del propio registro

El registro de eventos del sistema contiene información técnica que puede incluir datos personales de usuarios del propio sistema —profesionales del centro identificados en cada evento—. La política de anonimización del registro para determinados usos secundarios protege también estos datos.

7.1. Los datos personales dentro del registro

Los eventos incluyen habitualmente identificador del usuario responsable —profesional que inició sesión, administrador que cambió configuración—. Esa información es dato personal del propio profesional y su tratamiento en el registro está sujeto al RGPD igual que el resto de datos personales del sistema.

7.2. La anonimización para análisis agregado

Cuando el registro se usa para análisis estadístico agregado —patrones de uso del sistema, indicadores de rendimiento por franja horaria, tendencias de tipos de evento—, la anonimización previa protege la identidad individual de los profesionales y permite el análisis sin exposición innecesaria. La operativa técnica se apoya en los principios generales del propio registro operativo, tratados en registrar tratamiento sin identificar al paciente.

7.3. La conservación identificada para uso forense

Para investigación forense específica, la conservación identificada del registro es imprescindible porque la reconstrucción del incidente exige saber quién hizo cada operación. La coexistencia entre versión identificada para uso forense y versión anonimizada para análisis agregado es la operativa habitual en centros con volumen relevante de eventos.

8. Trazabilidad legal

El registro de eventos del sistema es evidencia técnica ante requerimientos posteriores y forma parte del despliegue de cumplimiento del centro. Su documentación es requisito propio del artículo 32 del RGPD sobre seguridad del tratamiento.

8.1. La disponibilidad ante requerimiento

El registro es accesible ante requerimiento de la AEPD, de la autoridad judicial y de auditor cualificado externo cuando corresponda. La entrega se prepara con el alcance específico solicitado y con las medidas de cadena de custodia correspondientes para preservar la validez de la evidencia.

8.2. La responsabilidad compartida centro-proveedor

La responsabilidad de mantener el registro de eventos correctamente configurado y accesible recae en el centro como responsable del tratamiento, con las obligaciones específicas del proveedor de la infraestructura como encargado. La distribución de responsabilidades se acredita con el contrato de encargo firmado, tratado en contrato de encargado del tratamiento.

8.3. La sanción por ausencia del registro

La ausencia de registro de eventos o su configuración manifiestamente insuficiente es incumplimiento del artículo 32 del RGPD sancionable con arreglo al régimen del artículo 83. La AEPD detecta esta ausencia con relativa facilidad en cualquier inspección seria del despliegue del cumplimiento del centro.

9. Qué aporta obeliOmed

Acceso al propio registro restringido a personas específicas. Cada consulta queda registrada a su vez.

Para que el registro de eventos del sistema cumpla su función técnica, el sistema tiene que capturar los cuatro tipos de evento con la granularidad adecuada, conservarlos durante el plazo definido por la política del centro y facilitar el volcado ante requerimiento con la cadena de custodia correspondiente.

9.1. Los cuatro tipos capturados de serie

En obeliOmed el sistema captura eventos de autenticación, de configuración y administración, de error de la aplicación y de operación de servicios internos con la granularidad técnica adecuada al uso previsto. La retención se configura por tipo según la política del centro. El volcado ante requerimiento se ejecuta con huella criptográfica y sello de tiempo cualificado. La distinción entre este registro y el registro de accesos internos a la historia clínica se mantiene por arquitectura: cada uno cumple su función específica y la consulta se hace en el registro correspondiente según lo que se busque. La responsabilidad de la política de retención y de acceso al registro sigue siendo del centro; lo que el sistema aporta es no dejar a la clínica sin la infraestructura técnica para capturar, conservar y volcar cuando corresponde.

9.2. Con qué se combina

El registro de eventos forma parte del despliegue de seguridad técnica del centro, sostenido por el pilar del cumplimiento del RGPD en RGPD en clínicas privadas.