Las API estandarizadas podrían por fin facilitar el intercambio de historiales médicos

Una ley federal exige que la información de salud sea fácil de intercambiar antes de fin de año. El desarrollo de interfaces de programación de aplicaciones estandarizadas, o API, contribuirá en gran medida a hacerlo posible. Los proveedores de atención, los planes de salud y los vendedores de software deberían tomar varias medidas para aprovechar las oportunidades que generarán.

••• Intentar acceder a la información médica personal ha sido una molestia intermitente para la mayoría de las personas en los Estados Unidos, hasta que la COVID-19 llegó con un recordatorio del lío que puede ser. Nos enfrentamos a opciones defectuosas de almacenamiento y[acceder a nuestra información sobre la vacunación contra la COVID-19](https://www.nytimes.com/interactive/2022/02/09/us/lost-vaccination-card.html): una tarjeta de papel que sea demasiado grande para nuestra cartera; una foto de la tarjeta guardada en nuestro teléfono como para que el maître la mire con poca luz; tal vez una [elegante carné de vacunación electrónico](https://dph.illinois.gov/resource-center/news/2021/december/illinois-vax-verify-system-now-offers-smart--health-card-vaccina.html) descargado mediante un código QR del departamento de salud estatal que podemos guardar en nuestro Apple Wallet. ¡Pero espere! Solo tiene nuestras dos primeras fotos de la primavera pasada y no la tercera de noviembre. Tal vez nuestro médico tenga una aplicación de portal en la que podamos obtener nuestras vacunas, excepto la dosis de refuerzo que recibimos en Walgreens. En una época en la que las aplicaciones bancarias agrupan toda nuestra información financiera a pedido y nuestro restaurante favorito puede recordar lo «de siempre» cuando hacemos pedidos por Internet, es desconcertante que un trozo de cartón contenga el único comprobante de vacunación de muchas personas. Las tarjetas de vacunación son solo un pequeño síntoma de un problema mayor. La información de salud de una persona en particular suele estar dispersa en varios hospitales, clínicas y farmacias. Se pierden grandes partes del historial médico de la mayoría de las personas con algún propósito útil cuando se mudan o cambian de médico porque transferir su información es demasiado complicado. Si tiene la suerte de recibir todos sus cuidados en un solo sistema de salud y se queda allí, puede que tenga algo parecido a una historia clínica electrónica (EHR) completa. De lo contrario, probablemente no. Los proveedores de atención médica se enfrentan a los mismos problemas. Incluso cuando utilizan el mismo software de historia clínica electrónica, los sistemas de salud no siempre pueden compartir información fácilmente, y tratar de acorralar un registro de vacunación de Walgreens o un informe de la sala de emergencias de otro estado es, aunque a veces factible, siempre es un desafío. Los intercambios de información de salud (HIE) funcionan en muchos estados y permiten a los proveedores compartir información demográfica básica e historiales médicos, pero su utilidad y disponibilidad varían. Sin embargo, se están introduciendo cambios obligatorios por el gobierno federal para facilitar considerablemente el intercambio electrónico de cualquier información médica. Es difícil exagerar su potencial no solo para permitir a todos el acceso total, completo y fácil a su información de salud personal, sino también para abrir innumerables formas nuevas de utilizar esa información, siempre y cuando las entidades que generan la información estén preparadas para aprovechar este avance de la tecnología. ## **Los obstáculos históricos al intercambio de información de salud, en resumen** ¿Por qué el intercambio de información de salud es tan errático, cuando prácticamente todos los datos de salud están informatizados? ¿Los ordenadores no pueden hablar entre sí? Otras industrias lo han descubierto. ¿Por qué no la atención médica? Las razones son muchas y complejas, pero se reducen a la falta de motivación. En primera línea, a los médicos les encantaría tener fácil acceso a la información que necesitan, pero en la suite ejecutiva, la rentabilidad no suele ser lo suficientemente alta ni obvia como para justificar la inversión. Para algunos proveedores, mantener la información de los pacientes como rehén ha sido una ventaja competitiva: una forma de evitar que pasen a otro proveedor. Algunas clínicas y hospitales siguen «compartiendo» información a regañadientes entregándole al paciente un disco o una carpeta con copias impresas. Incluso la informatización básica de la información médica iba muy despacio antes de que miles de millones de dólares en financiación federal para historiales médicos electrónicos, se destinaran como parte del[El paquete de estímulos de la administración Obama](https://www.govinfo.gov/content/pkg/PLAW-111publ5/pdf/PLAW-111publ5.pdf) promulgada en 2009, cambió la ecuación de inversión. Se necesitó dinero gratis para inducir a una masa crítica de proveedores a dar el paso. El envío de información de salud de un ordenador a otro tiene su propio historial irregular. Muchos proveedores de software de salud han hecho un negocio lucrativo con la creación de interfaces personalizadas para conectar los diversos sistemas que se utilizan en muchos hospitales, con ajustes facturables cada vez que el hospital adquiere una nueva aplicación o actualiza una existente. Además, los vendedores suelen bloquear la portabilidad de los datos como estrategia de retención de clientes. Si es difícil o caro mover sus datos al sistema de otro proveedor, pasarán por defecto a la siguiente versión del que ya tienen. Algunos vendedores han tomado medidas para ayudar a los proveedores a compartir. Por ejemplo, el proveedor de registros electrónicos Epic permite a sus clientes intercambiar datos fácilmente si así lo acuerdan mutuamente. Pero no puede convertirlos. Si dos clientes de Epic compiten en un mercado determinado, pueden decidir que no es lo mejor para ellos, aunque pueda ser lo mejor para sus pacientes. No es que el sector de la salud carezca de estándares de datos, sino todo lo contrario. Pero a menudo los crean grupos interesados en tipos específicos de datos, por ejemplo, los estándares desarrollados para las imágenes médicas por el Colegio Estadounidense de Radiólogos. Han hecho que el intercambio de datos sea un poco menos complicado, pero no pueden resolver los demás problemas que hemos discutido. Mientras tanto, los pacientes desconcertados no pueden acceder a su información de forma exhaustiva. Probablemente todo esté en un ordenador en alguna parte, pero no hay una fuerza lo suficientemente poderosa como para compilarlo en un solo lugar y facilitar su búsqueda, y mucho menos usarlo para mejorar nuestra salud. ## **El gobierno federal interviene** Entra el gobierno federal, el único partido con suficiente influencia, cuando así lo decide, como para impulsar un cambio genuino en la industria de la salud de EE. UU. A través de Medicare para todos los mayores de 65 años, Medicaid para los pobres, CHIP para los niños, el sistema de salud de Asuntos de los Veteranos, el sistema de salud del Departamento de Defensa para el personal militar y la cobertura médica para millones de empleados federales y sus familias, el gobierno paga más atención para más personas que cualquier otra entidad individual. En los últimos días del gobierno de Obama, la Ley de Curaciones del Siglo XXI finalmente aprovechó esta influencia al incluir el requisito de[fácil intercambio de datos de salud antes de finales de 2022](https://www.federalregister.gov/documents/2020/05/01/2020-07419/21st-century-cures-act-interoperability-information-blocking-and-the-onc-health-it-certification). Es posible que los proveedores que no cumplan con los requisitos no puedan participar en Medicare, y esa cantidad de ingresos perdidos sería devastadora para la mayoría de los hospitales y médicos. Dependen de sus proveedores de software para hacer lo que se necesita, lo que también los pone en aprietos. El reglamento también establece sanciones para los vendedores, proveedores y pagadores que sigan aplicando prácticas de «bloqueo de información» (lo que, en teoría, debería abolir la práctica de aprovechar el acceso a la información para mantener a sus clientes encarcelados). Dado que finales de 2022 no está muy lejos, ¿cómo va a cumplir la industria de la salud esta misión? Haciendo algo que debería haber descubierto hace mucho tiempo sin necesidad de un mandato federal: adoptar un método estándar para que sus ordenadores hablen entre sí. ## **El poder de las API** Ese método son interfaces de programación de aplicaciones o API abiertas y estandarizadas. Son la razón por la que sus dispositivos y programas de software pueden intercambiar datos sin que tenga que hacer nada. Las API permiten que una aplicación de un desarrollador lea y escriba datos de la aplicación de otro desarrollador. Las API son[en todas partes.](/2021/04/apis-arent-just-for-tech-companies) Si ha extraído información de todas sus cuentas bancarias y de tarjetas de crédito en una sola aplicación de planificación financiera, fueron las API las que lo hicieron. Las API le permiten utilizar la información de su cuenta de Google o Facebook para iniciar sesión en sitios web que no son propiedad de Facebook ni de Google. Las API son la razón por la que puede pasar del sitio web de una empresa a su aplicación de teléfono y viceversa y continuar siempre donde lo dejó. Imagínese poder hacer lo mismo con toda su información de salud, sin importar dónde o cuándo se generara. (Para empezar, todo el mundo puede tener una tarjeta de vacunación electrónica en el teléfono que se actualice automáticamente, incluso si utilizara un proveedor diferente para cada vacuna).[Uso de las API para desbloquear los datos de las historias clínicas electrónicas](/2015/12/the-untapped-potential-of-health-care-apis) podría dar a las personas un acceso fácil y eficiente a sus propios datos para ayudarlas a entender su salud y tomar decisiones más informadas. Los proveedores tendrían una imagen completa del historial de cada paciente. Podrían utilizar esa información no solo para respaldar su toma de decisiones clínicas, sino también como parte del análisis de la salud de la población para ver los patrones en sus poblaciones de pacientes. Los investigadores podrían identificar más fácilmente a los pacientes que podrían beneficiarse de un ensayo clínico en particular; solo una forma de utilizar los datos para descubrir y evaluar nuevos fármacos y terapias. ## **FHIR: Manual de instrucciones de la API de atención médica** Las API estandarizadas necesitan un documento de normas en el que se describan los formatos de datos y los valores permitidos para cada «recurso» o tipo de datos que se intercambie. El estándar podría ser tan simple como especificar que todas las fechas tengan el formato mm/dd/aaaa, aunque los tipos de datos más complejos tendrán estándares correspondientemente más complejos. La atención médica genera muchos tipos de datos, desde simples hasta extremadamente complejos, y necesita un manual de instrucciones extenso y detallado. Ese manual se llama_[Recurso de interoperabilidad rápida de atención médica](http://hl7.org/fhir/index.html)_ (FHIR, que se pronuncia «fuego») y es la que la Ley de Curaciones del Siglo XXI especifica que se utilizará para lograr la fácil interoperabilidad que describimos anteriormente antes de finales de este año. ¿Por qué el FHIR ha obtenido el respaldo federal? Varias razones: **Una gobernanza sólida.** El FHIR se gestiona mediante[Nivel de salud siete internacional (HL7)](http://www.hl7.org/about/index.cfm?ref=nav), una organización de desarrollo de normas de atención médica fundada en 1987 y con el apoyo (con tiempo, experiencia y dinero del personal) de todos los actores importantes de la tecnología de la información sanitaria. Uno de nosotros (John Glaser) forma parte de su consejo asesor. HL7 cuenta con más de 500 miembros corporativos y organizativos, entre ellos: - Proveedores de tecnología de la información sanitaria (por ejemplo, Epic, Cerner y Athena Health) - Agencias gubernamentales (por ejemplo, los Centros de Servicios de Medicare y Medicaid, los Centros para el Control y la Prevención de Enfermedades, la Administración de Alimentos y Medicamentos, el Departamento de Asuntos de Veteranos de los Estados Unidos, los Institutos Nacionales de Salud y la Agencia Europea de Medicamentos) - Sistemas de salud (por ejemplo, Mayo Clinic, Mass General Brigham, Kaiser Permanente, Centro Médico de la Universidad de Pittsburgh e Intermountain Healthcare) - Planes de salud (por ejemplo, Humana, Anthem, Aetna, Optum, Centene, Blue Cross Blue Shield Association, UnitedHealthcare y Cigna) - Empresas de tecnología de la información (por ejemplo, Apple, Microsoft y Google) - Empresas de tecnología y servicios de salud (por ejemplo, Accenture, CVS Health, Pfizer, Philips y Quest Diagnostics) - Organizaciones profesionales (por ejemplo, la Asociación Médica Estadounidense, el Colegio Estadounidense de Médicos, la Asociación Nacional de Centros de Salud Comunitarios y el Comité Nacional de Control de Calidad) HL7 ha mantenido un control estricto sobre las normas del FHIR desde su desarrollo[comenzó en 2011](https://prolifics.com/history-of-fhir/). Este control es importante porque evita un problema frecuente con el desarrollo de las normas: la creación progresiva de excepciones a la norma. No se necesitan muchas excepciones para que el «estándar» deje de ser estándar. HL7 ha desarrollado un sólido conjunto de servicios para apoyar la implementación de la FHIR. Estos servicios incluyen[bancos de pruebas](https://en.wikipedia.org/wiki/Testbed), programas educativos y guías de implementación. La adopción y el uso de estándares requieren estándares bien diseñados _y_ firme apoyo a la implementación de esas normas. **Aceptación internacional.** El FHIR ha evolucionado hasta convertirse en un estándar mundial, no solo estadounidense. Para los desarrolladores de aplicaciones, esto aumenta el valor de adoptar los estándares. La documentación completa del FHIR está disponible actualmente en ruso, chino y japonés, además de en inglés. **Uso exitoso actual.** La industria ya está adoptando el FHIR y su uso aporta valor. - UN[encuesta de 2019](https://www.healthit.gov/buzz-blog/health-it/the-heat-is-on-us-caught-fhir-in-2019) mostró que el 84% de los hospitales y el 61% de los médicos han adoptado e implementado la tecnología API certificada habilitada por el FHIR. - [Los kits de desarrollo de software de Apple](https://www.apple.com/healthcare/health-records/) apoyar al FHIR. Varios cientos de sistemas de salud han creado aplicaciones que permiten a los pacientes agregar su información de salud y acceder a ella mediante la tecnología de Apple. - La comunidad de desarrolladores de aplicaciones, que incluye a Apple, Google y Microsoft, utiliza activamente un estándar específico de aplicaciones llamado[SMART en FHIR](https://smarthealthit.org/smart-on-fhir-community/) para crear aplicaciones compatibles con la FHIR. - La Clínica Mayo ha descubierto que las API del FHIR pueden reducir, hasta dos órdenes de magnitud, el tiempo y el coste de desarrollar interfaces entre aplicaciones. - [Un pagador pudo aprobarlo automáticamente](https://www.cambiagrove.com/programs-and-initiatives/cambia-grove-innovator-fellowship) El 80% de las autorizaciones previas para la artroplastia de rodilla tras cambiar su interfaz personalizada por una interfaz basada en la FHIR, lo que reduce los tiempos medios de aprobación de 20 minutos a 20 segundos. ## **Acelerar la transición** Se ha formado HL7[varios aceleradores](https://www.hl7.org/about/fhir-accelerator/) centrado en los segmentos objetivo del intercambio de información sobre el cuidado de la salud. La primera fue la[Proyecto Argonaut](https://confluence.hl7.org/display/AP/Argonaut+Project+Home), creada en 2014 para desarrollar los componentes básicos de las normas de la FHIR. Dentro de cada acelerador, los desarrolladores y los usuarios trabajan juntos para definir los «casos de uso» (los contextos en los que se producirá el intercambio de información propuesto) y los estándares de datos necesarios para respaldar esos casos de uso. Los aceleradores HL7 también desarrollan guías para respaldar la implementación de los estándares que desarrollan para que los vendedores las utilicen a la hora de crear productos de software o incorporar nuevas funciones a los productos existentes. Los participantes financian los esfuerzos de las aceleradoras y, según las directrices del HL7, establecen cómo funcionará la aceleradora (incluida la elección del nombre de la aceleradora). Algunos ejemplos: - [La Alianza CARIN](https://www.hl7.org/carin/) (Creando el acceso a la información en tiempo real ahora) se centra en el acceso de los consumidores a su información de salud y en el control de la misma. - [Código Dex](https://www.hl7.org/codex/) está abordando las necesidades de la investigación del cáncer, como la realización de ensayos clínicos con «datos del mundo real» recopilados de los EHR y la comparación de los pacientes con los ensayos clínicos. - [De Da Vinci](https://www.hl7.org/about/davinci/) los esfuerzos se centran en las interacciones entre los proveedores de atención médica y los planes de salud: la autorización previa, la confirmación de la cobertura del seguro médico del paciente y el acceso a la información sobre el precio de la atención. - [Helios](https://www.hl7.org/helios/), creada en otoño de 2021, se centra en los casos de uso de la salud pública, incluida la notificación de la incidencia de enfermedades como la covid-19, la gripe y las enfermedades de transmisión sexual. La adopción generalizada del FHIR está en sus primeras etapas. Sin embargo, creemos que es muy prometedor dada la fuerza de los vientos a favor del FHIR: - Estándares bien definidos y compatibles - La obligación federal de implementar las API en todas las aplicaciones que gestionan la información de salud - Una amplia gama de casos de uso para todos los aspectos de la atención médica - El compromiso de un amplio espectro de participantes de la industria Que quede claro, las personas no disfrutarán de un acceso inmediato y sin problemas a toda su información de salud antes de que acabe este año. La compatibilidad universal con el FHIR es una base, no la línea de meta. Los estándares aún están en desarrollo. Los sistemas antiguos deben modernizarse con las API del FHIR. Todas las entidades que gestionan datos de salud deben sentirse cómodas compartiéndolos. Pero al menos podemos empezar la carrera. Las API estándar hacen su magia con relativa rapidez: la App Store de Apple se lanzó en 2008 con 500 aplicaciones y en la actualidad tiene 2 millones. La Google Play Store (lanzada el mismo año) tiene casi 3 millones. Si bien la industria del software para el cuidado de la salud no tiene una sola entidad corporativa con el dominio de Google o Apple, el apoyo universal del que disfruta HL7 tiene el mismo propósito y, en muchos sentidos, facilita una mejor colaboración en la comunidad de usuarios. Para aprovechar las oportunidades que ofrecen las API del FHIR, los proveedores, los planes de salud y los vendedores de software deberían tomar varias medidas. **Obtenga la mayor información posible sobre las normas del FHIR y los reglamentos federales.** Las organizaciones deberían revisar el gobierno federal[resúmenes de agencias sobre el FHIR y la normativa relacionada](https://www.cms.gov/Regulations-and-Guidance/Guidance/Interoperability/index) y aproveche los recursos que siempre acompañan a un cambio de esta magnitud: reuniones, seminarios web y artículos del sector. La reunión del HIMSS de 2022, la mayor reunión de TI sanitaria del mundo, incluirá casi 40 sesiones sobre varios aspectos de la implementación del FHIR, desde la autorización previa hasta la investigación del cáncer y la transparencia de los costes de la atención médica. **Participe en el programa acelerador HL7 FHIR.** Estas actividades de desarrollo necesitan una amplia participación para garantizar que las normas respondan a las necesidades de todos. **Desarrolle planes de implementación para migrar las interfaces antiguas actuales a las API del FHIR.** El incumplimiento de la normativa corre el riesgo de sanciones y problemas en el mercado. Además, dado el siguiente punto, las API proporcionan la base para la próxima generación de aplicaciones de atención médica. **Prepárese para identificar y evaluar las nuevas aplicaciones que facilita el FHIR.** Una ola de innovaciones acompañará a la implementación del FHIR para abordar cualquier problema que pueda resolverse con un mejor flujo de información. Pero recuerde que las API del FHIR son la base y cualquier solución nueva requiere la misma diligencia debida de siempre. El nuevo mandato federal permitirá y obligará a eliminar las persistentes barreras tecnológicas y empresariales al flujo de la información de salud y, en el proceso, creemos que acelerará una ola de innovación que rara vez se ha visto en este rincón históricamente aburrido del mundo de la TI. El FHIR acelerará la implementación de cualquier aplicación que dependa de un intercambio de información complejo, como[hacer coincidir a los donantes de órganos con los receptores](/2021/12/electronic-health-records-can-improve-the-organ-donation-process) o[identificar situaciones en las que el riesgo de mortalidad materna es elevado](/2021/08/how-ai-could-help-doctors-reduce-maternal-mortality). Y esperamos (y esperamos) que llegue un día en el que todos podamos dejar de preocuparnos por estropear accidentalmente nuestro registro de vacunación contra la COVID-19.