Seu Template de Data para Gestão do Ciclo de Receita

Optum360
Seu Template de Data para Gestão do Ciclo de Receita

Seu Template de Data para Gestão do Ciclo de Receita

Este template oferece um roteiro claro para coletar o data necessário para analisar seu processo de Gestão do Ciclo de Receita. Ele descreve atributos essenciais, atividades-chave para monitorar e orientações práticas para extrair essas informações. Ao seguir este modelo, você garante que seu data esteja pronto para um Process Mining eficiente.
  • Atributos recomendados para coletar
  • Atividades-chave a monitorizar
  • Orientação para Extração
É novo em event logs? Saiba como criar um event log para Process Mining.

Atributos de Gestão do Ciclo de Receita

Estes são os campos de data recomendados para incluir no seu event log para uma análise completa da gestão do ciclo de receita.
3 Obrigatório 6 Recomendado 11 Opcional
Nome Descrição
Evento de Faturamento
BillingEvent
O identificador exclusivo para a entrega de um serviço ou produto que gera uma cobrança, servindo como o case ID principal.
Descrição

O Billing Event serve como o case identifier principal, vinculando todas as atividades relacionadas a um serviço prestado ou produto entregue que gera uma cobrança. Isso permite o rastreio completo do ciclo de geração e coleta de receita para cada item faturável.

No Process Mining, analisar o processo por Billing Event permite que as empresas vejam toda a jornada ponta a ponta, da entrega do serviço ao pagamento final ou fechamento da conta. Esta visão é crucial para identificar gargalos, medir tempos de ciclo e entender variações no tratamento de diferentes guias ou faturas.

Por que é importante

Este é o Case ID essencial que conecta todas as atividades do ciclo de receita, permitindo uma visão completa do processo ponta a ponta.

Onde obter

Esta é a chave primária que vincula registros nas tabelas de faturamento e guias do Optum360. Consulte a documentação para os nomes específicos de tabelas e campos.

Exemplos
BE-2023-0012345BE-2023-0012346BE-2023-0012347
Nome da Atividade
ActivityName
O nome de um event ou tarefa específica que ocorreu no processo de Gestão do Ciclo de Receita.
Descrição

O Nome da Atividade descreve uma etapa no processo do ciclo de receita, como 'Fatura Enviada à Operadora' ou 'Pagamento Recebido'. Este atributo é fundamental para o Process Mining, pois define os pontos no mapa do processo.

Ao analisar a sequência e frequência das atividades, as organizações conseguem visualizar o fluxo real do processo, identificar desvios do procedimento padrão e apontar loops de retrabalho comuns. Essa análise é a chave para entender ineficiências e problemas de conformidade.

Por que é importante

Este atributo define as etapas individuais do processo, formando a base do mapa do processo e permitindo todas as análises baseadas em fluxo.

Onde obter

Geralmente é derivado de event logs, registros de mudança de status ou códigos de transação específicos nas tabelas operacionais do Optum360.

Exemplos
Sinistro CriadoFatura Enviada à OperadoraPagamento RecebidoGlosa RecebidaConta Fechada
Tempo do Evento
EventTime
O timestamp que indica quando uma atividade ou evento específico ocorreu.
Descrição

O Hora do Evento é o carimbo de data/hora associado a cada atividade, marcando a data e hora precisas de sua ocorrência. Esses dados temporais são essenciais para construir a sequência cronológica de eventos de cada caso.

Na análise, o Hora do Evento é usado para calcular tempos de ciclo entre atividades, medir a duração do caso e identificar gargalos onde se gasta muito tempo esperando. É a base de qualquer análise de processo baseada em tempo e medição de desempenho.

Por que é importante

Este timestamp é crítico para sequenciar os eventos corretamente e calcular todas as métricas baseadas em duração, como tempos de ciclo e gargalos.

Onde obter

Esta informação é geralmente armazenada junto com cada transação ou registro de mudança de status nas tabelas do Optum360.

Exemplos
2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:22:00Z
Código do Motivo da Glosa
DenialReasonCode
Um código padronizado da operadora explicando por que uma conta foi glosada.
Descrição

