Publicado el 8 de enero de 2015 por Nicola Rizhikov
El gobierno de San Petersburgo puso en marcha un proyecto cuyo objetivo es crear un bus de integración unificado para el intercambio de pedidos y resultados de laboratorio entre ambulatorios, hospitales y laboratorios del sector público.
Se esperan alcanzar numerosos objetivos: pedidos sin papel, acceso rápido a los resultados para médicos y pacientes, planificación y optimización de recursos, e información para análisis y minería de datos por parte de las organizaciones sanitarias estatales.
La primera iteración consistió en analizar los procesos actuales y crear un prototipo funcional. Esta iteración se completó mediante la creación de una API SOAP personalizada y la integración de algunas organizaciones del grupo de enfoque.
Al término del proyecto piloto quedó claro que debía utilizarse algún estándar internacional como base. Nos invitaron a ayudar a elegir entre los estándares disponibles (tenemos experiencia en integración, aunque en el ámbito estadounidense).
Consideramos HL7 v2, HL7 v3 y FHIR, y los comparamos con una API personalizada.
HL7 v2
A primera vista, HL7 v2 parece el mejor candidato. Esto podría ser cierto en Estados Unidos, donde existen numerosos sistemas en funcionamiento (HIS, EHR, LIS) que ya intercambian mensajes HL7 v2. Sin embargo, la situación en Rusia es diferente: la mayoría de los sistemas de información de laboratorio son desarrollos a medida y no utilizan HL7 v2. Por tanto, el argumento principal a favor de HL7 v2 no es válido, mientras que todos los defectos congénitos de la versión 2 entran en juego.
El protocolo HL7 v2 evolucionó de forma ad hoc, lo que nos deja con un formato de mensajes arcaico, sin extensibilidad integrada, sin perfilado/restricciones legibles por máquina y sin futuro (el estándar se encuentra en fase de solo mantenimiento, sin desarrollo activo).
El formato de mensajes arcaico obliga a implementar parsers y constructores engorrosos prácticamente desde cero. Solo los desarrolladores de Java y .Net pueden reutilizar las bibliotecas HAPI y nHAPI, mientras que otras plataformas populares (node.js, erlang, php, python, ruby, etc.) carecen de bibliotecas cómodas y robustas.
La ausencia de extensibilidad y de perfilado/restricciones podría subsanarse con enfoques como LRI. Sin embargo, al menos la mitad de LRI son simplemente correcciones y parches para errores de HL7 v2 sin aportar valor real.
En resumen: HL7 v2 requiere una gran cantidad de trabajo sin sentido para desplegar un estándar obsoleto.
HL7 v3 y CDA
Otro candidato es HL7 v3 y CDA. Existen dos argumentos a favor: algunos estándares de HL7 v3 son ahora normativos en Rusia, y el grupo de trabajo de HL7 publicó en 2013 un DSTU para pedidos y resultados de laboratorio.
HL7 v3 tiene una base teórica sólida y está diseñado para una verdadera interoperabilidad semántica, pero carece de una propiedad importante: la implementabilidad. Esto queda ilustrado por el hecho de que, incluso a día de hoy, no existen buenas bibliotecas de implementación. Además, tiene una curva de aprendizaje muy pronunciada y resulta complejo para los implementadores. HL7 v3 no es un único estándar, sino una pila profunda de estándares, por lo que incluso la localización de este estándar parece una tarea que consumiría mucho tiempo.
El proyecto tiene un plazo de aproximadamente 6 meses, y no parece realista utilizar HL7 v3 y CDA para arrancarlo. Todo ese tiempo se invertiría en la formación de los desarrolladores.
FHIR
La siguiente opción es FHIR. Se trata de un estándar moderno para la interoperabilidad rápida. El estándar está diseñado para encontrar el equilibrio adecuado entre las necesidades del intercambio semántico de información sanitaria y la complejidad de implementación.
Cuenta con extensibilidad y perfilado integrados, así como un buen conjunto de bibliotecas y servicios. FHIR permite implementar únicamente la parte del estándar que se necesita, lo que puede simplificar enormemente el inicio del proyecto y hace posible la incorporación incremental de nuevas funcionalidades.
Comparamos la API personalizada desarrollada en la primera iteración con la API de FHIR y encontramos una correspondencia casi perfecta. Para cumplir con FHIR, la API actual solo tendría que reimplementar unos pocos recursos: Organization, Practitioner, Patient, Encounter, DiagnosticOrder, DiagnosticReport y Observation. Las reglas de negocio necesarias podrían expresarse como extensiones de FHIR. Los sistemas de laboratorio, hospital y ambulatorio podrían comunicarse con el bus a través de una API REST, utilizando una implementación de referencia disponible y bibliotecas de cliente. Los servicios públicos de FHIR podrían emplearse como entornos de prueba para el desarrollo. Health Samurai, con el apoyo de HL7 Russia, ya ha localizado la mayor parte de la documentación de FHIR.
Sin duda existen numerosas pequeñas cuestiones técnicas, pero debemos afirmar que FHIR se adapta perfectamente a las necesidades y requisitos de este proyecto.
Esperamos que los responsables y los tomadores de decisiones hagan la elección correcta con FHIR y alcancen sus objetivos.
Comience con el servidor FHIR de Aidbox para almacenamiento de datos, integraciones, analítica sanitaria y mucho más, o contrate a nuestro equipo para dar soporte a sus necesidades de desarrollo de software.
Véase también: Cómo abordar la integración de sistemas heredados y Cómo utilizar FHIR para simplificar el desarrollo en el sector sanitario.
