|
11 min de lectura
|

Implementación del cumplimiento con CMS: un enfoque basado en FHIR

Resumir este artículo con:
ChatGPTPerplexityClaudeGrok
Watch the Prior Authorization Architecture Demo

See how CRD, DTR, and PAS actually plug into a legacy UM system with no native FHIR support — the piece of CMS-0057-F most payers underestimate:

  • Connecting CRD, DTR, and PAS to a UM system with no native FHIR support
  • Out-of-the-box vs. custom build — where each wins, where each breaks

We'll email the recording straight to your inbox.

Prior Auth demo · legacy UM integration · buy vs. build

CMS-0057 readiness, starting from your architecture

Book a collaborative architecture review with our engineering team and see exactly where your systems stand on CMS-0057.

We review your data flows, integration patterns, and API layers, then highlight where your architecture already supports CMS-0057 and where it may struggle under real-time FHIR and ePA workloads. The outcome is a clear architectural picture your team can take straight into roadmap planning.

45 minutes · architect-to-architect · no sales pitch

¿Se encuentra ante la necesidad de cumplir con las normativas de CMS? En este artículo me gustaría contarles nuestra experiencia en el proceso de adecuación de un sistema médico heredado de un plan de salud estadounidense a los requisitos de CMS.

En primer lugar, analicemos qué es exactamente el cumplimiento con CMS. Según la regla final de interoperabilidad y acceso a datos del paciente de CMS (CMS-9115-F), si un plan de atención sanitaria trabaja con pacientes de CMS, debe cumplir con sus normativas. En resumen, para cumplir con CMS, los planes de salud deben compartir sus directorios de proveedores, reclamaciones, formularios y datos clínicos con sus miembros. Esto significa que dichos planes de salud deben disponer de datos médicos consistentes en formato FHIR, además de proporcionar acceso mediante API compatible con FHIR a esos datos.

Veamos ahora nuestra experiencia real trabajando con un plan de salud estadounidense y haciendo que su sistema cumpliera con FHIR mediante una nueva solución basada en Aidbox. También repasaremos los desafíos técnicos específicos que encontramos y explicaremos exactamente cómo los resolvimos.

Este artículo será de utilidad para directores de tecnología, responsables técnicos, gestores de proyectos, líderes de equipo y otros expertos técnicos que sean responsables de adecuar su sistema de información sanitaria al cumplimiento con CMS.

Siga leyendo para descubrir:

  • El origen del proyecto de cumplimiento con CMS
  • Los requisitos de la solución de integración basada en Aidbox
  • Las funcionalidades y características de Aidbox utilizadas
  • Los desafíos de la integración
  • La estructura y el flujo de trabajo del adaptador de integración

Una breve nota sobre mí: me llamo Paul Chayka, soy líder de equipo y gestor de proyectos en WaveAccess, y trabajo con sistemas de información sanitaria e integración FHIR.

Origen del proyecto

Permítanme ofrecer una breve descripción del origen del proyecto. El plan de salud estadounidense se encontró ante la necesidad de cumplir con CMS y comenzó a buscar una plataforma FHIR. Decidieron utilizar Aidbox y solicitaron a Health Samurai que integrara una solución basada en Aidbox en su ecosistema digital existente e implementara la integración FHIR de sus datos médicos según las normativas de CMS.

Los resultados de la investigación inicial mostraron que la estructura de los datos médicos en el sistema del cliente era propietaria y que se requería una solución de integración personalizada. Por ello, Health Samurai solicitó a WaveAccess, en calidad de empresa asociada, que colaborara en la implementación de las integraciones FHIR personalizadas y en la integración de la solución en el entorno del cliente.

Recopilación de requisitos

El primer paso fue la recopilación de requisitos. Nuestro equipo analizó las solicitudes del cliente y elaboró una lista de requisitos que debía cumplir la futura solución de integración:

  • Los datos médicos deben convertirse a recursos FHIR según las guías de implementación FHIR predefinidas por CMS
  • Los datos médicos deben almacenarse en formato FHIR en Aidbox
  • El proceso de integración debe ejecutarse de forma periódica según los plazos predefinidos por CMS
  • La solución debe proporcionar acceso mediante API compatible con FHIR a esos datos
  • Algunos conjuntos de datos deben ser públicos y otros deben estar protegidos

De acuerdo con estos requisitos, el esquema básico de la solución se muestra a continuación:

integration pipeline

