Seu Template de Dados de Gestão do Ciclo de Receita (RCM)

R1 RCM
Seu Template de Dados de Gestão do Ciclo de Receita (RCM)

Seu Template de Dados de Gestão do Ciclo de Receita (RCM)

Este template de dados oferece um roteiro claro para coletar as informações necessárias para analisar seu processo de RCM. Ele descreve os atributos essenciais e as atividades críticas para rastrear. Você também encontrará orientações de como extrair esses dados do seu sistema R1 RCM, preparando sua iniciativa de Process Mining de forma eficiente.
  • Atributos recomendados para coletar
  • Principais atividades para monitorar na descoberta de processos
  • Guia detalhado de extração para o R1 RCM
É novo em event logs? Saiba como criar um event log para Process Mining.

Atributos de Gestão do Ciclo de Receita (RCM)

Estes são os campos de dados recomendados para incluir no seu event log para uma análise completa do seu processo de Gestão do Ciclo de Receita.
5 Obrigatório 6 Recomendado 8 Opcional
Nome Descrição
Evento de Faturamento
BillingEvent
O identificador único para um serviço ou item faturável individual, servindo como o ID de caso principal para rastrear todo o ciclo de receita.
Descrição

O ID do Evento de Faturamento representa uma instância distinta de prestação de serviço ou produto que gera uma cobrança. Ele funciona como o fio condutor que conecta todas as atividades relacionadas, desde a prestação inicial e captura da carga até o envio da fatura, lançamento do pagamento e fechamento da conta.

No Process Mining, analisar o ciclo de vida de cada Evento de Faturamento permite uma visão completa do ciclo de receita de ponta a ponta. É usado para rastrear a jornada total de uma única cobrança, identificar caminhos comuns, medir tempos de ciclo entre marcos importantes e entender variações que causam atrasos ou perda de receita.

Por que é importante

Este identificador é essencial para agrupar todas as atividades relacionadas em um único caso, permitindo uma análise completa e precisa do ciclo de receita para cada evento faturável.

Onde obter

Esta é a chave primária que vincula tabelas de atendimentos, encargos, guias e pagamentos. Consulte a documentação do R1 RCM para o campo específico, geralmente ligado ao ID do atendimento ou da guia.

Exemplos
BE-2023-0012345BE-2023-0054321BE-2024-0098765
Nome da Atividade
ActivityName
O nome do evento de negócio ou tarefa específica que ocorreu em determinado momento dentro do processo de ciclo de receita.
Descrição

Este atributo descreve uma etapa ou marco individual dentro do processo de RCM para um evento de faturamento. As atividades representam o trabalho realizado, como 'Captura de Encargos', 'Fatura Enviada' ou 'Pagamento Lançado'.

Analisar a sequência de atividades é a base do Process Mining. Permite descobrir o fluxo real, identificar gargalos onde as atividades demoram a começar e detectar loops de retrabalho onde etapas são repetidas sem necessidade, como 'Fatura Glosada' seguida de 'Início de Retrabalho de Glosa'.

Por que é importante

Define as etapas do processo, permitindo a visualização do mapa de processos, o cálculo dos tempos de transição e a identificação de desvios e retrabalhos.

Onde obter

Esta informação geralmente deriva de logs de eventos, registros de mudança de status ou códigos de transação em vários módulos do R1 RCM. Pode exigir um mapeamento de códigos técnicos para nomes amigáveis ao negócio.

Exemplos
Encargos CapturadosSinistro SubmetidoAdjudicação do Pagador RecebidaPagamento LançadoConta Encerrada
Tempo do Evento
EventTime
O timestamp que indica quando uma atividade ou evento específico ocorreu.
Descrição

O Event Time fornece a data e hora precisas em que uma atividade foi registrada no sistema. Esta informação temporal é fundamental para entender o processo sob uma ótica de análise baseada no tempo.

