Más allá del análisis de X12: Cerrando la brecha para los flujos de trabajo del ciclo de ingresos en la atención médica

Son las 8 AM del lunes. Un facturador médico abre su cola.

Durante el fin de semana, los archivos de remesas 835 del viernes aterrizaron perfectamente en su data lake. Cada Código de Razón de Ajuste de Reclamación (CARC) y código de Ajuste a Nivel de Proveedor (PLB) fue analizado, decodificado y normalizado. De las 412 reclamaciones en el archivo, 38 tienen pago insuficiente. La ventana de presentación de reclamaciones a tiempo para la denegación más antigua vence en 27 días.

Ella tiene todos los datos que necesita. Lo que no tiene es un lugar para actuar sobre ellos.

En cambio, pasa la mañana revisando manualmente los bucles 2100 y 2110, los detalles anidados de reclamaciones y líneas de servicio incrustados en cada archivo EDI, en una consulta SQL, copiando pagos insuficientes a una hoja de cálculo y conciliándolos contra un registro de pagos. Para cuando realmente levanta el teléfono para disputar una denegación, la mitad de su día ha desaparecido.

Según KFF, las aseguradoras denegaron 1 de cada 5 reclamaciones dentro de la red en HealthCare.gov en 2023, y menos del 1% de esas denegaciones fueron apeladas, lo que significa que la mayoría de los pagos insuficientes simplemente se quedan cortos.

La realidad de la TI moderna de la atención médica es esta: El problema de los datos está en gran medida resuelto. El problema del flujo de trabajo no lo está.

Esta es la brecha operativa en X12 de la atención médica: la capa faltante justo encima del motor de análisis. Para solucionarlo, Genpact y Databricks construyeron un banco de trabajo operativo unificado que reside completamente dentro de su entorno Databricks existente. La PHI nunca abandona su perímetro seguro, la interfaz de usuario consulta los datos en su lugar y la seguridad a nivel de fila se aplica automáticamente.

Así es como sacamos a sus facturadores de las hojas de cálculo y los devolvemos a trabajar con las reclamaciones.

Donde el Pipeline Suele Detenerse

X12 sigue siendo la columna vertebral del pago de la atención médica en EE. UU. (835, 834, 837). El analizador x12-edi de código abierto, creado por el equipo de Databricks, es el punto de partida perfecto. Toma archivos sin procesar, comprende los bucles y escribe registros normalizados en Delta Lake.

Pero mientras que eso permite a un analista de datos realizar una consulta SQL, no permite a un facturador presentar una apelación.

El pipeline de medallas desde archivos X12 sin procesar hasta la interfaz de usuario React, con el límite de PHI de Unity Catalog claramente delimitado alrededor de las capas de datos Bronze/Silver/Gold para mostrar el cumplimiento.

Lo Que Construimos: El Banco de Trabajo Operativo

Para cerrar esta brecha, construimos una solución en dos capas: extendiendo el analizador subyacente para la realidad de grado de producción y construyendo una superficie operativa segura e intuitiva para su equipo.

Capa 1: Extensión del Motor

Las necesidades de RCM del mundo real requieren búsquedas que los analizadores de código abierto estándar no siempre capturan. Extendimos el motor para incluir:

• Inscripción Contextual (834): Seguimiento de patrocinadores y dependencias de extremo a extremo.
• Ajustes Decodificados (835): Campos de grupo/razón de CAS decodificados por tabla de códigos. Esta es la diferencia entre un facturador mirando "CO-45" y leyendo "CO-45: el cargo excede el calendario de tarifas" en su pantalla.
• Contribuciones Previas: No bifurcamos el código; estas extensiones de esquema y prueba se envían directamente a la comunidad de código abierto.

Capa 2: El Escritorio del Facturador

Esta es la superficie operativa: una aplicación web segura que se asienta directamente sobre su conector Databricks SQL. Cada número en cada pantalla es una consulta en vivo contra una vista gold de Unity Catalog. No hay copia sombra de ETL ni caché sincronizada.

El banco de trabajo presenta seis vistas principales diseñadas para la forma en que los equipos de RCM realmente trabajan:

Trabajando las Reclamaciones:

• El Cajón de Remesas (835): Un facturador ve exactamente qué códigos CARC están impulsando la brecha entre lo facturado y lo pagado. Pueden abrir cualquier reclamación hasta el detalle de la línea de servicio y redactar una apelación o corrección sin salir de la pantalla.
• Banco de Trabajo de Denegaciones: Las ventanas de presentación a tiempo hacen de la antigüedad la métrica más crítica en el piso. Las filas se ponen rojas cuando superan los 30 días. Puede filtrar por pagador, CARC o cola. El estado del filtro se codifica en la URL, lo que significa que un gerente puede copiar una lista de trabajo priorizada limpiamente en Slack para su equipo.
• Inscripción (834): Los coordinadores de beneficios pueden ver nuevos empleados, cambios de plan y terminaciones en una sola vista, con accesos directos de un clic al segmento exacto que falla cuando un registro no es válido.

El Banco de Trabajo de Denegaciones. Observe las dos filas que superan los 30 días en rojo, las insignias de antigüedad que señalan la criticidad y el total de dólares en riesgo que se muestra en la barra de estado para una visibilidad inmediata.

Se selecciona la reclamación CLM-4209. El cajón muestra tres líneas de servicio, decodifica el ajuste CO-45 a lenguaje claro y expone botones de acción directos para Redactar Apelación / Corrección.

Gestión del Piso:

• Panel de Liderazgo: Reclamaciones MTD, tasas de coincidencia de pagos, miembros activos y denegaciones abiertas en una sola vista. Si un feed de pagador se interrumpe, lo ve el mismo día.
• Puertas de Calidad: Los recuentos de segmentos que no coinciden significan que un pagador rechazará un archivo completo. Nuestra capa de calidad detecta esas discrepancias en la ingesta, antes de que se envíe el archivo.
• Auditoría y Seguridad: Cada revelación de PHI y cambio de estado del flujo de trabajo se registra. Si un usuario necesita acceso a PHI de "break-glass", el sistema requiere una razón escrita, que se registra automáticamente en la auditoría.

El modal de "break-glass" que muestra el bloqueo de seguridad, el campo de razón prellenado, la advertencia de cumplimiento de HIPAA y la vista previa de la entrada de registro antes de que el facturador confirme el acceso.

Mirando Hacia el Futuro: Redacción de Apelaciones con GenAI

Poner los datos frente al facturador es el primer paso. El segundo paso es acelerar el trabajo.

La próxima frontera para este banco de trabajo es la integración de un modelo Claude a través de las API de modelos fundacionales de Databricks. Pronto, el sistema leerá el código CARC, extraerá el 837 original, revisará la documentación clínica y redactará dinámicamente la carta de apelación. En lugar de escribir desde cero, su facturador simplemente actúa como revisor y aprobador.

Pruébelo con Sus Propios Datos

Implementar esto en su entorno es una cuestión de configuración, no de código. Se empareja perfectamente con el acelerador Databricks X12 EDI.

Dénos dos semanas, su esquema de Unity Catalog y veinte denegaciones ya en su cola. Mida el tiempo que su facturador tarda en procesar esas denegaciones hoy y luego mídelo procesando un grupo emparejado en el banco de trabajo.

Usted es dueño de los datos, usted es dueño del cronómetro y usted es dueño de la conclusión.

Para definir el alcance de esto para su organización, comuníquese con Neel Shapur (srineel.shapur@genpact.com) o Aaron Zavora en Databricks.

(Esta entrada del blog ha sido traducida utilizando herramientas basadas en inteligencia artificial) Publicación original