El sistema heredado envía datos médicos en formato CSV a la plataforma FHIR. Estos datos son recibidos por la capa de integración, que también desempeña el papel de adaptador entre el sistema y Aidbox. En este módulo, los datos médicos se transforman en recursos FHIR y se envían a Aidbox, que también proporciona una API compatible con FHIR. Esta puede ser utilizada por los desarrolladores de portales para miembros y aplicaciones móviles para ofrecer a los miembros acceso a sus datos.

Aidbox

Aidbox es una plataforma basada en metadatos y en FHIR. Puede utilizarse como almacenamiento FHIR que también proporciona una API FHIR, así como como backend para el sistema de información sanitaria. Aidbox ofrece determinadas funcionalidades y características que utilizamos en este proyecto. Veámoslas a continuación.

Almacenamiento FHIR

Como solución avanzada de almacenamiento FHIR, Aidbox puede utilizarse para almacenar todo tipo de recursos FHIR, incluidos los recursos empleados en las guías de implementación FHIR de las normativas de CMS. Además, Aidbox ofrece funcionalidad adicional para la personalización de recursos y la creación de nuevos recursos.

API FHIR

Aidbox proporciona una API FHIR y una pasarela de API. Cumple todos los requisitos RESTful de HL7 FHIR y dispone de todos los parámetros de búsqueda predeterminados de los recursos FHIR. Los usuarios de Aidbox también pueden personalizar los parámetros de búsqueda y crear otros nuevos.

Carga de datos

Aidbox ofrece varias formas de cargar datos:

  • API REST. Una API REST es una solución sencilla para crear y actualizar un recurso. Sin embargo, si necesita cargar múltiples registros al mismo tiempo, este método no es adecuado, ya que tendría que realizar un gran número de llamadas a la API.

  • Batch Upsert. Para múltiples registros, Aidbox proporciona la inserción por lotes (batch upsert). Esto permite a los usuarios aprovechar todas las ventajas de la API CRUD, pero para múltiples registros. Este método permite controlar el estado de carga de cada registro individual. Aidbox valida inmediatamente el cumplimiento de los registros con el perfil especificado y mantiene un historial por cada registro. Si necesita cargar una cantidad muy grande de datos, este método no es óptimo, ya que todas las funciones adicionales ralentizarán la carga.

  • Bulk Import API. Si necesita cargar decenas de miles de registros o más, es preferible utilizar la Bulk API. Permite cargar una cantidad ilimitada de datos a la máxima velocidad. Sin embargo, la validación de datos no se realizará y el historial estará desactivado por defecto. Deberá controlar la calidad de los datos cargados de antemano. Para cargar los datos, necesitará generar un archivo NDJSON y subirlo a un repositorio con un enlace público, o con URL firmadas de Amazon S3 o Google Cloud Storage. Como alternativa, puede añadir credenciales para acceder al almacenamiento en Aidbox.

Seguridad

Aidbox incluye un módulo de autenticación integrado que proporciona:

  • Diversas implementaciones de servidor de autenticación (OAuth 2.0 y OpenID)
  • Autorización entre dominios y módulo de gestión de grupos
  • Flujos de registro e inicio de sesión con correo electrónico o número de teléfono
  • Inicio de sesión con Google, Facebook, Auth0, etc.
  • Acceso mediante JSON Web Token con Aidbox como servidor de recursos

Aidbox ofrece un modelo flexible para personalizar las reglas de autorización de solicitudes. Los usuarios pueden declarar un conjunto de comprobaciones para todas las solicitudes entrantes. Si una solicitud entrante satisface dichas comprobaciones, se considera «Autorizada» y se procesa. En caso contrario, la solicitud se deniega y el cliente recibe el error «403 No autorizado». Estas comprobaciones se declaran mediante el recurso AccessPolicy.

Despliegue

Aidbox dispone de una infraestructura cloud automatizada construida sobre Kubernetes (K8s) para AWS, Azure y GCP, y ofrece soluciones para copias de seguridad, monitorización y registro de forma integrada. Esta infraestructura puede utilizarse para desplegar otras partes de la aplicación en desarrollo. A continuación se muestra la lista completa de características de la infraestructura de Aidbox:

  • Pipeline de CI/CD automatizado: Drone CI / Kustomize para K8s
  • Replicación de bases de datos y copias de seguridad para alta disponibilidad y recuperación ante desastres
  • Registro de auditoría basado en Elasticsearch / Kibana / Grafana
  • Monitorización basada en Prometheus y Grafana
  • Almacenamiento de archivos para guardar ficheros y documentos
  • Gestor de certificados SSL para garantizar el cifrado de los datos en tránsito
  • Todas las demás salvaguardas técnicas de HIPAA

Comience a utilizar el servidor FHIR de Aidbox para el almacenamiento de datos, integraciones, análisis sanitario y mucho más, o contrate a nuestro equipo para satisfacer sus necesidades de desarrollo de software.

