Seu Template de dados de gerenciamento do ciclo de receita
Seu Template de dados de gerenciamento do ciclo de receita
Este é nosso Template genérico de dados para Process Mining para Gestão do ciclo de receita. Use nossos Templates específicos de sistemas para obter orientações mais detalhadas.
Selecione um sistema específico- Aplicável a qualquer sistema de RCM para Process Mining.
- Atributos e atividades essenciais para criar um Event Log eficiente.
- Um recurso fundamental para uma análise e otimização robustas do processo.
Atributos da gestão do ciclo de receita
| Nome | Descrição | ||
|---|---|---|---|
| ID do evento de faturamento BillingEventId | O identificador exclusivo de uma única entrega de serviço ou produto que gera uma cobrança. Ele funciona como o identificador principal do caso no processo do ciclo de receita. | ||
| Descrição O ID do evento de faturamento é uma chave exclusiva atribuída a cada instância de um serviço faturável, desde a captura inicial da cobrança até o pagamento ou a baixa final. Ele funciona como o fio condutor central que conecta todas as atividades relacionadas, como criação, envio, negativa e lançamento do pagamento de um sinistro, para um atendimento específico. No Process Mining, esse atributo é fundamental para reconstruir a jornada de ponta a ponta de cada evento de faturamento. Ao agrupar todas as atividades relacionadas sob um único ID do evento de faturamento, os analistas conseguem visualizar os fluxos do processo, identificar gargalos, medir tempos de ciclo e entender as variações na forma como diferentes casos são tratados. Ele é a base de toda análise centrada no caso dentro do ciclo de receita. Por que isso importa É o identificador essencial do caso que conecta todas as atividades relacionadas, permitindo reconstruir e analisar todo o ciclo de receita de cada serviço faturável. Onde obter Normalmente, é uma chave primária em tabelas de transações de faturamento ou de eventos financeiros. Exemplos BE-2024-001234INV-987654ACCN-456789012 | |||
| Nome da atividade ActivityName | O nome da etapa, tarefa ou evento específico que ocorreu no processo do ciclo de receita para um determinado evento de faturamento. | ||
| Descrição O nome da atividade descreve uma ação ou um marco distinto no ciclo de vida do ciclo de receita. Exemplos incluem 'Serviço prestado', 'Sinistro enviado', 'Remessa recebida', 'Pagamento lançado' e 'Conta baixada'. Cada atividade representa uma etapa do processo que consome tempo e recursos. Esse atributo é fundamental para o Process Mining, pois define os nós do mapa do processo. Analisar a sequência, a frequência e a duração dessas atividades permite visualizar o fluxo real do processo, comparar o processo com um modelo projetado e identificar desvios, ciclos de retrabalho, como negativas de sinistros, e ineficiências. Por que isso importa Esse atributo define as etapas do processo, sendo essencial para descobrir e visualizar o mapa do processo, identificar retrabalho e analisar a conformidade do processo. Onde obter Geralmente encontrado em logs de eventos, tabelas de transações ou derivado de registros de mudança de status no módulo de faturamento ou sinistros. Exemplos Solicitação enviadaPagamento lançadoRetrabalho da negativa iniciadoExtrato do paciente enviado | |||
| Registro de data e hora do evento EventTimestamp | A data e hora exatas em que uma atividade específica foi registrada no sistema. | ||
| Descrição O registro de data e hora do evento marca o momento em que uma atividade ocorreu ou foi registrada. Ele fornece o contexto cronológico de todos os eventos dentro de um caso, formando uma linha do tempo do início ao fim do ciclo de receita. Os registros de data e hora são a base da análise de performance no Process Mining. Eles são usados para calcular KPIs críticos, como o tempo total do ciclo, a duração entre atividades específicas e os tempos de espera. Ao analisar esses registros, as organizações conseguem identificar gargalos em que os casos passam mais tempo, medir a aderência aos acordos de nível de serviço e entender a dinâmica temporal do processo. Por que isso importa Ele fornece os dados cronológicos necessários para calcular tempos de ciclo, identificar gargalos e analisar a performance e a eficiência do processo. Onde obter Essas informações geralmente estão disponíveis em logs de transações, trilhas de auditoria ou em um campo de 'data de criação' ou 'data de mudança de status' nas tabelas de eventos. Exemplos 2023-10-26T10:00:00Z2023-11-15T14:35:10Z2024-01-05T09:12:45Z | |||
| Sistema de origem SourceSystem | O sistema de informação, aplicativo ou módulo do qual os dados do evento foram extraídos. | ||
| Descrição O atributo Sistema de origem identifica a origem dos dados de um evento específico. Em um ambiente de TI complexo, o processo do ciclo de receita geralmente abrange vários sistemas, como um sistema de prontuário eletrônico (EHR) para o registro do serviço, um sistema dedicado de faturamento para o envio de sinistros e uma plataforma separada de cobrança. Conhecer o sistema de origem é valioso para validar dados, solucionar problemas e entender a fragmentação do processo. Isso pode ajudar a identificar inconsistências entre sistemas ou revelar etapas do processo gerenciadas em aplicativos diferentes, que podem ser fontes de atrasos ou erros na transferência de dados. Essa análise ajuda a avaliar a integração e a eficiência da arquitetura geral de TI que sustenta o processo. Por que isso importa Ele ajuda a entender a fragmentação do processo entre diferentes sistemas de TI e é fundamental para validar dados e identificar gargalos específicos de cada sistema. Onde obter Essas informações geralmente estão disponíveis como um campo padrão nas extrações de dados ou podem ser derivadas da tabela ou do arquivo de origem dos dados. Exemplos Epic ResoluteOracle HealthR1 RCM PlatformWaystar | |||
| Última atualização dos dados LastDataUpdate | O registro de data e hora que indica a última vez em que os dados desse registro de evento específico foram atualizados ou extraídos do sistema de origem. | ||
| Descrição Esse atributo registra quando os dados foram extraídos pela última vez do sistema de origem. É um campo de metadados fundamental para entender a atualidade e a pontualidade dos dados analisados. Ele reflete a latência do pipeline de dados e indica o quanto a análise de Process Mining está atualizada. Em Dashboards e análises de Process Mining, o registro de data e hora da última atualização dos dados fornece ao usuário o contexto sobre a atualidade dos dados. É essencial saber, no monitoramento operacional, se a visualização representa o estado do processo de cinco minutos atrás ou da noite anterior. Isso ajuda a gerenciar as expectativas dos usuários e garantir que as decisões sejam tomadas com base em dados cuja idade é conhecida. Por que isso importa Ele fornece um contexto essencial sobre a atualidade dos dados, garantindo que as análises e decisões sejam baseadas em um período conhecido. Onde obter Normalmente, esse atributo é adicionado durante o processo de extração, transformação e carregamento (ETL) dos dados e armazenado como uma coluna de metadados no Event Log. Exemplos 2024-03-15T02:00:00Z2024-03-15T03:00:00Z2024-03-15T04:00:00Z | |||
| Categoria do serviço ServiceCategory | A categoria, o tipo ou a classificação do serviço prestado, como internação, atendimento ambulatorial ou radiologia. | ||
| Descrição A categoria do serviço classifica o tipo de atendimento ou serviço prestado ao paciente. Pode ser uma classificação de alto nível, como “internação” e “atendimento ambulatorial”, ou uma categoria departamental mais específica, como “cirurgia”, “emergência” ou “laboratório”. Diferentes categorias de serviço geralmente têm regras de faturamento, requisitos das operadoras e fluxos de processo próprios. Segmentar o processo de ciclo de receita por categoria do serviço é essencial para uma análise relevante. Isso permite comparar a performance de diferentes linhas de serviço, por exemplo, verificando se a taxa de negativas de procedimentos cirúrgicos é maior que a de consultas. Esse nível de detalhe ajuda a isolar problemas e adaptar as iniciativas de melhoria ao contexto operacional específico de cada área de serviço. Por que isso importa Ele permite comparar a performance entre diferentes linhas de serviço, revelando variações de eficiência, taxas de negativas e ciclos de pagamento específicos de determinados tipos de atendimento. Onde obter Essas informações geralmente estão disponíveis nos registros detalhados das cobranças ou podem ser derivadas da classe do paciente, do departamento ou dos códigos de procedimento. Exemplos InternaçãoAtendimento ambulatorialEmergênciaRadiologiaProcedimento cirúrgico | |||
| Código do motivo da negativa DenialReasonCode | Um código padronizado e uma descrição que indicam o motivo pelo qual um sinistro foi negado pela operadora. | ||
| Descrição Quando uma operadora rejeita um sinistro enviado, ela fornece um código do motivo da negativa para explicar por que o sinistro não foi pago. Esses códigos geralmente seguem padrões do setor, como os Claim Adjustment Reason Codes (CARCs), e apontam para problemas específicos, como 'Serviço não coberto', 'Sinistro duplicado' ou 'Informações adicionais necessárias'. Esse atributo é um dos mais importantes para a análise de causas-raiz no ciclo de receita. Ao analisar a frequência e o impacto financeiro de diferentes motivos de negativa, as organizações conseguem identificar as falhas nos processos anteriores que levam às negativas. Por exemplo, um número alto de negativas por 'Informações incorretas do paciente' aponta para problemas no processo de cadastro do paciente. Isso permite fazer melhorias baseadas em dados para evitar negativas futuras e aumentar a taxa de pagamento na primeira tentativa. Por que isso importa Ele é fundamental para a análise das causas-raiz das negativas de sinistros, permitindo melhorias direcionadas nos processos iniciais e intermediários para evitar perdas futuras de receita. Onde obter Essas informações são obtidas dos arquivos de Electronic Remittance Advice (ERA) ou Explanation of Benefits (EOB) recebidos das operadoras. Exemplos CO-16: A solicitação/serviço não contém as informações necessáriasPR-97: O benefício deste serviço está incluído no pagamento de outro serviçoOA-18: Solicitação/serviço duplicadoCO-22: Este atendimento pode ser coberto por outro pagador, conforme a coordenação de benefícios | |||
| Departamento responsável ResponsibleDepartment | O departamento, a equipe ou a área funcional responsável por realizar a atividade. | ||
| Descrição Esse atributo identifica a unidade organizacional associada a uma determinada etapa do processo, como 'Acesso do paciente', 'Codificação', 'Faturamento' ou 'Cobrança'. Ele ajuda a entender como o trabalho é distribuído e transferido entre diferentes equipes. Analisar o processo pela perspectiva departamental é essencial para entender a colaboração entre áreas e identificar gargalos que ocorrem nos pontos de transferência entre equipes. Isso permite que os gestores vejam quais departamentos participam de determinadas variantes do processo, meçam a eficiência departamental e aloquem recursos com mais eficácia. Essa análise pode destacar problemas sistêmicos dentro de um departamento que estejam afetando todo o ciclo de receita. Por que isso importa Ele ajuda a identificar gargalos entre departamentos e analisar a performance por área funcional, revelando oportunidades para melhorar a colaboração entre equipes. Onde obter Essas informações podem fazer parte dos dados da transação ou ser derivadas dos dados mestres associados ao usuário responsável. Exemplos Departamento de faturamentoServiços de codificaçãoGestão de negativasCobrança | |||
| Nome da operadora PayerName | O nome da seguradora, entidade governamental ou outra operadora responsável pelo pagamento. | ||
| Descrição O nome da operadora identifica a entidade principal à qual um sinistro é enviado para reembolso. As operadoras podem incluir seguradoras comerciais, como Aetna ou UnitedHealthcare, programas governamentais, como Medicare ou Medicaid, ou outras entidades. Cada operadora tem seu próprio conjunto de regras, requisitos de envio e comportamentos de pagamento. Esse atributo é fundamental para analisar a performance do ciclo de receita. Ao segmentar o processo por operadora, as organizações conseguem identificar quais operadoras têm as maiores taxas de negativa, os ciclos de pagamento mais longos ou a maior frequência de solicitações de informações adicionais. Essa análise permite intervenções direcionadas, como renegociar contratos, adaptar os processos de envio para operadoras específicas e concentrar os esforços de gerenciamento de negativas onde eles são mais necessários. Por que isso importa Ele permite segmentar métricas de performance, como taxas de negativa e tempos de pagamento, por operadora, o que é fundamental para melhorias direcionadas e negociações contratuais. Onde obter Essas informações geralmente são encontradas nos dados de cadastro do paciente, do seguro ou dos sinistros associados ao evento de faturamento. Exemplos AetnaCignaMedicareUnitedHealthcare | |||
| Usuário responsável ResponsibleUser | O identificador do usuário, funcionário ou agente automatizado que realizou a atividade. | ||
| Descrição O atributo Usuário responsável conecta uma etapa do processo à pessoa ou ao sistema que a executou. Pode ser um codificador concluindo a codificação médica, um especialista em faturamento enviando um sinistro ou um bot automatizado lançando um pagamento. Acompanhar o usuário adiciona uma perspectiva humana ou centrada no sistema à análise do processo. Analisar a performance do processo por usuário ou equipe pode revelar oportunidades de treinamento, identificar profissionais de alto desempenho e garantir uma distribuição adequada da carga de trabalho. Esse atributo também é fundamental para fins de conformidade e auditoria, permitindo atribuir claramente a responsabilidade por cada ação realizada. Ele possibilita uma análise detalhada da performance e da utilização dos recursos. Por que isso importa Ele permite analisar a performance da equipe e dos indivíduos, a distribuição da carga de trabalho e as taxas de automação, fornecendo insights sobre a eficiência dos recursos e identificando necessidades de treinamento. Onde obter Geralmente encontrado em logs de transações ou trilhas de auditoria nos campos 'ID do usuário', 'ID do funcionário' ou 'Processador'. Exemplos john.doejane.smithAUTO-POSTER-BOTU123456 | |||
| Valor do ajuste AdjustmentAmount | O valor monetário de quaisquer ajustes, baixas ou abatimentos contratuais feitos no saldo da conta. | ||
| Descrição O valor do ajuste representa a parte do valor faturado que não se espera receber da operadora ou do paciente por motivos como acordos contratuais, descontos ou baixas. Esses ajustes reduzem as contas a receber totais e são uma parte normal do ciclo de receita. Analisar os valores dos ajustes e seus respectivos motivos é fundamental para entender a integridade da receita. Níveis altos ou inesperados de ajustes podem indicar problemas na captura de cobranças, na codificação ou na gestão de contratos. O Process Mining pode ajudar a identificar quais variantes do processo ou atividades específicas levam a taxas de ajuste mais altas, permitindo uma análise direcionada das causas-raiz para maximizar a realização da receita. Por que isso importa Ele ajuda a analisar vazamentos de receita acompanhando baixas e abatimentos contratuais, destacando possíveis problemas nos processos de contratação ou faturamento. Onde obter Esse valor geralmente é registrado em tabelas de ajustes financeiros ou em módulos de lançamento de pagamentos. Exemplos 29.50500.75100.001500.00 | |||
| Valor faturado BilledAmount | O valor monetário bruto do serviço ou produto faturado, antes de quaisquer ajustes ou pagamentos. | ||
| Descrição O valor faturado representa a cobrança total pelos serviços prestados, conforme enviada em um sinistro ou fatura. É o valor financeiro inicial do evento de faturamento e serve como base para medir todas as transações financeiras posteriores, como pagamentos e ajustes. No Process Mining, analisar o valor faturado é fundamental para entender o impacto financeiro das ineficiências do processo. Ele pode ser usado para segmentar casos de alto e baixo valor, revelando se determinados problemas do processo afetam de forma desproporcional os sinistros de maior receita. Correlacionar esse valor com métricas como tempo de ciclo ou taxa de negativa ajuda a priorizar esforços de melhoria nos problemas com maiores consequências financeiras. Por que isso importa Ele estabelece o valor financeiro inicial de um caso, permitindo analisar o impacto financeiro de ineficiências do processo, como atrasos e negativas. Onde obter Este é um atributo financeiro essencial encontrado em tabelas de captura de cobranças, faturamento ou transações de sinistros. Exemplos 150.002500.75500.0010000.00 | |||
| ID da solicitação ClaimId | O identificador exclusivo atribuído a uma solicitação de reembolso enviada a uma operadora. | ||
| Descrição O ID da solicitação é um identificador específico da cobrança enviada a uma seguradora. Um único evento de faturamento pode resultar em várias solicitações se precisar ser faturado para operadoras primária, secundária e terciária, ou se uma solicitação for corrigida e reenviada. Acompanhar o ID da solicitação é importante para entender os detalhes do processo de interação com a operadora. Isso permite analisar loops de retrabalho envolvendo o reenvio de solicitações e acompanhar o status de uma cobrança específica enviada à operadora. Analisar o processo pelo ID da solicitação oferece uma visão mais granular do ciclo de vida de envio e resolução da solicitação do que analisar apenas o evento de faturamento. Por que isso importa Ele permite acompanhar detalhadamente o envio e o reenvio de solicitações, oferecendo uma análise granular das interações com as operadoras e dos loops de retrabalho. Onde obter Esse identificador é gerado pelo sistema de faturamento quando a solicitação é criada e armazenado nas tabelas de gerenciamento de solicitações. Exemplos CLM-2024-555-1239876543210-01TCN-A1B2C3D4E5 | |||
| ID do paciente PatientId | O identificador exclusivo do paciente que recebeu os serviços. | ||
| Descrição O ID do paciente é uma chave exclusiva atribuída a cada paciente no índice mestre de pacientes do sistema de saúde. Esse identificador conecta todos os atendimentos clínicos e financeiros do paciente ao longo do tempo. Enquanto o ID do evento de faturamento representa o caso de um único serviço, o ID do paciente permite uma análise mais ampla de vários atendimentos do mesmo paciente. Isso pode revelar problemas recorrentes, como erros repetidos de cadastro ou padrões de utilização de serviços. Também pode ser usado para analisar a jornada financeira completa de um paciente, o que é valioso para entender a responsabilidade financeira e a fidelidade do paciente. Por que isso importa Ele permite analisar vários eventos de faturamento do mesmo paciente, ajudando a identificar problemas recorrentes e entender a jornada financeira geral do paciente. Onde obter Este é um identificador primário encontrado em praticamente todos os sistemas clínicos e financeiros, originado no sistema de cadastro do paciente ou no sistema de prontuário eletrônico (EHR). Exemplos MRN-100345PAT-987654321202400567 | |||
| Motivo do ajuste AdjustmentReason | O motivo de um ajuste financeiro, como um abatimento contratual ou uma baixa por perda de crédito. | ||
| Descrição Assim como o motivo da negativa, o motivo do ajuste explica por que uma parte do valor faturado foi baixada ou ajustada. Esses motivos esclarecem se o ajuste ocorreu devido a uma obrigação contratual com uma operadora, a uma política de atendimento beneficente, a uma baixa de pequeno saldo ou à correção de um erro de faturamento. Analisar os motivos dos ajustes fornece insights sobre a integridade da receita e a performance financeira. Isso ajuda a diferenciar ajustes contratuais esperados de baixas evitáveis causadas por erros internos. Ao filtrar o mapa do processo por motivos específicos de ajuste, os analistas conseguem identificar fragilidades que levam a perdas de receita evitáveis e direcionar os esforços de melhoria. Por que isso importa Ele fornece contexto para os ajustes financeiros, ajudando a diferenciar obrigações contratuais de perdas de receita evitáveis causadas por erros do processo. Onde obter Encontrado em tabelas de transações financeiras do sistema de faturamento ou de contabilidade de pacientes, geralmente vinculado a transações de ajuste ou baixa. Exemplos Abatimento contratualBaixa de saldo pequenoDívida incobrávelCorreção de erro de faturamento | |||
| Saldo em aberto OutstandingBalance | O saldo restante não pago do evento de faturamento em determinado momento. | ||
| Descrição O saldo em aberto representa o valor que ainda precisa ser recebido em um evento de faturamento. Normalmente, ele é calculado como o valor faturado menos os valores pagos e os valores dos ajustes. Esse valor muda ao longo do ciclo de vida do caso à medida que pagamentos e ajustes são lançados. Esse atributo é um indicador importante da saúde das contas a receber. No Process Mining, analisar o saldo em aberto em diferentes etapas do processo ajuda a gerenciar o aging de contas a receber e a priorizar os esforços de cobrança. Ele pode ser usado para identificar quais tipos de casos ou caminhos do processo tendem a apresentar saldos residuais altos, sinalizando problemas no pagamento ou na resolução de negativas. Por que isso importa É uma medida importante das contas a receber e da eficácia da cobrança, ajudando a priorizar atividades de acompanhamento e analisar o aging de contas a receber. Onde obter Geralmente calculado a partir dos valores faturados, pagos e ajustados. Também pode ser armazenado como um campo em um sistema de contas a receber ou de contabilidade de pacientes. Exemplos 50.000.00125.308500.00 | |||
| Status da conta AccountStatus | O estado atual da conta de faturamento no ciclo de receita, como “faturada”, “paga” ou “em cobrança”. | ||
| Descrição O status da conta oferece uma visão instantânea da etapa em que um evento de faturamento se encontra no ciclo de vida a qualquer momento. Esse status reflete o resultado da atividade mais recente, indicando se a conta está aberta e aguardando pagamento, encerrada, enviada para cobrança ou em outro estado. Enquanto o Process Mining reconstrói o fluxo das atividades, o atributo de status da conta é útil para filtrar e segmentar casos com base na condição atual. Ele é especialmente útil em Dashboards de monitoramento operacional que precisam mostrar o volume e o valor das contas em diferentes etapas, como o total de contas a receber aguardando a resposta da operadora ou o número de contas enviadas recentemente para uma agência de cobrança. Por que isso importa Ele oferece uma visão do estado atual dos casos, útil para Dashboards operacionais e para segmentar a análise com base na etapa do ciclo de vida das contas. Onde obter Normalmente, esse é um campo de status no registro principal da conta do paciente ou do evento de faturamento no sistema de contabilidade de pacientes. Exemplos Faturado - Aguardando o pagadorPago integralmenteNegadoEnviado para cobrançaEncerrado - Baixado | |||
| Valor pago PaidAmount | O valor monetário total recebido das operadoras e do paciente pelos serviços faturados. | ||
| Descrição O valor pago é a soma acumulada de todos os pagamentos lançados contra um evento de faturamento específico. Isso inclui pagamentos de operadoras de seguro primárias e secundárias, além de pagamentos feitos pelo paciente. Ele representa o dinheiro efetivamente recebido pelos serviços prestados. Analisar o valor pago é essencial para medir o sucesso financeiro e a eficiência do ciclo de receita. Comparar o valor pago com o valor faturado fornece insights sobre a receita líquida e as taxas de cobrança. No Process Mining, esse atributo ajuda a quantificar o resultado financeiro de diferentes caminhos do processo e pode ser usado para identificar as características dos sinistros pagos integralmente e no prazo em comparação com os demais. Por que isso importa Ele mede o dinheiro efetivamente recebido em um caso, o que é fundamental para avaliar a eficácia da cobrança e a performance financeira geral do processo. Onde obter Essas informações estão localizadas nas tabelas de transações de lançamento de pagamentos ou aplicação de caixa. Exemplos 120.502000.000.00450.25 | |||
Atividades da gestão do ciclo de receita
| Atividade | Descrição | ||
|---|---|---|---|
| Evento de faturamento encerrado | O evento de faturamento foi totalmente resolvido, seu saldo em aberto chegou a zero e nenhuma atividade adicional é esperada. Isso pode ocorrer por meio de pagamentos, ajustes, baixas ou uma combinação desses eventos. | ||
| Por que isso importa Esta atividade marca o fim do processo, permitindo calcular o tempo total do ciclo de ponta a ponta. Ela confirma o resultado final do evento de faturamento, seja uma cobrança bem-sucedida ou uma baixa. Onde obter Esse status geralmente é inferido quando o saldo da conta chega a zero. Alguns sistemas podem ter um status explícito de 'Encerrado' ou um campo de data de encerramento no registro da conta. Captura Infira este evento identificando o registro de data e hora da última transação financeira que resultou em saldo zero para o evento de faturamento. Tipo de evento inferred | |||
| Pagamento lançado | Um pagamento recebido é aplicado oficialmente à conta do paciente e alocado a linhas de serviço específicas. Essa ação transfere o saldo de contas a receber para caixa e reduz o saldo em aberto. | ||
| Por que isso importa Este é um marco importante de sucesso, confirmando que a receita foi recebida da operadora. Atrasos no lançamento de pagamentos podem distorcer a precisão do aging de contas a receber e dos relatórios de fluxo de caixa. Onde obter Esta é uma transação financeira explícita registrada no livro-razão do sistema de contabilidade de pacientes. Cada aplicação de pagamento deve ter sua própria data e hora de transação. Captura Use o registro de data e hora da transação na aplicação do pagamento ou no diário de lançamento de caixa. Tipo de evento explicit | |||
| Serviço prestado | Esta atividade marca o início do Billing Event, representando o momento em que um serviço clínico é prestado ao paciente. Esse é o gatilho que inicia todo o processo de ciclo de receita de um atendimento específico. | ||
| Por que isso importa Este é o principal ponto de início do processo de ponta a ponta, permitindo medir o tempo total do ciclo de receita. Ele ajuda a identificar os intervalos entre a prestação do serviço clínico e o início das atividades de faturamento. Onde obter Essas informações normalmente vêm de um sistema clínico, de agendamento ou de prontuário eletrônico. Muitas vezes, são registradas a partir de uma anotação clínica assinada, de um registro de procedimento concluído ou do registro de alta do paciente. Captura Registre o timestamp associado à finalização do atendimento clínico, à data do serviço ou à data de alta. Tipo de evento explicit | |||
| Sinistro negado | Representa a rejeição de um sinistro ou de itens de linha específicos pela operadora, impedindo o pagamento. Normalmente, isso é identificado quando o prestador recebe e processa um documento de remessa da operadora. | ||
| Por que isso importa Identificar negativas de sinistros é fundamental para analisar vazamentos de receita, taxas de negativa e a eficácia do processo de gerenciamento de negativas. Esse evento é o principal gatilho para ciclos de retrabalho e recursos. Onde obter Este evento geralmente é encontrado nos dados da remessa, especificamente pela identificação dos códigos de motivo de ajuste do sinistro (CARCs) que indicam uma negativa. Captura Infira este evento analisando os dados da remessa em busca de códigos de negativa associados a um sinistro ou a uma linha de serviço. Tipo de evento inferred | |||
| Solicitação enviada | Esta atividade marca o envio eletrônico ou em papel da solicitação gerada à seguradora ou ao pagador para avaliação. Ela representa o pedido oficial de pagamento pelos serviços prestados. | ||
| Por que isso importa Acompanhar esta atividade é essencial para medir o tempo do ciclo entre o serviço e a fatura e identificar atrasos entre a criação e o envio da solicitação. Esse é um marco importante, pois indica quando o Billing Event entra oficialmente nas contas a receber. Onde obter Este evento normalmente é registrado nos logs de transações de sinistros ou nas tabelas de interface da clearinghouse, geralmente com uma atualização de status específica indicando a transmissão bem-sucedida. Captura Capture o registro de data e hora em que o status do sinistro muda para 'Enviado', 'Transmitido' ou um estado equivalente. Tipo de evento explicit | |||
| Cobrança iniciada | A conta do paciente ficou inadimplente e os esforços proativos de cobrança foram iniciados. Isso pode variar de cartas de lembrete automatizadas até o encaminhamento para um especialista interno ou externo em cobrança. | ||
| Por que isso importa Este evento marca uma intensificação dos esforços para cobrar contas a receber vencidas. Monitorar essa atividade ajuda a avaliar a eficácia das estratégias de cobrança e a performance das agências de cobrança. Onde obter Este evento geralmente é capturado por uma mudança na classe financeira ou no código de status da conta, ou pela atribuição a uma fila de trabalho ou agência de cobrança específica. Captura Infira este evento a partir do primeiro registro de data e hora em que o status da conta muda para 'Cobrança', 'Inadimplente' ou um estado semelhante. Tipo de evento inferred | |||
| Cobranças capturadas | Representa o registro formal de todos os serviços, procedimentos e materiais faturáveis de um atendimento. Isso transforma as atividades clínicas em transações financeiras que podem ser faturadas. | ||
| Por que isso importa Analisar o intervalo entre a prestação do serviço e a captura da cobrança destaca possíveis atrasos no reconhecimento da receita. Essa etapa é essencial para garantir que todos os serviços faturáveis sejam contabilizados e evitar perdas de receita. Onde obter Esses dados estão nas tabelas de transações de cobrança ou nos registros financeiros do sistema de faturamento ou de contas de pacientes. Cada item faturável deve ter um timestamp de criação correspondente. Captura Use a data de criação dos registros de transação de cobrança vinculados ao Billing Event. Tipo de evento explicit | |||
| Codificação concluída | Indica que os codificadores médicos atribuíram códigos clínicos padronizados, como códigos ICD ou CPT, às cobranças capturadas. Essa etapa garante que os serviços sejam representados de uma forma que os pagadores possam entender e avaliar. | ||
| Por que isso importa Essa atividade é essencial para a precisão das solicitações e costuma ser uma fonte comum de gargalos. Medir a duração da etapa de codificação ajuda a identificar oportunidades para melhorar a produtividade dos codificadores e reduzir retenções de solicitações. Onde obter Isso geralmente é registrado como uma mudança de status no Billing Event ou como um timestamp no momento em que uma tarefa relacionada à codificação é marcada como concluída em uma fila de trabalho. Captura Identifique o timestamp em que o status de codificação do atendimento é definido como 'Complete' ou quando o código final é aprovado. Tipo de evento explicit | |||
| Conta ajustada | Uma transação sem pagamento que altera o saldo da conta, como um ajuste contratual, uma baixa de pequeno saldo ou um desconto de cortesia. Esses ajustes são necessários para reconciliar a conta com base nos contratos das operadoras ou nas políticas internas. | ||
| Por que isso importa Os ajustes são um dos principais fatores da variação da receita. Analisar as atividades e os motivos dos ajustes ajuda a entender a rentabilidade, a performance dos contratos com as operadoras e a integridade da receita. Onde obter Esses ajustes são registrados como transações financeiras distintas no livro-razão do paciente, cada uma com um código ou tipo de transação específico indicando o motivo do ajuste. Captura Capture a data da transação de qualquer transação financeira sem pagamento e sem cobrança que modifique o saldo da conta. Tipo de evento explicit | |||
| Conta baixada como perda | Todos os esforços de cobrança foram esgotados e o saldo restante da conta foi considerado incobrável. O saldo é ajustado para zero e classificado como perda de crédito, representando uma perda final de receita. | ||
| Por que isso importa Esta atividade é um evento financeiro crítico que representa receita perdida. Analisar as baixas é essencial para entender a taxa final de sucesso da cobrança e as fontes de dívidas irrecuperáveis. Onde obter Esta é uma transação financeira explícita, normalmente um ajuste com um código de motivo específico, como 'Baixa por perda de crédito' ou 'Enviado para agência de cobrança'. Captura Capture a data da transação do ajuste que classifica o saldo restante como perda de crédito. Tipo de evento explicit | |||
| Extrato do paciente enviado | Depois que todos os pagamentos e ajustes do seguro são lançados, um extrato de cobrança é gerado e enviado ao paciente para sua parte da conta. Isso transfere o foco da cobrança da operadora institucional para o indivíduo. | ||
| Por que isso importa Esta atividade inicia a parte de pagamento direto pelo paciente do ciclo de receita. Acompanhar esse evento ajuda a analisar a eficácia da cobrança aos pacientes e a medir o tempo até o faturamento do paciente. Onde obter Este é um evento explícito registrado pelo módulo de faturamento ou de comunicações com o paciente. O sistema deve registrar a data em que cada extrato foi gerado ou enviado. Captura Use a data de criação ou envio do histórico de extratos do paciente. Tipo de evento explicit | |||
| Remessa recebida | O sistema recebe uma resposta da operadora sobre o sinistro enviado, geralmente em um arquivo Electronic Remittance Advice (ERA). Essa resposta detalha o que foi pago, negado ou ajustado para cada linha de serviço. | ||
| Por que isso importa Este é o evento decisivo que determina o caminho seguinte do processo, seja o lançamento do pagamento, o gerenciamento de negativas ou a realização de ajustes. O tempo até o recebimento da remessa mede a performance da operadora. Onde obter Este evento é capturado quando o sistema ingere um arquivo de intercâmbio eletrônico de dados (EDI), como um arquivo 835, ou quando um usuário insere manualmente os dados de uma Explanation of Benefits (EOB) em papel. Captura Use o registro de data e hora do processamento ou da importação do arquivo de remessa associado ao sinistro. Tipo de evento explicit | |||
| Retrabalho da negativa iniciado | Um usuário ou Workflow automatizado iniciou o processo de análise e resolução de um sinistro negado. Esta atividade marca o início do processo interno para contestar a negativa e recuperar a receita potencial. | ||
| Por que isso importa Esta atividade inicia o ciclo de retrabalho da negativa. Analisar o tempo entre a negativa e o início do retrabalho ajuda a medir a capacidade de resposta da equipe de gerenciamento de negativas e a identificar acúmulos. Onde obter Este evento pode ser capturado a partir das ações do usuário em um módulo de gerenciamento de negativas, de uma mudança de status do sinistro ou da atribuição do sinistro negado à fila de trabalho de um usuário. Captura Capture o registro de data e hora em que um sinistro negado é aberto ou atribuído pela primeira vez, ou quando seu status muda para 'Em retrabalho'. Tipo de evento explicit | |||
| Sinistro reenviado | Após uma negativa ou rejeição, o sinistro foi corrigido e reenviado à operadora para reconsideração. Isso representa uma segunda tentativa de obter o pagamento e encerra o ciclo inicial de retrabalho. | ||
| Por que isso importa Esta atividade é fundamental para entender a eficiência do processo de resolução de negativas. Acompanhar os reenvios ajuda a medir os tempos dos ciclos de retrabalho e a taxa de sucesso dos recursos. Onde obter Este evento é registrado como um novo envio de sinistro vinculado ao sinistro negado original. Procure registros de envio com um indicador de correção ou reenvio. Captura Identifique uma transação de envio de sinistro que faça referência a um ID de sinistro enviado anteriormente ou que tenha um indicador de reenvio. Tipo de evento explicit | |||
| Solicitação criada | Uma solicitação formal de faturamento foi gerada pelo sistema, reunindo todas as cobranças, códigos e informações demográficas em um formato padronizado. Essa é uma etapa preparatória antes do envio da solicitação ao pagador. | ||
| Por que isso importa Isso representa o momento em que uma fatura faturável está pronta. Analisar o tempo entre esse ponto e o envio ajuda a identificar atrasos do sistema ou de processamento em lote que tornam o faturamento mais lento. Onde obter Este é um evento gerado pelo sistema que deve ser registrado em uma tabela ou arquivo de solicitações, com um timestamp de criação claro para o cabeçalho da solicitação. Captura Use o timestamp de criação do registro principal da solicitação associado ao Billing Event. Tipo de evento explicit | |||
Guias de extração
Os métodos de extração variam conforme o sistema. Para obter instruções detalhadas,
Pronto para começar?
Escolha abaixo um dos nossos guias de extração específicos do sistema para ver instruções detalhadas sobre como exportar seus dados ou use este Template genérico como ponto de partida para qualquer outro sistema.
Transforme agora seu gerenciamento do ciclo de receita
Tenha insights, reduza negativas e acelere o fluxo de caixa em todos os sistemas.
Não é necessário cartão de crédito • Comece em poucos minutos