Seu Template de dados para gestão do ciclo de receita

Optum360
Seu Template de dados para gestão do ciclo de receita

Seu Template de dados para gestão do ciclo de receita

Este Template apresenta um roteiro claro para coletar os dados necessários à análise do processo de gestão do ciclo de receita. Ele indica os atributos essenciais, as principais atividades a acompanhar e orientações práticas para extrair essas informações. Com este Template, você prepara os dados para gerar insights com Process Mining.
  • Atributos recomendados para coleta
  • Principais atividades a acompanhar
  • Orientações para extração
Novidade em Event Logs? Saiba como criar um Event Log para Process Mining.

Atributos da gestão do ciclo de receita

Estes são os campos de dados recomendados para incluir no Event Log e realizar uma análise completa da gestão do ciclo de receita.
3 Obrigatório 6 Recomendado 10 Opcional
Nome Descrição
Evento de faturamento
BillingEvent
Identificador único de um serviço prestado ou produto entregue que gera uma cobrança. É o ID do caso principal.
Descrição

O evento de faturamento funciona como identificador principal do caso e conecta todas as atividades relacionadas a um serviço prestado ou produto entregue que gera uma cobrança. Isso permite acompanhar todo o ciclo de geração e recebimento da receita de cada item ou serviço faturável.

Em Process Mining, analisar o processo por evento de faturamento permite que as organizações vejam a jornada completa, da prestação do serviço ao pagamento final ou encerramento da conta. Essa visão é essencial para identificar gargalos, medir tempos de ciclo e entender as diferenças na forma como cada solicitação ou fatura é processada.

Por que isso importa

Este é o ID do caso essencial que conecta todas as atividades relacionadas ao ciclo de receita e permite analisar o processo de ponta a ponta.

Onde encontrar

Esta é a chave primária que conecta os registros nas principais tabelas de faturamento e solicitações do Optum360. Consulte a documentação do Optum360 para saber os nomes específicos das tabelas e dos campos.

Exemplos
BE-2023-0012345BE-2023-0012346BE-2023-0012347
Horário do evento
EventTime
Registro de data e hora que indica quando uma atividade ou evento específico ocorreu.
Descrição

O horário do evento é o registro de data e hora associado a cada atividade, indicando a data e a hora exatas em que ela ocorreu. Esses dados temporais são essenciais para organizar cronologicamente os eventos de cada caso.

Na análise, o horário do evento é usado para calcular os tempos de ciclo entre atividades, medir a duração dos casos e identificar gargalos em que há longos períodos de espera. É a base de qualquer análise de processo por tempo e de medição de performance.

Por que isso importa

Este registro de data e hora é essencial para ordenar corretamente os eventos e calcular métricas de duração, como tempos de ciclo e períodos de gargalo.

Onde encontrar

Em geral, essas informações são armazenadas junto a cada transação ou registro de mudança de status nas tabelas do banco de dados do Optum360.

Exemplos
2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:22:00Z
Nome da atividade
ActivityName
Nome de um evento ou tarefa específica que ocorreu no processo de gestão do ciclo de receita.
Descrição

O nome da atividade descreve uma etapa do ciclo de receita, como 'Solicitação enviada ao pagador' ou 'Pagamento recebido'. Este atributo é fundamental para Process Mining, pois define os nós do mapa do processo.

Ao analisar a sequência e a frequência das atividades, as organizações podem visualizar o fluxo real do processo, identificar desvios do procedimento padrão e localizar ciclos de retrabalho recorrentes. Essa análise é essencial para entender as ineficiências do processo e os problemas de conformidade.

Por que isso importa

Este atributo define cada etapa do processo, forma a base do mapa do processo e permite todas as análises de fluxo.

Onde encontrar

Em geral, é obtido dos Event Logs, dos registros de mudança de status ou de códigos de transação específicos nas tabelas operacionais do Optum360.

Exemplos
Solicitação criadaSolicitação enviada ao pagadorPagamento recebidoNegativa recebidaConta encerrada
Código do motivo da glosa
DenialReasonCode
Código padronizado fornecido pela operadora para explicar por que uma solicitação foi glosada.
Descrição