No process mining, este timestamp é usado para ordenar os eventos cronologicamente e calcular a duração entre atividades, o que é crítico para a análise de desempenho. Ele permite o cálculo de métricas essenciais como tempo de ciclo, tempo de processamento e tempo de espera, fundamentais para identificar gargalos e medir a eficiência.

Por que é importante

Este timestamp é a base para todas as análises temporais, incluindo cálculo de tempos de ciclo, identificação de gargalos e monitoramento de performance em relação aos SLAs.

Onde obter

Normalmente encontrado em campos como 'Data de Criação', 'Timestamp' ou 'Data da Última Atualização' vinculados a transações ou mudanças de status no R1 RCM.

Exemplos
2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-11-05T09:12:45Z
Sistema de Origem
SourceSystem
O sistema de registro do qual os dados do evento foram extraídos.
Descrição

Este atributo identifica o aplicativo ou módulo de origem que gerou os dados de um evento. Em ambientes complexos de saúde, os dados podem vir de um prontuário eletrônico (PEP/EMR), módulo de faturamento, clearinghouse ou plataforma de cobrança.

Entender o sistema de origem é crucial para a validação dos dados e para analisar variações de processo que podem ser específicas de certos sistemas, ajudando a resolver inconsistências e entender o cenário tecnológico.

Por que é importante

Identifica a origem dos dados, o que é crucial para a governança de dados, validação e compreensão de como diferentes sistemas interagem no processo ponta a ponta.

Onde obter

Geralmente é um valor estático adicionado durante a extração de dados, identificando o sistema (ex: 'R1 RCM') de onde os dados se originam.

Exemplos
R1 RCMCernerEpic
Última Atualização de Dados
LastDataUpdate
O timestamp da atualização ou extração de dados mais recentes do sistema de origem.
Descrição

Este atributo indica a última vez que os dados da análise de Process Mining foram atualizados, dando contexto sobre quão recentes são as informações.

Isso é importante para relatórios e dashboards, informando ao usuário a atualidade dos insights. Ajuda a gerir expectativas sobre a pontualidade dos dados e garante que as decisões sejam tomadas com base em um período de tempo conhecido.

Por que é importante

Fornece um contexto crucial sobre a atualização dos dados, garantindo que analistas e stakeholders saibam quão recentes são os insights do processo.

Onde obter

Este timestamp é gerado durante o processo de extração, transformação e carga (ETL) e costuma ser aplicado a todo o conjunto de dados.

Exemplos
2024-05-20T08:00:00Z2024-05-21T08:00:00Z
Código do Motivo da Glosa
DenialReasonCode
Um código padronizado do pagador explicando por que uma fatura ou guia foi glosada.
Descrição

Quando uma operadora glosa uma fatura, ela fornece um código de motivo, como o CARC, para explicar a decisão. Esses códigos indicam problemas como 'Serviço Não Coberto' ou 'Cobrança Duplicada'.

Este atributo é vital para a gestão de glosas. Ao analisar a frequência desses códigos, as organizações identificam causas raiz — como problemas de elegibilidade ou erros de codificação — permitindo reduzir o retrabalho e acelerar o fluxo de caixa.

Por que é importante

Indica o motivo específico das glosas (denials), permitindo a análise da causa raiz para reduzir negativas futuras, diminuir o retrabalho e melhorar as taxas de pagamento na primeira tentativa.

Onde obter

Esta informação é recebida no aviso de remessa eletrônica (arquivo ERA ou 835) da operadora e é armazenada no módulo de gestão de guias do R1 RCM.

Exemplos
CO-16: Fatura/serviço carece de informações necessárias para adjudicação.PR-97: O benefício deste serviço está incluído no pagamento/abono de outro serviço.CO-22: Este atendimento pode ser coberto por outro pagador conforme a coordenação de benefícios.OA-18: Fatura/serviço duplicado exato.
Departamento de Faturamento
BillingDepartment
O departamento ou equipe funcional responsável pela execução da atividade.
Descrição