Quando uma operadora glosa uma guia, ela fornece um Código de Motivo de Glosa (como 'Serviço Não Coberto' ou 'Guia Duplicada'). Esses códigos são fundamentais para entender a causa raiz de atrasos na receita e retrabalho.

Analisar esses códigos permite que a equipe de gestão de glosas priorize o trabalho, identifique tendências e tome ações corretivas. Por exemplo, uma alta frequência de glosas por 'Informação Ausente' pode indicar um problema na criação da guia. Esta análise é central para reduzir a taxa de glosa e acelerar o fluxo de caixa.

Por que é importante

Fornece a causa raiz das glosas, permitindo intervenções direcionadas para evitar glosas futuras e reduzir retrabalhos dispendiosos.

Onde obter

Este código está incluído nos arquivos de Aviso de Recebimento Eletrônico (ERA) recebidos das operadoras e é armazenado no módulo de gestão de guias do Optum360.

Exemplos
CO-16: Falta informação na fatura/serviçoPR-97: O benefício para este serviço está incluído no pagamento/abono de outro serviço/procedimentoOA-18: Fatura/serviço duplicado
Departamento de Faturamento
BillingDepartment
O departamento ou equipe interna que gerenciou ou executou a atividade de faturamento.
Descrição

O atributo Departamento de Faturamento identifica a equipe ou área funcional específica dentro das operações do ciclo de receita responsável por uma atividade. Por exemplo, equipes diferentes podem lidar com codificação, envio de guias e gestão de glosas.

Este atributo é essencial para benchmarking de performance, conforme solicitado pelo dashboard 'Benchmarks de Performance do Depto. de Faturamento'. Ele permite que a liderança compare a eficiência, velocidade e precisão das equipes, identifique as melhores práticas e aloque recursos para corrigir lacunas de desempenho.

Por que é importante

Permite comparar o desempenho entre diferentes equipes de faturamento, ajudando a identificar grupos de alta performance e áreas que precisam de melhoria.

Onde obter

Pode ser derivado do usuário que executa a tarefa ou de um campo na conta que indica a responsabilidade. Consulte a documentação do Optum360.

Exemplos
Central de FaturamentoEquipe de Gestão de GlosasDepartamento de CodificaçãoServiços Financeiros ao Paciente
ID do paciente
PatientId
O identificador exclusivo do paciente que recebeu os serviços.
Descrição

O ID do Paciente é um identificador exclusivo atribuído a cada paciente no sistema de saúde. Ele vincula vários billing events a um único paciente, permitindo uma análise centrada no paciente.

Ao usar o ID do Paciente, analistas podem investigar padrões relacionados a casos específicos, como reinternações frequentes ou histórico de glosas. Também permite segmentar o processo com base na demografia ou histórico, revelando insights importantes para melhorar a experiência financeira do paciente.

Por que é importante

Permite uma análise centrada no paciente, ajudando a entender a jornada financeira de ponta a ponta e a identificar padrões para populações específicas de pacientes.

Onde obter

Este identificador é um campo central nos dados mestres de pacientes e tabelas de transação no Optum360. Consulte a documentação do Optum360 para detalhes.

Exemplos
PAT-98765PAT-98766PAT-98767
ID do Pagador
PayerId
O identificador exclusivo da seguradora ou operadora responsável pela guia.
Descrição

O ID da Operadora identifica a seguradora específica, plano de saúde ou entidade responsável pelo pagamento da guia. Cada pagador geralmente tem seu próprio conjunto de regras, exigências de envio e comportamentos de pagamento.

Analisar o processo pelo ID da Operadora é crítico para a gestão de receita (RCM). Isso ajuda a identificar quais operadoras têm os ciclos mais longos, as maiores taxas de glosa ou processos de recurso mais complexos. Esse insight permite que os departamentos de faturamento adaptem suas estratégias para melhorar a velocidade de recebimento.

Por que é importante

Segmentar o processo por operadora é essencial para identificar quais delas causam atrasos ou glosas, permitindo melhorias direcionadas na gestão de convênios.

Onde obter

Esta informação é armazenada em cada registro de guia no Optum360. Consulte a documentação do sistema para nomes de tabelas e campos de operadoras.