Quando uma operadora glosa uma solicitação, ela fornece um código do motivo da glosa que explica o problema, como 'Serviço não coberto' ou 'Solicitação duplicada'. Esses códigos são essenciais para entender as causas raiz dos atrasos na receita e do retrabalho.

A análise desses códigos permite que a equipe de gestão de glosas priorize o trabalho, identifique tendências e implemente ações corretivas. Por exemplo, muitas glosas por 'Informações ausentes' podem indicar um problema no processo de criação das solicitações. Essa análise é fundamental para reduzir a taxa de glosas e acelerar o fluxo de caixa.

Por que isso importa

Aponta a causa raiz das glosas, permitindo intervenções direcionadas para evitar novas glosas e reduzir o retrabalho dispendioso.

Onde encontrar

Esse código consta nos arquivos Electronic Remittance Advice (ERA) recebidos das operadoras e fica armazenado no módulo de gestão de solicitações do Optum360.

Exemplos
CO-16: faltam informações na solicitação ou no serviçoPR-97: o benefício deste serviço está incluído no pagamento ou na cobertura de outro serviço ou procedimentoOA-18: solicitação ou serviço duplicado
Departamento de faturamento
BillingDepartment
O departamento interno ou a equipe que gerenciou ou executou a atividade de faturamento.
Descrição

O atributo Departamento de faturamento identifica a equipe ou área funcional específica responsável por uma atividade nas operações do ciclo de receita. Por exemplo, equipes diferentes podem cuidar da codificação, do envio de solicitações e da gestão de glosas.

Esse atributo é essencial para comparar a performance, como no Dashboard 'Referências de performance do departamento de faturamento'. Ele permite que a liderança compare a eficiência, a velocidade e a precisão das equipes, identifique boas práticas e distribua recursos de forma eficaz para corrigir lacunas de performance.

Por que isso importa

Permite comparar a performance entre diferentes equipes de faturamento, ajudando a identificar os grupos com melhores resultados e as áreas que precisam melhorar.

Onde encontrar

Esse dado pode ser obtido a partir do usuário que executou a tarefa ou de um campo da conta que indique a responsabilidade. Consulte a documentação do Optum360.

Exemplos
Escritório central de faturamentoEquipe de gestão de glosasDepartamento de codificaçãoServiços financeiros ao paciente
ID da operadora
PayerId
Identificador exclusivo da seguradora ou operadora responsável pela solicitação.
Descrição

O ID da operadora identifica a seguradora, o programa governamental, como Medicare ou Medicaid, ou outra entidade responsável pelo pagamento da solicitação. Cada operadora costuma ter suas próprias regras, exigências para envio e práticas de pagamento.

Analisar o processo por ID da operadora é essencial para o RCM. Isso ajuda a identificar quais operadoras têm os ciclos de pagamento mais longos, as maiores taxas de glosa ou os processos de recurso mais complexos. Esse insight permite que os departamentos de faturamento adaptem suas estratégias a cada operadora, acelerando os recebimentos e reduzindo a carga administrativa.

Por que isso importa

Segmentar o processo por operadora é essencial para identificar quais delas causam atrasos ou glosas e direcionar melhorias na gestão das operadoras.

Onde encontrar

Essas informações ficam armazenadas em cada registro de solicitação no Optum360. Consulte a documentação do Optum360 para encontrar os nomes das tabelas e dos campos relacionados às operadoras.

Exemplos
PAYER-AETNAPAYER-BCBS-MAPAYER-MEDICAREPAYER-UHC
ID do paciente
PatientId
Identificador único do paciente que recebeu os serviços.
Descrição

O ID do paciente é um identificador único atribuído a cada paciente no sistema de saúde. Ele conecta vários eventos de faturamento a um mesmo paciente e permite fazer análises centradas no paciente.

Com o ID do paciente, os analistas podem investigar padrões relacionados a pacientes específicos, como reinternações frequentes ou histórico de solicitações negadas. O identificador também permite segmentar o processo por dados demográficos ou histórico do paciente, revelando insights importantes para melhorar sua experiência financeira.

