¿Por qué es tan difícil integrar la telemedicina con la Historia Clínica electrónica?

Hay muchos sistema de Historias Clínica Electrónica (HCE) pero no todos siguen estándares reconocidos como HL7 v2, HL7 v3, FHIR, openEHR y VISTA. Muchos tienen infraestructuras propias con interfaces para uno o más de estos estándares con el fin de proporcionar una ruta de integración, lo que dificulta la integración de la telemedicina en los HCE.

Estos estándares son bastante diferentes, por lo que proporcionar una interfaz para cada uno requiere esfuerzo. Peor aún es que las comunicaciones entre dos entidades, cada una con una interfaz basada en estándares, no significa que esas dos entidades podrán pasar información.

Casi siempre se requiere cierto nivel de personalización.

HL7 versión 2.x es el estándar HCE más antiguo, originario de 1987. Proporciona una especificación de interoperabilidad para transacciones médicas y de salud para sistemas de información hospitalarios.

Fue desarrollado de manera ad hoc para integrar varios sistemas hospitalarios, como el administrativo y el clínico. Esto permitió una rápida adopción ya que los desarrolladores podían concentrarse en las convenciones y problemas locales. Este uso intensivo de la personalización local se convirtió en una tarea integrada y convirtió cada tarea de integración en un esfuerzo personalizado. Esto generó un sector empresarial de motor de integración HL7, que todavía se está fortaleciendo hoy.

HL7 v2 con sus separadores de campo, separadores de componentes, separadores de subcomponentes, separadores de repetición de campo, caracteres de escape y lo más significativo, los segmentos Z, no es complejo, pero cada implementación está altamente personalizada.

La versión 3 de HL7 comenzó en 1995 para abordar las deficiencias de HL7 v2. Los profesionales de los estándares tomaron el control de este esfuerzo e hicieron un enfoque de abstracción de arriba hacia abajo donde la plataforma es independiente y desacoplada de la implementación. El resultado final fue un estándar que no es directamente implementable. La complejidad de transformar el modelo de elementos de implementación abstractos a concretos fue desalentadora. Aún más desalentador, no hay dos implementaciones reales que sean compatibles. Dadas las dificultades encontradas en las primeras implementaciones de alta visibilidad, la adopción de HL7 v3 comenzó lentamente y se ha reducido progresivamente desde allí.

Pero las deficiencias de HL7 v2 son tan importantes que las personas orientadas a los estándares no se rindieron. En 2011, un grupo independiente de arquitectos HL7 comenzó con un nuevo enfoque aprovechando las capacidades modernas de Internet, específicamente REST (Representational State Transfer). Esto permite una implementación que no tiene estado, usa métodos HTTP, usa XML (buena transferencia de HL7 v3) o JSON (notación de objetos JavaScript) como representaciones de recursos y tiene recursos en URL predecibles. Este nuevo intento se llama FHIR (Fast Healthcare Interoperability Resources). Como implica la R en FHIR, se basa en el concepto de "recursos" (por ejemplo, Recursos del paciente, Recursos del dispositivo, Recursos de documentos).

Al adoptar el enfoque RESTful y evitar tanto el enfoque ad hoc de HL7 v2 como el enfoque de arriba hacia abajo de HL7 v3, tuvo un comienzo atractivo. Telemedicina FHIR

Pero FHIR es abstracto y no especifica detalles de implementación. (¿Suena familiar?) Todavía se está desarrollando y, aunque tiene mucho soporte, no tiene tantas implementaciones en el campo.

A pesar de sus deficiencias y críticas, las implementaciones de HL7 v2 gobiernan. Entonces, si desea conectarse a la mejor base EHR instalada, debe hablar HL7 v2.

Más del 90% de los hospitales en los EE. UU. Usan HL7 v2 y no es razonable esperar que saquen algo que ha estado funcionando (durante muchos años) y lo reemplacen con algo nuevo y aún no probado. Las nuevas implementaciones son claramente los mejores objetivos para FHIR. Pero para tener relevancia en un mundo HL7 v2, se necesita un motor de interfaz FHIR a HL7 v2 para cada una de esas implementaciones de FHIR.

Dado que el enfoque RESTful de FIHR simplifica la transición a Internet, es ideal en el extremo de origen de una transacción de interfaz. El extremo receptor con una implementación HL7 v2 necesitaría un motor de interfaz FHIR. Fácil para el extremo de origen, pero sigue siendo un esfuerzo en el extremo de recepción debido a la personalización local de HL7.

Si FHIR pudiera ir un poco más allá de sus reglas de abstracción y especificar una cierta cantidad de detalles de implementación específicamente para la telemedicina, entonces podría ser extremadamente útil.

Por otro lado, si HL7 pudiera reducir la miríada de opciones locales al mínimo necesario para la telemedicina, podríamos tener una especificación enfocada con relativa facilidad de implementación. Más sobre esto en entregas posteriores de esta serie de artículos.

Referencia
https://ehrguide.org/integrate-telemedicine-ehrs/
https://corepointhealth.com/will-fhir-be-used-telehealth-and-telemedicine/
https://www.healthcareguy.com/2012/10/11/essentials-of-telehealth-and-telemedicine-top-dos-and-donts-mhealth-and-other-health-it-advice/