Contexto
Es frecuente que en un laboratorio haya gran variedad de instrumentos que cubran la complejidad de análisis a realizar. Las grandes marcas (Agilent, Waters, Qiagen …) han desarrollado carísimos programas que permiten tratar los datos que generan sus instrumentos. En el mejor de los casos también permiten la comunicación entre los instrumentos (siempre y cuando sean todos de la misma marca), por lo que los resultados obtenidos en uno de ellos sirvan para cumplimentar parte de los parámetros que necesita el otro para realizar en su análisis.
Generalmente este tipo de softwares son muy cerrados y las posibilidades de importación / exportación son bastante limitadas por lo que traspasar datos entre diferentes softwares se convertía en un problema que generaba más inconvenientes que ventajas. En el mejor de los casos, las marcas te ofrecían aplicaciones complementarias que permitían el traspaso de forma confiable, pero eran soluciones sólo validas con sus productos y bastante costosas.
Objetivos
Se pretendía cumplir los siguientes objetivos:
- Que permitiera el traspaso de los resultados de una manera homogénea para diferentes softwares (tanto de laboratorio como de otros ámbitos).
- Evitar errores de transcripción.
- Disminuir el tiempo en tareas repetitivas del personal de laboratorio.
- Trazabilidad de los resultados introducidos.
- Prueba de concepto. Si obteniamos los resultados esperados, podría servir de punto de partida para otros proyectos.
Requisitos
Aparte de cumplir con los objetivos, debía hacerlo de forma apropiada:
- Tenía que ser capaz de ingerir toda la información generada.
- Flexible para poder trabajar con los diferentes instrumentos de la empresa (no exclusivamente de laboratorio) y sobre aquellos de los que no se disponía de ningún software controlador.
- Fácilmente escalable tanto horizontal como vertical.
- Que garantizara la máxima trazabilidad y transparencia de los datos.
- Que consistiera en una solución abierta, que no implicara “atarse” con un proveedor concreto
- Dado que los resultados estaban validados antes de generar el fichero de exportación, una vez introducidos en el ERP, el análisis debía quedar cerrado y validado.
Implementación
Finalmente optamos por la implementación de una plataforma CDF (Cloudera Data Flow) que se basaba en los siguientes componentes principales:
- Sistema distribuido de ficheros (Apache Hadoop).
- ETL (Apache NiFi)
- Plataforma distribuida de transmisión / publicación de datos (Apache Kafka).
Por el lado del ERP decidimos que se debía recibir la información mediante un webservice que necesitan las menos datos posibles, ya que se iba a utilizar para ingerir datos desde diferentes softwares, de diferentes compañías del grupo con diferente mecanismos y grados de integración con el ERP:
- Los parámetros para identificar dónde debe escribir el resultado (identificador del plan de inspección, código de operación y identificador de muestra).
- El resultado en sí mismo.
- Meta-datos: Usuario, identificador de instrumento y fecha / hora.
Se configuró el software mayoritario en el laboratorio para exportar en un informe muy sencillo (archivo de texto) con estructuras lo más estándar posible. La plataforma monitorizaba unas carpetas concretas del servidor donde se dejaban los informes en busca de archivos nuevos cada pocos minutos. Dependiendo de la ubicación de estos archivos, la plataforma esperaba una estructura concreta y si coincidía extraía los datos y generaba la petición al webservice del ERP.
Para garantizar la trazabilidad, se configuró para que cada línea del archivo se tratara de forma separada de modo que, si una línea / resultado generaba un error, se siguiera procesando el resto del archivo. Por cada línea se guardaba la petición que se hacía en SAP y la respuesta obtenida. Así mismo, en caso de error se enviaba un e-mail a diferentes listas de distribución, dependiendo de si era un error “operativo” (archivo mal formateado, falta de datos …) o técnico (servicios caídos, error en la comunicación, errores inesperados …). En estos últimos casos, se configuró un flujo para reintentar automáticamente el envío durante cierto tiempo. Además a nivel de máquinas, toda la plataforma era monitorizada por Nagios.
Mi aportación
Primeramente me encargué de buscar plataformas que aparentemente cumplieran con los requisitos establecidos, de hacer un pequeño estudio con las ventajas, inconvenientes y los casos en los que se suele implementar cada una de ellas. De la solución que recomendaba, se incluía la descripción de los componentes que la podrían formar y un esquema de la interacción entre ellos.
Una vez validada la opción recomendada con el equipo, me encargué de facilitar una lista de posibles proveedores y mi opinión (basándome en la información encontrada por internet) de cada uno de ellos.
Posteriormente redacté, la RFI, la RFP y el desarrollo de los requerimientos (Funcionales, Arquitectura, Seguridad, Formativos …).
Una vez el proyecto se inició, mi responsabilidad consistió en el seguimiento de la implementación y de facilitador para el proveedor elegido.
Finalmente, cuando el proyecto ya estaba finalizando me encargué de redactar el PNT de Administración del proyecto, diseñar las pruebas que se efectuarían para dar por valida la implementación, y facilitar las evidencias en el departamento de QA.
Conclusiones
A pesar de las dificultades comentadas anterioremente, el proyecto finalmente fue un exito. No solo se consiguio el traspaso de los resultados cumpliendo con los requisitos marcados, sinó que además permitió tener montada la plataforma y validar las capacidades y el funcionamiento. De esta manera se establecieron las bases en las que se apoyaron muchos otros proyectos en los que la mejor manera de recoger la información era mediante la plataforma de este tipo.
Posibles mejoras
Como comentaba anteriormente, es necesario introducir algunos parámetros en el software que gestiona el instrumento para que posteriormente aparezcan en el informe que lee la plataforma CDF. Esos parámetros posteriormente se enviaran al ERP para que sepa donde debe colocar los datos que le estamos facilitando. Dichos parmetros se obtienen del ERP.
Para mejorar la experiencia del usuario se podría implementar una solución que permitiera una introducción automática de dichos parámetros en el software del instrumento. Una posible solución seria que en el informe que acompaña la muestra a la que se realizará el test, existiera un código BIDI que contenga dichos parámetros y que puedan ser capturados mediante un lector.