Por que isso importa

Permite fazer análises centradas no paciente, entender toda a jornada financeira e identificar padrões em grupos específicos de pacientes.

Onde encontrar

Este identificador é um campo essencial nos dados mestres de pacientes e nas tabelas de transações do Optum360. Consulte a documentação do Optum360 para mais detalhes.

Exemplos
PAT-98765PAT-98766PAT-98767
Valor ajustado
AdjustedAmount
Valor monetário de baixas, ajustes contratuais ou correções aplicados ao valor faturado.
Descrição

Valor ajustado representa a parcela do valor faturado que não se espera receber devido a acordos contratuais com operadoras, correções de faturamento ou outras baixas. Esse valor reduz diretamente a receita.

Esse atributo é essencial para o Dashboard 'Impacto dos ajustes na receita' e para o KPI 'Taxa de ajuste da receita'. Analisar os ajustes ajuda a identificar o impacto financeiro dos contratos com operadoras e a encontrar oportunidades de reduzir perdas de receita com mais precisão no faturamento ou renegociação de contratos.

Por que isso importa

Mede diretamente as perdas de receita e é essencial para calcular KPIs de performance financeira e entender a rentabilidade.

Onde encontrar

Essas informações estão nos registros de transações de ajuste do sistema financeiro do Optum360.

Exemplos
30.00250.2510.00
Valor faturado
BilledAmount
Valor monetário total de todas as cobranças enviadas na solicitação ou fatura.
Descrição

Valor faturado é o valor bruto cobrado pelos serviços prestados, antes de pagamentos, ajustes ou baixas. É o valor inicial da conta a receber referente ao evento de faturamento.

Esse atributo é fundamental para a análise financeira em Process Mining. Ele é usado para calcular KPIs importantes, como a taxa de ajuste da receita, e permite segmentar os casos por valor para verificar se solicitações de alto valor são processadas de forma diferente ou sofrem mais atrasos do que as de baixo valor.

Por que isso importa

Fornece o contexto financeiro de cada caso, permitindo análises por valor e o cálculo de KPIs financeiros essenciais.

Onde encontrar

Esse é um campo padrão em todas as solicitações ou contas de pacientes nas tabelas financeiras do Optum360.

Exemplos
150.001250.7585.50
Código do serviço
ServiceCode
Código do procedimento, como CPT ou HCPCS, que identifica o serviço prestado.
Descrição

O código do serviço é um código médico padronizado que identifica com precisão o procedimento ou serviço prestado ao paciente. Esses códigos são necessários para o faturamento e determinam, em grande parte, o valor do reembolso.

Analisar o processo por código do serviço pode revelar que certos procedimentos estão mais sujeitos a glosas, exigem mais documentação ou têm ciclos de pagamento mais longos. Isso permite entender os desafios do processo com mais precisão e orientar as políticas de codificação e faturamento para cada tipo de serviço.

Por que isso importa

Permite analisar os dados por tipo de serviço médico e identificar padrões de glosas ou atrasos nos pagamentos relacionados a procedimentos específicos.

Onde encontrar

Esse código é parte fundamental dos registros de lançamento de cobranças e dos detalhes das solicitações no Optum360.

Exemplos
992137104527447
Duração do caso
CaseDuration
Tempo de ciclo total de um evento de faturamento, da primeira à última atividade.
Descrição

Duração do caso mede o tempo total entre o primeiro e o último evento de um único evento de faturamento. Esse é um KPI geral importante para avaliar a eficiência do processo como um todo.

Essa métrica dá suporte direto ao Dashboard 'Visão geral do tempo de ciclo de ponta a ponta do RCM' e ao KPI 'Tempo médio de ciclo do RCM'. Acompanhar esse indicador ao longo do tempo permite que a liderança veja o impacto das iniciativas de melhoria em todo o ciclo de receita.

Por que isso importa

Representa o tempo de ciclo de ponta a ponta do processo, um KPI essencial para medir a velocidade e a eficiência gerais.

Onde encontrar

