Context
Es freqüent que un laboratori hi hagi gran varietat d’instruments que cobreixin la complexitat d’anàlisis que s’han de realitzar. Les grans marques (Agilent, Waters,Qiagen…) han desenvolupat carissims programes que permeten tractar les dades que generen els seus instruments. En el millor dels casos també permeten la comunicació entre els instruments (sempre i quan, siguin tots de la mateixa marca), de manera que els resultats obtinguts en un d’ells serveixin per complimentar part dels paràmetres que necessita l’altre per realitzar en seu anàlisis.
Generalment aquests tipus de software son molt tancats i les possibilitats d’importació/exportació son força limitades de manera que traspassar dades entre diferents software esdevenia un problema que generava més inconvenients que avantatges. En el millor dels casos, les marques t’oferien softwares complementaris que permetien el traspàs de forma confiable, però eren solucions només valides amb els seus productes i força costoses.
Objectius
Es pretenia complir els següents objectius:
- Que permetés el traspàs dels resultats d’una manera homogéna per a diferents softwares (tant de laboratori com d’altres àmbits).
- Evitar errors de transcripció.
- Disminuir el temps en tasques repetitives del personal de laboratori.
- Traçabilitat dels resultats introduïts.
- Prova de concepte. Si obteníem els resultats esperats podria servir de punt de partida per a altres projectes.
Requisits
Apart de complir amb els objectius, s’havia de fer de forma apropiada:
- Tenia que ser capaç d’ingerir tota l’informació generada.
- Flexible per poder treballar amb els diferents instruments de l’empresa (no exclusivament de laboratori) inclus aquells dels que no es disposava cap software controlador.
- Fàcilment escalable.
- Que fos una solució oberta, que no impliqués “lligar-se” con un proveïdor concret.
- Que garantís la màxima traçabilitat i transparència de les dades.
- Donat que els resultats estaven validats abans de generar el fitxer d’exportació, un cop introduïts al ERP, l’anàlisis havia de quedar tancat i validat.
Implementació
Es va optar per la implementació d’una plataforma CDF (Cloudera Data Flow) que es basava en el següents components principals:
- Sistema distribuit de fitxers (Apache Hadoop).
- ETL (Apache NiFi)
- Plataforma distribuïda de transmissió/publicació de dades (Apache Kafka).
Per la banda de l’ERP es va decidir rebre la informació, mitjançant un webservice que necesités les menys dades possibles, ja que s’anava a utilitzar per ingerir dades des de diferents softwares, de diferents companyies del grup amb diferent mecanismes i graus d’integració amb el ERP:
- Els paràmetres per identificar on ha d’escriure el resultat (identificador del plà d’inspecció, codi d’operació e identificador de mostra).
- El resultat en si mateix.
- Meta-dades : Usuari, identificador d’instrument i data/hora.
Es van configurar el software majoritari del laboratori per a exportar en un informe molt senzill (fitxer de text) amb estructures lo més estandard possible. La plataforma monitoritzava unes carpetes concretes del servidor on es deixaven els informes en busca de fitxers nous cada pocs minuts. Depenent de la ubicació d’aquests fitxers, la plataforma esperava una estructura concreta i si coincidia extreia les dades i generava la petició al webservice del ERP.
Per tal de garantir la traçabilitat, es va configura perquè cada línea del fitxer es tractes de forma separada de manera que, si una línea/resultat generava una error, es seguís processant la resta del fitxer. Per cada línea es guardava en el sistema de fitxers distribuit la petició que es feia a SAP i la resposta obtinguda. Tant mateix, en cas d’error s’enviava un e-mail a diferents llistes de distribució, depenent de si era un error “operatiu” (fitxer mal formatat, falta de dades…) o tècnic (serveis caiguts, error en la comunicació, errors inesperats…). En aquests últims casos, es va configurar un flux per reintentar automàticament l’enviament durant cert temp. A més a més a nivell de maquines, tota la plataforma era monitoritzada per Nagios.
La meva aportació
Primerament em vaig encarregar de buscar plataformes que aparentment complissin amb els requisits establerts, fer-ne un petit estudi amb els avantatges, inconvenients i els casos en els que s’acostuma a implementar cada una d’elles. De la sol·lució que recomanava, s’incloïa la descripció dels components que la podrien formar i un esquema de la interacció entre ells.
Un cop validada la opció recomanada amb l’equipe, em vaig encarregar de facilitar una llista de possibles proveïdors i la meva opinió (basant-me en l’informació trobada per internet) de cada un d’ells.
Posteriorment vaig redactar, la RFI, la RFP i el desenvolupament dels requeriments (Funcionals, Arquitectura,Seguretat, Formatius…).
Un cop el projecte es va iniciar, la meva responsabilitat va consistir en el seguiment de la implementació i de facilitador pel proveïdor escollit.
Finalment, quan el projecte ja estava finalitzant em vaig encarregar de redactar el PNT d’Administració del projecte, dissenyar les proves que s’efectuarien per donar per valida la implementació i de facilitar-ne les evidencies al departament de QA.
Conclusions
Tot i les dificultats comentades anterioremente, el projecte finalment va ser un èxit. No només es va aconseguir el traspàs dels resultats cumplint amb els requisits marcats, sinó que a més va permetre tenir muntada la plataforma i validar-ne les capacitats i el funcionament. D’aquesta manera es van establir les bases en què es van recolzar molts altres projectes en els que la millor manera de recollir la informació era mitjançant la plataforma d’aquest tipus.
Possibles millores
Com comentava anteriorment, cal introduir alguns paràmetres en el software que gestiona l’instrument perquè posteriorment apareguin a l’informe que llegeix la plataforma CDF. Aquests paràmetres posteriorment s’enviaran a l’ERP perquè sàpiga on ha de col·locar les dades que li estem facilitant. Aquests paràmetres s’obtenen de l’ERP.
Per millorar l’experiència de l’usuari es podria implementar una solució que permetés una introducció automàtica d’aquests paràmetres en el software de l’instrument. Una possible solució seria que en l’informe que acompanya la mostra a la qual es realitzarà el test, hi hagués un codi BIDI que contingui aquests paràmetres i que puguin ser capturats mitjançant un lector.