Sincronización horaria de instrumentos: cronología y audit trail

Una adquisición parece posterior a su revisión. Una inyección parece anterior a la que figura primero en la secuencia. Antes de concluir que alguien modificó los datos, hay que entender qué miden los relojes implicados y cómo presentan el tiempo los sistemas.

La cronología del laboratorio atraviesa instrumentos, estaciones de trabajo, aplicaciones, bases de datos e interfaces. Dos marcas temporales distintas pueden describir un mismo instante en zonas diferentes o eventos distintos, como adquisición y recepción. El objetivo es una secuencia verificable que preserve datos originales, contexto e incertidumbre residual.

1. Identificar quién genera cada marca temporal

Para cada evento relevante, identificar el sistema que asigna fecha y hora. El software puede utilizar el reloj del sistema operativo, el del instrumento o un servicio centralizado: comprobarlo forma parte del conocimiento del sistema. La base de datos puede registrar otro momento, distinto del evento científico.

Distinguir inicio de adquisición, guardado, recepción en la interfaz, importación, procesamiento y aprobación. La fecha de modificación de un archivo no demuestra por sí sola cuándo se analizó la muestra. Un retraso de transmisión no implica necesariamente una desviación del reloj.

La conciliación entre instrumento y LIMS debe preservar también este significado: una columna llamada «fecha» no identifica por sí sola el evento representado.

2. Separar instante, zona y visualización

UTC proporciona una referencia común. La hora local requiere su desfase respecto a UTC y, cuando corresponda, las reglas de zona aplicadas. «02:30» sin fecha ni contexto puede ser ambiguo, especialmente al finalizar el horario de verano.

Almacenar en UTC y mostrar hora local son decisiones técnicas que deben verificarse en el producto. No suponer que la hora mostrada coincide con la almacenada. Comprobar pantallas, exportaciones y audit trail, incluidos signo del desfase, precisión y fracciones de segundo. El formato debe preservar el significado durante las transferencias.

RFC 3339 describe el desfase como hora local menos UTC. Para obtener UTC se resta el desfase indicado. Ordenar las marcas alfabéticamente no garantiza su orden cronológico cuando difieren representaciones o desfases. Las reglas de las zonas cambian: identificar también las dependencias de la base de datos horaria utilizada.

3. Construir el mapa temporal

Esta matriz es un ejemplo de investigación, no una arquitectura prescrita. Completarla con comportamiento documentado y evidencia observada. Aclarar los campos desconocidos antes de apoyar una decisión crítica en esa marca temporal.

Definir quién mantiene este mapa al sustituir estaciones, actualizar aplicaciones o cambiar interfaces. Una configuración válida del servidor no demuestra automáticamente la de cada dispositivo conectado.

4. Definir fuentes, criterios y pruebas

Establecer fuentes horarias autorizadas, responsabilidades de configuración y permisos de modificación. NTP distribuye una referencia temporal; usar el protocolo no demuestra por sí solo corrección, disponibilidad o protección de la configuración. Prever la observación de desviaciones y pérdidas de sincronización.

Los criterios dependen del proceso: resolver eventos muy próximos puede exigir una precisión distinta de la necesaria para registrar una revisión diaria. Justificar tolerancia, frecuencia de comparación y respuesta a alarmas según granularidad del dato, posible deriva y consecuencias. Aquí no se prescribe un umbral universal en segundos.

En un entorno separado y autorizado, probar pérdidas de fuente, recuperación de comunicación, cambios de zona y transiciones de horario pertinentes. Verificar que los eventos sigan siendo interpretables y las anomalías se detecten. Documentar condición probada, resultados esperados y observados, y excepciones; no modificar el reloj de producción para crear una prueba.

5. Caso simulado: la hora local parece retroceder

Supongamos un cambio de desfase en el mismo día: el evento A se registra a las 02:55 con +02:00; B a las 02:10 con +01:00. En UTC, A corresponde a 00:55 y B a 01:10. Por tanto, B ocurre 15 minutos después de A, aunque muestre una hora local anterior.

Para justificar esta reconstrucción hacen falta fecha completa, desfases realmente asociados a los eventos, identificadores, origen de los relojes y reglas de visualización. No basta saber que «por esas fechas cambia la hora». Si falta el desfase, conservar la ambigüedad y buscar evidencias independientes, como el orden de secuencia y registros relacionados, evaluando también su fiabilidad.

La conversión forma parte de la reconstrucción documentada; no sustituye las marcas originales. Una copia de trabajo normalizada debe identificar origen, transformación y vínculo con el registro conservado.

6. Gestionar anomalías sin reescribir el historial

Si se corrige un reloj, registrar valor anterior y nuevo, motivo, autorización e intervalo potencialmente afectado según el sistema y el procedimiento. Evaluar el impacto sobre secuencias, firmas, importaciones y resultados ya utilizados. Una corrección puede producir saltos o solapamientos aparentes: no «reparar» retrospectivamente los registros para que parezcan ordenados.

La revisión del audit trail en CDS debe distinguir error temporal, retraso del proceso y modificación real. Si el orden sigue siendo incierto, documentar esa limitación y la decisión sobre su impacto; evitar una cronología solo aparentemente precisa.

Fuentes y estado — verificación: 2 de octubre de 2026. Anexo 11 de las NCF UE, revisión de enero de 2011, §§9 y 12.4; 21 CFR Part 11, §11.10(e), dentro de su ámbito aplicable. Referencias técnicas sin imponer una configuración NCF universal: RFC 3339, julio de 2002, significado de los desfases; actualizado por RFC 9557; IANA Time Zone Database, recurso en línea; PTB, indicaciones técnicas NTP; NIST SP 800-53 Rev. 5, septiembre de 2020, actualización de diciembre de 2020, controles AU-8 y SC-45. Matriz y caso son ejemplos editoriales originales.