O cálculo é feito subtraindo o timestamp do primeiro evento do timestamp do último evento de cada ID de caso exclusivo de 'BillingEvent'.

Exemplos
30 dias95 dias45 dias
É retrabalho
IsRework
Indicador que mostra se uma atividade faz parte de um ciclo de retrabalho, como a gestão de glosas ou recursos.
Descrição

É retrabalho é um indicador booleano que identifica atividades consideradas retrabalho sem valor agregado, como 'Retrabalho de glosa iniciado' ou 'Recurso enviado'. Essas atividades costumam ocorrer quando o processo se desvia do 'Caminho ideal'.

Esse atributo ajuda a quantificar o retrabalho no processo, um indicador direto de ineficiência e custo. Ele é usado para calcular o KPI 'Taxa de retrabalho por erro de faturamento' e dá suporte ao Dashboard 'Identificação de gargalos e ciclos de retrabalho', facilitando a filtragem e a visualização desses ciclos ineficientes.

Por que isso importa

Ajuda a quantificar a ineficiência do processo ao sinalizar atividades que representam retrabalho, facilitando a medição e a redução de desperdícios.

Onde encontrar

Esse indicador costuma ser definido com base em regras de negócio na ferramenta de Process Mining. Por exemplo, qualquer atividade após um evento 'Glosa recebida' pode ser sinalizada como retrabalho.

Exemplos
truefalse
Hora de término
EndTime
Registro de data e hora que indica quando uma atividade foi concluída.
Descrição

A hora de término marca a conclusão de uma atividade. Enquanto a hora de início indica quando um evento ocorreu, a hora de término é necessária para calcular a duração de atividades com tempo de processamento definido, como 'Retrabalho da negativa iniciado' e sua conclusão.

Na análise de processos, comparar a hora de início e a hora de término das atividades permite calcular o tempo de processamento. Isso ajuda a diferenciar o tempo de trabalho ativo do tempo ocioso, ou seja, da espera entre atividades, e oferece uma visão mais detalhada da eficiência do processo.

Por que isso importa

Permite calcular com precisão o tempo de processamento das atividades e diferenciar o tempo de trabalho ativo do tempo de espera no processo.

Onde encontrar

Para algumas atividades, pode haver um campo separado de registro de data e hora no sistema de origem. Para outras, talvez seja necessário inferir esse valor a partir da hora de início da atividade seguinte.

Exemplos
2023-10-26T10:15:00Z2023-10-26T11:45:00Z2023-10-27T15:00:00Z
Prestador do serviço
ServiceProvider
O profissional de saúde, departamento ou estabelecimento que prestou o serviço faturável.
Descrição

Este atributo identifica o prestador específico, como um médico, terapeuta ou departamento hospitalar, responsável pela prestação do serviço. Diferentes prestadores podem ter práticas de faturamento ou hábitos de documentação distintos, que afetam o ciclo de receita.

Analisar os dados por prestador do serviço ajuda a localizar problemas na captura de cobranças, na precisão da codificação ou na qualidade da documentação, que podem ter origem no atendimento. A análise também pode apontar oportunidades de capacitação dos prestadores ou de melhoria do processo, para garantir que as solicitações sejam geradas corretamente desde o início.

Por que isso importa

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

Onde encontrar

Essas informações são parte importante do registro de cobrança ou solicitação no Optum360 e costumam estar vinculadas aos dados mestres dos prestadores.

Exemplos
Dra. Emily CarterDepartamento de radiologiaCirurgia geralFisioterapia
Sistema de origem
SourceSystem
Sistema ou aplicativo de origem em que os dados do evento foram registrados.
Descrição

Este atributo identifica o sistema de origem de onde os dados de um evento foram extraídos. Em ambientes de TI complexos, os dados de RCM podem vir da plataforma principal do Optum360, de um sistema integrado de prontuário eletrônico (EHR), de uma câmara de compensação ou de um portal do paciente.

Conhecer o sistema de origem ajuda a validar os dados, solucionar problemas de integração e analisar variações do processo que podem decorrer do comportamento de cada sistema ou das práticas de entrada de dados.