Este atributo especifica a unidade organizacional, como 'Entrada de Encargos', 'Envio de Faturas' ou 'Gestão de Glosas', que executou a etapa. Ajuda a entender as passagens de bastão (handoffs) entre equipes.

Isso é crucial para analisar a vazão de cada setor e identificar gargalos interfuncionais. Ao filtrar o mapa do processo por departamento, a organização vê onde as transições fluem bem e onde ocorrem atrasos, auxiliando na alocação de recursos.

Por que é importante

Permite a análise do desempenho do processo por unidade organizacional, ajudando a identificar gargalos específicos da equipe, restrições de recursos ou as melhores práticas.

Onde obter

Pode ser derivado do perfil do usuário no R1 RCM ou armazenado como um 'Código de Departamento' nos dados da transação.

Exemplos
Captura de EncargosGestão de SinistrosGlosas e RecursosLançamento de Pagamento
Nome do Pagador
PayerName
O nome da seguradora, entidade governamental ou paciente responsável pelo pagamento.
Descrição

Este atributo identifica a operadora principal da fatura. Pode ser uma seguradora privada, um órgão governamental ou o próprio paciente (particular).

Analisar o processo por operadora é fundamental no RCM. Pode revelar que certas operadoras têm taxas de glosa maiores, ciclos de pagamento mais longos ou exigências de envio complexas. Esses insights permitem que a organização adapte processos e recursos para gerir comportamentos específicos de cada pagador.

Por que é importante

Permite segmentar o processo por pagador para identificar atrasos específicos, padrões de glosas ou comportamentos de pagamento, o que é crucial para otimizar a receita.

Onde obter

Encontrado nas informações demográficas ou de seguro do paciente vinculadas à fatura no R1 RCM.

Exemplos
MedicareUnitedHealthcareBlue Cross Blue ShieldAetnaParticular
Status da Fatura
InvoiceStatus
O status atual da fatura ou cobrança em seu ciclo de vida.
Descrição

Este atributo indica o último estado conhecido de um evento de faturamento, como 'Enviado', 'Pago', 'Glosado' ou 'Em Cobrança'. Oferece um retrato de onde a fatura está no processo.

O status da fatura é vital para relatórios de aging e monitoramento de contas a receber. No Process Mining, serve para filtrar casos travados em estados específicos ou analisar resultados de diferentes variantes, como comparar o caminho de faturas pagas versus glosadas.

Por que é importante

Oferece uma visão do estado atual de cada caso, fundamental para criar relatórios de aging e analisar os resultados finais de diferentes caminhos do processo.

Onde obter

Geralmente é um campo de status no registro principal da guia ou da conta no R1 RCM.

Exemplos
Envio PendenteEnviado para a OperadoraNegadoPago na ÍntegraEm Cobrança
Usuário Atribuído
AssignedUser
O ID de usuário ou nome do funcionário que realizou a atividade.
Descrição

Este atributo identifica o responsável pela execução de uma tarefa específica. Pode ser o faturista que criou a guia, o analista que tratou a glosa ou o especialista que lançou o pagamento.

Analisar por usuário ajuda a entender a distribuição da carga de trabalho, o desempenho individual e necessidades de treinamento. Pode destacar quem é mais eficiente ou quem está associado a taxas de erro maiores, permitindo uma gestão focada e melhorias no processo.

Por que é importante

Permite analisar o desempenho de equipes e indivíduos, a distribuição de carga de trabalho e ajuda a identificar necessidades de treinamento ou desvios de processo de usuários específicos.

Onde obter

Geralmente encontrado nos campos 'UserID', 'Processador' ou 'AtualizadoPor' nos logs de transação do R1 RCM.

Exemplos
jdoeasmithp.jonesBOT_RPA01
Valor da Fatura
InvoiceAmount
O valor monetário total das cobranças na fatura ou guia.
Descrição

Este atributo representa o valor total faturado pelos serviços prestados em um evento. Reflete a receita esperada da fatura.

