Hace unas semanas pasamos a producción un proyecto que hemos estado pensando por años y que por diferentes razones no habíamos logrado concretar. Nuestra Historia Clínica Electrónica Núcleo comienza a tener una copia en formato FHIR en el FHIR Server Cloud de Google (Google Healthcare API).
Todo especialista en Informática Médica tiene en sus raíces la importancia de implementar estándares, pero la implementación de cualquier estándar siempre es compleja, ya que significa limitarse y hacer lo que el estándar permite. Desde que construimos Núcleo, la comunicación HL7 ha sido implementada en algunos procesos, pero siempre cuando la necesidad era imperiosa, por ejemplo, comunicar los resultados del RIS/PACS a la Historia Clínica, o que la Historia Clínica envíe los fármacos prescritos a un paciente al dispensador automático de la Urgencia (Omnicell). Hemos implementado los estándares de interoperabilidad para cumplir temas concretos, siempre eligiendo alguna versión HL7 y utilizando nuestro middleware Cloverleaf de INFOR para ello.
Pero esta historia de implementar estándares de interoperabilidad “a demanda” nos pesaba. Cada proyecto requería estar haciendo mapeos y, en general, estos proyectos suelen ser difíciles de dimensionar cuánto vas a tardar.
Así que cuando sale el estándar FHIR, lo vimos con grandes ojos, y hemos visto su evolución en el tiempo, lo que nos daba muchas ganas de tener nuestro FHIR server.
Tuvimos que tomar dos decisiones clave. La primera fue elegir entre usar una estrategia fachada, generando recursos FHIR on-the-fly, o almacenar una copia persistente de nuestra Historia Clínica en formato FHIR. Aunque ambas opciones tienen sus pros y contras, optamos por mantener una copia estandarizada y persistente en FHIR para garantizar una representación consistente de nuestra información clínica. La segunda decisión importante fue determinar dónde hostear esta solución.
Comenzamos con un proyecto on-premise utilizando SMILE CDR y documentando con FHIR Shorthand donde aprendimos los desafíos que tiene implementar un proyecto de esta naturaleza.
Creamos nuestra Guía Core, basándonos en la guía Core HL7 Chile y mapeamos toda la información a los estándares que utiliza FHIR:
- LOINC
- SNOMED CT
- UCUM
- Otros value-sets propios de HL7 FHIR
Después de hacer nuestra experiencia on-premise, decidimos mirar al Cloud y obtener los beneficios de las Healthcare API de alguna de las 3 grandes nubes públicas. Después de varias semanas de evaluación, nos decidimos por Google Healthcare API, principalmente porque nuestro Datalake se encuentra ahí, y podíamos utilizar BigQuery para crear los recursos FHIR.
¿Cómo darle visibilidad a un proyecto de interoperabilidad?
Hasta este punto, quienes trabajamos en interoperabilidad estamos entusiasmados y celebrando los avances, pero para los profesionales clínicos aún resulta difícil percibir el verdadero valor de estas iniciativas. Hemos implementado un sistema que no solo nos permite cumplir con la ley de interoperabilidad de Chile (próxima a reglamentarse), sino también participar en proyectos de comunicación interinstitucional. Sin embargo, para los profesionales que están en contacto directo con los pacientes, este impacto puede parecer abstracto. Por eso, en Núcleo, decidimos implementar una aplicación Smart on FHIR que permita evidenciar de manera concreta los beneficios clínicos y hacer tangible el aporte de la interoperabilidad en su práctica diaria.
Exploramos la Smart APP Gallery de FHIR en busca de aplicaciones Smart on FHIR que pudieran agregar valor en pediatría y encontramos dos excelentes opciones: Growth Chart y BP Centiles v1 (Open Source). Ambas destacan por ser visualmente atractivas, de fácil integración y con requerimientos de recursos moderados. Por ello, decidimos incorporarlas en Núcleo, aprovechando que estas smart-apps se alimentan directamente de nuestro servidor FHIR alojado en Google Cloud.
Los profesionales pueden cargar nuevos parámetros de peso, talla, presión arterial, y ver en las pestañas que abren las Smart-APPs las aplicaciones desarrolladas por el Boston Children’s Hospital.
¿Cuál es nuestro roadmap FHIR para los próximos meses?
Nuestro foco está en seguir generando recursos FHIR y llevarlos a nuestro repositorio con el objetivo de ser cada vez más interoperables. Esto implica un trabajo constante de identificar y priorizar aquellos recursos que más valor puedan aportar en el menor tiempo posible, maximizando su impacto en la experiencia clínica y en la capacidad de integración con otros sistemas.
Además, un paso clave será integrar la Receta Electrónica Nacional mediante una integración que permita gestionar este proceso desde nuestra Historia Clínica. Esto se logrará generando recursos FHIR en nuestro repositorio y enviándolos posteriormente a la API de la Receta Electrónica Nacional. Este enfoque garantiza una interoperabilidad robusta, alineada con los estándares, mientras optimizamos el flujo de información entre los distintos sistemas involucrados.
La implementación del FHIR server nos abre la puerta para buscar aplicaciones smart-on-fhir que generen valor rápidamente en la Historia Clínica, como mejores visualizaciones o herramientas de apoyo clínico (sean gratuitas o pagas). Además, buscamos desarrollar un esquema OMOP de OHDSI para investigación, siguiendo los lineamientos de transformación de FHIR a OMOP. Nuestro objetivo es sumar soluciones útiles, vistosas y fáciles de implementar, fortaleciendo la percepción positiva del proyecto entre los profesionales.
El camino es desafiante, pero los avances realizados nos inspiran a seguir construyendo un ecosistema verdaderamente interoperable que beneficie no solo a Clínica Alemana sino también a toda la comunidad de salud.