Resumen

Como puede apreciarse, Aidbox proporciona un servidor FHIR de alto rendimiento, infraestructura basada en la nube y una API FHIR segura y compatible. Puede servir como backend integral para un sistema de información sanitaria moderno. Sin embargo, en este proyecto nos enfrentamos a desafíos adicionales que nos obligaron a ampliar Aidbox con un módulo de integración adicional. En la siguiente sección, analizaremos estos desafíos y veremos exactamente cómo nuestra solución de integración personalizada los resolvió.

Aidbox FHIR Platform

Adaptador de integración FHIR

Capa de integración

Como mencioné anteriormente, los datos médicos del cliente no seguían ningún estándar del sector. Aidbox dispone de un adaptador EDI integrado para los estándares más comunes de datos sanitarios, como HL7 v.2 y X12, pero en nuestra situación necesitábamos desarrollar una solución de integración personalizada. Para empezar, mi equipo preparó una lista de las funcionalidades principales para el futuro adaptador:

  • Conexión con la fuente de datos del sistema heredado
  • Conversión de datos médicos a recursos FHIR
  • Conexión con Aidbox
  • Envío de recursos FHIR a Aidbox

Estructura general

En el caso general, la arquitectura del adaptador tenía el siguiente aspecto:

FHIR adapter - first version

El adaptador recibía los datos médicos del sistema heredado, los transformaba en recursos FHIR y los enviaba a Aidbox. Durante el proceso de desarrollo, nos enfrentamos a desafíos adicionales:

  • El sistema heredado contenía una cantidad considerable de datos.
  • Los datos médicos existentes podían modificarse con el tiempo.
  • Los registros médicos no tenían claves primarias.
  • El sistema heredado no proporcionaba campos como «lastModifyDate» ni otros indicadores de modificación.

Por lo tanto, tuvimos que mejorar nuestro adaptador para resolver estos desafíos.

Consistencia de datos

Los procesos de integración deben ejecutarse de forma periódica. ¿Cómo podemos garantizar que los datos en Aidbox sean consistentes? La opción más sencilla es eliminar todos los datos correspondientes de Aidbox antes de cada integración y cargar los datos desde cero. La principal desventaja de este enfoque es el tiempo de integración extremadamente largo. Habitualmente, los datos no cambian mucho, y si pudiéramos encontrar una manera de rastrear los cambios y omitir los datos que no han cambiado durante el período anterior, el tiempo de integración mejoraría drásticamente.

En primer lugar, debemos dividir los datos entrantes en nuevos y modificados. El esquema del adaptador debería tener el siguiente aspecto:

FHIR Adapter with versioning

Pero ¿cómo podemos saber qué registros son nuevos y cuáles deben actualizarse? Recuérdese que en estos datos no había claves primarias. Para superar este desafío, necesitamos añadir un nuevo módulo de historial que calcule los hashes de los registros y los almacene junto con los IDs de FHIR. De este modo, podemos diferenciar un registro nuevo de uno existente. Además, incluso podemos determinar si el registro existente ha sido modificado y omitir operaciones de actualización innecesarias.

Almacenamiento de datos y registro

Para proporcionar la funcionalidad del módulo de historial, necesitamos almacenar los hashes de los registros junto con los IDs de FHIR en el almacenamiento de datos. El adaptador utiliza la base de datos PostgreSQL de Aidbox para este propósito. Disponemos de una tabla de historial independiente para cada perfil FHIR utilizado en las integraciones. Para la funcionalidad de registro, utilizamos la pila ELK de Aidbox.

En algunos casos, el adaptador de integración debe desplegarse de forma independiente a Aidbox; por ejemplo, cuando un cliente no desea exponer su almacenamiento de datos médicos fuera de su entorno interno. En este caso, el adaptador puede instalarse de forma independiente en el entorno seguro del cliente, mientras que Aidbox puede estar basado en la nube. Para aumentar la personalización del adaptador y preservar el nivel de seguridad del cliente, añadimos la funcionalidad para instalar el adaptador como solución independiente. Puede utilizar una base de datos PostgreSQL personalizada para almacenar los datos de historial y una instancia ELK personalizada para el registro.

Flujo de trabajo del adaptador

El diagrama final de nuestro adaptador se muestra a continuación:

FHIR Adapter workflow

En primer lugar, el adaptador lee los datos del almacenamiento de datos médicos del sistema heredado; la fuente de datos puede presentarse en diferentes formas, siendo la más común la base de datos SQL.

