Mejoras en el LIS

Aunque los sistemas informáticos de laboratorio (SIL) llevan muchos años de uso y están bastante evolucionados,se detectan una serie de carencias funcionales que implican que no todos los procesos del laboratorio se puedan llevar a cabo de la mejor forma posible.

En esta entrada vamos a revisar los procesos fundamentales que se llevan a cabo en un laboratorio clínico, resaltando las funcionalidades que debe tener el SIL para optimizarlos, con las consiguientes mejoras en calidad y costes. Estas mejoras se basan en un análisis de los distintos flujos de trabajo de nuestros clientes y en las sugerencias reportadas por los usuarios de nuestros sistemas.

Quiero destacar que para implantar estas mejoras no podemos hablar de recortes sino de inversión. Se van a proponer cambios en los procesos del laboratorio y en los SIL que, en general, tienen un coste económico inicial. Estos cambios buscan mejorar la eficiencia, la calidad y disminuir costes a medio plazo, mediante una optimización de los procesos y un mejor aprovechamiento de los recursos materiales y humanos. Enfocaremos estas mejoras analizando la arquitectura del sistema de información y los distintos procesos del laboratorio.

ARQUITECTURA DEL SISTEMA

Datos en la nube (cloud computing)

Si el sistema informático de laboratorio se basa en una arquitectura en la nube (pública o privada), que consiste en que la infraestructura de servidores y datos se encuentran centralizadas y compartidas para varios sistemas en un centro de datos, se obtiene un ahorro de costes de hardware y mantenimiento. Esta arquitectura se puede afrontar teniendo los sistemas en internet (nube) o en una intranet local del servicio de salud o del grupo empresarial (nube privada). Ante esta arquitectura pueden surgir dudas de seguridad de los datos y velocidad de acceso. La seguridad de los datos se garantiza con una conexión de acceso encriptada y la implantación de un sistema de auditoría y seguridad de datos que cumpla con la Ley de Protección de Datos vigente. El tema de la velocidad de acceso está hoy ampliamente superado con la potencia de proceso de servidores en los centros de datos, la velocidad de navegación por internet y un correcto diseño del esquema de base de datos por parte del equipo de desarrollo del producto.

Arquitectura web

Derivado de tener los datos en la nube, el acceso al sistema debe ser mediante navegador web. Esto implica que el sistema no necesita instalación en el cliente por lo que se reducen drásticamente los tiempos de instalación y mantenimiento en los ordenadores que utiliza el usuario para el acceso al sistema.

Accesos móviles

El sistema debe permitir acceso mediante dispositivos móviles (tablets y smartphones), lo que permite mejorar la productividad. De esta forma podemos realizar accesos al sistema sin presencia física en el laboratorio, acceso desde puntos sin ordenador de sobremesa (ambulancias, habitación del paciente,..), validación remota en guardias localizadas, etc.

Sistemas multicentro

El sistema debe ser multicentro con lo que con un único software se puedan gestionar varios centros, logrando un ahorro de costes al minimizar el número de sistemas a utilizar.

Sistemas multidepartamentales

La arquitectura de los sistemas de software sanitario tiene un núcleo común (usuarios, servicios, datos de paciente, pruebas diagnósticas, etc). Si logramos desarrollar sistemas que apoyándose en ese núcleo común sirvan para gestionar varias areas clínicas, estaremos ahorrando costes, ya que con un sólo sistema solucionamos aquello para lo que antes necesitabamos varios. Es posible desarrollar sistemas complejos, que partiendo de ese núcleo común, gestionen el laboratorio de análisis clínicos, el laboratorio de microbiología, el laboratorio de anatomía patológica, el banco de sangre, el servicio de radiología, la historia clínica electrónica, etc.

PETICION