Exemplos
PAYER-AETNAPAYER-BCBS-MAPAYER-MEDICAREPAYER-UHC
Valor Ajustado
AdjustedAmount
O valor monetário de baixas, ajustes contratuais ou correções feitas no valor faturado.
Descrição

O Valor Ajustado representa a parte da cobrança que não deve ser recebida devido a acordos com operadoras, correções de faturamento ou outras baixas. Isso é uma redução direta da receita.

Este atributo é fundamental para o dashboard de 'Impacto de Ajuste de Receita' e para o KPI de 'Taxa de Ajuste de Receita'. Analisar esses ajustes ajuda a identificar o impacto financeiro dos contratos com operadoras e a encontrar oportunidades para reduzir a perda de receita com faturamentos mais precisos ou negociações de contrato.

Por que é importante

Mede diretamente a perda de receita e é fundamental para calcular KPIs de desempenho financeiro e entender a rentabilidade.

Onde obter

Esta informação é encontrada nos registros de transação de ajuste no sistema financeiro do Optum360.

Exemplos
30.00250.2510.00
Valor Faturado
BilledAmount
O valor monetário total de todas as cobranças enviadas na guia ou fatura.
Descrição

O Valor Faturado representa a cobrança bruta pelos serviços prestados, antes de quaisquer pagamentos, ajustes ou baixas. É o valor inicial do contas a receber para o evento de faturamento.

Este atributo é fundamental para a análise financeira no Process Mining. Ele é usado para calcular KPIs essenciais, como a Taxa de Ajuste de Receita, e permite segmentar casos por valor para verificar se contas de alto valor são processadas de forma diferente ou sofrem mais atrasos do que as de baixo valor.

Por que é importante

Fornece o contexto financeiro de cada caso, permitindo análises baseadas em valor e o cálculo de KPIs financeiros fundamentais.

Onde obter

Este é um campo padrão em todas as guias ou contas de pacientes nas tabelas financeiras do Optum360.

Exemplos
150.001250.7585.50
Código do Serviço
ServiceCode
O código do procedimento (ex: TUSS, CBHPM) que identifica o serviço específico prestado.
Descrição

O Código do Serviço é um código médico padronizado que identifica precisamente o procedimento ou serviço prestado. Esses códigos são obrigatórios para o faturamento e determinam o reembolso.

Analisar o processo por Código do Serviço pode revelar que certos procedimentos são mais propensos a glosas, exigem mais documentação ou têm ciclos de pagamento mais longos. Isso permite entender os desafios do processo de forma granular e orientar políticas de faturamento para serviços específicos.

Por que é importante

Permite análises baseadas no tipo de serviço médico, o que pode revelar padrões de glosas ou atrasos nos pagamentos específicos de certos procedimentos.

Onde obter

Este código é uma parte fundamental dos registros de entrada de cobrança e detalhes de guias no Optum360.

Exemplos
992137104527447
Duração do Caso
CaseDuration
O tempo total de ciclo de um billing event, da primeira à última atividade.
Descrição

A Duração do Caso mede o tempo total decorrido desde o primeiro evento até o último para um único Evento de Faturamento. É um KPI de alto nível essencial para avaliar a eficiência geral do processo.

Essa métrica alimenta o dashboard 'Visão Geral do Ciclo de Ponta a Ponta do RCM' e o KPI 'Tempo Médio de Ciclo do RCM'. O acompanhamento ao longo do tempo permite que a liderança visualize o impacto das iniciativas de melhoria em todo o ciclo de receita.

Por que é importante

Representa o tempo de ciclo de ponta a ponta do processo, um KPI crítico para medir a velocidade e eficiência geral.

Onde obter

Isso é calculado subtraindo o timestamp do primeiro event do timestamp do último event para cada case ID único de 'BillingEvent'.

Exemplos
30 dias95 dias45 dias
É Retrabalho
IsRework
Um sinalizador indicando se uma atividade faz parte de um ciclo de retrabalho, como gestão de glosas ou recursos.
Descrição