Tras la extracción de los datos, el adaptador los convierte a los recursos especificados por FHIR de acuerdo con las guías de implementación requeridas. Como resultado, se obtendrá un conjunto de recursos FHIR consistentes que deben cargarse en Aidbox.

Tras el proceso de conversión, la solución calcula diferentes hashes para los recursos resultantes y los compara con los hashes de los recursos ya cargados. A continuación, el adaptador determina qué recursos fueron cargados en la iteración de integración anterior y deben actualizarse, qué recursos de la operación de integración anterior han quedado obsoletos y cuáles son nuevos.

Por último, el adaptador carga y actualiza los recursos nuevos y modificados, y elimina los obsoletos. Al mismo tiempo, almacena los hashes de los nuevos recursos en la base de datos. A lo largo de todo el proceso, el adaptador proporciona registros con una descripción del paso actual de la iteración de integración.

Detalles técnicos

El adaptador utiliza la siguiente pila tecnológica:

  • Java 11
  • PostgreSQL 11
  • Spring 5, Spring Boot 2
  • Hibernate 5, MyBatis 3
  • Maven
  • Amazon S3, Google Cloud Storage
  • Kubernetes, Docker

El diagrama de arquitectura de alto nivel se muestra a continuación:

Technical details - diagram

El adaptador de integración se utiliza para extraer datos de la fuente de datos del cliente, convertir dichos datos al estándar FHIR y enviarlos a Aidbox. Puede utilizar la base de datos PG de Aidbox como almacenamiento de historial, así como la pila ELK de Aidbox para el registro. Como alternativa, esta solución puede desplegarse de forma independiente a Aidbox. En ese caso, el adaptador puede utilizar su propia base de datos PG y su propia pila ELK. También dispone de una API REST para la inicialización manual de los procesos de integración.

Resumen técnico

Desarrollamos nuestro adaptador de integración FHIR como una extensión de integración para Aidbox. Es una solución personalizable con un conjunto de bibliotecas desarrolladas para la ejecución eficiente, rápida y flexible de operaciones de lectura de datos de diversas fuentes, conversión a recursos FHIR y carga en Aidbox.

Para concluir esta sección, me gustaría enumerar las ventajas del adaptador de integración FHIR:

  • El adaptador utiliza y personaliza bibliotecas fiables y en evolución, que ofrecen un gran número de posibilidades para interactuar con Aidbox, convertir recursos y otras funcionalidades que pueden reducir significativamente el tiempo de desarrollo.
  • El adaptador ofrece posibilidades integradas para la integración con los tipos más comunes de fuentes de datos, como bases de datos SQL, almacenamiento S3 y otras.
  • El adaptador proporciona diversas formas de interactuar con Aidbox, ya sea mediante una descarga de un único recurso, una descarga por lotes, una descarga de archivos comprimidos, etc.
  • El adaptador ofrece una capacidad de actualización incremental que le permite calcular y cargar eficientemente solo los recursos modificados durante cada nueva iteración de actualización.
  • El adaptador proporciona operaciones transaccionales y controla la integridad de los datos para que Aidbox no contenga recursos inconsistentes.

Conclusiones

En este artículo hemos compartido nuestra experiencia ayudando a un plan de salud estadounidense a cumplir con las normativas de CMS. Nos asociamos con Health Samurai e integramos Aidbox en el ecosistema digital del cliente mediante el adaptador de integración FHIR, desarrollado por nuestro equipo. Como resultado, hemos diseñado una solución de integración FHIR totalmente personalizable que puede ayudar a cualquier organización que trabaje con datos sanitarios a transferirlos al formato FHIR y mantenerlos consistentes de manera oportuna y sin complicaciones.

Si se encuentra ante la necesidad de cumplir con CMS, desea integrarse con el estándar FHIR o simplemente tiene alguna pregunta, no dude en ponerse en contacto con nosotros. Nosotros y el equipo de Health Samurai estaremos encantados de ayudarle.

Para explorar cómo puede integrarse el cumplimiento con CMS en sus sistemas, pruebe la versión gratuita de Aidbox. Ofrece un entorno completo para probar e implementar medidas de cumplimiento, proporcionando todas las herramientas necesarias sin ninguna limitación de funcionalidades.

Autor: Paul Chayka, Experto en soluciones sanitarias | Gestor de Proyectos y Líder de Equipo en WaveAccess WaveAccess Logo

Aidbox FHIR Platform for CMS

Véase también: Cumplimiento de la Ley de Curas del Siglo XXI.

Compartir este artículo
Comments
Comments
Sign in
Loading comments...
Subscribe to our blog

Get the latest articles on FHIR, interoperability, and healthcare IT.