Full text
¿Qué es un bus de interoperabilidad para intercambio de información de salud?
Autores: Daniel Otzoy1, Alejandro Benavides2 Diseño: RECAINSA Agradecimientos: Los autores agradecen el apoyo de Luis Otzoy, Camila Canelas y Joseline Carias de RECAINSA para la realización de este trabajo. *Los autores participan a nivel profesional y organizacional con distintas organizaciones asesoras en temas de interoperabilidad en salud y salud digital, pero declaran no tener conflicto de interés en la producción de este documento. Copyright © 2023 RECAINSA NGO. Esta obra se encuentra sujeta a una licencia Creative Commons IGO 4.0 Reconocimiento NoComercial Sin Obras Derivadas (CC BY-NC-ND 4.0) (https://creativecommons.org/licenses/by-nc-nd/4.0/legalcode.en) y puede ser reproducida para cualquier uso no comercial otorgando el reconocimiento respectivo RECAINSA NGO. No se permiten obras derivadas. Cualquier disputa relacionada con el uso de las obras de RECAINSA que no pueda resolverse amistosamente se someterá a arbitraje de conformidad con las reglas de la CNUDMI (UNCITRAL). El uso del nombre de RECAINSA para cualquier fin distinto al reconocimiento respectivo y el uso del logotipo de RECAINSA, no están autorizados por esta licencia CC-IGO y requieren de un acuerdo de licencia adicional. Note que el enlace URL incluye términos y condiciones adicionales de esta licencia. Las opiniones expresadas en esta publicación son de los autores y no necesariamente reflejan el punto de vista de RECAINSA NGO, RECAINSA Inc., RECAINSA AC Argentina, su consejo directivo u otra entidad vinculada de forma legal a la misma. ¿Qué es un bus de interoperabilidad para intercambio de información de salud? 1 https://orcid.org/0009-0006-1678-2432 2 https://orcid.org/0009-0009-4446-4476
Marco Estratégico para la Transformación Digital en Salud en México Contenido Introducción 01 ¿Por qué es necesario un bus de interoperabilidad para datos de salud? 05 Conclusiones y recomendaciones 08 Bibliografía 09 Características de un Bus de Interoperabilidad para Salud (BIS) 02
¿Qué es un bus de interoperabilidad para intercambio de información de salud? 01 Introducción La interoperabilidad en la atención médica es un requisito para una comunicación efectiva entre entidades, para garantizar el acceso oportuno a información y conocimientos médicos actualizados sobre los pacientes y, por lo tanto, facilitar una atención consistente al paciente.3 Un bus de interoperabilidad para la salud (BIS) es un modelo de arquitectura de software y hardware que facilita el intercambio de información de salud entre diferentes sistemas de información, como registros electrónicos de salud (EHR), sistemas de información de laboratorio (LIS), sistemas de gestión de medicamentos, prescripción electrónica, entre otras aplicaciones de atención en salud. Este se basa, comúnmente, en la arquitectura de software middleware Enterprise Service Bus (ESB)4 como una solución para tres de los cuatro niveles de interoperabilidad para sistemas de información en salud salud: fundacional, estructural y semántica.5 Este tipo de infraestructura tecnológica está diseñada para permitir una comunicación y un intercambio de datos con un principio de neutralidad tecnológica6, asegurando que los proveedores de atención médica tengan acceso a la información que necesitan para brindar una atención al paciente efectiva, empoderando al ciudadano sobre el valor de sus datos de salud para mejorar la trazabilidad y cuidado de la salud. Este documento contiene una guía práctica para tener una mayor comprensión de lo que es un Bus de Interoperabilidad en Salud (BIS), cuales son sus características y por qué es necesario contemplar este tipo de soluciones para tener un mayor impacto en la salud en las poblaciones de los países de América Latina y El Caribe. Así mismo, pretende orientar a aquellos gobiernos y entidades que están desarrollando procesos de adquisición de este tipo de soluciones, quienes están a cargo de la auditoría, transparencia de las inversiones para su financiamiento y la rendición de cuentas, así también, el usuario final de los servicios de salud quien financia de forma directa o indirecta la atención sanitaria. 3 Ryan A, Eklund P. The Health Service Bus: an architecture and case study in achieving interoperability in healthcare. Stud Health Technol Inform. 2010;160(Pt 2):922-6. PMID: 20841819. 4 Un Enterprise Service Bus (ESB) es un modelo de arquitectura de software utilizado para diseñar e implementar la comunicación entre aplicaciones de software que interactúan entre sí en una arquitectura orientada a servicios (SOA). 5 Understand the four levels of interoperability in healthcare. (n.d.). Retrieved December 20, 2023, from https://www.wolterskluwer.com/en/expert-insights/understand-the-four-levels-of-interoperability-in-healthcare 6 Technology Neutrality | Joinup. (n.d.). Retrieved December 20, 2023, from https://joinup.ec.europa.eu/collection/common-assessment-metod-standards-and-specifications-camss/solution/elap/technology-neutrality
¿Qué es un bus de interoperabilidad para intercambio de información de salud? 02 Características de un Bus de Interoperabilidad para Salud (BIS) Las especificaciones técnicas para un bus de interoperabilidad para la salud pueden variar dependiendo de los requisitos específicos de la organización de salud o las organizaciones en caso que sea un colectivo (ciudad, estado, país, región, etc.), el entorno regulatorio y los estándares adoptados en el marco de una arquitectura empresarial. Sin embargo, algunas especificaciones técnicas y características comunes que se podría esperar encontrar en un bus de interoperabilidad para la salud incluyen: 7 Overview—FHIR v5.0.0. (n.d.). Retrieved December 20, 2023, from https://www.hl7.org/fhir/overview.html 8 About DICOMOverview. (n.d.). DICOM. Retrieved December 20, 2023, from https://www.dicomstandard.org/about 9 International Classification of Diseases (ICD). (n.d.). Retrieved December 20, 2023, from https://www.who.int/standards/classifications/classification-of-diseases 10 Framework. (n.d.). OpenHIE. Retrieved December 20, 2023, from https://ohie.org/framework/ 11 IHE Domains. (n.d.). IHE International. Retrieved December 20, 2023, from https://www.ihe.net/ihe_domains/ 12 Rights (OCR), O. for C. (2021, June 9). Health Information Privacy [Text]. https://www.hhs.gov/hipaa/index.html 13 General Data Protection Regulation (GDPR) – Official Legal Text. (n.d.). General Data Protection Regulation (GDPR). Retrieved December 20, 2023, from https://gdpr-info.eu/ •Cumplimiento de estándares: Debe admitir estándares de intercambio de datos de salud como HL7 (Health Level Seven), FHIR (Fast Healthcare Interoperability Resources)7, DICOM (Digital Imaging and Communications in Medicine)8, CIE (Clasificación Internacional de Enfermedades)9 y demás estándares terminológicos (SNOMED-CT, LOINC, Meddra, etc.), así como otros definidos por el país. Además de asegurar que su adopción se basa en buenas prácticas basados en modelos de referencia como OpenHIE10 o IHE.11 •Formatos de datos: La capacidad de manejar varios formatos de datos, incluyendo XML, JSON y otros, para garantizar la compatibilidad con diferentes sistemas de información. •Seguridad de la información: Funciones de seguridad sólidas para proteger los datos sensibles de los pacientes, incluyendo cifrado, protocolos de transporte seguros (por ejemplo, HTTPS, TLS) y cumplimiento con regulaciones como HIPAA (Health Insurance Portability and Accountability Act)12 de los Estados Unidos de América y/o GDPR (Reglamento General de Protección de Datos)13 de Europa. •Enrutamiento y transformación de mensajes: El bus debe ser capaz de enrutar mensajes entre sistemas y transformar datos según sea necesario para asegurar que el sistema receptor pueda interpretarlos correctamente. •Motor de interfaz: Un componente central que gestiona las conexiones y las traducciones de datos entre los diferentes sistemas conectados al bus.
¿Qué es un bus de interoperabilidad para intercambio de información de salud? 03 14 What is an API? - Application Programming Interface Explained - AWS. (n.d.). Amazon Web Services, Inc. Retrieved December 20, 2023, from https://aws.amazon.com/what-is/api/ 15 14:00-17:00. (2022, May 4). ISO/IEC 27000:2018. ISO. https://www.iso.org/standard/73906.html 16 14:00-17:00. (2016, September 5). ISO/IEC 27031:2011. ISO. https://www.iso.org/standard/44374.html 17 What is enterprise master patient index (EMPI)? | Definition from TechTarget. (n.d.). Health IT. Retrieved December 20, 2023, from https://www.techtarget.com/searchhealthit/definition/master-patient-index-MPI 18 Profiling—FHIR v6.0.0-cibuild. (n.d.). Retrieved December 20, 2023, from https://build.fhir.org/profiling.html 19 What the Heck Is a Connectathon? (2020, January 17). Rhapsody. https://rhapsody.health/blog/what-the-heck-is-a-connectathon/ •Gestión de API: Soporte para API14s RESTful y otros servicios web para permitir una fácil integración con aplicaciones hacia una arquitectura basada en servicios. •Monitoreo y registro: Herramientas para monitorear las transacciones de los datos que fluyen a través de él, así como registro para propósitos de auditoría y solución de problemas. Debe considerarse la familia de estándares ISO/IEC 2700015 como parte del cumplimiento. • Escalabilidad: La capacidad de escalar para manejar grandes volúmenes de datos y transacciones a medida que los proveedores de salud se integren al bus. Por ejemplo, la población promedio de un país del Sistema de Integración Centroamericano (SICA), es de 8 millones de habitantes, por lo que al implementar en un BIS para la historia de salud electrónica nacional, debe considerarse este volumen de potenciales historias clínicas y el volumen de transacciones esperadas dentro del alcance del proyecto. •Fiabilidad y disponibilidad: Arquitectura de alta disponibilidad para asegurar que el bus esté operativo en todo momento, con capacidades de failover y planes de recuperación ante desastres basados en ISO/IEC 2703116 y otros estándares relevantes. •Gestión de usuarios y control de acceso: Mecanismos para gestionar el acceso de los usuarios y asegurar que solo las personas autorizadas puedan acceder o modificar los datos de los pacientes. Para ello contar con el servicio del Índice Maestro de Pacientes (MPI)17 será importante dentro de la oferta presentada por el proveedor. •Recursos de interoperabilidad: Soporte para recursos de interoperabilidad específicos que definen los casos de uso (perfilamiento18) y los requisitos de intercambio de datos para varios escenarios de atención en salud. Para ello, la entidad a cargo deberá facilitar los casos de uso esperados dentro de las distintas etapas de interoperabilidad. Lo anterior refleja que la escalabilidad, es una propiedad importante de una arquitectura de interoperabilidad y por ende un requisito dentro de un Bus de Interoperabilidad en Salud (BIS). •Herramientas de prueba y validación: Herramientas incorporadas para probar y validar los procesos de intercambio de datos para asegurar el cumplimiento con los estándares y el funcionamiento correcto. Para ello se propone, generalmente, la realización de un evento público de prueba de interoperabilidad (connectathon19), en dónde los proveedores de servicios interesados prueben que cumplen con los requisitos definidos.
¿Qué es un bus de interoperabilidad para intercambio de información de salud? 04 20 Understand the four levels of interoperability in healthcare. (n.d.). Retrieved December 20, 2023, from https://www.wolterskluwer.com/en/expert-insights/understand-the-four-levels-of-interoperability-in-healthcare 21 Digital signatures and certificates—Microsoft Support. (n.d.). Retrieved December 20, 2023, from https://support.microsoft.com/en-au/office/digital-signatures-and-certificates-8186cd15-e7ac-4a16-8597-22bd163e8e96 22 What is data lifecycle management (DLM)? - Definition from TechTarget. (n.d.). Storage. Retrieved December 20, 2023, from https://www.techtarget.com/searchstorage/definition/data-life-cycle-management •Documentación y soporte: Documentación completa para desarrolladores e integradores de sistemas, así como opciones de soporte para ayudar con la implementación y solución de problemas. •Neutralidad de proveedor: HEl Bus de Interoperabilidad en Salud debe ser neutral con respecto al proveedor, permitiendo la integración con sistemas de diferentes proveedores sin sesgo. A pesar de que existen tecnologías patentadas por proveedores, es importante destacar que el enfoque en estándares y buenas prácticas siempre debe predominar, evitando subjetividades que no agregan valor al resultado final en el corto, mediano y largo plazo. •Cumplimiento regulatorio: Este aspecto es algo que muchas veces no se contempla, ya que responde a la capa de interoperabilidad organizacional20, que no es informática y por ende no es de total dominio de los equipos de tecnologías digitales generalmente involucrados en los procesos de adquisiciones de este tipo de soluciones. Es importante mencionar que en la mayoría de los países de América Latina y El Caribe, no existe suficiente regulación o no es clara en cuanto a la interoperabilidad de los sistemas de información en salud, los estándares y buenas prácticas a considerar. •No repudio: El BIS debe garantizar que la fuente de un mensaje electrónico no pueda negar haber enviado dicho mensaje. Esto es importante en el contexto de la salud, ya que permite a los proveedores de atención médica confiar en la información que reciben de otros proveedores. Esto se puede lograr mediante el uso de técnicas de firma digital o electrónica21, la cual es un método criptográfico que permite a un usuario firmar digitalmente un documento o mensaje electrónico. •Mecanismos de gobernanza: Implementar, escalar y mantener un Bus de Interoperabilidad en Salud, requiere mecanismos de gobernanza de los datos, en donde los liderazgos deben estar claramente definidos (rectoría), para garantizar el ciclo de gestión22 de los mismos. Adicionalmente, un mecanismo que se encargue de la definición de las especificaciones técnicas y requerimientos (funcionales y no funcionales) del BIS, un mecanismo de seguridad de la información que defina los requerimientos del sistema de gestión de la seguridad de la información, un mecanismo de gestión que se encargue de la operación, mantenimiento y escalabilidad del bus, entre otros. Los criterios para definir los entes participantes en los mecanismos de gobernanza, así como los requisitos que se deben cumplir por parte de los mismos, dependerá del ámbito, contexto y alcance establecido en el proyecto de interoperabilidad a implementar.
¿Qué es un bus de interoperabilidad para intercambio de información de salud? 05 ¿Por qué es necesario un bus de interoperabilidad para datos de salud? 23 Interoperabilidad, Capacidad de dos o más sistemas de intercambiar y utilizar dicha información entre ellos, Retrieved December 20, 2023, from https://www.hospitalitaliano.org.ar/#!/home/infomed/noticia/32367 La complejidad y diversidad que supone la gran cantidad de intercambio de datos que sucede entre los diferentes áreas en salud donde todos afectan uno o varios actores, se hace necesario tener arquitectura que resuelva de una manera menos compleja un marco común para la comunicación y el intercambio de datos entre sistemas heterogéneos. A este desafío debemos considerar que esta orquestación debe suceder soportada y basada en estándares en informática en salud interoperables. ¿Qué sucedería sí intentaramos resolver interoperar sin un bus de interoperabilidad?, los equipos técnicos y clínicos que conformen las mesas de trabajo para interoperar tendrían que resolver por cada caso de uso de intercambio construir y mantener una interface específica, esto supondría considerar la siguiente fórmula matemática23: interfaces = n . (n -1) 2 Imagen 1. "Ecuación para estimación de interfaces de interoperabilidad (Fuente: Hospital Italiano)
¿Qué es un bus de interoperabilidad para intercambio de información de salud? 06 Haciendo un ejercicio en donde consideramos que en nuestro ecosistema de información en salud interoperan 10 sistemas de información (n) diferentes y suponiendo que según el nivel de complejidad y necesidad podríamos suponer un costos entre los $10,000 USD a $ 15,000 USD, tendríamos el siguiente escenario: Tabla 1. Ejemplo de estimación de esfuerzo y costo en la interoperabilidad basada en interfaces (Elaboración propia) n interfaces costos aproximados $10,000 - $15,000 USD2 1 $30,000 - $45,000 USD3 3 $60,000 - $90,000 USD4 6 $100,000 - $150,000 USD5 10 $150,000 - $225,000 USD6 15 $210,000 - $315,000 USD7 21 $280,000 - $420,000 USD8 28 $360,000 - $540,000 USD9 36 $450,000 - $675,000 USD10 45