O É Retrabalho é um sinalizador booleano que identifica atividades consideradas retrabalho sem valor agregado, como 'Início de Retrabalho de Glosa' ou 'Recurso Apresentado'. Essas atividades geralmente ocorrem quando o processo se desvia do seu caminho ideal.

Este atributo ajuda a quantificar o volume de retrabalho no processo, sendo um indicador direto de ineficiência e custo. É usado para calcular o KPI 'Taxa de Retrabalho por Erro de Faturamento' e alimenta o dashboard de 'Identificação de Gargalos e Loops de Retrabalho', facilitando a filtragem e visualização desses fluxos ineficientes.

Por que é importante

Ajuda a quantificar a ineficiência do processo sinalizando atividades que representam retrabalho, facilitando a medição e o combate ao desperdício.

Onde obter

Geralmente é derivado usando lógica de negócios na ferramenta de Process Mining. Por exemplo, qualquer atividade após um event de 'Glosa Recebida' pode ser marcada como retrabalho.

Exemplos
verdadeirofalse
End Time
EndTime
O timestamp que indica quando uma atividade foi concluída.
Descrição

O End Time marca a conclusão de uma atividade. Enquanto o Start Time indica quando um event ocorreu, o End Time é necessário para calcular a duração de atividades que têm um tempo de processamento específico, como o início e o fim de um 'Retrabalho de Glosa'.

Na análise de processos, comparar o Start Time e o End Time permite calcular o tempo de execução. Isso ajuda a distinguir o tempo de trabalho ativo (tempo de processamento) do tempo de inatividade (tempo de espera entre atividades), oferecendo uma visão detalhada da eficiência do processo.

Por que é importante

Permite o cálculo preciso dos tempos de processamento das atividades, ajudando a diferenciar o tempo de trabalho ativo do tempo de espera ocioso no processo.

Onde obter

Para algumas atividades, este pode ser um campo de carimbo de data/hora separado no sistema de origem. Para outras, pode ser necessário inferi-lo a partir do horário de início da atividade subsequente.

Exemplos
2023-10-26T10:15:00Z2023-10-26T11:45:00Z2023-10-27T15:00:00Z
Prestador de Serviço
ServiceProvider
O médico, departamento ou unidade que prestou o serviço faturável.
Descrição

Este atributo identifica o prestador específico, como médico, terapeuta ou departamento hospitalar, responsável pelo serviço. Diferentes prestadores podem ter padrões de faturamento ou hábitos de documentação distintos que afetam o ciclo de receita.

Analisar por Prestador de Serviço ajuda a identificar problemas de captura de cobrança, precisão de codificação ou qualidade da documentação na origem. Isso destaca oportunidades de treinamento ou melhoria de processos para garantir que faturamentos limpos sejam gerados desde o início.

Por que é importante

Ajuda a rastrear problemas de faturamento até a origem, permitindo feedback direcionado e treinamento para a equipe clínica para melhorar a captura de cobranças e a documentação.

Onde obter

Esta informação é parte fundamental do registro de cobrança ou guia no Optum360, geralmente vinculada aos dados mestres do prestador.

Exemplos
Dr.ª Emily CarterDepto de RadiologiaCirurgia GeralFisioterapia
Sistema de Origem
SourceSystem
O sistema ou aplicativo de origem onde os event data foram registrados.
Descrição

Este atributo identifica o sistema de origem de onde o data de um event específico foi extraído. Em cenários de TI complexos, os data de RCM podem vir da plataforma core Optum360, de um sistema de Prontuário Eletrônico (EHR), de uma clearinghouse ou portal do paciente.

Entender o sistema de origem é útil para validação de data, solução de problemas de integração e análise de variações de processo causadas por comportamentos diferentes do sistema ou práticas de entrada de dados.

Por que é importante

Identifica a origem dos dados, o que é crucial para a governança de dados, avaliação de qualidade e compreensão das variações de processo em diferentes sistemas.

Onde obter

Pode ser um valor estático definido durante a extração de data ou um campo nas tabelas de origem que indica a procedência do data.

Exemplos
Optum360Interface-EHRAPI-da-ClearinghousePortal-do-Paciente
Status da Conta
AccountStatus
O estado atual da conta de faturamento dentro do ciclo de receita.
Descrição