Analisar o valor da fatura é crítico para o Process Mining financeiro. Permite priorizar contas de alto valor, entender o impacto financeiro de atrasos ou glosas e segmentar o processo por valor. Por exemplo, uma análise pode revelar que faturas acima de certo valor seguem um caminho diferente e mais manual.

Por que é importante

Oferece contexto financeiro ao processo, permitindo analisar como as variações impactam a receita e ajudando a priorizar casos de alto valor para melhoria.

Onde obter

Localizado na tabela principal de faturas ou cabeçalho no R1 RCM, frequentemente nomeado como 'TotalBilledAmount' ou similar.

Exemplos
150.002500.7585.5012000.00
Código do Serviço
ServiceCode
O código de faturamento para o serviço ou procedimento específico prestado, como um código CPT ou HCPCS.
Descrição

Códigos de serviço, como os códigos CPT, são padrões médicos usados para reportar procedimentos e diagnósticos às operadoras para reembolso.

Analisar o processo por código de serviço é essencial para identificar problemas de faturamento ligados a tipos específicos de atendimento. Isso destaca quais procedimentos são mais glosados, quais têm os ciclos de pagamento mais longos ou exigem mais retrabalho, permitindo melhorias focadas nas práticas de codificação e faturamento.

Por que é importante

Permite analisar o processo com base no tipo de serviço prestado, fundamental para identificar padrões de glosas ou atrasos de pagamento vinculados a procedimentos específicos.

Onde obter

Esta informação é encontrada no nível de item de linha para cada cobrança ou guia dentro do R1 RCM.

Exemplos
992139928573560
É Automatizado
IsAutomated
Um marcador que indica se a atividade foi realizada por um sistema automatizado ou por um usuário humano.
Descrição

Este atributo booleano distingue tarefas executadas por automação (ex: bot de RPA para envio de guias) de tarefas manuais.

Analisar este atributo é fundamental para entender o impacto da automação. Permite comparar velocidade, custo e taxas de erro entre processos automatizados e manuais, ajudando a identificar novas oportunidades e medir o ROI dos bots existentes.

Por que é importante

Distingue entre atividades humanas e automatizadas, o que é crítico para medir o impacto da automação na eficiência, custo e qualidade do processo.

Onde obter

Pode ser derivado do campo 'AssignedUser', onde IDs específicos são reservados para bots (ex: 'BOT_RPA01'), ou de campos dedicados do sistema para sinalizar transações automáticas.

Exemplos
verdadeirofalse
É Retrabalho
IsRework
Um marcador calculado que identifica atividades que fazem parte de um loop de retrabalho, como a reapresentação de uma fatura glosada.
Descrição

Este atributo é uma flag booleana calculada durante a análise de Process Mining. Torna-se 'verdadeiro' se uma atividade é a repetição de um passo anterior ou faz parte de uma sequência de correção de erro (ex: qualquer atividade após 'Fatura Glosada').

Identificar o retrabalho é uma das maiores vantagens do Process Mining. Ele quantifica o desperdício de esforço, tempo e recursos. Ao sinalizar o retrabalho, as organizações podem focar em prevenir os erros originais, gerando ganhos significativos de eficiência.

Por que é importante

Ajuda a quantificar a frequência e o impacto do retrabalho, como glosas de faturas, permitindo análises direcionadas para reduzir ineficiências e desperdício de esforço.

Onde obter

Não é um campo no sistema de origem. É calculado pela ferramenta de Process Mining com base na sequência de atividades, como detectar quando um 'Fatura Enviada' ocorre mais de uma vez para o mesmo caso.

Exemplos
verdadeirofalse
ID do paciente
PatientId
O identificador único do paciente que recebeu o serviço.
Descrição

Este atributo é o ID exclusivo do paciente no sistema de saúde, muitas vezes chamado de Prontuário ou MRN.

Embora o foco não seja o cuidado clínico individual, o ID do Paciente serve para analisar problemas recorrentes de faturamento para um mesmo paciente. Também ajuda a segmentar o processo por demografia ou histórico, revelando problemas sistêmicos que afetam grupos específicos de pacientes.