El aspecto más importante desde el punto de vista de la mejora del proceso de petición al laboratorio es disponer de petición electrónica. Con la petición electrónica podemos ahorrar costes por dos vías:

  • Necesitaremos menos personal administrativo o lo podremos dedicar a otras tareas
  • Control de la demanda. Es decir, lograr que se racionalice la petición de pruebas al laboratorio. Para ello el software de petición electrónica debe tener una serie de característcas que orienten al peticionario con el fín de lograr esa racionalización de la demanda de pruebas. Estas características son:
    • Visión previa de análisis y resultados anteriores como paso previo a la petición, para que de esta forma el peticionario puede verificar si hay peticiones en curso, la fecha de la última analítica pedida y últimos resultados
    • Perfiles de petición y volantes de petición electrónica particularizados por servicio. De esta forma el laboratorio puede orientar al clínico en las pruebas a solicitar
    • Reglas de rechazo. El sistema debe tener reglas de rechazo de pruebas que son improcedentes según valores anteriores , ámbito o servicio peticionario, edad, sexo y tiempo transcurrido desde la última petición.
    • Instrucciones para el paciente y el extractor. Si el sistema imprime un volante para el paciente y suministra información al extractor con las instrucciones de preparación del paciente y muestras, se pueden ahorrar costes asegurando que se va a realizar la extracción de las pruebas de laboratorio con la correcta preparación del paciente, evitando su repetición por preparación inadecuada

FASE PREANALITICA

Gestión de la extracción

El sistema debe tener un módulo de gestión de la extracción que facilite que:

  • Se extraen las muestras y contenedores necesarios correctamente identificados con su tipo de etiqueta adecuado (prefijo)
  • Se garantice la seguridad del paciente identificando correctamente pacientes y muestras
  • Se aplican las condiciones de conservación y tratamiento de las muestras por el extractor
  • Se registran incidencias en la extracción (falta muestra, incidencias en el paciente,…)

La realización correcta de este proceso es fundamental ya que agilizará los procesos posteriores en el laboratorio:

  • Evitará errores de extracción
  • Evitará el reetiquetado de tubos
  • Evitará la repetición de técnicas por incorrecto tratamiento o conservación de la muestra
  • Garantizará el correcto flujo de trabajo del laboratorio evitando compartir tubos entre secciones si así se ha definido. Por ejemplo, si un análisis necesita suero para bioquímica y suero para serología y no se extrae uno de los dos, se tiene que compartir el tubo, cuando el laboratorio para optimizar su flujo de trabajo ha decidido que haya dos tubos
  • Al registrar incidencias de la extracción, el laboratorio tiene información de las mismas y se aceleran los procesos de asignación de incidencias a las pruebas de tubos que faltan, comunicar al paciente que tiene que repetirse la extracción, etc.

Para mejorar la seguridad se deben evitar las etiquetas preimpresas y el proceso de gestión de la extracción tiene que controlarse según el ámbito del paciente, distinguiéndose los siguientes casos:

  • Urgencias: El sistema de petición electrónica debería generar las etiquetas de los tubos
  • Hospitalización: El sistema de petición electrónica debería generar las etiquetas de los tubos para los pacientes por control de enfermería o el laboratorio debe enviar a las plantas los tubos etiquetados mediante sistemas de dispensación
  • Consultas externas: Se deben generar etiquetas por parte del LIS o tener aparatos dispensadores de tubos
  • Primaria: El sistema de historia clínica de primaria debe generar las etiquetas o apoyarse en módulos del LIS que las puedan generar
  • Sistemas de registro de tubos y / o alicuotado.Estos sistemas permiten automatizar el proceso de alicuotado y permiten registrar la llegada de los contenedores al laboratorio, de tal manera que el SIL puede sacar listados de los tubos no recibidos para registrar la incidencia en el análisis e informar al centro de salud o al paciente para la repetición de la extracción.
  • Sistemas de sembrado automático para microbiología. Estos sistemas permiten automatizar el sembrado de los cultivos microbiológicos evitando errores y agilizando el proceso. También puede utilizarse como sistema de registro de llegada de las muestras microbiológicas

FASE ANALITICA