O Status da Conta fornece um resumo de onde um evento de faturamento se encontra no processo geral (por exemplo: 'Pendente Operadora', 'Paga' ou 'Em Cobrança'). Este atributo contextualiza as atividades realizadas.

Isso é útil para filtrar e segmentar casos, focando em partes específicas do processo. Por exemplo, analisar todas as contas 'Em Cobrança' ajuda a entender os gatilhos e o volume dessa etapa dispendiosa, alimentando o dashboard de 'Volume e Causas de Cobrança'.

Por que é importante

Fornece contexto de alto nível sobre o estado atual de um caso, permitindo filtrar e analisar populações específicas, como as que estão em cobrança.

Onde obter

Geralmente é um campo de resumo na conta principal do paciente ou no registro da guia no Optum360.

Exemplos
AbertoPendente OperadoraPago na ÍntegraEm CobrançaEncerrado
Tempo de Processamento
ProcessingTime
O tempo gasto para concluir uma atividade específica, calculado a partir de seus timestamps de início e fim.
Descrição

O Tempo de Processamento mede a duração de uma atividade individual, representando o 'tempo de toque' ou trabalho ativo realizado. Geralmente é calculado como a diferença entre a Hora Final e a Hora Inicial de uma atividade.

Essa métrica é crucial para distinguir entre o tempo gasto trabalhando ativamente em uma tarefa e o tempo gasto esperando a próxima etapa. Na análise de gargalos, entender os tempos de processamento ajuda a determinar se um atraso se deve a uma tarefa demorada ou a uma fila longa, levando a melhorias de processo mais eficazes.

Por que é importante

Mede o tempo de trabalho ativo das atividades, ajudando a distinguir o trabalho que agrega valor do tempo de espera desperdiçado na análise de gargalos.

Onde obter

Isso é calculado subtraindo o 'EventTime' (StartTime) do 'EndTime' para um registro de atividade específico.

Exemplos
15 minutos2 horas1 dia 4 horas
Ú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 registra a data e a hora em que o data foi extraído pela última vez do sistema de origem e carregado na ferramenta de Process Mining. Ele fornece o contexto sobre a atualidade do data analisado.

Isso é importante para que analistas e usuários de negócios saibam se estão vendo informações atualizadas. Ajuda a gerenciar expectativas sobre latência e é um metadado essencial para qualquer projeto de análise.

Por que é importante

Fornece contexto crucial sobre a atualização dos dados, garantindo que os usuários saibam o quão recente é a análise.

Onde obter

Este timestamp é geralmente gerado e armazenado pelo processo de extração, transformação e carga (ETL) de data.

Exemplos
2023-11-01T02:00:00Z2023-11-02T02:00:00Z
Utilizador
User
O identificador do usuário ou agente do sistema que executou a atividade.
Descrição

O atributo Usuário identifica a pessoa, equipe ou bot automatizado responsável por executar uma atividade. Isso permite analisar a performance em nível individual ou de grupo.

Entender qual usuário ou equipe realizou uma ação é valioso para avaliar produtividade, qualidade e adesão aos procedimentos padrão. Ajuda a identificar necessidades de treinamento ou reconhecer talentos de alta performance, além de distinguir tarefas manuais daquelas tratadas por automação.

Por que é importante

Atribui responsabilidades pelas etapas do processo e permite a análise de desempenho por indivíduo ou equipe, o que é fundamental para a gestão de recursos e treinamento.

Onde obter

Os IDs de usuário são geralmente capturados nos logs de auditoria ou histórico de transações dos registros no Optum360.

Exemplos
j.doem.smithAutoBillerBots.jones
Valor Pago
PaidAmount
O valor monetário total recebido da operadora e do paciente pelos serviços faturados.
Descrição

O Valor Pago é a soma acumulada de todos os pagamentos lançados para um billing event específico. Ele representa o dinheiro real coletado e é a principal medida de sucesso do ciclo de receita.

Na análise de processos, acompanhar o valor pago é essencial para entender o fluxo de caixa e o desempenho financeiro geral. Ele pode ser usado para analisar a velocidade de pagamento e comparar valores faturados com valores recebidos, destacando problemas com subpagamentos ou dívidas incobráveis.