Por que isso importa

Identifica a origem dos dados, informação essencial para a governança e a avaliação da qualidade dos dados e para entender as variações do processo entre sistemas.

Onde encontrar

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

Exemplos
Optum360Interface do EHRAPI da câmara de compensaçãoPortal do paciente
Status da conta
AccountStatus
Estado atual da conta de faturamento no ciclo de receita.
Descrição

Status da conta mostra em que ponto do processo está um evento de faturamento, por exemplo, 'Aguardando operadora', 'Pago integralmente' ou 'Em cobrança'. Esse atributo dá contexto às atividades realizadas.

Ele é útil para filtrar e segmentar casos, concentrando a análise em partes específicas do processo. Por exemplo, analisar todas as contas atualmente 'Em cobrança' ajuda a entender os fatores e o volume dessa etapa específica e dispendiosa do processo, dando suporte ao Dashboard 'Volume e fatores das atividades de cobrança'.

Por que isso importa

Fornece uma visão geral do estado atual do caso, permitindo filtrar e analisar grupos específicos, como as contas em cobrança.

Onde encontrar

Esse costuma ser um campo de resumo no registro principal da conta do paciente ou da solicitação no Optum360.

Exemplos
Em abertoAguardando operadoraPago integralmenteEm cobrançaEncerrado
Última atualização dos dados
LastDataUpdate
Registro de data e hora da atualização ou extração mais recente dos dados do sistema de origem.
Descrição

Este atributo registra a data e a hora da última extração dos dados do sistema de origem e do carregamento na ferramenta de Process Mining. Ele informa o quão recentes são os dados analisados.

Essa informação ajuda analistas e usuários de negócios a saber se estão consultando os dados mais atuais. Também permite alinhar expectativas sobre a latência dos dados e é um metadado importante em qualquer projeto de análise.

Por que isso importa

Informa o quão recentes são os dados, ajudando os usuários a entender até que ponto a análise está atualizada.

Onde encontrar

Em geral, esse registro de data e hora é gerado e armazenado pelo processo de extração, transformação e carregamento de dados (ETL).

Exemplos
2023-11-01T02:00:00Z2023-11-02T02:00:00Z
Usuário
User
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 no nível individual ou de grupo.

Saber qual usuário ou equipe executou uma ação ajuda a avaliar produtividade, qualidade e adesão aos procedimentos padrão. Também pode revelar necessidades de treinamento ou destacar pessoas e equipes com bons resultados. Além disso, ajuda a diferenciar tarefas executadas manualmente daquelas realizadas por automação.

Por que isso importa

Atribui responsabilidade pelas etapas do processo e permite analisar a performance por pessoa ou equipe, algo essencial para a gestão de recursos e o treinamento.

Onde encontrar

Os IDs de usuário costumam ser registrados nos logs de auditoria ou no histórico de transações dos registros no Optum360.

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

Valor pago é a soma acumulada de todos os pagamentos registrados na conta para um evento de faturamento específico. Esse valor representa o dinheiro efetivamente recebido e é uma das principais medidas do sucesso do ciclo de receita.

Na análise de processos, acompanhar o valor pago é essencial para entender o fluxo de caixa e a performance financeira geral. Esse dado pode ser usado para analisar a velocidade dos pagamentos e comparar os valores faturados com os recebidos, revelando problemas de pagamentos abaixo do esperado ou dívidas que não podem ser cobradas.

Por que isso importa

Representa o dinheiro efetivamente recebido, um indicador importante de resultado do processo de RCM e essencial para a análise do fluxo de caixa.

Onde encontrar

Esse valor costuma ser armazenado nas tabelas de transações de pagamento ou consolidado no nível da conta no Optum360.

Exemplos
120.001000.500.00
Obrigatório Recomendado Opcional

Atividades da gestão do ciclo de receita

Estas são as principais etapas e marcos do processo que você deve registrar no Event Log para descobrir o processo com precisão.
6 Recomendado 9 Opcional
Atividade Descrição
Aviso de pagamento recebido
O sistema recebeu do pagador um arquivo eletrônico de aviso de pagamento (ERA), com detalhes de pagamentos, ajustes e negativas. Este evento explícito é registrado quando o sistema importa um arquivo EDI 835.
Por que isso importa