Por que é importante

Permite a análise de eventos de faturamento no nível do paciente, ajudando a identificar problemas recorrentes ou padrões para pacientes específicos em múltiplos atendimentos.

Onde obter

Este identificador é parte central dos dados demográficos do paciente vinculados a cada atendimento e fatura no R1 RCM.

Exemplos
MRN837262MRN937281MRN103847
Motivo do Ajuste
AdjustmentReason
O motivo fornecido para um ajuste financeiro, como 'Abatimento Contratual' ou 'Baixa de Dívida Incobrável'.
Descrição

Este atributo dá o contexto do porquê um ajuste financeiro foi feito. Os motivos geralmente são códigos ou descrições padrão.

Analisar os motivos de ajuste ajuda a diagnosticar causas de perda de receita. Por exemplo, muitos casos de 'Baixa de Pequeno Saldo' podem sugerir ineficiência na cobrança de valores baixos, enquanto 'Abatimentos Contratuais' são esperados em negociações com operadoras. Esta análise alimenta o dashboard de Auditoria de Ajustes e Conformidade.

Por que é importante

Explica o "porquê" por trás dos ajustes de receita, ajudando a identificar causas raiz de perdas, como questões contratuais, erros de faturamento ou falhas na cobrança.

Onde obter

Geralmente é um código ou campo de texto no mesmo registro de transação do AdjustmentAmount no R1 RCM.

Exemplos
Abatimento ContratualBaixa de Dívida IncobrávelBaixa de Pequenos SaldosCorreção de Erro de Faturamento
Resultado da Cobrança
CollectionOutcome
O resultado final das atividades de cobrança de um saldo pendente.
Descrição

Este atributo descreve o resultado dos esforços para receber o pagamento de uma conta vencida. Resultados possíveis incluem 'Pago Integralmente', 'Acordado', 'Dívida Incobrável' ou 'Não Resolvido'.

Acompanhar os resultados de cobrança é essencial para avaliar a eficácia do processo. Ao analisar quais atividades levam a quais resultados, as organizações podem otimizar estratégias, melhorar taxas de recuperação e decidir quando encerrar esforços de cobrança e baixar saldos. Isso alimenta o dashboard de Performance de Atividades de Cobrança.

Por que é importante

Mede a eficácia do processo de cobrança rastreando a resolução final de contas vencidas, ajudando a otimizar as estratégias de recuperação.

Onde obter

Provavelmente é um campo de status na conta do paciente ou em um módulo de cobrança dedicado dentro do R1 RCM.

Exemplos
Pago na ÍntegraAcordo por Valor InferiorEnviado para Agência ExternaBaixado como Dívida Incobrável
Tempo de Ciclo do Serviço ao Pagamento
ServiceToPaymentCycleTime
A duração total calculada desde a prestação do serviço até o lançamento do pagamento final.
Descrição

Esta métrica mede a duração de ponta a ponta do ciclo de receita para um único evento de faturamento. Representa o tempo total que a organização leva para converter um serviço prestado em caixa.

Este é um KPI crítico para a saúde financeira. Analisar esta duração ajuda a identificar áreas para aceleração do processo. Ao detalhar o tempo de ciclo em partes, como 'tempo para faturar' e 'tempo para receber', as organizações identificam as melhores oportunidades para melhorar o fluxo de caixa.

Por que é importante

Este é um KPI crítico de alto nível que mede a eficiência global do ciclo de conversão de caixa, impactando diretamente o fluxo de caixa da organização.

Onde obter

Esta é uma métrica calculada. É a diferença de tempo entre o timestamp da atividade 'Service Rendered' e a atividade 'Payment Posted' para um determinado Evento de Faturamento.

Exemplos
35 dias e 8 horas92 dias e 4 horas15 dias 12 horas
Valor do Ajuste
AdjustmentAmount
O valor monetário de um ajuste feito no saldo da conta.
Descrição