Por que é importante

Representa o dinheiro real coletado, que é uma métrica de resultado fundamental para o processo de RCM e essencial para a análise do fluxo de caixa.

Onde obter

Este valor é geralmente armazenado em tabelas de transações de pagamento ou resumido no nível da conta no Optum360.

Exemplos
120.001000.500.00
Obrigatório Recomendado Opcional

Atividades de Gestão do Ciclo de Receita

Estas são as etapas e marcos principais do processo que você precisa capturar no seu Event Log para uma descoberta de processos precisa.
6 Recomendado 9 Opcional
Atividade Descrição
Aviso de Remessa Recebido
O sistema recebeu um arquivo eletrônico de aviso de recebimento (ERA) da operadora, detalhando pagamentos, ajustes e glosas. Este é um event explícito capturado quando o sistema processa um arquivo EDI 835.
Por que é importante

Esta atividade é um marco importante que indica que a operadora processou a guia. O conteúdo deste arquivo dita as ações seguintes, como o lançamento do pagamento ou a gestão de glosas.

Onde obter

Registrado nos logs de transação EDI para arquivos ANSI 835 recebidos. O carimbo de data/hora reflete quando o arquivo foi recebido e processado pelo sistema.

Captura

Timestamp associado ao processamento do arquivo EDI 835 (Aviso de Recebimento Eletrônico).

Tipo de evento explicit
Conta Fechada
O billing event é considerado concluído quando o saldo é zerado e nenhuma outra atividade é esperada. Este event é inferido quando o saldo da conta chega a zero e o status é atualizado para 'Fechado' ou um estado final semelhante.
Por que é importante

Este é o event final principal do processo. Medir o tempo total de ciclo até aqui oferece uma visão abrangente da eficiência geral do RCM.

Onde obter

Inferido a partir de uma combinação do saldo da conta chegando a zero e o campo de status da conta sendo definido como 'Fechada', 'Paga' ou um status final equivalente.

Captura

O timestamp mais recente, seja do lançamento do pagamento final que resulta em saldo zero ou de uma mudança de status para 'Fechado'.

Tipo de evento inferred
Dados do Serviço Recebidos
Marca o início do evento de faturamento quando as informações do serviço clínico são recebidas do EHR ou de outro sistema de origem. Este evento é geralmente capturado via um log explícito ou registro de transação criado por uma interface de integração após a ingestão de dados bem-sucedida.
Por que é importante

Este é o event de início principal do ciclo de receita. Analisar o tempo desta atividade até a captura da cobrança é crítico para identificar atrasos de data na entrada que afetam todo o processo.

Onde obter

Registrado em logs de interface ou tabelas de transação que gerenciam dados de serviços de pacientes vindos de sistemas externos (EHR). Procure por carimbos de data/hora de mensagens HL7 ou logs de chamadas de API.

Captura

Capturado de logs de integração ou tabelas de transação com carimbo de data/hora no recebimento dos dados.

Tipo de evento explicit
Fatura Enviada à Operadora
A guia gerada foi enviada eletronicamente para a operadora de saúde para análise. Este event é registrado explicitamente pelo módulo de envio de faturamento ou interface da clearinghouse após a transmissão bem-sucedida.
Por que é importante

Este é um marco crítico que inicia a contagem do tempo de resposta da operadora. Ajuda a medir a eficiência do envio de guias e a identificar atrasos na submissão.

Onde obter

Encontrado em logs de transação de faturas ou tabelas de transação EDI, rastreando especificamente os envios de arquivos 837. Procure por um 'carimbo de data/hora de envio' ou 'data de transmissão'.

Captura

Timestamp do log de transação EDI 837 indicando o envio bem-sucedido.

Tipo de evento explicit
Glosa Recebida
Uma conta foi glosada pela operadora, conforme indicado em um aviso de recebimento. Este evento é inferido analisando os dados do aviso de recebimento em busca de códigos de motivo de glosa específicos associados às linhas da fatura.
Por que é importante