Esta atividade é um marco importante que indica que o pagador processou a solicitação. O conteúdo do arquivo determina as próximas ações, como lançar o pagamento ou gerenciar a negativa.

Onde encontrar

Registrado nos logs de transações EDI dos arquivos ANSI 835 recebidos. O registro de data e hora indica quando o sistema recebeu e processou o arquivo.

Coleta

Registro de data e hora associado à importação do arquivo EDI 835 (aviso eletrônico de pagamento).

Tipo de evento explicit
Conta encerrada
O evento de faturamento é considerado concluído quando o saldo chega a zero e não há previsão de novas atividades. Esse evento é identificado quando o saldo da conta zera e o status é atualizado para 'Encerrada' ou outro estado final equivalente.
Por que isso importa

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

Onde encontrar

Identificado pela combinação do saldo da conta zerado com o campo de status definido como 'Encerrada', 'Totalmente paga' ou outro status final equivalente.

Coleta

O registro de data e hora mais recente entre o lançamento do pagamento final que zera o saldo e a mudança de status para 'Encerrada'.

Tipo de evento inferred
Dados do serviço recebidos
Marca o início do evento de faturamento, quando as informações sobre o serviço clínico são recebidas do prontuário eletrônico (EHR) ou de outro sistema de origem. Em geral, esse evento é registrado por uma entrada explícita no log ou por um registro de transação criado por uma interface de integração após a importação bem-sucedida dos dados.
Por que isso importa

Este é o principal evento de início do ciclo de receita. Analisar o tempo entre esta atividade e o registro da cobrança é essencial para identificar atrasos nos dados de entrada que afetam todo o processo.

Onde encontrar

Registrado em logs de interface ou tabelas de transações que recebem dados de serviços prestados a pacientes de sistemas externos, como um EHR. Procure registros de data e hora de mensagens HL7 ou logs de chamadas de API.

Coleta

Capturado nos logs de integração ou nas tabelas de transações, com registro de data e hora no recebimento dos dados.

Tipo de evento explicit
Negativa recebida
O pagador negou uma solicitação, conforme indicado em um aviso de pagamento recebido. Esse evento é identificado pela análise dos dados do aviso de pagamento em busca de códigos de motivo de negativa associados aos itens da solicitação.
Por que isso importa

Acompanhar as negativas é essencial para identificar as causas raiz da perda de receita e das ineficiências do processo. Esta atividade dá início a todos os ciclos de retrabalho de gestão de negativas e recursos.

Onde encontrar

Identificado nos dados do aviso eletrônico de pagamento (EDI 835). O sistema detecta códigos de motivo de ajuste da solicitação (CARCs) que indicam uma negativa.

Coleta

Identificado pela detecção de códigos específicos de negativa (CARCs/RARCs) nos dados analisados do aviso de pagamento EDI 835.

Tipo de evento inferred
Pagamento lançado
Um pagamento recebido foi aplicado com sucesso à conta específica do paciente e aos itens de serviço correspondentes. Esta ação explícita, realizada por um usuário ou automaticamente, concilia o pagamento com as cobranças em aberto.
Por que isso importa

Esta atividade é essencial para medir a eficiência do processo de aplicação de pagamentos no back-office. Atrasos no lançamento podem distorcer os relatórios de contas a receber e postergar o encerramento da conta.

Onde encontrar

Encontrado nas tabelas de transações de pagamento. O registro de data e hora da transação de lançamento indica o momento do evento.

Coleta

Registro de data e hora de criação do registro da transação de pagamento aplicada a uma cobrança específica.

Tipo de evento explicit
Solicitação enviada ao pagador
A solicitação gerada foi enviada eletronicamente à seguradora para análise. Este evento é registrado explicitamente pelo módulo de envio de solicitações ou pela interface da câmara de compensação após a transmissão bem-sucedida.
Por que isso importa