Este atributo captura o valor de quaisquer ajustes financeiros feitos na conta de um paciente após o faturamento inicial. Ajustes podem ser positivos ou negativos e incluem abatimentos contratuais, baixas ou correções.

Rastrear os valores de ajuste é crítico para entender a integridade da receita. Níveis altos de ajustes negativos podem indicar perda de receita por problemas como falha na captura de encargos ou dívidas incobráveis. Analisar esses dados ajuda a identificar o impacto financeiro de erros de faturamento e ineficiências de cobrança.

Por que é importante

Quantifica a perda de receita (leakage) e as correções financeiras, ajudando a identificar o impacto monetário de imprecisões no faturamento, obrigações contratuais ou inadimplência.

Onde obter

Encontrado nos logs de transação relacionados a ajustes de conta ou lançamento de pagamentos no R1 RCM.

Exemplos
-50.2520.00-1200.00
Obrigatório Recomendado Opcional

Atividades de Gestão do Ciclo de Receita (RCM)

Estas são as etapas e marcos fundamentais do processo a serem capturados no seu event log para uma descoberta precisa de processos no RCM.
6 Recomendado 8 Opcional
Atividade Descrição
Conta Encerrada
O evento de faturamento é totalmente resolvido com saldo zero e a conta é formalmente fechada. Isso indica a conclusão bem-sucedida do ciclo de receita para esse atendimento específico.
Por que é importante

Este é o principal evento de fim do 'fluxo ideal' (happy path). Medir o tempo de ciclo de fechamento de conta ajuda a garantir que tarefas administrativas sejam concluídas com eficiência.

Onde obter

Este evento é inferido quando o saldo da conta chega a zero e um status final de 'Fechado' ou 'Pago Integralmente' é aplicado. O timestamp é retirado da última transação financeira que zerou o saldo.

Captura

Inferido quando o saldo da conta chega a zero e um status 'Fechado' é aplicado, junto com um timestamp de atividade final.

Tipo de evento inferred
Encargos Capturados
Esta atividade representa o registro formal de todos os serviços, procedimentos e insumos faturáveis de um atendimento. É uma etapa crítica de entrada de dados que traduz atividades clínicas em transações financeiras.
Por que é importante

Marca a transição das operações clínicas para as financeiras. É o ponto inicial para medir os tempos de ciclo de faturamento e ajuda a identificar acúmulos na entrada de encargos.

Onde obter

Capturado no módulo de entrada de encargos do R1 RCM ou recebido via interface de um prontuário eletrônico (EHR). O evento é tipicamente marcado por um log de transação específico ou pelo timestamp de criação do registro de encargo.

Captura

Identificado pelo timestamp de criação do registro da transação de encargo na tabela de faturamento.

Tipo de evento explicit
Pagamento Lançado
O pagamento recebido é oficialmente aplicado à conta do paciente, reduzindo o saldo devedor. Esta é a etapa final de conciliação do pagamento com os serviços faturados.
Por que é importante

Esta atividade fornece o ponto final para o cálculo dos tempos de ciclo de 'Serviço ao Pagamento' e 'Lançamento de Pagamento'. Ela confirma que a receita foi reconhecida e as contas atualizadas.

Onde obter

Gravado como uma transação financeira explícita no módulo de contabilidade de pacientes do R1 RCM. Cada lançamento inclui data, valor e origem.

Captura

Registrado como uma transação específica com data de lançamento quando um usuário ou processo automatizado aplica o pagamento.

Tipo de evento explicit
Pagamento Recebido
Um pagamento é recebido de um pagador ou de um paciente. Este evento marca o recebimento dos fundos, mas os valores ainda não foram aplicados às contas ou linhas de serviço específicas.
Por que é importante

Representa a entrada de caixa. O intervalo de tempo entre 'Payment Received' e 'Payment Posted' é uma métrica fundamental para entender a eficiência do back-office e os atrasos na conciliação financeira.

Onde obter