Rastrear glosas é crucial para identificar as causas raiz da perda de receita e ineficiência do processo. Esta atividade é o ponto de partida para toda a gestão de glosas e loops de retrabalho de recursos.

Onde obter

Inferido a partir dos dados do EDI 835 (Electronic Remittance Advice). O sistema identifica códigos de motivo de ajuste de conta (CARCs) que sinalizam uma glosa.

Captura

Inferido pela detecção de códigos de glosa específicos (CARCs/RARCs) nos dados de aviso de recebimento EDI 835 analisados.

Tipo de evento inferred
Pagamento Lançado
Um pagamento recebido foi aplicado com sucesso à conta do paciente e às linhas de serviço específicas. Esta é uma ação explícita (usuário ou automatizada) que concilia o pagamento com as cobranças pendentes.
Por que é importante

Esta atividade é crítica para medir a eficiência do processo de conciliação bancária. Atrasos nos lançamentos podem distorcer os relatórios de contas a receber e atrasar o fechamento das contas.

Onde obter

Encontrado nas tabelas de transação de pagamento. O carimbo de data/hora da transação para a ação de lançamento serve como a hora do evento.

Captura

O timestamp de criação do registro de transação de pagamento aplicado a uma cobrança específica.

Tipo de evento explicit
Atividade de Cobrança Iniciada
A conta do paciente foi movida para um processo de cobrança ativa por falta de pagamento. Isso geralmente é inferido por uma mudança na classe financeira ou status da conta.
Por que é importante

Identifica contas que exigem acompanhamento intensivo. Analisar a frequência e os motivos desta atividade ajuda a melhorar as estratégias de cobrança iniciais.

Onde obter

Inferido a partir de uma mudança de status da conta para 'Cobrança', 'Dívida Incobrável' ou 'Enviado para Agência'. A data dessa mudança de status é o carimbo de data/hora do evento.

Captura

Timestamp de uma mudança no campo de status da conta para um valor relacionado à cobrança.

Tipo de evento inferred
Cobranças Capturadas
Representa o ponto onde serviços e suprimentos faturáveis específicos são formalmente inseridos no sistema. Esta é uma ação explícita de usuário ou sistema que cria registros de transação de cobrança.
Por que é importante

Esta atividade é essencial para medir o atraso na cobrança (charge lag), que é o intervalo entre a prestação do serviço e o início do faturamento. Reduzir esse atraso acelera diretamente o ciclo de receita.

Onde obter

Encontrado em tabelas de transação de encargos, muitas vezes rotuladas como tabelas de entrada de cobrança ou de linha de serviço. O carimbo de data/hora de criação do registro de cobrança serve como a hora do evento.

Captura

O evento é o carimbo de data/hora de criação de um registro na tabela de mestre de encargos ou de transações de cobrança.

Tipo de evento explicit
Codificação Concluída
Indica que os codificadores médicos revisaram a documentação clínica e atribuíram os códigos CPT, HCPCS e CID apropriados. Normalmente é um evento explícito marcado por um usuário ou por um motor de codificação automatizado concluindo a tarefa.
Por que é importante

A codificação é um gargalo frequente que pode atrasar o envio de faturas. Rastrear essa atividade ajuda a medir a produtividade dos codificadores e a identificar atrasos na fila de codificação.

Onde obter

Registrado em um módulo de workflow de codificação ou por uma mudança de status no evento de faturamento de 'Codificação Pendente' para 'Codificado'. É usado o carimbo de data/hora dessa mudança ou da conclusão da tarefa.

Captura

Timestamp de uma atualização de status ou log quando um usuário ou sistema finaliza a codificação do atendimento.

Tipo de evento explicit
Conta Ajustada
Um ajuste contratual, baixa ou outra correção financeira foi lançada na conta. Este é um lançamento financeiro explícito registrado no livro-razão do sistema.
Por que é importante

Os ajustes impactam diretamente a realização da receita. Analisar os motivos e o timing dos ajustes é fundamental para identificar problemas com tabelas de honorários, contratos ou precisão do faturamento.

Onde obter

Localizado na tabela de transações financeiras, identificável por códigos de transação específicos para baixas ou ajustes. A data da transação é a hora do evento.

Captura