Este é um marco crítico, pois inicia a contagem do tempo de resposta do pagador. Ajuda a medir a eficiência do processo de envio de solicitações e a identificar atrasos.

Onde encontrar

Encontrado nos logs de transações de solicitações ou nas tabelas de transações EDI (intercâmbio eletrônico de dados), que acompanham especificamente o envio de arquivos de solicitação 837. Procure um campo de 'registro de data e hora do envio' ou 'data de transmissão'.

Coleta

Registro de data e hora do log de transações EDI 837 que indica o envio bem-sucedido.

Tipo de evento explicit
Atividade de cobrança iniciada
A conta do paciente entrou em um processo ativo de cobrança por falta de pagamento. Em geral, isso é identificado por uma mudança na categoria financeira ou no status da conta.
Por que isso importa

Este evento identifica as contas que precisam de um acompanhamento mais intensivo. Analisar a frequência e os fatores que levam a essa atividade ajuda a melhorar as estratégias de cobrança inicial.

Onde encontrar

Identificado por uma mudança no status da conta para 'Em cobrança', 'Dívida incobrável' ou 'Encaminhada a uma agência de cobrança'. A data dessa mudança de status é o registro de data e hora do evento.

Coleta

Registro de data e hora da alteração de um campo de status da conta para um valor relacionado à cobrança.

Tipo de evento inferred
Cobranças registradas
Representa o momento em que serviços e materiais faturáveis específicos são registrados formalmente no sistema de faturamento. Trata-se de uma ação explícita do usuário ou do sistema que cria registros de transação de cobrança.
Por que isso importa

Esta atividade é essencial para medir o atraso no registro da cobrança, ou seja, o intervalo entre a prestação do serviço e o início do faturamento. Reduzir esse intervalo acelera diretamente o ciclo de receita.

Onde encontrar

Encontrado nas tabelas de transações de cobrança, muitas vezes chamadas de tabelas de registro de cobranças ou de itens de serviço. O registro de data e hora de criação da cobrança indica o momento do evento.

Coleta

O evento corresponde ao registro de data e hora de criação de um registro na tabela principal de cobranças ou na tabela 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 ICD adequados. Em geral, é um evento explícito, registrado quando um usuário ou mecanismo automatizado conclui a tarefa de codificação.
Por que isso importa

A codificação costuma ser um gargalo que atrasa o envio de solicitações. Acompanhar esta atividade ajuda a medir a produtividade dos codificadores e identificar atrasos na fila de codificação.

Onde encontrar

Registrado em um módulo de fluxo de trabalho de codificação ou por uma mudança de status do evento de faturamento de 'Aguardando codificação' para 'Codificado'. Usa-se o registro de data e hora dessa mudança de status ou da conclusão da tarefa.

Coleta

Registro de data e hora de uma atualização de status ou de uma entrada no log, quando um usuário ou sistema finaliza a codificação do atendimento.

Tipo de evento explicit
Conta ajustada
Um ajuste contratual, uma baixa contábil ou outra correção financeira foi lançado na conta. Trata-se de uma transação financeira explícita, registrada no razão do sistema.
Por que isso importa

Os ajustes afetam diretamente a realização da receita. Analisar os motivos e o momento dos ajustes é essencial para identificar problemas nas tabelas de preços, nos contratos ou na precisão do faturamento.

Onde encontrar

Localizado na tabela de transações financeiras e identificado por códigos específicos de transação para baixas contábeis ou ajustes. A data da transação indica o momento do evento.

Coleta

Data da transação de um lançamento no razão financeiro com um código de ajuste específico.

Tipo de evento explicit
Demonstrativo enviado ao paciente
Um demonstrativo de faturamento foi gerado e enviado ao paciente, referente à parte da conta que cabe a ele. Este evento explícito é registrado pelo módulo de faturamento de pacientes quando o demonstrativo é criado.
Por que isso importa

Esta atividade inicia a parte de pagamento direto pelo paciente no ciclo de receita. Acompanhar esse processo ajuda a analisar a eficiência e a eficácia da cobrança de pacientes.

Onde encontrar