Cadenas que integren el core (Bioquímica + Hematología + Serología)

Diseñar el core de nuestro laboratorio con el máximo de equipos y tipos de muestra integrados ahorra costes en personal, en material, disminuye errores y tiempos de respuesta. Por otro lado el laboratorio es totalmente dependiente del funcionamiento de la cadena por lo que se requiere implementar medidas de redundancia para garantizar el funcionamiento ininterrumpido del sistema

Reglas expertas de validación

La adopción de reglas de validación más complejas que las típicas de validación automática según valores de normalidad, permite disminuir el tiempo que el facultativo dedica al proceso de validación, pudiendo dedicarse a otros procesos organizativos o de investigación que redunden en la mejora de los servicios prestados por el laboratorio.

Un ejemplo de este tipo de reglas es la validación de la hematología según alarmas que proporciona el analizador. En el analizador de hemogramas se definen reglas complejas que hacen saltar alarmas. Los técnicos revisan estas alarmas haciendo fórmulas manuales o frotis. Al transmitirse los resultados al LIS, se transmite también la alarma, de tal modo que los análisis sin alarmas se autovalidan.

Otro ejemplo es la validación según el valor de referencia del cambio. Este tipo de validación se basa en estudios publicados sobre la variabilidad biológica de los parámetros bioquímicos y la variabilidad analítica de los aparatos de nuestro laboratorio. Con estos dos parámetros de entrada, hemos de calcular un valor de variabilidad bioquímica o deltacheck que se configura en las pruebas. A la hora de recibir resultados el sistema comprueba el valor actual y el valor histórico cálculando la variación. Si es menor que la admitida el análisis queda validado.

Alertas

El sistema debe incorporar alertas manuales o automáticas que se envíen al sistema de historia clínica electrónica. De esta manera se mejora la atención al paciente y se disminuyen tiempos de respuesta, se evita repetir pruebas, etc.

FASE POSTANALITICA

Las mejoras en la fase postanalítica deben ir encaminadas en la siguientes líneas:

Distribución electrónica de informes

Debe eliminarse el papel con la correspondiente reducción de costes materiales y administrativos. Los informes deben ser enviados automáticamente tras su validación a la historia clínica o publicados en alguna aplicación tipo web para su consulta

Almacenamiento de muestras

El SIL debe gestionar el almacenamiento de muestras terminadas para estudios o repeticiones posteriores: seroteca, cepario, etc. De esta forma el proceso de búsqueda y recuperación de esas muestras será rápido con el consiguiente ahorro de costes y mejora de la seguridad.

ESTADÍSTICAS

No se puede controlar lo que no se puede medir. Por eso es fundamental que el SIL disponga de un potente sistema de análisis de datos que permita consultar actividades a varios niveles (por ámbito, servicio,etc.), estado de las analíticas, tiempos de respuesta, incidencias, cuadros de mando y análisis de datos mediante aplicaciones específicas

CONFIGURACIÓN

La configuración del sistema debe ser ágil, intuitiva y sencilla y basada dentro de lo posible en estándares internacionales (LOINC, SNOMED, etc.) para de esta manera disminuir los tiempos de parametrización y mantenimiento del sistema

CONEXIONES CON ANALIZADORES

Se debe valorar a la hora de su adquisición, aquellos equipos que tienen protocolos de comunicación estándar como ASTM o HL7 y modos de trabajo en host-query. De esta manera se garantiza una rápida conexión y un modo de funcionamiento ágil con el SIL

LABORATORIO DE REFERENCIA

El SIL debe tener conexión con los laboratorios de referencia para automatizar procesos y disminuir errores. Si se dispone de un entorno multicentro de base de datos única, donde se derivan pruebas entre los centros, la interconexión de laboratorios queda muy simplificada. Si los laboratorios externos están fuera de la red es necesario realizar una conexión con su software de gestión intentando seguir estándares de interoperabilidad como HL7

Desde HORUS, estamos incluyendo todas estas características en nuestro producto MILENIO