¿Resuelve plenamente FHIR los retos de la interoperabilidad de los datos sanitarios en silos?

Admitámoslo, la retención de información es habitual en muchos sectores, pero ha sido especialmente rampante en el espacio sanitario. Los pagadores y los proveedores han evitado el escrutinio del coste de la atención prestada y de los reembolsos que percibían. En consecuencia, el bloqueo de la información se ha convertido en uno de los principales impedimentos para pasar de un modelo de pago por servicio (FFS) a otro más transparente de atención basada en el valor (VBC). Por supuesto, el bloqueo de la información no es absoluto ni explícito. En cambio, se manifiesta a través de barreras infraestructurales como la lenta transición de los registros en papel, los procesos manuales y la persistente necesidad de integraciones puntuales entre plataformas propietarias. A veces, el bloqueo de la información es un efecto secundario de la HIPAA y el Meaningful Use, donde directrices bienintencionadas pueden impedir o desalentar el intercambio de información cuando la tecnología o el proceso no son lo suficientemente granulares o flexibles para permitir el intercambio sin sacrificar la seguridad y la privacidad.

El Congreso elaboró la Ley de Curas de 2016 para abordar estas barreras en el intercambio de información y aportar más transparencia a los costes y reembolsos sanitarios. Además, la Oficina de Coordinación Nacional de Tecnología de la Información Sanitaria (ONCHIT y ahora ONC) definió normas específicas de intercambio de datos (interoperabilidad), directrices de uso y plazos de implantación obligatorios para que pagadores y proveedores se pusieran manos a la obra. La norma de interoperabilidad resultante, Fast Healthcare Interoperability Resources (FHIR, pronunciado "Fire"), es la última actualización de la Health Layer 7 (HL7), HL7V4 en vigor. Para 2024, el plan es sustituir el actual estándar de facto HL7v2 (HL7v3 no ha tenido una implantación generalizada en EE.UU.) por FHIR. Dado que más del 95% de las organizaciones sanitarias utilizan HL7v2, es posible que desee comprender mejor cómo puede afectar esto a su negocio sanitario.

¿Por qué FHIR en lugar de HL7v2?

¿Por qué molestarse? HL7v2 tiene varios inconvenientes, los principales de los cuales son los siguientes:

• En primer lugar, HL7v2 no permite que una persona vea el contenido de cada mensaje transmitido.
• En segundo lugar, los mensajes sanitarios pueden ser extensos y constar de varias piezas de información que uno puede querer enviar o recibir o ver por separado; HL7v2 no ofrece una forma fácil de hacerlo.
• Además, HL7v2 se limita a la última generación de normas para el formateo y la transferencia de datos semiestructurados, XML y SOAP.
• Y, por último, HL7v2 no comenzó como un estándar abierto gratuito y no se convirtió en uno hasta 2013, y la mayoría de las versiones de los principales adoptantes tempranos son anteriores a este cambio. El resultado son múltiples implementaciones con compatibilidad con versiones anteriores y problemas de integración entre proveedores.

FHIR resuelve cada una de estas deficiencias de HL7v2 de las siguientes maneras:

• FHIR es un estándar abierto y gratuito desde el principio, diseñado para que lo utilice cualquier desarrollador, no sólo los del ámbito sanitario.
• Los mensajes FHIR se basan en formatos de datos XML, RDF y JSON, y utilizan API RESTful para exponer los datos como un conjunto de servicios web.
• El formato exacto de los datos también se estandariza para adherirse al formato de datos USCDI (US Core Data Interoperability), que debe almacenarse y descargarse en una Arquitectura de Documentos Clínicos Consolidada (CCDA). Cuando se trata de normas reguladas, su adopción depende de que se proporcione un conjunto de datos acordado en un formato que todos los sistemas puedan leer.
• Los mensajes FHIR son legibles por humanos y modulares, lo que permite compartir elementos específicos y comprobar a simple vista si se ha recibido lo que se esperaba.

En el sitio web de HealthIT del gobierno hay comparaciones más extensas de FHIR y HL7v2 y descripciones detalladas de USCDI y CCDA. Lo más importante es que el nuevo estándar FHIR ofrece mucha más simplicidad, granularidad y estandarización de los datos que deben compartirse y de cómo deben formatearse para permitir ese intercambio. Aunque FHIR elimina los obstáculos a la interoperabilidad, no garantiza un partage des données sanitario abierto y accesible si no se abordan los demás retos de integración de datos que rodean a los silos de datos sanitarios. Si no lo combina con los cambios adecuados en su estrategia e implementación de análisis de datos, los silos seguirán existiendo. Por extensión, sólo reforzará marginalmente el cambio de FFS a VBC.

La interoperabilidad es sólo el punto de partida de la integración

Sin duda, la interoperabilidad FHIR facilitará a los proveedores compartir sus datos clínicos entre ellos y con los pagadores. También facilitará la incorporación de datos clínicos externos (como repositorios estatales y federales de datos de salud de la población) mediante la exposición de estos repositorios externos como servicios web. Por supuesto, esto requerirá que sus equipos de TI creen más conexiones punto a punto. Y, aunque puede reutilizar estas conexiones punto a punto, hay una forma mejor de optimizar el uso de FHIR: Embarquer en un concentrador de datos.