Registrado em uma tabela de correspondências com pacientes ou no histórico de geração de demonstrativos. O registro de data e hora indica quando o demonstrativo foi criado ou enviado.

Coleta

Registro de data e hora de um log ou histórico de geração de demonstrativos para pacientes.

Tipo de evento explicit
Pagamento recebido
Indica que um pagamento foi recebido do pagador ou do paciente, geralmente como parte do aviso de pagamento. O evento pode ser capturado explicitamente em arquivos eletrônicos de aviso de pagamento ou em logs manuais de recebimento de valores.
Por que isso importa

Esta é uma atividade fundamental para analisar o fluxo de caixa e medir a velocidade dos pagamentos. Ela dá início ao processo de lançamento do pagamento.

Onde encontrar

Obtido das informações de pagamento no arquivo de aviso EDI 835 ou dos arquivos de lockbox de um banco. Geralmente, usa-se a data do cheque ou a data de processamento indicada no arquivo.

Coleta

Extraído do segmento BPR de um arquivo EDI 835 ou do arquivo de dados de lockbox de um banco.

Tipo de evento explicit
Recurso enviado
Um recurso foi enviado formalmente ao pagador para contestar uma solicitação negada. Esta ação explícita é registrada por um usuário no módulo de gestão de negativas ou de recursos.
Por que isso importa

Esta atividade é uma etapa importante da recuperação de receita. Acompanhar os recursos enviados e seus tempos de ciclo é essencial para entender a eficácia da estratégia de resolução de negativas.

Onde encontrar

Registrado em um módulo de acompanhamento de recursos ou como um tipo específico de transação associado à solicitação. Procure um campo de 'data do recurso' ou 'data de reenvio'.

Coleta

Registro de data e hora explícito, gravado quando um usuário registra o envio de um recurso.

Tipo de evento explicit
Retrabalho da negativa iniciado
Um usuário ou fluxo de trabalho automatizado iniciou a análise e a resolução de uma solicitação negada. O evento pode ser registrado explicitamente por uma ação do usuário ou identificado por uma mudança de status da solicitação.
Por que isso importa

Esta atividade inicia o ciclo de retrabalho das negativas. Medir o tempo entre o recebimento da negativa e o início do retrabalho ajuda a identificar acúmulos na fila de gestão de negativas.

Onde encontrar

Encontrado nos módulos de gestão de negativas ou de filas de trabalho. Pode ser um registro de data e hora explícito, quando um usuário 'abre' ou 'assume' uma tarefa de negativa, ou ser identificado por uma mudança de status, como de 'Negada' para 'Em retrabalho'.

Coleta

Identificado por uma mudança de status da solicitação para 'Retrabalho' ou 'Em revisão', ou por um log explícito de ação do usuário.

Tipo de evento inferred
Solicitação criada
O sistema gerou uma solicitação faturável, reunindo todas as cobranças, os códigos e as informações demográficas em um formato padronizado. Este é um evento explícito, gerado pelo sistema e associado a um registro de data e hora de criação.
Por que isso importa

Esta atividade marca a transição do registro da cobrança para o processo formal de faturamento. É um pré-requisito para o envio e essencial para acompanhar os tempos de processamento interno.

Onde encontrar

Localizado na tabela de solicitações ou no log de transações. O registro de data e hora de criação do registro principal da solicitação indica o evento.

Coleta

Capturado a partir do registro de data e hora de criação do registro principal na tabela de solicitações do banco de dados.

Tipo de evento explicit
Recomendado Opcional

Guias de extração

Como obter seus dados do Optum360

Os métodos de extração deste processo estão sendo validados. Volte mais tarde ou entre em contato conosco para receber ajuda.

Pronto para começar?

Use este Template para simplificar a coleta de dados e começar a otimizar seus processos de gestão do ciclo de receita. Descubra insights e aumente a eficiência com confiança.

Otimize a gestão do ciclo de receita e reduza atrasos hoje

Junte-se a organizações que reduziram o tempo de ciclo em 30% e melhoraram sua saúde financeira.

Comece o teste grátis

Não é necessário informar cartão de crédito. Configure em poucos minutos.