Seu Template de Dados de Gestão do Ciclo de Receita (RCM)
Seu Template de Dados de Gestão do Ciclo de Receita (RCM)
- Atributos recomendados para coletar
- Principais atividades para monitorar na descoberta de processos
- Guia detalhado de extração para o R1 RCM
Atributos de Gestão do Ciclo de Receita (RCM)
| 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 | |||
Atividades de Gestão do Ciclo de Receita (RCM)
| 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 | |||
Guias de Extração
Etapas
- Faça login na plataforma R1 RCM com uma conta de usuário que tenha permissões de acesso aos módulos de business intelligence ou relatórios.
- Navegue até a seção de relatórios da plataforma. Ela pode estar rotulada como "Business Intelligence", "Portal de Relatórios" ou "Analytics".
- Localize a ferramenta para criar um novo relatório ou consulta personalizada. Isso permite definir os campos de dados e a lógica específica para a extração.
- Como o R1 RCM não fornece um event log unificado nativo, você deve construir um combinando dados de diferentes fontes. A configuração de consulta fornecida utiliza uma abordagem UNION ALL para mesclar eventos de vários objetos de negócio em um único log cronológico.
- Copie a consulta completa fornecida na seção "Query" deste documento e cole-a no editor de consultas ou na interface de configuração do relatório personalizado.
- Configure os parâmetros do relatório, especialmente o intervalo de datas. Defina os espaços reservados
'{StartDate}'e'{EndDate}'na consulta para determinar o período da extração, como os últimos 6 meses. - Adicione outros filtros necessários à configuração do relatório, como filtrar por unidades, departamentos ou grupos de pagadores específicos para restringir o escopo dos dados.
- Execute o relatório. Isso rodará a consulta no banco de dados do R1 RCM e gerará os resultados com base nos parâmetros especificados.
- Assim que o relatório terminar de rodar, procure a opção de exportar os dados. Selecione CSV (Valores Separados por Vírgula) como formato de exportação, pois é diretamente compatível com o ProcessMind.
- Baixe o arquivo CSV gerado e abra-o para uma revisão rápida. Certifique-se de que os cabeçalhos das colunas correspondam aos atributos exigidos:
BillingEvent,ActivityName,EventTime,SourceSystemeLastDataUpdate. - Verifique se os formatos de data e hora nas colunas
EventTimeeLastDataUpdateestão consistentes antes de fazer o upload do arquivo para o ProcessMind.
Configuração
- Pré-requisitos: É necessária uma conta de usuário com permissões suficientes para acessar e criar relatórios personalizados no módulo de Business Intelligence do R1 RCM.
- Tipo de Relatório: Utilize uma consulta personalizada ou um construtor de relatórios avançado que permita a recuperação de dados complexos e o uso de instruções UNION ALL para combinar diferentes conjuntos de dados.
- Intervalo de Datas: Para gerenciar o desempenho e o volume de dados, é fundamental filtrar por um período específico. Recomendamos começar com uma janela de 3 a 6 meses para a análise inicial. Aplique o filtro de data ao campo de timestamp principal de cada atividade.
- Filtros Principais: Além do intervalo de datas, considere aplicar filtros para
ID da Unidade,Tipo de PagadorouDepartamento de Faturamentopara focar a análise em áreas operacionais específicas e reduzir o tamanho da exportação. - Formato de Exportação: Selecione sempre CSV como formato de saída. Isso garante um arquivo limpo e estruturado que pode ser facilmente processado por ferramentas de process mining.
- Agendamento: Se o módulo de relatórios do R1 RCM permitir, considere agendar este relatório para ser executado de forma recorrente (ex: semanal ou mensal) para automatizar a atualização dos dados para monitoramento contínuo.
a Consulta de Exemplo config
SELECT
c.ClaimID AS BillingEvent,
'Service Rendered' AS ActivityName,
c.ServiceDate AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
c.ClinicianID AS AssignedUser,
d.DepartmentName AS BillingDepartment,
c.TotalChargeAmount AS InvoiceAmount,
p.PayerName AS PayerName,
'Rendered' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [ServiceAndChargeData] c
JOIN [Departments] d ON c.DepartmentID = d.DepartmentID
JOIN [Payers] p ON c.PayerID = p.PayerID
WHERE c.ServiceDate BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
c.ClaimID AS BillingEvent,
'Charges Captured' AS ActivityName,
c.ChargeEntryTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
c.ChargeEntryUserID AS AssignedUser,
d.DepartmentName AS BillingDepartment,
c.TotalChargeAmount AS InvoiceAmount,
p.PayerName AS PayerName,
'Open' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [ServiceAndChargeData] c
JOIN [Departments] d ON c.DepartmentID = d.DepartmentID
JOIN [Payers] p ON c.PayerID = p.PayerID
WHERE c.ChargeEntryTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
cl.ClaimID AS BillingEvent,
'Claim Created' AS ActivityName,
cl.CreationTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
cl.CreatedByUserID AS AssignedUser,
cl.BillingDepartment AS BillingDepartment,
cl.TotalAmount AS InvoiceAmount,
cl.PayerName AS PayerName,
'Created' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [ClaimsData] cl
WHERE cl.CreationTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
cl.ClaimID AS BillingEvent,
'Claim Submitted' AS ActivityName,
cl.SubmissionTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
cl.SubmittedByUserID AS AssignedUser,
cl.BillingDepartment AS BillingDepartment,
cl.TotalAmount AS InvoiceAmount,
cl.PayerName AS PayerName,
'Submitted' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [ClaimsData] cl
WHERE cl.SubmissionTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
era.ClaimID AS BillingEvent,
'Payer Adjudication Received' AS ActivityName,
era.ReceivedTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
'System' AS AssignedUser,
pa.BillingDepartment AS BillingDepartment,
pa.InvoiceAmount AS InvoiceAmount,
era.PayerName AS PayerName,
'Adjudicated' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [RemittanceAdvice] era
JOIN [PatientAccounts] pa ON era.ClaimID = pa.BillingEvent
WHERE era.ReceivedTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
d.ClaimID AS BillingEvent,
'Claim Denied' AS ActivityName,
d.DenialTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
'System' AS AssignedUser,
cl.BillingDepartment AS BillingDepartment,
cl.TotalAmount AS InvoiceAmount,
cl.PayerName AS PayerName,
'Denied' AS InvoiceStatus,
d.ReasonCode AS DenialReasonCode
FROM [DenialsLog] d
JOIN [ClaimsData] cl ON d.ClaimID = cl.ClaimID
WHERE d.DenialTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
dr.ClaimID AS BillingEvent,
'Denial Rework Started' AS ActivityName,
dr.ReworkStartTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
dr.AssignedUserID AS AssignedUser,
cl.BillingDepartment AS BillingDepartment,
cl.TotalAmount AS InvoiceAmount,
cl.PayerName AS PayerName,
'In Rework' AS InvoiceStatus,
dr.OriginalDenialCode AS DenialReasonCode
FROM [DenialRework] dr
JOIN [ClaimsData] cl ON dr.ClaimID = cl.ClaimID
WHERE dr.ReworkStartTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
ps.PatientAccountID AS BillingEvent,
'Patient Statement Generated' AS ActivityName,
ps.GenerationTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
ps.GeneratedByUserID AS AssignedUser,
pa.BillingDepartment AS BillingDepartment,
ps.StatementBalance AS InvoiceAmount,
'Patient' AS PayerName,
'Patient Billed' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [PatientStatements] ps
JOIN [PatientAccounts] pa ON ps.PatientAccountID = pa.BillingEvent
WHERE ps.GenerationTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
p.AssociatedClaimID AS BillingEvent,
'Payment Received' AS ActivityName,
p.ReceiptTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
p.ProcessedByUserID AS AssignedUser,
pa.BillingDepartment AS BillingDepartment,
p.PaymentAmount AS InvoiceAmount,
p.PayerName AS PayerName,
'Payment Pending' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [PaymentsLog] p
JOIN [PatientAccounts] pa ON p.AssociatedClaimID = pa.BillingEvent
WHERE p.ReceiptTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
pt.ClaimID AS BillingEvent,
'Payment Posted' AS ActivityName,
pt.PostingTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
pt.PostedByUserID AS AssignedUser,
pa.BillingDepartment AS BillingDepartment,
pt.PostedAmount AS InvoiceAmount,
pt.PayerName AS PayerName,
'Partially Paid' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [PaymentTransactions] pt
JOIN [PatientAccounts] pa ON pt.ClaimID = pa.BillingEvent
WHERE pt.PostingTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
a.ClaimID AS BillingEvent,
'Account Adjustment Made' AS ActivityName,
a.AdjustmentTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
a.AdjusterID AS AssignedUser,
pa.BillingDepartment AS BillingDepartment,
a.AdjustmentAmount AS InvoiceAmount,
pa.PayerName AS PayerName,
'Adjusted' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [Adjustments] a
JOIN [PatientAccounts] pa ON a.ClaimID = pa.BillingEvent
WHERE a.AdjustmentTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
ca.PatientAccountID AS BillingEvent,
'Collection Activity Started' AS ActivityName,
ca.ActivityTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
ca.AssignedAgentID AS AssignedUser,
'Collections' AS BillingDepartment,
pa.CurrentBalance AS InvoiceAmount,
'Patient' AS PayerName,
'In Collections' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [CollectionsActivity] ca
JOIN [PatientAccounts] pa ON ca.PatientAccountID = pa.BillingEvent
WHERE ca.ActivityTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
pa.BillingEvent AS BillingEvent,
'Account Placed in Bad Debt' AS ActivityName,
pa.BadDebtPlacementDate AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
pa.BadDebtUserID AS AssignedUser,
'Finance' AS BillingDepartment,
pa.CurrentBalance AS InvoiceAmount,
'Patient' AS PayerName,
'Bad Debt' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [PatientAccounts] pa
WHERE pa.BadDebtPlacementDate BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
pa.BillingEvent AS BillingEvent,
'Account Closed' AS ActivityName,
pa.ClosureDate AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
'System' AS AssignedUser,
pa.BillingDepartment AS BillingDepartment,
0 AS InvoiceAmount,
pa.PayerName AS PayerName,
'Closed' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [PatientAccounts] pa
WHERE pa.ClosureDate BETWEEN '{StartDate}' AND '{EndDate}' AND pa.CurrentBalance = 0;