Além de analisar X12: Fechando a lacuna para fluxos de trabalho do ciclo de receita na área da saúde

É segunda-feira, 8h. Uma faturista médica abre sua fila.

Durante o fim de semana, os arquivos de remessa 835 de sexta-feira caíram perfeitamente em seu data lake. Cada Código de Motivo de Ajuste de Reivindicação (CARC) e código de Ajuste em Nível de Prestador (PLB) foi analisado, decodificado e normalizado. Das 412 reivindicações no arquivo, 38 estão com pagamento a menor. A janela de prazo para apresentação da apelação da negação mais antiga está a 27 dias de distância.

Ela tem todos os dados de que precisa. O que ela não tem é um lugar para agir sobre eles.

Em vez disso, ela passa a manhã percorrendo manualmente os loops 2100 e 2110, os detalhes aninhados de reivindicações e linhas de serviço embutidos em cada arquivo EDI, em uma consulta SQL, colando pagamentos a menor em uma planilha e reconciliando-os com um registro de pagamento. Quando ela realmente pega o telefone para contestar uma negação, metade do seu dia se foi.

De acordo com a KFF, as seguradoras negaram 1 em cada 5 reivindicações dentro da rede no HealthCare.gov em 2023, e menos de 1% dessas negações foram contestadas, o que significa que a maioria dos pagamentos a menor simplesmente permanecem a menor.

A realidade da TI moderna em saúde é esta: O problema dos dados está em grande parte resolvido. O problema do fluxo de trabalho não está.

Esta é a lacuna operacional em X12 de saúde – a camada ausente logo acima do motor de análise. Para corrigi-lo, Genpact e Databricks construíram uma bancada de trabalho operacional unificada que reside inteiramente em seu ambiente Databricks existente. O PHI nunca sai do seu perímetro seguro, a UI consulta os dados no local e a segurança em nível de linha é aplicada automaticamente.

Veja como tiramos suas faturistas de planilhas e as colocamos de volta no trabalho com reivindicações.

Onde o Pipeline Geralmente Para

X12 continua sendo a espinha dorsal do pagamento de saúde nos EUA (835, 834, 837). O parser de código aberto x12-edi-parser, de autoria da equipe Databricks, é o ponto de partida perfeito. Ele pega arquivos brutos, entende os loops e grava registros normalizados no Delta Lake.

Mas, embora isso leve um analista de dados a uma consulta SQL, não leva uma faturista a uma apelação.

O pipeline de medalhão de arquivos X12 brutos até a UI React, com o limite de PHI do Unity Catalog claramente tracejado em torno das camadas de dados Bronze/Silver/Gold para mostrar conformidade.

O Que Construímos: A Bancada de Trabalho Operacional

Para preencher essa lacuna, construímos uma solução em duas camadas: estendendo o parser subjacente para a realidade de nível de produção e construindo uma superfície operacional segura e intuitiva para sua equipe.

Camada 1: Estendendo o Motor

As necessidades de RCM do mundo real exigem consultas que os parsers de código aberto padrão nem sempre capturam. Estendemos o motor para incluir:

• Inscrição Contextual (834): Rastreamento de ponta a ponta de patrocinadores e dependências.
• Ajustes Decodificados (835): Campos de grupo/motivo CAS decodificados por tabela de códigos. Esta é a diferença entre uma faturista olhando para "CO-45" versus lendo "CO-45: o custo excede a tabela de honorários" em sua tela.
• Contribuições Upstream: Não fizemos um fork do código; essas extensões de esquema e teste são enviadas de volta para a comunidade de código aberto.

Camada 2: A Área de Trabalho da Faturista

Esta é a superfície operacional – um aplicativo web seguro que fica diretamente sobre o seu conector Databricks SQL. Cada número em cada tela é uma consulta ao vivo contra uma visão gold do Unity Catalog. Não há cópia sombra de ETL nem cache sincronizado.

A bancada de trabalho possui seis visualizações principais projetadas para a forma como as equipes de RCM realmente trabalham:

Trabalhando as Reivindicações:

• A Gaveta de Remessa (835): Uma faturista vê exatamente quais códigos CARC estão impulsionando a lacuna entre o faturado e o pago. Elas podem abrir qualquer reivindicação até o detalhe da linha de serviço e redigir uma apelação ou correção sem sair da tela.
• Bancada de Trabalho de Negações: As janelas de prazo para apresentação de apelações tornam a idade a métrica mais crítica no chão de fábrica. Linhas ficam vermelhas quando ultrapassam 30 dias. Você pode filtrar por pagador, CARC ou fila. O estado do filtro é codificado na URL, o que significa que um gerente pode colar uma lista de trabalho priorizada no Slack para sua equipe.
• Inscrição (834): Coordenadores de benefícios podem ver novos contratados, mudanças de plano e rescisões em uma única visualização, com cliques para detalhar o segmento exato que falhou.

A Bancada de Trabalho de Negações. Observe as duas linhas com mais de 30 dias em vermelho, os indicadores de idade chamando a atenção para a criticidade e o total de dólares em risco na barra de status para visibilidade imediata.

A reivindicação CLM-4209 está selecionada. A gaveta exibe três linhas de serviço, decodifica o ajuste CO-45 em linguagem clara e expõe botões de ação diretos para Rascunhar Apelação / Correção.

Gerenciando o Chão de Fábrica:

• Painel de Liderança: Reivindicações MTD, taxas de correspondência de pagamento, membros ativos e negações abertas em uma única visualização. Se um feed de pagador falhar, você verá no mesmo dia.
• Portões de Qualidade: Contagens de segmentos incompatíveis significam que um pagador rejeitará um arquivo inteiro. Nossa camada de qualidade detecta essas incompatibilidades na ingestão, antes que o arquivo seja enviado.
• Auditoria e Segurança: Cada revelação de PHI e mudança de estado do fluxo de trabalho é registrada. Se um usuário precisar de acesso a PHI de emergência, o sistema exigirá um motivo escrito, que é automaticamente registrado em auditoria.

O modal de acesso de emergência mostrando o bloqueio de segurança, o campo de motivo pré-preenchido, o aviso de conformidade HIPAA e a visualização da entrada de log antes que a faturista confirme o acesso.

Olhando para o Futuro: Redação de Apelações com GenAI

Colocar os dados na frente da faturista é o primeiro passo. O segundo passo é acelerar o trabalho.

A próxima fronteira para esta bancada de trabalho é a integração de um modelo Claude via APIs do Databricks Foundation Model. Em breve, o sistema lerá o código CARC, buscará o 837 original, revisará a documentação clínica e redigirá dinamicamente a carta de apelação. Em vez de escrever a partir de uma página em branco, sua faturista simplesmente atua como revisora e aprovadora.

Experimente com Seus Próprios Dados

A implantação disso em seu ambiente é uma questão de configuração, não de código. Ele se integra perfeitamente com o acelerador Databricks X12 EDI.

Dê-nos duas semanas, seu esquema do Unity Catalog e vinte negações já em sua fila. Cronometre sua faturista trabalhando nessas negações hoje – depois cronometre-as trabalhando em um coorte correspondente na bancada de trabalho.

Você é dono dos dados, você é dono do cronômetro e você é dono da conclusão.

Para dimensionar isso para sua organização, entre em contato com Neel Shapur ([email protected]) ou Aaron Zavora na Databricks.

(Esta publicação no blog foi traduzida utilizando ferramentas baseadas em inteligência artificial) Publicação original