Capturado a partir de arquivos de remessa eletrônica dos pagadores ou do processamento de pagamentos de pacientes. O evento corresponde à data de depósito ou data de recebimento do arquivo.

Captura

Registrado a partir da data de vigência do pagamento no arquivo ERA ou da data da transação de um pagamento de paciente.

Tipo de evento explicit
Serviço Prestado
Representa o momento em que um serviço ou procedimento faturável é concluído para o paciente. Este evento geralmente é capturado em sistemas clínicos ou de agendamento e serve como gatilho para o ciclo de receita.
Por que é importante

Este é o ponto de partida para o KPI de tempo de ciclo Serviço-ao-Pagamento. Analisar o tempo a partir deste evento ajuda a identificar atrasos iniciais (front-end) no ciclo de receita.

Onde obter

Geralmente vem de um Prontuário Eletrônico (PEP/EHR) ou sistema de gestão integrado ao R1 RCM. Costuma ser inferido de timestamps de 'Data do Serviço' ou 'Procedimento Concluído'.

Captura

Inferido a partir do timestamp da 'Data do Serviço' associado ao atendimento do paciente.

Tipo de evento inferred
Sinistro Submetido
A fatura gerada é enviada eletronicamente para a operadora responsável (ex: seguradora). Isso marca a primeira comunicação externa no processo de faturamento para garantir o reembolso.
Por que é importante

Um marco crítico que inicia a contagem para o reembolso do pagador. O acompanhamento desse evento ajuda a monitorar atrasos nas submissões e garante a conformidade com os prazos dos pagadores.

Onde obter

Este evento é gravado como uma transação explícita quando a fatura é transmitida para uma clearinghouse. O sistema registra o horário do envio e os detalhes de confirmação.

Captura

Registrado explicitamente como uma transação com um timestamp de submissão quando a fatura é enviada via clearinghouse.

Tipo de evento explicit
Adjudicação do Pagador Recebida
O sistema recebe uma resposta da operadora sobre a fatura enviada, geralmente via arquivo ERA (Electronic Remittance Advice). Esta resposta detalha o que foi pago, glosado ou ajustado.
Por que é importante

Este evento é uma ramificação crucial no processo, determinando se o próximo passo é o lançamento do pagamento ou a gestão de glosas. Analisá-lo ajuda a entender o comportamento do pagador e a velocidade do pagamento.

Onde obter

Capturado quando um arquivo de remessa eletrônica, como um arquivo ANSI 835 do pagador, é processado pelo R1 RCM. O evento é marcado pelo timestamp de processamento deste arquivo.

Captura

Registrado após a ingestão e o processamento do arquivo de Aviso de Recebimento Eletrônico (ERA/835).

Tipo de evento explicit
Ajuste de Conta Realizado
Uma transação não monetária é lançada na conta para alterar o saldo. Isso pode incluir ajustes contratuais baseados em acordos com pagadores, baixas de pequenos saldos ou correções.
Por que é importante

Volumes elevados de ajustes podem indicar problemas com tabelas de honorários, gestão de contratos ou erros de faturamento. O rastreamento de ajustes é crítico para analisar a integridade da receita.

Onde obter

Registrado como um tipo de transação específica no módulo financeiro do paciente no R1 RCM. Cada ajuste possui um código, um valor e uma data de lançamento.

Captura

Registrado como uma transação de ajuste distinta, identificável por um código de transação único.

Tipo de evento explicit
Atividade de Cobrança Iniciada
A conta do paciente tornou-se inadimplente e esforços de cobrança proativos são iniciados. Isso pode variar de cartas de lembrete automáticas até o encaminhamento para um especialista em cobranças.
Por que é importante

Marca o início do custoso processo de cobrança. Analisar a eficácia e o tempo de ciclo dessas atividades ajuda a otimizar as estratégias para recuperar dívidas ativas.

Onde obter

Este evento provavelmente é registrado ou inferido a partir de uma mudança de status quando uma conta é movida para uma fila de trabalho de cobrança no R1 RCM.

Captura

