Seu Template de dados para gestão do ciclo de receita
Seu Template de dados para gestão do ciclo de receita
- Atributos recomendados para coleta
- Principais atividades para acompanhar na descoberta do processo
- Orientações detalhadas para extração de dados da R1 RCM
Atributos da gestão do ciclo de receita
| Nome | Descrição | ||
|---|---|---|---|
| Data e hora do evento EventTime | Data e hora que indicam quando uma atividade ou evento específico ocorreu. | ||
| Descrição A data e hora do evento indicam o momento exato em que uma atividade foi registrada no sistema. Essas informações temporais são fundamentais para entender o processo por meio de uma análise baseada no tempo. Na mineração de processos, esses dados são usados para ordenar os eventos cronologicamente e calcular a duração entre atividades, algo essencial para analisar a performance. Com eles, é possível calcular métricas importantes, como tempo de ciclo, tempo de processamento e tempo de espera, fundamentais para identificar gargalos e medir a eficiência. Por que isso importa Esses dados de data e hora são a base de todas as análises relacionadas ao tempo, incluindo o cálculo dos tempos de ciclo, a identificação de gargalos e o acompanhamento da performance do processo em relação aos SLAs. Onde encontrar Geralmente aparece como um campo 'Data de criação', 'Timestamp' ou 'Data da última atualização' associado a cada transação ou registro de alteração de status na R1 RCM. Exemplos 2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-11-05T09:12:45Z | |||
| Evento de faturamento BillingEvent | Identificador exclusivo de um serviço ou item faturável, usado como identificador principal do caso para acompanhar todo o ciclo da receita. | ||
| Descrição O ID do evento de faturamento representa uma ocorrência específica da prestação de um serviço ou da entrega de um produto que gera uma cobrança. Ele funciona como o elo central entre todas as atividades relacionadas, desde a prestação inicial do serviço e o registro da cobrança até o envio da conta, o lançamento do pagamento e o encerramento da conta. Na mineração de processos, analisar o ciclo de vida de cada evento de faturamento permite ter uma visão completa do ciclo da receita de ponta a ponta. Esse identificador é usado para acompanhar toda a jornada de uma cobrança, identificar caminhos recorrentes, medir os tempos de ciclo entre etapas importantes e entender as variações que causam atrasos ou perda de receita. Por que isso importa Esse identificador é essencial para agrupar todas as atividades relacionadas em um único caso e permitir uma análise completa e precisa do processo do ciclo da receita para cada evento faturável. Onde encontrar Essa é a chave primária que conecta várias tabelas relacionadas a atendimentos, cobranças, contas e pagamentos de pacientes. Consulte a documentação da R1 RCM para identificar o campo específico, geralmente relacionado ao identificador de um atendimento ou de uma conta. Exemplos BE-2023-0012345BE-2023-0054321BE-2024-0098765 | |||
| Nome da atividade ActivityName | Nome do evento de negócio ou da tarefa específica que ocorreu em determinado momento do processo do ciclo da receita. | ||
| Descrição Este atributo descreve uma etapa ou marco específico do processo de gestão do ciclo da receita para um determinado evento de faturamento. As atividades representam o trabalho realizado, como 'Cobranças registradas', 'Conta enviada' ou 'Pagamento contabilizado'. Analisar a sequência de atividades é a base da mineração de processos. Isso permite descobrir o fluxo real do processo, identificar gargalos em que as atividades demoram para começar e detectar ciclos de retrabalho, nos quais atividades são repetidas sem necessidade, como quando 'Conta negada' é seguida por 'Retrabalho da negativa iniciado'. Por que isso importa Define as etapas do processo e permite visualizar o mapa do processo, calcular os tempos de transição e identificar desvios e retrabalho. Onde encontrar Essas informações geralmente vêm de registros de eventos, registros de alteração de status ou códigos de transação em vários módulos da R1 RCM. Talvez seja necessário mapear códigos técnicos para nomes mais claros para a equipe de negócios. Exemplos Cobranças registradasSolicitação de pagamento enviadaResposta do pagador recebidaPagamento registradoConta encerrada | |||
| Sistema de origem SourceSystem | Sistema de registro de onde 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 específico. Em um ambiente complexo como o da área da saúde, os dados podem vir de um prontuário eletrônico, de um módulo de faturamento, de uma câmara de compensação de contas médicas ou de uma plataforma de cobrança. Conhecer o sistema de origem é essencial para validar os dados e analisar variações do processo que podem ser específicas de determinados sistemas. Isso ajuda a investigar inconsistências nos dados e a entender o ambiente tecnológico do processo. Por que isso importa Identifica a origem dos dados, algo essencial para a governança e a validação dos dados e para entender como os diferentes sistemas interagem ao longo do processo de ponta a ponta. Onde encontrar Geralmente é um valor estático adicionado durante a extração dos dados, que identifica o sistema de origem (por exemplo, 'R1 RCM'). Exemplos R1 RCMCernerEpic | |||
| Última atualização dos dados LastDataUpdate | Data e hora da atualização ou extração mais recente dos dados do sistema de origem. | ||
| Descrição Este atributo indica quando os dados da análise de mineração de processos foram atualizados pela última vez. Ele informa o quão recentes são os dados analisados. Essa informação é importante para relatórios e Dashboards, pois mostra ao usuário o quanto os insights sobre o processo estão atualizados. Ela ajuda a alinhar as expectativas sobre a atualidade dos dados e garante que as decisões sejam tomadas com base em um período conhecido. Por que isso importa Dá contexto essencial sobre a atualidade dos dados e ajuda analistas e partes interessadas a saber o quanto os insights sobre o processo estão atualizados. Onde encontrar Esses dados de data e hora são gerados durante o processo de extração, transformação e carregamento (ETL) e geralmente se aplicam ao conjunto de dados inteiro. Exemplos 2024-05-20T08:00:00Z2024-05-21T08:00:00Z | |||
| Código do motivo da negativa DenialReasonCode | Código padronizado da fonte pagadora que explica por que uma conta foi negada. | ||
| Descrição Quando uma fonte pagadora nega uma conta, ela informa um código de motivo, como um CARC (Claim Adjustment Reason Code), para explicar a decisão. Esses códigos são padronizados e indicam problemas como 'Serviço não coberto' ou 'Conta duplicada'. Este atributo é muito importante para a gestão de negativas. Ao analisar a frequência dos diferentes códigos de motivo, as organizações podem identificar e tratar as causas raiz das negativas, sejam elas relacionadas à elegibilidade do paciente, a erros de codificação ou à falta de necessidade médica. Isso contribui diretamente para reduzir o retrabalho e acelerar o fluxo de caixa. Por que isso importa Informa o motivo específico das negativas de contas e permite analisar as causas raiz para reduzir negativas futuras, diminuir o retrabalho e melhorar a taxa de pagamentos na primeira tentativa. Onde encontrar Essa informação é recebida no demonstrativo eletrônico de pagamento (arquivo ERA ou 835) da fonte pagadora e fica armazenada no módulo de gestão de contas da R1 RCM. Exemplos CO-16: Faltam informações necessárias para analisar a conta ou o serviço.PR-97: O benefício deste serviço está incluído no pagamento ou desconto de outro serviço.CO-22: Este atendimento pode ser coberto por outra fonte pagadora, conforme as regras de coordenação de benefícios.OA-18: Conta ou serviço exatamente duplicado. | |||
| Departamento de faturamento BillingDepartment | Departamento ou equipe funcional responsável por realizar a atividade. | ||
| Descrição Este atributo especifica a unidade organizacional, como 'Registro de cobranças', 'Envio de contas' ou 'Gestão de negativas', que executou uma etapa específica do processo. Ele ajuda a entender como o trabalho é transferido entre diferentes equipes. Isso é essencial para analisar o fluxo de trabalho entre departamentos e identificar gargalos entre áreas. Ao filtrar o mapa do processo por departamento, as organizações podem ver onde as transferências funcionam bem e onde ocorrem atrasos, apoiando a alocação de recursos e a otimização dos processos organizacionais. Por que isso importa Permite analisar a performance do processo por unidade organizacional e ajuda a identificar gargalos específicos de cada equipe, restrições de recursos ou boas práticas. Onde encontrar Essa informação pode vir do perfil do usuário na R1 RCM ou estar armazenada como 'Department Code' nos dados da transação. Exemplos Registro de cobrançasGestão de reivindicaçõesNegativas e recursosContabilização de pagamentos | |||
| Nome da operadora PayerName | Nome da seguradora, entidade governamental ou paciente responsável pelo pagamento. | ||
| Descrição Este atributo identifica a principal fonte pagadora da conta. Pode ser uma seguradora comercial, como a Aetna, uma fonte pagadora governamental, como o Medicare, ou o próprio paciente, no caso de valores pagos diretamente. Analisar o processo por fonte pagadora é fundamental para a gestão do ciclo da receita. Isso pode revelar que determinadas fontes pagadoras têm mais negativas, ciclos de pagamento mais longos ou requisitos de envio mais complexos. Esses insights permitem adaptar os processos e os recursos para lidar melhor com as particularidades de cada fonte pagadora. Por que isso importa Permite segmentar o processo por fonte pagadora para identificar atrasos, padrões de negativas ou comportamentos de pagamento específicos, algo essencial para otimizar a receita. Onde encontrar Está nos dados do seguro ou demográficos do paciente vinculados à conta na R1 RCM. Exemplos MedicareUnitedHealthcareBlue Cross Blue ShieldAetnaPagamento direto pelo paciente | |||
| Status da fatura InvoiceStatus | Status atual da fatura ou da conta ao longo do seu ciclo de vida. | ||
| Descrição Este atributo indica o último status conhecido de um evento de faturamento, como 'Enviado', 'Pago', 'Negado' ou 'Em cobrança'. Ele mostra em que etapa do processo a fatura está em determinado momento. O status da fatura é essencial para criar relatórios de contas vencidas e acompanhar a situação das contas a receber. Na mineração de processos, ele pode ser usado para filtrar casos parados em determinado status ou analisar os resultados de diferentes variantes do processo, por exemplo, comparando os caminhos de contas 'Pagas' e 'Negadas'. Por que isso importa Mostra o status atual de cada caso, essencial para criar relatórios de contas vencidas e analisar os resultados finais de diferentes caminhos do processo. Onde encontrar Geralmente é um campo de status no registro principal da conta ou do paciente na R1 RCM. Exemplos Aguardando envioEnviado à operadoraNegadoPago integralmenteEm cobrança | |||
| Usuário responsável AssignedUser | ID ou nome do funcionário que realizou a atividade. | ||
| Descrição Este atributo identifica a pessoa responsável por executar uma tarefa específica do processo. Pode ser o profissional de faturamento que criou a conta, o analista que refez o trabalho em uma negativa ou o especialista que contabilizou um pagamento. Analisar os dados por usuário ajuda a entender a distribuição da carga de trabalho, a performance individual e as necessidades de treinamento. Isso pode mostrar quais usuários trabalham com mais eficiência ou estão associados a mais erros, permitindo direcionar ações de gestão e melhoria do processo. Por que isso importa Permite analisar a performance da equipe e de cada pessoa, além da distribuição da carga de trabalho, e ajuda a identificar oportunidades de treinamento ou desvios do processo associados a usuários específicos. Onde encontrar Geralmente aparece como um campo 'UserID', 'Processor' ou 'UpdatedBy' nos registros de transação da R1 RCM. Exemplos jdoeasmithp.jonesBOT_RPA01 | |||
| Valor da fatura InvoiceAmount | Valor monetário total das cobranças na fatura ou conta. | ||
| Descrição Este atributo representa o valor total faturado pelos serviços prestados em um determinado evento de faturamento. Ele corresponde à receita esperada pela conta. Analisar o valor da fatura é essencial para a mineração de processos financeiros. Isso permite priorizar contas de alto valor, entender o impacto financeiro de atrasos ou negativas e segmentar o processo por valor. Por exemplo, uma análise pode revelar que contas acima de determinado valor seguem um fluxo diferente, com mais etapas manuais. Por que isso importa Dá contexto financeiro ao processo, permitindo analisar como as variações do processo afetam a receita e priorizar casos de alto valor para melhoria. Onde encontrar Fica na tabela principal de cabeçalho da conta ou da fatura na R1 RCM, geralmente com o nome 'TotalBilledAmount' ou algo semelhante. Exemplos 150.002500.7585.5012000.00 | |||
| Código do serviço ServiceCode | Código de faturamento do serviço ou procedimento prestado, como um código CPT ou HCPCS. | ||
| Descrição Códigos de serviço, como os códigos CPT (Current Procedural Terminology), são códigos médicos padronizados usados para informar às fontes pagadoras sobre procedimentos e serviços médicos, cirúrgicos e diagnósticos para fins de reembolso. Analisar o processo por código de serviço é essencial para identificar problemas de faturamento relacionados a tipos específicos de atendimento. Isso pode mostrar quais procedimentos são negados com mais frequência, têm os ciclos de pagamento mais longos ou exigem mais retrabalho, permitindo melhorias direcionadas nas práticas de codificação e faturamento. Por que isso importa Permite analisar o processo com base no tipo de serviço prestado, algo essencial para identificar padrões de negativas ou atrasos de pagamento associados a procedimentos específicos. Onde encontrar Essa informação aparece no nível do item de cobrança para cada cobrança ou conta na R1 RCM. Exemplos 992139928573560 | |||
| É automatizado IsAutomated | Indicador que informa se a atividade foi realizada por um sistema automatizado ou por uma pessoa. | ||
| Descrição Este atributo booleano diferencia tarefas executadas por automação de software, como um bot de RPA que envia contas, daquelas realizadas manualmente por um funcionário. Analisar este atributo é essencial para entender o impacto e a eficácia das iniciativas de automação. Ele permite comparar a velocidade, o custo e as taxas de erro dos processos automatizados e manuais, ajudando a identificar novas oportunidades de automação e medir o ROI dos bots existentes. Por que isso importa Diferencia atividades realizadas por pessoas daquelas executadas por sistemas, algo essencial para medir o impacto da automação na eficiência, no custo e na qualidade do processo. Onde encontrar Essa informação pode ser obtida do campo 'AssignedUser', no qual determinados IDs de usuário são reservados para bots (por exemplo, 'BOT_RPA01'). Alguns sistemas também têm um campo específico para identificar transações automatizadas. Exemplos truefalse | |||
| É retrabalho IsRework | Indicador calculado que identifica atividades que fazem parte de um ciclo de retrabalho, como o reenvio de uma conta negada. | ||
| Descrição Este atributo é um indicador booleano geralmente calculado durante a análise de mineração de processos. Seu valor é 'true' quando uma atividade repete uma etapa anterior ou faz parte de uma sequência que indica a correção de um erro, por exemplo, qualquer atividade após 'Conta negada'. Identificar retrabalho é um dos recursos mais úteis da mineração de processos. Isso permite quantificar o desperdício de esforço, tempo e recursos no processo. Ao identificar o retrabalho, as organizações podem direcionar as melhorias para evitar os erros que o causam, gerando ganhos significativos de eficiência. Por que isso importa Ajuda a quantificar a frequência e o impacto do retrabalho, como as negativas de contas, e permite direcionar a análise para reduzir ineficiências e esforço desperdiçado. Onde encontrar Este campo não existe no sistema de origem. A ferramenta de mineração de processos o calcula com base na sequência de atividades, por exemplo, identificando quando a atividade 'Conta enviada' ocorre mais de uma vez no mesmo caso. Exemplos truefalse | |||
| ID do paciente PatientId | Identificador exclusivo do paciente que recebeu o serviço. | ||
| Descrição Este atributo é o ID exclusivo atribuído a um paciente no sistema de saúde, geralmente chamado de número do prontuário médico (MRN). Embora o atendimento individual ao paciente não seja o foco, o ID do paciente pode ser usado para analisar problemas recorrentes de faturamento ao longo do tempo. Ele também pode ajudar a segmentar o processo por dados demográficos ou histórico do paciente, quando vinculado a outros dados, e revelar problemas sistêmicos que afetam determinados grupos. Por que isso importa Permite analisar eventos de faturamento por paciente e ajuda a identificar problemas recorrentes ou padrões para pacientes específicos em vários atendimentos. Onde encontrar Este identificador é parte essencial dos dados demográficos do paciente vinculados a cada atendimento e conta na R1 RCM. Exemplos MRN837262MRN937281MRN103847 | |||
| Motivo do ajuste AdjustmentReason | Motivo informado para um ajuste financeiro, como 'Desconto contratual' ou 'Baixa de dívida incobrável'. | ||
| Descrição Este atributo explica por que um ajuste financeiro foi feito em uma conta. Os motivos geralmente são códigos ou descrições padronizados que categorizam o tipo de ajuste. Analisar os motivos dos ajustes ajuda a identificar as causas raiz da perda de receita. Por exemplo, muitas 'Baixas de saldo pequeno' podem indicar um processo de cobrança ineficiente para valores baixos, enquanto 'Descontos contratuais' frequentes são esperados nas negociações com as fontes pagadoras. Essa análise dá suporte ao Dashboard de auditoria de ajustes de faturamento e conformidade. Por que isso importa Explica os motivos dos ajustes de receita e ajuda a identificar as causas raiz da perda de receita, como problemas contratuais, erros de faturamento ou falhas na cobrança. Onde encontrar Geralmente é um campo de código ou texto no mesmo registro de transação que o AdjustmentAmount na R1 RCM. Exemplos Desconto contratualBaixa de dívida incobrávelBaixa de saldo pequenoCorreção de erro de faturamento | |||
| Resultado da cobrança CollectionOutcome | Resultado final das atividades de cobrança de um saldo em aberto. | ||
| Descrição Este atributo descreve o resultado das tentativas de receber o pagamento de uma conta vencida. Os resultados possíveis incluem 'Pago integralmente', 'Quitado por valor menor', 'Encaminhado para cobrança de dívida incobrável' ou 'Não resolvido'. Acompanhar os resultados das cobranças é essencial para avaliar a eficácia do processo. Ao analisar quais atividades levam a cada resultado, as organizações podem otimizar suas estratégias de cobrança, melhorar as taxas de recuperação e tomar decisões fundamentadas sobre quando encerrar as tentativas de cobrança e baixar os saldos. Isso dá suporte ao Dashboard de performance das atividades de cobrança. Por que isso importa Mede a eficácia do processo de cobrança acompanhando a resolução final de contas vencidas e ajuda a otimizar as estratégias de cobrança. Onde encontrar Provavelmente é um campo de status na conta do paciente ou em um módulo específico de cobrança da R1 RCM. Exemplos Pago integralmenteQuitado por valor menorEnviado para agência externaBaixado como dívida incobrável | |||
| Tempo de ciclo do serviço ao pagamento ServiceToPaymentCycleTime | Duração total calculada entre a prestação do serviço e o lançamento do pagamento final. | ||
| Descrição Esta métrica mede a duração de ponta a ponta do ciclo da receita para um único evento de faturamento. Ela representa o tempo total que a organização leva para transformar um serviço prestado em dinheiro recebido. Este é um indicador-chave de performance (KPI) essencial para a saúde financeira. Analisar essa duração ajuda a identificar as principais oportunidades para acelerar o processo. Ao dividir o tempo de ciclo em etapas, como 'tempo até o faturamento' e 'tempo até o pagamento', as organizações podem identificar as maiores oportunidades de melhorar o fluxo de caixa. Por que isso importa Este é um KPI essencial e estratégico que mede a eficiência geral do ciclo de conversão de caixa e afeta diretamente o fluxo de caixa da organização. Onde encontrar Esta métrica é calculada pela diferença entre a data e hora da atividade 'Serviço prestado' e as da atividade 'Pagamento contabilizado' para um determinado evento de faturamento. Exemplos 35 dias e 8 horas92 dias e 4 horas15 dias e 12 horas | |||
| Valor do ajuste AdjustmentAmount | Valor monetário de um ajuste feito no saldo da conta. | ||
| Descrição Este atributo registra o valor de qualquer ajuste financeiro feito na conta de um paciente após o faturamento inicial. Os ajustes podem ser positivos ou negativos e incluem descontos contratuais, baixas ou correções. Acompanhar os valores dos ajustes é essencial para entender a integridade da receita. Um volume elevado de ajustes negativos pode indicar perda de receita causada por problemas como o registro incorreto de cobranças ou dívidas incobráveis. Analisar esses dados ajuda a identificar o impacto financeiro de erros de faturamento e ineficiências na cobrança. Por que isso importa Quantifica a perda de receita e as correções financeiras, ajudando a identificar o impacto monetário de imprecisões no faturamento, obrigações contratuais ou dívidas incobráveis. Onde encontrar Está nos registros de transação relacionados a ajustes de conta ou à contabilização de pagamentos na R1 RCM. Exemplos -50.2520.00-1200.00 | |||
Atividades da gestão do ciclo de receita
| Atividade | Descrição | ||
|---|---|---|---|
| Cobranças registradas | Esta atividade representa o registro formal de todos os serviços, procedimentos e materiais faturáveis de um atendimento. É uma etapa crítica de entrada de dados que transforma atividades clínicas em transações financeiras. | ||
| Por que isso importa Marca a transferência das operações clínicas para as financeiras. É o ponto de partida para medir os tempos de ciclo de geração de faturas e solicitações de pagamento, além de ajudar a identificar acúmulos no registro de cobranças. Onde encontrar Registrado no módulo de lançamento de cobranças do R1 RCM ou recebido por uma interface de um prontuário eletrônico (EHR). O evento costuma ser marcado por um registro de transação específico ou pela data e hora de criação do registro da cobrança. Coleta Identificado pela data e hora de criação do registro da transação de cobrança na tabela de faturamento. Tipo de evento explicit | |||
| Conta encerrada | O evento de faturamento foi totalmente resolvido, o saldo chegou a zero e a conta foi encerrada formalmente. Isso indica a conclusão bem-sucedida do ciclo de receita desse atendimento. | ||
| Por que isso importa Este é o evento final do caminho ideal do processo. Medir o tempo de ciclo de encerramento da conta ajuda a garantir que as tarefas administrativas sejam concluídas com eficiência e os registros, finalizados. Onde encontrar Inferido quando o saldo da conta chega a zero e o status final "Encerrada" ou "Paga integralmente" é aplicado. A data e hora são obtidas da última transação financeira que zerou o saldo. Coleta Inferido quando o saldo da conta chega a zero e o status "Encerrada" é aplicado, junto com a data e hora da última atividade. Tipo de evento inferred | |||
| Pagamento recebido | Um pagamento é recebido de um pagador ou de um paciente. Este evento marca o recebimento dos recursos, mas eles ainda não foram aplicados à conta ou aos serviços específicos. | ||
| Por que isso importa Representa uma entrada de caixa. O intervalo entre "Pagamento recebido" e "Pagamento registrado" é uma métrica importante para entender a eficiência das operações administrativas e os atrasos na conciliação de caixa. Onde encontrar Registrado a partir de arquivos eletrônicos de remessa dos pagadores ou do processamento de pagamentos de pacientes. O evento corresponde à data do depósito ou do recebimento do arquivo. Coleta Registrado com base na data efetiva do pagamento no arquivo ERA ou na data da transação de pagamento do paciente. Tipo de evento explicit | |||
| Pagamento registrado | O pagamento recebido é aplicado oficialmente à conta do paciente, reduzindo o saldo em aberto. Esta é a etapa final da conciliação do pagamento com os serviços faturados. | ||
| Por que isso importa Esta atividade marca o ponto final para calcular os tempos de ciclo entre a prestação do serviço e o pagamento e para o registro de pagamentos. Ela confirma o reconhecimento da receita e a atualização correta das contas. Onde encontrar Registrado como uma transação financeira explícita no módulo de contabilidade de pacientes do R1 RCM. Cada lançamento inclui uma data, um valor e uma origem. Coleta Registrado como uma transação específica com uma data de lançamento, quando uma pessoa ou um processo automatizado aplica o pagamento. Tipo de evento explicit | |||
| Serviço prestado | Indica o momento em que um serviço ou procedimento faturável é concluído para um paciente. Esse evento costuma ser registrado em um sistema clínico ou de agendamento e dá início ao ciclo de receita. | ||
| Por que isso importa Este é o ponto de partida do KPI de tempo de ciclo entre a prestação do serviço e o pagamento. Analisar o tempo desde esse evento ajuda a identificar atrasos nas etapas iniciais do ciclo de receita. Onde encontrar Geralmente, os dados vêm de um prontuário eletrônico (EHR) ou de um sistema de gestão de consultórios integrado ao R1 RCM. O evento costuma ser inferido a partir da data do serviço ou da data e hora de conclusão do procedimento no prontuário do paciente. Coleta Inferido a partir da data e hora do atendimento associadas ao encontro com o paciente. Tipo de evento inferred | |||
| Solicitação de pagamento enviada | A solicitação de pagamento gerada é enviada eletronicamente ao pagador responsável, como uma seguradora. Este é o primeiro contato externo do processo de faturamento para obter o reembolso. | ||
| Por que isso importa Um marco crítico que inicia a contagem do prazo para o reembolso pelo pagador. Acompanhar esse evento ajuda a monitorar o acúmulo de envios e a garantir que os prazos de envio exigidos pelos pagadores sejam cumpridos. Onde encontrar Este evento é registrado como uma transação explícita quando a solicitação de pagamento é transmitida a uma câmara de compensação. O sistema registra a data e hora do envio e os detalhes da confirmação. Coleta Registrado explicitamente como uma transação com a data e hora do envio, quando a solicitação de pagamento é encaminhada pela câmara de compensação. Tipo de evento explicit | |||
| Ajuste de conta realizado | Uma transação que não é de pagamento é lançada na conta para alterar o saldo. Isso pode incluir ajustes contratuais com base em acordos com pagadores, baixas de saldos pequenos ou correções. | ||
| Por que isso importa Um volume elevado de ajustes pode indicar problemas nas tabelas de preços, na gestão de contratos ou erros de faturamento. Acompanhar os ajustes é essencial para analisar a integridade da receita. Onde encontrar Registrado como um tipo específico de transação no módulo de contabilidade de pacientes do R1 RCM. Cada ajuste tem um código, um valor e uma data de lançamento. Coleta Registrado como uma transação de ajuste distinta, identificada por um código de transação exclusivo. Tipo de evento explicit | |||
| Atividade de cobrança iniciada | A conta do paciente está em atraso e as ações proativas de cobrança são iniciadas. Elas podem incluir desde cartas de lembrete automatizadas até o encaminhamento do caso a um especialista em cobranças. | ||
| Por que isso importa Marca o início do processo de cobrança, que exige muitos recursos. Analisar a eficácia e o tempo de ciclo dessas atividades ajuda a otimizar as estratégias de recuperação de dívidas em atraso. Onde encontrar Este evento provavelmente é registrado ou inferido a partir de uma mudança de status, quando uma conta é transferida para uma fila de trabalho de cobrança ou recebe um código de status de cobrança no R1 RCM. Coleta Inferido a partir da mudança de status da conta para "Em cobrança" ou "Em atraso". Tipo de evento inferred | |||
| Conta classificada como dívida incobrável | Todas as tentativas de cobrança foram esgotadas e o saldo restante da conta é considerado incobrável. O saldo é baixado como dívida incobrável, representando uma perda definitiva de receita. | ||
| Por que isso importa Este é um resultado negativo do processo e representa uma perda direta de receita. Analisar quais casos terminam como dívidas incobráveis pode revelar padrões de inadimplência e oportunidades para melhorar as cobranças. Onde encontrar Normalmente, este é um lançamento explícito no R1 RCM, pelo qual o saldo em aberto é transferido para uma categoria específica de dívida incobrável, geralmente por ação de um usuário ou de regras automatizadas de envelhecimento de saldo. Coleta Registrado como uma transação financeira específica para baixar o saldo, muitas vezes associada à transferência para uma agência externa de cobrança. Tipo de evento explicit | |||
| Demonstrativo do paciente gerado | Após a análise do seguro, é criado um demonstrativo para o paciente com o saldo restante sob sua responsabilidade. Esse valor pode incluir coparticipações, franquias ou serviços não cobertos. | ||
| Por que isso importa Esta atividade inicia a etapa de pagamento pelo paciente no ciclo de receita. Analisar seu momento e frequência é importante para gerenciar as cobranças de pacientes e o fluxo de caixa. Onde encontrar Geralmente, é registrado como um evento quando um processo em lote cria e imprime ou envia eletronicamente os demonstrativos dos pacientes. O R1 RCM registra a data de geração do demonstrativo. Coleta Registrado como uma transação quando o processo em lote de geração dos demonstrativos dos pacientes é executado. Tipo de evento explicit | |||
| Resposta do pagador recebida | O sistema recebe uma resposta do pagador sobre a solicitação de pagamento enviada, geralmente em um arquivo de aviso eletrônico de remessa (ERA). A resposta detalha os valores pagos, negados ou ajustados. | ||
| Por que isso importa Este evento é uma bifurcação importante no processo, pois determina se a próxima etapa será o registro do pagamento ou a gestão de negativas. Analisá-lo ajuda a entender o comportamento dos pagadores e a velocidade dos pagamentos. Onde encontrar Registrado quando o R1 RCM processa um arquivo eletrônico de remessa do pagador, como um arquivo ANSI 835. O evento é marcado pela data e hora de processamento do arquivo. Coleta Registrado quando o arquivo de aviso eletrônico de remessa (ERA/835) é recebido e processado. Tipo de evento explicit | |||
| Retrabalho de negativa iniciado | Uma pessoa ou um fluxo de trabalho automatizado começa a investigar e resolver uma solicitação de pagamento negada. Isso pode envolver corrigir a codificação, enviar documentação ou recorrer da decisão do pagador. | ||
| Por que isso importa Marca o início do ciclo oneroso de retrabalho das solicitações negadas. Medir o tempo gasto nessa etapa é essencial para entender a eficiência da equipe responsável pela gestão de negativas. Onde encontrar Este evento costuma ser inferido quando o status da solicitação negada muda para "Retrabalho em andamento" ou "Em revisão" em uma fila de trabalho ou módulo de gestão de negativas do R1 RCM. Coleta Inferido a partir de uma mudança de status em uma fila de trabalho de gestão de negativas ou da primeira ação de um usuário em uma solicitação negada. Tipo de evento inferred | |||
| Solicitação de pagamento criada | Uma solicitação formal de pagamento é gerada no sistema com base nas cobranças registradas. Para isso, são reunidos os dados demográficos do paciente, as informações do seguro e os códigos dos serviços em um formato padronizado. | ||
| Por que isso importa Este é um marco interno importante antes do envio externo. Atrasos nessa etapa podem indicar problemas de codificação, validação de dados ou configuração do sistema que tornam todo o processo de faturamento mais lento. Onde encontrar Este é um evento interno do sistema R1 RCM. Ele provavelmente é registrado como uma mudança de status na conta de faturamento ou pela data e hora de criação do próprio registro da solicitação de pagamento. Coleta Inferido a partir da mudança de status para "Solicitação de pagamento gerada" ou da data e hora de criação do registro da solicitação. Tipo de evento inferred | |||
| Solicitação de pagamento negada | O pagador recusou o pagamento total ou parcial da solicitação. O motivo da negativa é registrado e dá início ao processo de retrabalho e recurso. | ||
| Por que isso importa Esta atividade evidencia perda de receita e ineficiência do processo. Analisar os motivos das negativas é essencial para identificar as causas raiz e aumentar a taxa de aprovação das solicitações na primeira tentativa. Onde encontrar Este não é um evento isolado, mas um status inferido dos detalhes de um arquivo ERA processado. Códigos específicos de negativa nos dados da remessa alteram o status da solicitação de pagamento. Coleta Inferido a partir dos códigos de negativa no arquivo ERA processado, que alteram o status da solicitação para "Negada". Tipo de evento inferred | |||
Guias de extração
Etapas
- Acesse a plataforma R1 RCM com uma conta de usuário que tenha permissão para acessar os módulos de Business Intelligence ou relatórios.
- Acesse a seção de relatórios da plataforma. Ela pode aparecer como "Business Intelligence", "Reporting Portal" ou "Analytics".
- Localize a ferramenta para criar um novo relatório ou consulta personalizada. Nela, você pode definir os campos de dados e a lógica específicos para a extração.
- Como a R1 RCM não fornece um Event Log unificado pronto para uso, você precisa criá-lo combinando dados de diferentes fontes. A configuração de consulta fornecida usa uma abordagem UNION ALL para reunir eventos de vários objetos de negócio em um único registro 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 período. Defina os marcadores
'{StartDate}'e'{EndDate}'na consulta para especificar o intervalo da extração, como os últimos 6 meses. - Adicione outros filtros necessários à configuração do relatório, como unidade, departamento ou grupo de pagadores, para restringir o escopo dos dados.
- Execute o relatório. A consulta será processada no banco de dados da R1 RCM e os resultados serão gerados de acordo com os parâmetros definidos.
- Quando a execução terminar, localize a opção de exportação dos dados. Selecione CSV (valores separados por vírgula), formato diretamente compatível com o ProcessMind.
- Baixe o arquivo CSV gerado e abra-o para fazer uma revisão rápida. Confira se os cabeçalhos das colunas correspondem aos atributos necessários:
BillingEvent,ActivityName,EventTime,SourceSystemeLastDataUpdate. - Antes de carregar o arquivo no ProcessMind, verifique se os formatos de data e hora nas colunas
EventTimeeLastDataUpdatesão consistentes.
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 Business Intelligence da R1 RCM.
- Tipo de relatório: Use uma consulta personalizada ou um criador de relatórios avançado que permita recuperar dados complexos e usar instruções UNION ALL para combinar diferentes conjuntos de dados.
- Período: Para controlar o desempenho e o volume de dados, é fundamental filtrar um período específico. Recomendamos começar com um intervalo 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 período, considere filtrar por
Facility ID,Payer TypeouBilling Departmentpara concentrar 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. Assim, você terá um arquivo estruturado e fácil de processar por ferramentas de Process Mining.
- Agendamento: Se o módulo de relatórios da R1 RCM oferecer esse recurso, considere programar a execução recorrente do relatório, por exemplo, semanal ou mensalmente, para atualizar os dados automaticamente e permitir o monitoramento contínuo.
a Consulta de exemplo sql
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; Pronto para começar?
Use este Template para simplificar a coleta de dados e dar início à otimização da gestão do ciclo de receita. Estamos aqui para apoiar você em cada etapa.
Otimize agora seu R1 RCM: aumente a eficiência do ciclo de receita
Elimine gargalos no RCM, reduza o tempo de ciclo em 30% e melhore o fluxo de caixa.
Não é necessário cartão de crédito. Comece em poucos minutos.