LIMS con automatización de procesos para Laboratorios Microal

El cliente

Laboratorios Microal es un laboratorio de ensayo acreditado de Sevilla. Sus analistas procesan muestras de alimentos, aguas y medioambiente contra un catálogo de 601 métodos analíticos que cubren 3.524 parámetros, con 1.511 equipos, para 1.134 clientes.

El laboratorio ya tenía un LIMS comercial. Lo que no tenía era nada que gestionase el trabajo: qué muestras estaban pendientes, quién las estaba haciendo, qué botes se habían preparado, qué posición del digestor ocupaba cada muestra, qué controles de calidad exigía el método y si habían pasado. Esa capa vivía en hojas de trabajo en papel, en hojas de cálculo y en la memoria de quien llevaba cada línea.

El Sistema MICROAL cierra ese hueco. Recoge cada muestra del LIMS automáticamente, convierte los análisis pendientes en trabajo asignable, guía al técnico por la preparación y la lectura, impone el régimen de control de calidad que exige el método, aplica los cálculos y devuelve los resultados validados al LIMS sin que nadie vuelva a teclear un número.

Que la sincronización se pueda creer

Dos decisiones de ingeniería marcan la diferencia entre una sincronización fiable y una que no lo es.

La primera: la importación nunca borra trabajo pendiente. Un planteamiento anterior deducía que «si la muestra no está en la lista de pendientes del LIMS, el LIMS la ha cerrado». El equipo midió esa inferencia y resultó falsa, porque el endpoint devuelve lo que se recibió ese día, no lo que está pendiente. Ahora el trabajo se marca como resuelto, nunca se elimina.

La segunda: la ingesta es idempotente y corre bajo bloqueo, de modo que el proceso nocturno y un «sincronizar ahora» manual no pueden chocar ni importar dos veces lo mismo.

Una sola definición de «pendiente»

Lo que hace correcta —y no solo cómoda— la pantalla de asignación es que hay una única definición compartida de qué significa «queda por hacer». Una línea de lectura está viva solo si se cumplen las tres condiciones:

1. El LIMS todavía no tiene resultado para ella (una fila vacía de relleno no es un resultado).
2. No se ha bloqueado internamente.
3. La sincronización de entrada no la ha marcado como completada.

Esa definición vive en un único sitio del código y la comparten la pantalla de asignación, la rejilla de preparativa y el movimiento de «método madre». Antes estaba escrita dos veces y las dos copias habían divergido, que es como tres pantallas acaban discrepando sobre la misma muestra.

La asignación, además, se niega a crear trabajo que no se puede hacer: la comprobación de capacidad conoce cuántas posiciones tiene cada digestor y no deja montar una hoja que no vaya a caber en el poyete.

El registro primario, el documento regulado

Un registro primario es el documento controlado de un lote de trabajo. Abrir uno enseña cuánto rigor metrológico carga el sistema: el analista y la fecha, el equipo elegido del catálogo con su número de serie y su número de posiciones, un recuento de muestras que incluye explícitamente los controles de calidad —porque un control ocupa una posición física igual que una muestra—, un campo de observaciones del responsable cuyo marcador de texto dice para qué es («justifique por escrito, p. ej., la aceptación de un registro con QC ausente o fallido») y el control de temperatura de digestión.

Ese último merece atención. Los límites de conformidad no son una banda fija: se calculan como 120 °C ± 2 con una corrección de +0,1903 tomada del certificado de calibración del termómetro concreto que se usa en el digestor concreto, lo que da 118,1903 – 122,1903 °C. El registro no se puede cerrar sin la temperatura, y la pantalla lo dice.

Un registro no se cierra en silencio con controles malos

El estado del registro primario lo decide un evaluador que reduce sus controles enlazados a una de tres señales: todos pasados, al menos uno fallado de forma definitiva o incompleto. Un fallo definitivo pesa más que los hermanos incompletos; es la opción conservadora. Los registros cerrados en modo automático con controles que no cumplen las proporciones exigidas por el método generan una alerta de QC persistida que aparece en la pantalla de validación.

Y donde el responsable decide aceptar un registro de todas formas, el sistema no se lo impide: le exige escribir por qué, que es exactamente lo que va a pedir un auditor.

La trazabilidad, de regalo

Cada registro primario lleva los equipos usados por número de serie, la posición que ocupó cada muestra, las pesadas, el analista, las marcas de tiempo y quién lo cerró y cuándo. Nada de eso es un formulario extra que rellenar: es el registro que el técnico ya estaba recorriendo.

Cómo trabajamos el código

Tres prácticas se ven por todo el repositorio:

• La documentación está en el código y recoge el porqué. Los módulos se abren con una explicación de la decisión que codifican y, a menudo, de la medición que la zanjó, incluidos los casos en que se puso a prueba una suposición anterior y resultó falsa. Es lo que permite que una regla sobreviva a quien la escribió.
• Toda ruta de la API exige sesión autenticada. Los routers se montan detrás de una única dependencia de sesión, con cuatro endpoints públicos deliberados (login, logout, raíz y comprobación de salud). Un test recorre la tabla de rutas viva y falla si alguna es alcanzable sin sesión, y un segundo test comprueba que ese recorrido sigue viendo las cuatro públicas, para que la comprobación no pueda dejar de comprobar sin que nadie se entere.
• Los cambios se revisan contra una copia viva de producción. Cada pull request se monta junto a las demás en un entorno de integración, sus migraciones se ensayan contra una copia fresca de la base de datos de producción y se verifican por valor —filas tocadas, filas que quedan pendientes, filas fuera de alcance— antes de que nada llegue al laboratorio.

Dónde está el proyecto

La plataforma está en producción y en uso diario para la entrada de muestras, los catálogos de métodos y equipos, la preparativa y la asignación de trabajo. Los módulos de ejecución y control de calidad están desplegados y se adoptan línea a línea según el laboratorio va sacando cada una del papel.

El desarrollo continúa con cadencia semanal, con los cambios llegando a producción por una tubería de pull requests revisados y un camino de migración ensayado.