Las API estandarizadas finalmente podrían facilitar el intercambio de registros de salud

Una ley federal exige que la información de salud sea fácil de intercambiar para fines de este 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 proveedores de software deben tomar varias medidas para capitalizar 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 llegó el Covid-19 con un recordatorio del desastre que puede ser.
Nos enfrentamos a opciones defectuosas para almacenar y acceder a nuestra información de vacunación contra el: una tarjeta de papel que es demasiado grande para nuestra billetera; una foto de la tarjeta guardada en nuestro teléfono para que el maître d' la mire con poca luz; tal vez tarjeta de vacunación electrónica slick descargado a través de un código QR de nuestro departamento de salud estatal que podemos guardar en nuestro Apple Wallet. ¡Pero espera! Solo tiene nuestras dos primeras tomas de la primavera pasada, y no la tercera de noviembre. Tal vez nuestro médico tenga una aplicación de portal donde podamos obtener nuestras vacunas, excepto por el refuerzo que recibimos en Walgreens.
En una época en la que las aplicaciones bancarias agregan toda nuestra información financiera a pedido y nuestro restaurante favorito puede recordar lo «habitual» cuando hacemos pedidos en línea, es desconcertante que un pedazo de cartón contenga la única prueba de vacunación de muchas personas.
Las cartillas de vacunación son solo un pequeño síntoma de un problema mayor. La información de salud de cualquier persona en particular suele estar dispersa en varios hospitales, clínicas y farmacias. Gran parte de los historiales médicos de la mayoría de las personas se pierden para cualquier 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 toda su atención dentro de un sistema de salud y se queda quieto, es posible que tenga algo parecido a un registro médico electrónico completo (EHR). De lo contrario, probablemente no.
Los proveedores de atención médica enfrentan estos mismos problemas. Incluso cuando usan el mismo software de registro de salud electrónico, 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 médica (HIE) operan en muchos estados y permiten a los proveedores compartir información demográfica básica e historias médicas, pero varían en utilidad y disponibilidad.
Sin embargo, los cambios exigidos por el gobierno federal están en marcha para simplificar significativamente el intercambio electrónico de cualquier información médica. Es difícil exagerar su potencial no solo para permitir a todos un acceso completo, completo y fácil a su información de salud personal, sino también para desbloquear innumerables formas nuevas de usar esa información, siempre y cuando las entidades que generan la información estén preparadas para aprovechar este avance en tecnología.
Obstáculos históricos para el intercambio de información sobre 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 computarizados? ¿Las computadoras no pueden comunicarse 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, el rendimiento no suele ser lo suficientemente grande o obvio 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 salten 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 avanzaba muy lentamente antes de que miles de millones de dólares en fondos federales de registros médicos electrónicos, asignados como parte de la Paquete de estímulo del gobierno de Obama promulgada en 2009, cambió la ecuación de la 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 médica de un ordenador a otro tiene su propia historia irregular. Muchos proveedores de software de atención médica han hecho un negocio lucrativo al crear interfaces personalizadas para conectar los diversos sistemas en uso en muchos hospitales, con ajustes facturables cada vez que el hospital adquiere una nueva aplicación o actualiza una existente. Además, los proveedores a menudo han bloqueado la portabilidad de datos como estrategia de retención de clientes. Si es difícil o costoso mover sus datos al sistema de un proveedor diferente, simplemente pasarán a la siguiente versión del que ya tienen. Algunos proveedores han tomado medidas para ayudar a los proveedores a compartir. Por ejemplo, el proveedor de EHR Epic permite a sus clientes intercambiar datos fácilmente si aceptan hacerlo de mutuo acuerdo. Pero no los puede hacer. Si dos clientes de Epic compiten en un mercado determinado, pueden decidir que no es lo mejor para sus intereses, incluso si es lo mejor para sus pacientes.
No es que la industria del cuidado de la salud carezca de estándares de datos, sino todo lo contrario. Pero a menudo los crean grupos con intereses en tipos específicos de datos, por ejemplo, estándares desarrollados para imágenes médicas por el Colegio Estadounidense de Radiólogos. Han hecho que el intercambio de datos sea algo menos complicado, pero no pueden resolver los otros problemas que discutimos.
Mientras tanto, los pacientes desconcertados no pueden acceder a su información de manera integral. Probablemente todo esté en una computadora en alguna parte, pero no hay una fuerza lo suficientemente poderosa como para compilarlo en un solo lugar y hacer que sea fácil de encontrar, y mucho menos usarlo para mejorar nuestra salud.
El gobierno federal interviene
Ingrese al gobierno federal, el único partido con suficiente influencia, cuando lo decide, para impulsar un cambio genuino en la industria del cuidado 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 niños, el sistema de atención médica de Asuntos de Veteranos, el sistema de atención médica 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 un requisito para fácil intercambio de datos de salud para finales de 2022. 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 lograr lo que se requiere, lo que también los coloca en el banquillo. Las regulaciones también establecen sanciones para los vendedores, proveedores y pagadores que continúen exhibiendo prácticas de «bloqueo de información» (que teóricamente deberían 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á tan lejos, ¿cómo va a cumplir esta misión la industria del cuidado de la salud? Al hacer algo, debería haber descubierto cómo hacerlo hace mucho tiempo sin necesidad de un mandato federal: adoptar un método estándar para que sus computadoras hablen entre sí.
El poder de las APIs
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 tener que hacer nada. Las API respaldan la capacidad de una aplicación de un desarrollador para leer y escribir datos de la aplicación de otro desarrollador.
Las APIs son en todas partes. Si ha extraído información de todas sus cuentas bancarias y de tarjetas de crédito en una aplicación de planificación financiera, fueron las API las que lo hicieron. Las API te permiten usar la información de tu 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 retomar 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 generó. (Para empezar, todos podrían tener una tarjeta de vacunación electrónica en su teléfono que se actualizaría automáticamente incluso si usaran un proveedor diferente para cada vacuna). Uso de API para desbloquear datos de registros médicos electrónicos podría brindar a las personas un acceso fácil y eficiente a sus propios datos para ayudarles a entender su salud y tomar decisiones más informadas. Los proveedores tendrán una imagen completa de la historia de cada paciente. Podrían usar esa información no solo para apoyar su toma de decisiones clínicas, sino también como parte del análisis de salud de la población para ver 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 de las formas en que los datos podrían usarse 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 estándares que describa los formatos de datos y los valores permitidos para cada «recurso» o tipo de datos que se va a intercambiar. El estándar podría ser tan simple como especificar que todas las fechas tendrán 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 grueso y detallado.
Ese manual se llama Recurso de interoperabilidad rápida en atención (FHIR, pronunciado «fuego»), y es el que la Ley de Curas del Siglo XXI especifica que se utilizará para lograr la fácil interoperabilidad que describimos anteriormente para fines de este año.
¿Por qué el FHIR ha obtenido el respaldo federal? Por varios motivos:
Gobernanza sólida. El FHIR se gestiona mediante Salud Nivel Siete Internacional (HL7), una organización de desarrollo de estándares de atención médica fundada en 1987 y apoyada (con tiempo, experiencia y dinero del personal) por todos los actores importantes de la tecnología de la información de salud. Uno de nosotros (John Glaser) forma parte de su consejo asesor. HL7 tiene más de 500 miembros corporativos y organizativos, que incluyen:
- Proveedores de tecnología de la información de salud (por ejemplo, Epic, Cerner y Athena Health)
- Agencias gubernamentales (por ejemplo, Centros de Servicios de Medicare y Medicaid, Centros para el Control y la Prevención de Enfermedades, Administración de Alimentos y Medicamentos, Departamento de Asuntos de Veteranos de los EE. UU., Institutos Nacionales de Salud y 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 atención médica (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 Garantía de Calidad)
HL7 ha mantenido un control estricto sobre los estándares de la FHIR desde su desarrollo iniciado en 2011. Este control es importante porque evita un problema frecuente con el desarrollo de estándares: la creación progresiva de excepciones al estándar. No se necesitan muchas excepciones antes de que el «estándar» ya no sea estándar.
HL7 ha desarrollado un conjunto sólido de servicios para apoyar la implementación del FHIR. Estos servicios incluyen bancos de pruebas, programas educativos y guías de implementación. La adopción y el uso de estándares requieren estándares bien diseñados y un fuerte apoyo a la aplicació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 actual con éxito. La industria ya está adoptando el FHIR y su uso está generando valor.
- A Encuesta 2019 mostró que el 84% de los hospitales y el 61% de los médicos han adoptado e implementado tecnología API certificada habilitada con el FHIR.
- Kits de desarrollo de software de Apple apoyar al FHIR. Varios cientos de sistemas de salud han creado aplicaciones que permiten a los pacientes agregar y acceder a su información de salud mediante la tecnología de Apple.
- La comunidad de desarrollo de aplicaciones, que incluye a Apple, Google y Microsoft, está utilizando activamente un estándar específico para aplicaciones llamado SMART en FHIR para crear aplicaciones compatibles con FHIR.
- Mayo Clinic descubrió que las API del FHIR pueden reducir, hasta dos órdenes de magnitud, el tiempo y el costo de desarrollar interfaces entre aplicaciones.
- Un pagador pudo aprobar automáticamente El 80% de las autorizaciones previas de reemplazo de rodilla después de cambiar su interfaz personalizada por una interfaz basada en FHIR, lo que reduce los tiempos de aprobación promedio de 20 minutos a 20 segundos.
Aceleración de la transición
HL7 se ha formado varios aceleradores centrado en segmentos objetivo del intercambio de información sobre la atención de salud. La primera fue la Proyecto Argonauta, establecido en 2014 para desarrollar los componentes básicos de las normas del FHIR. Dentro de cada acelerador, los desarrolladores y los usuarios trabajan juntos para definir «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 apoyar la implementación de los estándares que desarrollan para que los proveedores las usen en la creación de productos de software o la incorporación de nuevas funciones en productos existentes. Los participantes financian los esfuerzos de los aceleradores y, dentro de las pautas del HL7, establecen cómo funcionará el acelerador (incluida la elección del nombre del acelerador).
Algunos ejemplos:
- La alianza CARIN (Crear acceso a la información en tiempo real ahora) se centra en el acceso de los consumidores y el control de su información de salud.
- CódeX aborda 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 correspondencia de los pacientes con los ensayos clínicos.
- Da Vinci los esfuerzos se centran en las interacciones entre los proveedores de atención médica y los planes de salud: autorización previa, confirmación de la cobertura de seguro médico de un paciente y acceso a información sobre el precio de la atención.
- Helios, formada en el otoño de 2021, se centra en casos de uso de salud pública, incluida la notificación de la incidencia de enfermedades como Covid-19, influenza y enfermedades de transmisión sexual.
La adopción amplia del FHIR se encuentra en sus primeras etapas. Sin embargo, creemos que es muy prometedor dada la fuerza de los vientos de cola del FHIR:
- Estándares bien definidos y compatibles
- Un mandato federal para implementar las API en todas las aplicaciones que manejan 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
Para ser claros, las personas no disfrutarán de un acceso inmediato y sin interrupciones a toda su información de salud para fines de este año. La compatibilidad universal con FHIR es un punto de referencia, no la línea de meta. Los estándares aún están en desarrollo. Los sistemas heredados deben adaptarse con las API del FHIR. Todas las entidades que manejan datos de salud deben sentirse cómodas compartiéndolos.
Pero al menos podemos empezar la carrera. Las API estándar pueden hacer su magia con relativa rapidez: la App Store de Apple se lanzó en 2008 con 500 aplicaciones y hoy tiene 2 millones. La Google Play Store (lanzada el mismo año) tiene casi 3 millones. Si bien la industria del software de atención médica no tiene una sola entidad corporativa con el dominio de Google o Apple, el soporte 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 brindan las API del FHIR, los proveedores, los planes de salud y los proveedores de software deben tomar varias medidas.
Aprenda todo lo posible sobre las normas de la FHIR y las regulaciones federales. Las organizaciones deben revisar descripciones generales de la agencia sobre el FHIR y las regulaciones relacionadas y aproveche los recursos que siempre acompañan a un cambio de esta magnitud: reuniones, seminarios web y artículos de la industria. La reunión del HIMSS de 2022, la reunión de IT de salud más grande del mundo, presenta 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 costos de la atención médica.
Sea activo en el programa acelerador HL7 FHIR. Estas actividades de desarrollo necesitan una amplia aportación para garantizar que las normas respondan a las necesidades de todos.
Desarrollar planes de implementación para migrar las interfaces heredadas actuales a las API FHIR. El incumplimiento de las regulaciones corre el riesgo de sanciones y problemas en el mercado. Además, dado el siguiente punto, las API proporcionan una base para la próxima generación de aplicaciones de atención médica.
Esté preparado para identificar y evaluar aplicaciones novedosas que facilite el FHIR. Una ola de innovaciones acompañará la implementación del FHIR para abordar cualquier problema que pueda resolverse con un mejor flujo de información. Pero recuerde, 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 obstinadas barreras tecnológicas y comerciales al flujo de información de salud y, en el proceso, creemos que acelerará una ola de innovación que rara vez se ve en este rincón históricamente aburrido del mundo de IT. El FHIR acelerará la implementación de cualquier aplicación que dependa de un intercambio de información complejo, como hacer coincidir donantes de órganos con los receptores o identificar situaciones en las que el riesgo de mortalidad materna es elevado.
Y esperamos (y esperamos) que llegue el día en que todos podamos dejar de preocuparnos por lavar accidentalmente nuestro registro de vacunación contra el Covid-19.
John Glaser John Glaser Elizabeth Gardner