Inferido a partir de uma mudança de status na conta para 'Em Cobrança' ou 'Inadimplente'.

Tipo de evento inferred
Conta em Dívida Ativa
Todos os esforços de cobrança foram esgotados e o saldo remanescente da conta é considerado incobrável. O saldo é baixado como dívida perdida, representando uma perda final de receita.
Por que é importante

Isso representa um resultado negativo e perda direta de receita. Analisar quais casos terminam em dívida incobrável pode revelar padrões de inadimplência e oportunidades para melhorar as cobranças.

Onde obter

Geralmente é uma transação explícita no R1 RCM onde o saldo devedor é movido para uma categoria de dívida incobrável, acionada por usuário ou regras automáticas de aging.

Captura

Registrado como uma transação financeira específica para baixar o saldo, muitas vezes associada a uma transferência para uma agência de cobrança externa.

Tipo de evento explicit
Demonstrativo do Paciente Gerado
Após a adjudicação do seguro, um demonstrativo é criado para o paciente detalhando o saldo remanescente de sua responsabilidade. Isso pode incluir coparticipações, franquias ou serviços não cobertos.
Por que é importante

Esta atividade inicia a parte do pagamento do paciente no ciclo de receita. Analisar seu tempo e frequência é importante para gerir cobranças e fluxo de caixa.

Onde obter

Geralmente capturado quando um processo em lote é executado para criar e enviar extratos aos pacientes. O R1 RCM registraria a data em que o extrato foi gerado.

Captura

Registrado como uma transação quando o processo em lote para gerar os demonstrativos dos pacientes é executado.

Tipo de evento explicit
Retrabalho de Glosa Iniciado
Um usuário ou fluxo de trabalho automatizado inicia a investigação e resolução de uma fatura glosada. Isso pode envolver correção de codificação, envio de documentação ou recurso da decisão do pagador.
Por que é importante

Rastreia o início do oneroso loop de retrabalho para faturas glosadas. Medir o tempo gasto nesta fase é essencial para entender a eficiência da equipe de gestão de glosas.

Onde obter

Este evento costuma ser inferido de uma mudança no status da fatura glosada para 'Retrabalho em Andamento' ou 'Em Revisão' dentro de uma fila do R1 RCM.

Captura

Inferido a partir de uma mudança de status em uma fila de trabalho de gestão de glosas ou pela primeira ação do usuário em uma fatura glosada.

Tipo de evento inferred
Sinistro Criado
Uma fatura ou guia de cobrança formal é gerada no sistema com base nos encargos capturados. Isso envolve a compilação de dados demográficos do paciente, informações do seguro e códigos de serviço em um formato padronizado.
Por que é importante

Este é um marco interno importante antes do envio externo. Atrasos aqui podem indicar problemas com codificação, validação de dados ou configuração do sistema que atrasam todo o processo de faturamento.

Onde obter

Este é um evento interno do sistema R1 RCM. Provavelmente é capturado como uma mudança de status na conta de faturamento ou pelo timestamp de criação da própria guia.

Captura

Inferido a partir da mudança de status para 'Fatura Gerada' ou pelo timestamp de criação do registro da fatura.

Tipo de evento inferred
Sinistro Negado
A operadora recusou o pagamento da fatura, total ou parcialmente. O motivo da glosa é registrado, iniciando um processo de retrabalho e recurso.
Por que é importante

Esta atividade evidencia perdas de receita e ineficiência de processos. Analisar os motivos de glosa é essencial para identificar causas raiz e melhorar as taxas de aceitação de faturas de primeira.

Onde obter

Não é um evento discreto, mas um status inferido dos detalhes de um arquivo ERA processado. Códigos específicos de glosa nos dados de remessa acionam uma mudança de status na guia.

Captura

Inferido a partir de códigos de glosa presentes no arquivo ERA processado, que alteram o status da fatura para 'Glosada'.

Tipo de evento inferred
Recomendado Opcional

Guias de Extração

Como obter seus dados do R1 RCM