Con la funcionalidad de concentrador de datos, puede ingerir, preparar y combinar datos financieros y operativos complementarios de sistemas administrativos de proveedores y pagadores con datos clínicos FHIR. Normalmente, los datos de los pagadores, y los datos que se envían y reciben de ellos, están en formatos EDI como X.12 8xx. Gran parte de los determinantes sociales de la salud o datos SDOH se encuentran en otros formatos fuera del ámbito sanitario. Los datos de los recursos FHIR deben descomprimirse y transformarse en datos EDI u otros formatos, y viceversa. A menudo, es necesaria la combinación de datos clínicos, SDOH y financieros, lo que hace que las conexiones punto a punto no sean óptimas.

En cambio, una ubicación central virtual para conectar todos los datos posibles es una forma más eficaz y flexible de tratar la variedad y diversidad de los datos sanitarios. Este es el concepto en el que se basa un centro de datos. Históricamente, los centros de datos sanitarios han sido plataformas de integración de datos muy complejas utilizadas por ingenieros de datos y otros especialistas en integración de TI. Pero, en el espíritu de democratización de los datos que promueven la Ley de Curas y FHIR, el centro de datos sanitarios del futuro debería incluir la capacidad de evitar la codificación rígida y las secuencias de comandos únicas. Un menú de arrastrar y soltar, sin código/con poco código, evita sobrecargar a los equipos informáticos sanitarios y permite a los analistas y otros usuarios avanzados el acceso autoservicio a los datos. Además, los concentradores de datos sanitarios deberían tener plantillas de transformación integradas, ya que las estructuras USCDI y CCDA y los formatos EDI como el 837 están bien definidos. Esto elimina uno de los mayores sumideros de tiempo para el departamento de TI y permite a los superusuarios no informáticos trabajar directamente con los datos.

Un mayor partage des données datos no implica automáticamente una mayor calidad.

Otra cuestión que FHIR no aborda y que, en todo caso, puede agravar aún más el problema es la calidad de los datos. Dado el partage des données más amplio y, esperemos, más frecuente, siempre habrá errores de conversión de datos inherentes al envío de recursos específicos separados en lugar de registros monolíticos, como ocurre con HL7V2. Además, la necesidad de transformaciones de datos seguirá existiendo y crecerá a medida que se compartan conjuntos de datos más diversos y dispares. Un concentrador de datos sanitarios debe dominar FHIR, EDI X.12 8xx, las versiones heredadas de HL7 y otros estándares para realizar ingestas de datos, efectuar las transformaciones entre estándares y proporcionar funciones de calidad de datos como la deduplicación y la capacidad de configurar el reconocimiento de patrones para errores de conversión comunes. Por último, los estándares para los formatos de datos dentro de cada recurso FHIR pueden cambiar con el tiempo. Un concentrador de datos sanitarios debe ser consciente de los cambios en la forma en que deben transformarse los datos específicos.

Todo este partage des données entre diversos proveedores y pagadores tiene lugar entre aplicaciones y repositorios de datos. Las integraciones punto a punto representan las conexiones de datos entre procesos operativos y empresariales específicos, y respaldan el análisis automatizado de datos y el apoyo a la toma de decisiones de los profesionales sanitarios y los trabajadores del conocimiento. La automatización de la ingestion de données y la salida hacia y desde las distintas aplicaciones, servicios web y repositorios de datos, la preparación, transformación y unificación es también un factor crítico para el éxito partage des données. Una vez más, FHIR facilita -pero no completa- la solución.

Conclusiones

La Ley de Protección al Paciente y Asistencia Asequible de 2009 fue un buen comienzo para ampliar el acceso a la asistencia sanitaria de millones de ciudadanos sin recurrir a un sistema de pagador único. Además, las secciones de la ley que promovían las organizaciones de atención responsable centradas en los resultados abordaban parcialmente la necesidad -o al menos la reconocían- de abandonar el modelo de pago por servicio. La Cures Act, la interpretación de la ONC y el apoyo de FHIR como herramienta para partage des données acelerarán sin duda el cambio hacia una atención basada en el valor al crear unas condiciones equitativas para el partage des données. Sigue siendo necesaria una estrategia de integración de datos más completa, que debería centrarse en combinar y mejorar la calidad de los datos sanitarios y no sanitarios.

Una estrategia integral de integración de datos con un centro de datos como el medio más eficaz para garantizar que todos los datos relevantes y necesarios reunidos no pueden responder a preguntas sobre lo que es necesario ajustar en cualquier proceso o decisión clínica, operativa o financiera para mejorar los resultados. Es necesario integrar un entrepôt de données cloud y herramientas analíticas con el centro de datos para analizar y extraer la información necesaria para impulsar el cambio de FFS a VBC. En mi último blog, describimos el Actian Healthcare Data Analytics Hub, una forma más eficiente y eficaz de extraer información para la Atención Basada en el Valor. En el próximo blog, veremos algunos casos de uso en los que la analítica impulsa el cambio de FFS a VBC.

Acerca de Actian Corporation

Actian hace que los datos sean fáciles. Nuestra plataforma de datos simplifica el modo en que las personas conectan, gestionan y analizan los datos en entornos en la nube, híbridos y locales. Con décadas de experiencia en gestión de datos y análisis, Actian ofrece soluciones de alto rendimiento que permiten a las empresas tomar decisiones basadas en datos. Actian cuenta con el reconocimiento de los principales analistas y ha recibido premios del sector por su rendimiento e innovación. Nuestros equipos comparten casos de uso probados en conferencias (por ejemplo, Strata Data) y contribuyen a proyectos de código abierto. En el blog de Actian, cubrimos temas que van desde la ingestión de datos en tiempo real hasta el análisis impulsado por IA.