A data da transação de um lançamento no livro contábil com um código de ajuste específico.

Tipo de evento explicit
Demonstrativo do Paciente Enviado
Um demonstrativo de faturamento foi gerado e enviado ao paciente referente à sua parte da conta. Este é um evento explícito registrado pelo módulo de faturamento do paciente no momento da criação do demonstrativo.
Por que é importante

Esta atividade inicia a parte de pagamento direto (self-pay) do ciclo de receita. Acompanhar isso ajuda a analisar a eficiência das cobranças aos pacientes.

Onde obter

Registrado em uma tabela de correspondência do paciente ou histórico de geração de demonstrativos. O carimbo de data/hora indica quando o demonstrativo foi criado ou enviado.

Captura

Timestamp de um log de geração de extrato do paciente ou tabela de histórico.

Tipo de evento explicit
Pagamento Recebido
Indica que um pagamento foi recebido de uma operadora ou paciente, frequentemente registrado como parte do aviso de recebimento. Este evento pode ser capturado explicitamente de arquivos eletrônicos de remessa ou logs manuais de recebimento de caixa.
Por que é importante

Atividade fundamental para análise de fluxo de caixa e velocidade de pagamento. Serve como gatilho para o processo de lançamento de pagamentos.

Onde obter

Derivado das informações de pagamento no arquivo EDI 835 ou de arquivos bancários. A data do cheque ou a data de processamento no arquivo é frequentemente utilizada.

Captura

Extraído do segmento BPR de um arquivo EDI 835 ou de um arquivo de dados bancário (lockbox).

Tipo de evento explicit
Recurso Apresentado
Um recurso foi formalmente enviado à operadora para contestar uma glosa. Esta é uma ação explícita registrada por um usuário no módulo de gestão de glosas ou recursos.
Por que é importante

Esta atividade é um passo fundamental no processo de recuperação de receita. Rastrear os envios de recursos e seus tempos de ciclo é vital para entender a eficácia da estratégia de resolução de glosas.

Onde obter

Registrado em um módulo de acompanhamento de recursos ou como um tipo de transação específica contra a conta. Procure por campos de 'data do recurso' ou 'data de reenvio'.

Captura

Carimbo de data/hora explícito registrado quando um usuário registra o envio de um recurso.

Tipo de evento explicit
Retrabalho de Glosa Iniciado
Um usuário ou workflow automatizado iniciou o processo de revisão e resolução de uma conta glosada. Isso pode ser capturado explicitamente por uma ação do usuário ou inferido por uma mudança de status da conta.
Por que é importante

Esta atividade inicia o loop de retrabalho para glosas. Medir o tempo entre o recebimento da glosa e o início do retrabalho ajuda a identificar acúmulos na fila de gestão de glosas.

Onde obter

Encontrado em módulos de gestão de glosas ou filas de trabalho. Pode ser um carimbo de data/hora explícito de quando um usuário 'abre' ou 'assume' uma tarefa de glosa, ou inferido por uma mudança de status como 'Glosado' para 'Em Retrabalho'.

Captura

Inferido a partir de uma mudança de status da conta para 'Retrabalho' ou 'Em Revisão', ou de um log de ação explícita do usuário.

Tipo de evento inferred
Sinistro Criado
Uma conta faturável foi gerada pelo sistema, reunindo todas as cobranças, códigos e informações demográficas em um formato padronizado. Este é um evento explícito gerado pelo sistema com um carimbo de data/hora de criação correspondente.
Por que é importante

Esta atividade marca a transição da captura de cobrança para o processo de faturamento formal. É um pré-requisito para o envio e fundamental para rastrear os tempos internos de processamento.

Onde obter

Localizado na tabela de faturas ou log de transações. O carimbo de data/hora de criação do registro de cabeçalho da fatura sinaliza o evento.

Captura

Capturado a partir do carimbo de data/hora de criação do registro principal na tabela do banco de dados de faturas.

Tipo de evento explicit
Recomendado Opcional

Guias de Extração

Como obter seus dados do Optum360

Os métodos de extração para este processo estão sendo validados atualmente. Por favor, verifique novamente mais tarde ou fale conosco para assistência.