¿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.

Congress crafted the Cures Act of 2016 to address these barriers in information sharing and bring more transparency to healthcare costs and reimbursements. Further, the Office of National Coordination of Healthcare Information Technology (ONCHIT and now ONC) defined specific data sharing standards (interoperability), guidelines for use, and mandated implementation timelines for payers and providers to get their act together. The resulting interoperability standard, Fast Healthcare Interoperability Resources (FHIR, pronounced “Fire”), is the latest update to Health Layer 7 (HL7), HL7V4 in effect. By 2024, the plan is to replace the current de-facto standard HL7v2 (HL7v3 did not see widespread implementation in the US) with FHIR. With over 95% of healthcare organizations using HL7v2, you may want to understand better how this may impact your healthcare business.

¿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.

There are more extensive comparisons of FHIR and HL7v2 and detailed descriptions of USCDI and CCDA on the government’s HealthIT website. The key takeaway should be that the new FHIR standard provides far more simplicity, granularity, and standardization of what data should be shared and how it should be formatted to enable that sharing. While FHIR removes interoperability barriers, it does not guarantee open and accessible healthcare data sharing if you don’t address the other data integration challenges surrounding healthcare data silos. Without pairing it with the right changes to your data analytics strategy and implementations, silos will remain. By extension, it will only marginally bolster the shift from FFS to 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.

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 que utilice un centro de datos como el medio más eficaz para garantizar que se recopilen todos los datos relevantes y necesarios no basta para responder a las preguntas sobre qué aspectos deben ajustarse en cualquier proceso o decisión clínica, operativa o financiera con el fin de mejorar los resultados. Es necesario integrar un almacén de datos en la nube y herramientas de análisis con el centro de datos para analizar y extraer los conocimientos que impulsen el cambio del modelo de pago por servicio (FFS) al modelo de atención basada en el valor (VBC). En mi último blog, describimos el Actian Life Sciences 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, analizaremos algunos casos de uso en los que el análisis impulsa el cambio del pago por servicio (FFS) a la atención basada en el valor (VBC).

About Author