Seu Template de Dados de Gestão do Ciclo de Receita
Seu Template de Dados de Gestão do Ciclo de Receita
- Atributos recomendados para coletar
- Atividades-chave a monitorizar
- Guia de extração para Oracle Health Revenue Cycle
Atributos de Gestão do Ciclo de Receita
| Nome | Descrição | ||
|---|---|---|---|
| Event Timestamp EventTimestamp | A data e hora exatas em que uma atividade foi registrada no sistema. | ||
| Descrição Este atributo fornece o registro de data e hora para cada atividade, marcando o momento exato em que ocorreu. É essencial para entender o tempo e a sequência de eventos dentro do ciclo de receita para um evento de faturamento específico. Na análise, o Timestamp do Evento é usado para ordenar as atividades cronologicamente, calcular durações e tempos de ciclo entre diferentes etapas e realizar análises de gargalos. É a base para todas as métricas de Process Mining baseadas em tempo, como a identificação de atrasos entre 'Fatura Enviada' e 'Remessa Recebida'. Por que é importante Este registro de data e hora é crítico para ordenar eventos, calcular todas as métricas de desempenho, como tempos de ciclo e durações, e identificar gargalos no processo. Onde obter Cada tabela de transação ou event log no Oracle Health Revenue Cycle deve ter uma coluna de timestamp indicando quando o registro foi criado ou o evento ocorreu. Exemplos 2023-04-15T09:00:00Z2023-04-18T14:30:00Z2023-05-02T11:25:10Z | |||
| Evento de Faturamento BillingEvent | O identificador único para a entrega de um único serviço ou produto que gera uma cobrança, servindo como identificador de caso para o processo do ciclo de receita. | ||
| Descrição O Evento de Faturamento atua como o identificador de caso principal, vinculando todas as atividades, desde a captura da cobrança até o fechamento da conta de um item faturável específico. Cada Evento de Faturamento representa uma instância única do processo do ciclo de receita, permitindo o rastreamento completo de sua jornada por vários estágios, como envio da fatura, lançamento do pagamento e possíveis glosas ou ajustes. Na análise de Process Mining, este atributo é fundamental para reconstruir o fluxo do processo ponta a ponta. Ele permite a visualização das variantes do processo, o cálculo dos tempos de ciclo entre as atividades e a identificação de gargalos ou desvios associados a eventos faturáveis específicos. Por que é importante Esta é a chave essencial para rastrear todo o ciclo de vida de um serviço faturável, permitindo toda a análise de fluxo de processo e medição de desempenho. Onde obter Este identificador deve ser uma chave exclusiva presente nas tabelas principais de faturamento ou transação de cobrança no Oracle Health Revenue Cycle. Consulte a documentação do sistema para identificar a chave primária para eventos de cobrança. Exemplos BEVNT-987654321BEVNT-987654322BEVNT-987654323 | |||
| Nome da Atividade ActivityName | O nome da etapa ou evento específico que ocorreu no processo do ciclo de receita. | ||
| Descrição Este atributo registra o nome de cada atividade realizada no ciclo de vida de um evento de faturamento. Exemplos incluem 'Cobranças Capturadas', 'Fatura Enviada ao Pagador' e 'Pagamento Lançado'. Estas atividades formam os nós do mapa de processo descoberto. Analisar a sequência e a frequência das atividades é o cerne do Process Mining. Este atributo ajuda a identificar os caminhos de processo mais comuns, descobrir desvios do procedimento padrão e entender o fluxo operacional do ciclo de receita. Por que é importante Define as etapas do processo, permitindo a visualização do mapa de processos e a análise dos padrões de workflow. Onde obter Normalmente derivado de event logs, registros de mudança de status ou tabelas de transação específicas associadas a diferentes estágios do ciclo de receita no Oracle Health. Exemplos Guia GeradaRemessa RecebidaRecurso de Glosa RealizadoConta Fechada | |||
| Classe do Paciente PatientClass | A classificação do atendimento ao paciente, como Internação ou Ambulatorial. | ||
| Descrição Este atributo categoriza o tipo de visita ou atendimento ao paciente que gerou a cobrança. Classificações comuns incluem Internação, Ambulatorial, Emergência e Paciente Recorrente. A classe do paciente geralmente dita todo o processo de faturamento e envio de guias. Diferentes classes de pacientes seguem caminhos de processo distintos e possuem requisitos de conformidade variados. Analisar o processo com base neste atributo ajuda a entender essas variações, personalizar iniciativas de melhoria e garantir que os procedimentos corretos sejam seguidos para cada classe. Por que é importante Separa fluxos de processo distintos (ex: Internação vs. Ambulatorial) que possuem diferentes complexidades, prazos e requisitos de faturamento. Onde obter Este é um campo padrão associado a um atendimento de paciente ou registro de admissão no Oracle Health. Exemplos InternaçãoAmbulatorialEmergencial (Emergency)Recorrente | |||
| Código do Motivo da Glosa DenialReasonCode | Um código padronizado que indica o motivo pelo qual a conta foi glosada pela operadora. | ||
| Descrição Quando um pagador glosa uma fatura, ele fornece um código de motivo explicando a recusa, como 'Serviço não coberto' ou 'Fatura duplicada'. Este atributo captura esse código e sua descrição associada. Analisar os motivos de glosa é fundamental para melhorar o ciclo de receita. Permite que a organização identifique padrões comuns, como problemas de codificação ou elegibilidade do paciente, e implemente ações corretivas para evitar glosas futuras. Isso impacta diretamente a taxa de faturamento limpo e reduz o custo do retrabalho. Por que é importante Fornece a causa raiz das glosas, permitindo melhorias focadas para aumentar a taxa de contas limpas e acelerar a arrecadação da receita. Onde obter Esta informação é recebida no aviso de remessa eletrônica (arquivo ANSI 835) do pagador e deve ser armazenada nas tabelas de fatura ou remessa no Oracle Health. Exemplos CO-16: Conta/serviço sem as informações necessárias para análise.PR-96: Itens não cobertos.CO-18: Conta/serviço duplicado. | |||
| Departamento de Faturamento BillingDepartment | O departamento ou equipe funcional responsável pela atividade. | ||
| Descrição Este atributo especifica o departamento, como 'Captura de Cobrança', 'Codificação' ou 'Cobranças', que realizou a atividade. Ele fornece um contexto organizacional ao fluxo do processo. Analisar o processo sob uma perspectiva departamental é essencial para entender as transferências entre equipes e identificar ineficiências multifuncionais. Ele alimenta o Dashboard de 'Carga de Trabalho do Departamento de Faturamento', permitindo a agregação de atividades e métricas de desempenho por departamento. Por que é importante Atribui atividades a unidades organizacionais, o que é fundamental para analisar passagens de bastão entre departamentos, carga de trabalho e desempenho da equipe. Onde obter Esta informação pode estar armazenada diretamente nos dados do perfil do usuário no Oracle Health ou ser derivada com base no usuário ou tipo de atividade. Exemplos Acesso do PacienteCodificaçãoFaturamentoCobranças | |||
| Nome do Pagador PayerName | O nome da seguradora ou operadora responsável pelo pagamento. | ||
| Descrição Este atributo identifica a entidade, como uma seguradora ou programa governamental (ex: SUS), que é faturada pelo serviço. A informação do pagador é fundamental para a análise do ciclo de receita. Analisar o processo por pagador pode revelar variações significativas nos tempos de pagamento, taxas de glosa e taxas de sucesso em recursos. Isso ajuda a identificar pagadores problemáticos que causam atrasos ou perda de receita, sendo essencial para gerir contratos e relacionamentos com as operadoras de forma eficaz. Por que é importante Permite segmentar o processo por operadora, revelando diferentes comportamentos, taxas de glosa e velocidades de pagamento — essencial para a performance financeira. Onde obter Esta informação é armazenada nos registros de faturamento ou seguro do paciente no Oracle Health Revenue Cycle. Exemplos AetnaBlue Cross Blue ShieldUnitedHealthcareMedicareCigna | |||
| Saldo Pendente OutstandingBalance | O saldo devedor restante do evento de faturamento em um determinado momento. | ||
| Descrição Este atributo mostra o valor pendente atual devido por um evento de faturamento após a aplicação de todos os pagamentos e ajustes. Representa as contas a receber ativas para essa cobrança específica. Este é um atributo crítico para o Dashboard de 'Envelhecimento de Saldo Pendente'. Analisar este valor ao longo do tempo ajuda a monitorar a velocidade do fluxo de caixa, avaliar a eficácia dos esforços de cobrança e calcular KPIs financeiros fundamentais como o Prazo Médio de Recebimento (DSO). Por que é importante Rastreia as contas a receber atuais para cada caso, o que é essencial para gerenciar o fluxo de caixa e analisar a eficácia das cobranças. Onde obter Este valor é normalmente calculado a partir da soma de todas as transações financeiras (cobranças, pagamentos, ajustes) de um determinado evento de faturamento. Pode existir como um campo em uma tabela de resumo de conta. Exemplos 75.000.00550.80 | |||
| Utilizador UserPerformingAction | O ID do usuário ou nome da pessoa que realizou a atividade. | ||
| Descrição Este atributo identifica o funcionário ou usuário do sistema automatizado responsável por executar uma atividade específica no processo. É crucial para entender a distribuição da carga de trabalho, o desempenho dos recursos e identificar necessidades de treinamento. Na análise, este atributo permite filtrar o mapa do processo por usuário ou equipe, comparar o desempenho entre diferentes recursos e analisar a carga de trabalho para o Dashboard de 'Carga de Trabalho do Departamento de Faturamento'. Ele pode ajudar a identificar os profissionais com melhor desempenho ou indivíduos que podem precisar de suporte ou treinamento adicional. Por que é importante Vincula atividades de processo a usuários ou equipes, permitindo análise de carga de trabalho, comparação de performance e identificação de necessidades de treinamento. Onde obter Campos de ID de usuário (ex: 'CREATED_BY', 'USER_ID') estão normalmente presentes nas tabelas de transação em todos os módulos do Oracle Health. Exemplos j.doeasmithBillingBot_AUTOk.williams | |||
| Valor do Ajuste AdjustmentAmount | O valor monetário de quaisquer ajustes feitos no saldo da conta. | ||
| Descrição Este atributo captura o valor de qualquer ajuste financeiro, como descontos contratuais, baixas ou correções, aplicado ao evento de faturamento. Os ajustes reduzem diretamente a receita esperada de uma cobrança. O Dashboard de 'Impacto de Ajuste de Conta' depende muito deste atributo. Analisar os valores de ajuste e seus motivos associados ajuda a identificar fontes de perda de receita, problemas com a gestão de contratos ou falhas no processo inicial de captura de cobranças. É uma métrica essencial para a saúde financeira. Por que é importante Quantifica a perda de receita por baixas (write-offs) ou correções, ajudando a identificar e tratar as causas raízes da erosão financeira. Onde obter Encontrado nas tabelas de transações financeiras que registram ajustes ou baixas (write-offs) em uma conta de paciente. Exemplos -50.25-120.0025.00 | |||
| É Automatizado IsAutomated | Um sinalizador que indica se a atividade foi realizada por um sistema automatizado ou por um usuário humano. | ||
| Descrição Este atributo booleano diferencia as atividades executadas por automação de software, como bots ou trabalhos em lote do sistema, daquelas realizadas manualmente por um usuário. Por exemplo, 'Fatura Gerada' pode ser uma etapa automatizada, enquanto 'Recurso de Glosa' é provavelmente manual. Analisar este atributo ajuda a entender o nível de automação do processo e seu impacto na eficiência e nas taxas de erro. Pode ser usado para comparar o desempenho de caminhos automatizados versus manuais e identificar oportunidades para novas automações. Por que é importante Diferencia atividades humanas de automáticas, o que é crítico para analisar a eficácia da automação e identificar novas oportunidades de robotização. Onde obter Isso geralmente é derivado do atributo UsuárioQueRealizaAAção. Por exemplo, atividades realizadas por IDs de usuário como 'SISTEMA' ou 'RPA_BOT' são sinalizadas como automatizadas. Exemplos verdadeirofalse | |||
| É Retrabalho IsRework | Um marcador (flag) que identifica atividades que representam retrabalho ou esforço repetido. | ||
| Descrição Este atributo calculado sinaliza atividades que indicam um desvio do 'caminho ideal' e constituem retrabalho. Exemplos incluem 'Fatura Corrigida Enviada' ou 'Recurso de Glosa', que não ocorreriam se o processo fosse perfeito na primeira vez. Identificar e quantificar o retrabalho é um dos principais objetivos do Process Mining. Esta sinalização permite filtrar e analisar facilmente todos os loops de retrabalho, ajudando a medir a frequência, o custo e as causas das ineficiências do processo. É essencial para entender o verdadeiro custo da qualidade no ciclo de receita. Por que é importante Ajuda a quantificar a frequência e o impacto dos ciclos de retrabalho, destacando ineficiências e o custo da baixa qualidade. Onde obter Este é um atributo derivado. É calculado durante a transformação de dados, aplicando uma lógica de negócio que sinaliza nomes de atividades específicas como retrabalho. Exemplos verdadeirofalse | |||
| Event End Time EventEndTime | O registro de data e hora que marca a conclusão de uma atividade, se disponível. | ||
| Descrição Enquanto o HorárioDeInício marca o começo de uma atividade, o HorárioDeFimDoEvento marca sua conclusão. Nem todas as atividades têm um horário de término distinto, pois muitas são eventos instantâneos. No entanto, para atividades que possuem duração, como 'Recurso de Glosa', que pode levar tempo para ser processado, este campo é muito útil. Este atributo permite um cálculo mais preciso do tempo de processamento de atividades individuais. Ajuda a diferenciar entre tempo de espera (tempo entre atividades) e tempo de processamento (tempo gasto em uma atividade). Por que é importante Permite o cálculo direto de quanto tempo uma atividade leva para ser concluída, separando o tempo de execução do tempo de espera. Onde obter Algumas tabelas de transação no Oracle Health Revenue Cycle podem conter tanto o timestamp de início quanto o de fim para tarefas específicas de longa duração. Exemplos 2023-04-15T09:05:14Z2023-04-18T16:00:00Z | |||
| ID do paciente PatientId | O identificador único do paciente associado ao evento de faturamento. | ||
| Descrição Este atributo é o identificador único do paciente que recebeu o serviço, muitas vezes conhecido como Registro Geral (RG) ou Prontuário Médico. Ele vincula a transação financeira a um indivíduo específico. Embora não seja o ID de caso do processo, o ID do Paciente é útil para agregar todos os eventos de faturamento de um único paciente para entender sua jornada financeira completa. Também permite a segmentação baseada em demografia ou histórico do paciente, se combinado com dados mestres de pacientes. Por que é importante Vincula eventos financeiros a um paciente específico, permitindo análises centradas no paciente e a agregação de todas as suas atividades de faturamento. Onde obter Este identificador é um elemento central do registro mestre do paciente e estará presente em todas as tabelas de transação relacionadas, como cobranças, faturas e pagamentos. Exemplos MRN-1002345MRN-1002346MRN-1002347 | |||
| ID do Sinistro ClaimId | O identificador único da fatura de seguro enviada a um pagador. | ||
| Descrição Este atributo é o ID exclusivo atribuído a uma fatura gerada e enviada a um pagador para reembolso. Um único evento de faturamento pode resultar em uma ou mais faturas ao longo do seu ciclo de vida, por exemplo, se uma correção for necessária. O uso do ID da Fatura permite rastrear um envio específico a um pagador e vinculá-lo diretamente à resposta, como um pagamento ou uma glosa. Ele fornece um nível mais granular de rastreamento dentro do processo mais amplo do ciclo de receita. Por que é importante Fornece um identificador específico para rastrear a jornada de uma guia com a operadora, sendo mais granular que o evento de faturamento geral. Onde obter Este ID é gerado pelo Oracle Health quando uma fatura é criada e fica armazenado na tabela principal de faturas. Exemplos CLM-2023-55489CLM-2023-55490CLM-2023-55491-C1 | |||
| Motivo da Disputa DisputeReason | O motivo fornecido pelo cliente ou paciente para contestar uma fatura ou cobrança. | ||
| Descrição Este atributo captura o motivo pelo qual um paciente ou outra parte responsável contestou uma conta. Os motivos podem incluir cobranças incorretas, serviços não prestados ou problemas com o processamento do seguro. Esta informação é essencial para o Dashboard de 'Métricas de Resolução de Disputa de Fatura'. Compreender os motivos mais comuns das disputas ajuda a identificar problemas sistêmicos nos processos de captura, codificação ou faturamento. Resolver essas causas raiz pode reduzir significativamente a taxa de disputa e a carga administrativa necessária para resolvê-las. Por que é importante Explica por que as faturas estão sendo contestadas, oferecendo insights diretos sobre problemas de precisão ou clareza que precisam ser corrigidos. Onde obter Isso provavelmente está armazenado em um módulo de gestão de casos ou atendimento ao cliente no Oracle Health, vinculado à conta do paciente. Exemplos Serviço Incorreto FaturadoCobrança DuplicadaSeguro Faturado IncorretamenteServiço Não Prestado | |||
| Sistema de Origem SourceSystem | O sistema do qual os dados de evento foram extraídos. | ||
| Descrição Este atributo identifica o aplicativo ou módulo de origem de onde os dados vieram. Para este processo, geralmente será 'Oracle Health Revenue Cycle', mas também pode especificar diferentes módulos dentro do sistema se os dados forem integrados de vários lugares. Esta informação é valiosa para a governança de dados e solução de problemas. Ela ajuda a confirmar a linhagem dos dados e é importante em ambientes onde múltiplos sistemas contribuem para um único processo ponta a ponta. Por que é importante Fornece contexto sobre a origem dos dados, o que é crucial para validação, governança e entendimento de variações de processo que possam depender do sistema. Onde obter Geralmente é um valor estático adicionado durante o processo de extração, transformação e carregamento (ETL) para rotular a origem do conjunto de dados. Exemplos OracleHealth-RCMOracleHealth-CernerOH-RevCycle-PROD | |||
| Tempo de Processamento ProcessingTime | A duração do tempo gasto a trabalhar ativamente numa atividade. | ||
| Descrição Este atributo mede o tempo de processamento ativo de um evento, calculado como a diferença entre os seus timestamps de início e fim. Ajuda a distinguir o tempo gasto trabalhando ativamente em uma tarefa do tempo de espera pela próxima etapa. Esta é uma métrica crucial para a análise de desempenho, pois isola a eficiência do recurso que realiza a tarefa de atrasos sistêmicos. Ajuda a responder perguntas sobre quanto tempo leva para codificar uma fatura ou lançar um pagamento, independentemente de quanto tempo o item ficou parado em uma fila de trabalho. Por que é importante Mede a duração real do trabalho em uma atividade, separando-a do tempo de inatividade ou espera para uma visão clara da eficiência dos recursos. Onde obter Esta é uma métrica calculada, derivada da subtração do EventTimestamp do EventEndTime. Só pode ser calculada quando ambos os campos estão disponíveis. Exemplos 300120045 | |||
| Última Atualização de Dados LastDataUpdate | O timestamp que indica a última vez que os dados deste evento foram atualizados ou extraídos. | ||
| Descrição Este atributo mostra quando o conjunto de dados foi atualizado pela última vez. Ele fornece contexto sobre o quão recentes são os dados analisados, o que é importante para entender a atualidade dos insights derivados da análise de Process Mining. Os usuários podem verificar este atributo para confirmar se estão visualizando as informações de processo mais atuais. Isso ajuda a gerenciar as expectativas sobre a recência dos dados e é um componente fundamental da governança e garantia de qualidade de dados. Por que é importante Indica a atualização dos dados, garantindo que as análises e decisões sejam baseadas em informações recentes. Onde obter Este é um campo de metadados normalmente gerado e preenchido durante o processo de ETL que carrega os dados na plataforma de Process Mining. Exemplos 2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
| Valor da Cobrança ChargeAmount | O valor monetário bruto do serviço ou produto faturado. | ||
| Descrição Este atributo representa o valor inicial e sem descontos cobrado por um serviço antes da aplicação de quaisquer ajustes, descontos contratuais ou pagamentos. É o valor financeiro inicial para o evento de faturamento. Rastrear o valor da cobrança é crucial para análises financeiras, como calcular o valor total dos serviços prestados e entender o impacto financeiro de ajustes ou baixas subsequentes. Serve como linha de base para medir a realização da receita. Por que é importante Estabelece o valor financeiro inicial do case, o que é fundamental para todas as análises financeiras e avaliações de impacto posteriores. Onde obter Localizado nos detalhes de cobrança ou tabelas de transação de 'charge' no Oracle Health. Exemplos 150.001250.7585.50 | |||
Atividades de Gestão do Ciclo de Receita
| Atividade | Descrição | ||
|---|---|---|---|
| Atendimento de Paciente Criado | Marca a criação de uma conta de paciente para uma visita ou serviço. Geralmente é um evento explícito disparado pelo sistema de registro ou feed ADT. | ||
| Por que é importante Serve como ponto de partida para todo o ciclo de receita de um evento de faturamento, permitindo analisar a duração total e a precisão do registro. Onde obter Obtido dos logs do módulo de Registro de Pacientes ou ADT. Procure por eventos de criação de atendimento ou o timestamp mais antigo associado ao atendimento ou número financeiro. Captura Event registrado no momento do registro ou admissão do paciente. Tipo de evento explicit | |||
| Conta Fechada | A atividade final, indicando que o saldo da conta é zero e nenhuma outra atividade é esperada. Isso geralmente é inferido quando o saldo da conta chega a zero. | ||
| Por que é importante Marca a conclusão bem-sucedida do ciclo de receita. O tempo para atingir este estado é uma métrica fundamental da eficiência do processo. Onde obter Isso geralmente é inferido identificando a primeira vez que o saldo pendente da conta se torna zero e permanece zero após todos os pagamentos e ajustes. Captura Calculado quando o saldo da conta chega a zero pela primeira vez após o lançamento de todos os itens e pagamentos. Tipo de evento calculated | |||
| Guia Enviada para Operadora | Representa o envio eletrônico ou em papel da guia gerada para a operadora ou seguradora. O sistema deve registrar a data e hora dessa transmissão. | ||
| Por que é importante Esta atividade inicia a contagem do ciclo de pagamento. Analisar o tempo desde o envio até o pagamento é fundamental para entender o desempenho do pagador e o Prazo Médio de Recebimento (DSO). Onde obter Obtido do módulo de gestão de faturas, que registra eventos de transmissão. Procure por um timestamp de submissão ou uma mudança de status para 'Enviado' no histórico da fatura. Captura Event registrado quando a guia é transmitida com sucesso através da clearinghouse. Tipo de evento explicit | |||
| Guia Gerada | Marca o ponto em que as cobranças individuais são compiladas em uma guia formal (como uma guia de honorários ou SADT). É um evento gerado pelo sistema que cria a fatura inicial. | ||
| Por que é importante Este é um marco importante que sinaliza a prontidão para faturar um pagador. É o ponto final para medir o atraso interno entre a cobrança e o faturamento. Onde obter Um evento explícito registrado nos logs de geração de guias. Procure o timestamp de criação do registro da guia principal associado ao atendimento. Captura Event registrado na criação do registro da guia de faturamento. Tipo de evento explicit | |||
| Pagamento Lançado | Representa a aplicação do pagamento recebido da operadora aos itens correspondentes na conta do paciente. É uma transação financeira registrada por usuário ou processo automático. | ||
| Por que é importante A eficiência no lançamento de pagamentos afeta a precisão das contas a receber. Atrasos aqui podem distorcer o cenário financeiro e atrasar faturamentos secundários. Onde obter Encontrado nas tabelas de transação de pagamento. Cada lançamento terá um ID de transação único e um timestamp associado. Captura Uma transação financeira é registrada quando o pagamento é aplicado à conta. Tipo de evento explicit | |||
| Atividade de Cobrança Iniciada | Indica que a conta do paciente foi movida para um processo de cobrança por falta de pagamento. Geralmente é capturado por uma mudança na classe financeira ou status da conta. | ||
| Por que é importante Esta é uma etapa crítica para gerir dívidas incobráveis. Analisar o que leva a esse estágio e sua taxa de sucesso é vital para a saúde financeira. Onde obter Inferido a partir de uma mudança no campo de status da conta para 'Cobrança' ou 'Dívida Ativa'. Esta alteração deve ter um timestamp associado. Captura Inferido a partir de uma mudança no status da conta para 'Cobrança' ou estado similar. Tipo de evento inferred | |||
| Conta Ajustada | Representa um ajuste financeiro no saldo da conta, como uma margem contratual, uma baixa ou um desconto. Cada ajuste é uma transação financeira separada. | ||
| Por que é importante Ajustes afetam diretamente a receita. Analisar sua frequência, tipo e valor ajuda a identificar perdas de receita e imprecisões no faturamento. Onde obter Encontrado nas tabelas de transações financeiras. Cada ajuste é registrado como um item separado com um código de transação e timestamp específicos. Captura Uma transação financeira é registrada com um código de ajuste específico. Tipo de evento explicit | |||
| Demonstrativo do Paciente Enviado | Marca o evento onde a fatura da responsabilidade residual do paciente é gerada e enviada. É uma ação explícita registrada pelo módulo de faturamento do paciente. | ||
| Por que é importante Isso inicia a parte do pagamento do paciente no ciclo de receita. Rastrear isso ajuda a analisar a eficácia das cobranças aos pacientes. Onde obter Obtido a partir dos registros de faturamento ou correspondência do paciente. O sistema deve registrar a data em que cada extrato foi gerado ou enviado. Captura Event registrado quando o demonstrativo do paciente é gerado e impresso ou enviado eletronicamente. Tipo de evento explicit | |||
| Glosa Recebida | Marca o evento onde a operadora rejeitou uma guia ou itens específicos. Este evento costuma ser inferido dos códigos de glosa presentes nos dados de remessa. | ||
| Por que é importante Rastrear glosas é essencial para identificar as causas raiz, como erros de codificação ou problemas de elegibilidade, e melhorar a taxa de faturamento limpo. Onde obter Inferido a partir dos dados de remessa (ERA/835). Quando uma conta ou item tem um valor de glosa diferente de zero e um código de motivo correspondente, este event é disparado. Captura Inferido a partir de dados de remessa que contêm códigos de motivo de glosa (CARCs/RARCs). Tipo de evento inferred | |||
| Guia Corrigida Enviada | Representa o envio de uma guia revisada ou corrigida para a operadora, geralmente após uma glosa ou pedido de mais informações. Identificado por um novo envio com indicador de correção. | ||
| Por que é importante Esta atividade é parte essencial do loop de retrabalho na gestão de glosas. Uma frequência alta indica problemas na precisão inicial da fatura. Onde obter Capturado dos logs de envio de guias. Procure por um novo envio para um atendimento existente, geralmente marcado com um código de reapresentação ou número de iteração superior. Captura Event registrado para uma reapresentação de guia, geralmente identificável por um código de tipo de frequência de guia específico. Tipo de evento explicit | |||
| Itens Capturados | Representa a entrada de serviços ou itens faturáveis na conta do paciente. Pode ocorrer automaticamente via sistemas clínicos ou por lançamento manual. | ||
| Por que é importante Esta atividade é crítica para medir o 'atraso na cobrança', o tempo entre a prestação do serviço e o início do faturamento, o que impacta diretamente o fluxo de caixa e a integridade da receita. Onde obter Capturado das tabelas de transação de cobrança, identificado pelo timestamp de criação de cada item. No Oracle Health, isso costuma estar em tabelas relacionadas a 'charges'. Captura Entrada de log de transação criada para cada nova cobrança. Tipo de evento explicit | |||
| Itens Codificados | Representa o processo onde a codificação médica atribui códigos padronizados (como TUSS, CID-10) aos itens capturados. Geralmente rastreado por mudança de status. | ||
| Por que é importante Atrasos na codificação são um gargalo comum. Rastrear essa atividade ajuda a identificar ineficiências no workflow de codificação e seu impacto nos prazos de faturamento. Onde obter Frequentemente inferido por uma mudança de status no atendimento ou lote de cobrança, por exemplo, de 'Não Codificado' para 'Codificado'. Exige um timestamp para essa mudança. Captura Inferido a partir da mudança no status do atendimento ou da cobrança para 'Codificado' ou 'Pronto para Faturamento'. Tipo de evento inferred | |||
| Recurso de Glosa Realizado | Uma ação de usuário ou sistema indicando que uma glosa está sendo contestada. Geralmente é capturada como uma atualização de status ou uma tarefa específica em uma fila de trabalho. | ||
| Por que é importante Esta atividade inicia um loop de retrabalho. Analisar a frequência e a taxa de sucesso dos recursos é fundamental para otimizar os esforços de recuperação de receita. Onde obter Isso pode ser um evento explícito iniciado pelo usuário ou inferido de uma mudança de status na fatura, como 'Em Recurso' ou 'Em Revisão'. Captura Uma mudança de status ou evento registrado quando um usuário inicia o processo de recurso para uma guia glosada. Tipo de evento explicit | |||
| Remessa Recebida | Indica o recebimento de uma remessa eletrônica (ERA) ou uma Explicação de Benefícios (EOB) em papel. Este documento detalha quais itens foram pagos, glosados ou ajustados. | ||
| Por que é importante Esta é a primeira resposta do pagador e é crucial para entender a velocidade do pagamento e identificar tendências de glosa precocemente. Onde obter Registrado no módulo de processamento de remessa. Procure pelo timestamp de importação ou criação do arquivo ERA (como um arquivo 835) vinculado à guia. Captura Event registrado no momento da importação e processamento do arquivo de remessa da operadora (ex: ANSI 835). Tipo de evento explicit | |||
Guias de Extração
Etapas
- Solicitar Acesso ao Banco de Dados: Obtenha credenciais de apenas leitura para o banco de dados do Oracle Health Revenue Cycle. Você precisará de acesso aos esquemas que contêm dados de pacientes, atendimentos, faturamento e transações financeiras. Isso geralmente requer aprovação das equipes de segurança de TI e administração de banco de dados.
- Identificar Nomes de Esquemas e Tabelas: Trabalhe com um administrador de banco de dados ou analista de sistemas para confirmar os nomes exatos de esquemas e tabelas da sua instância Oracle Health. Os nomes fornecidos na consulta são placeholders e devem ser mapeados para o seu ambiente específico.
- Instalar um Cliente SQL: Instale um cliente SQL compatível, como Oracle SQL Developer ou DBeaver, em sua estação de trabalho. Essa ferramenta será usada para conectar ao banco de dados e executar o script de extração.
- Estabelecer Conexão com o Banco de Dados: Configure uma nova conexão em seu cliente SQL usando o host, porta, nome do serviço e credenciais fornecidos. Teste a conexão para garantir que ela funcione.
- Personalizar a Consulta SQL: Copie o script SQL fornecido para uma nova janela do editor de consultas. Localize os valores de placeholder, como
[START_DATE]e[END_DATE], e substitua-os pelo intervalo de datas desejado para sua análise (ex: '2023-01-01'). Ajuste as condições de filtro conforme suas necessidades, como filtrar por uma Classe de Paciente específica. - Executar o Script de Extração: Execute o script SQL personalizado. A consulta foi projetada para ser abrangente e pode levar de alguns minutos a horas para ser concluída, dependendo do intervalo de datas e do tamanho do seu banco de dados.
- Revisar Resultados Iniciais: Quando a consulta terminar, revise as primeiras centenas de linhas na grade de resultados. Verifique se há erros óbvios, como colunas totalmente nulas ou formatos de dados incorretos, para garantir que o script rodou corretamente.
- Exportar Dados para CSV: Exporte todo o conjunto de resultados para um arquivo CSV. Use a codificação UTF-8 para evitar problemas com caracteres especiais. Certifique-se de que o arquivo inclua uma linha de cabeçalho com os nomes das colunas especificados nos aliases da query (ex: "BillingEvent", "ActivityName").
- Preparar para o Upload: Antes de carregar em uma ferramenta de Process Mining, abra o arquivo CSV para confirmar sua integridade. Verifique se o formato do timestamp está consistente e se os cabeçalhos das colunas correspondem exatamente aos atributos exigidos. O arquivo agora está pronto para o upload.
Configuração
- Intervalo de Datas: A consulta utiliza os placeholders
[START_DATE]e[END_DATE]. É fundamental definir um intervalo de datas razoável para controlar o volume de dados. Recomendamos um período de 3 a 6 meses para a análise inicial. - Filtragem: O conjunto de dados inicial é filtrado pela data de registro do atendimento (
reg_dt_tm) na seçãoRelevantEncounters. Você pode adicionar outras cláusulasWHEREnesta seção para refinar o escopo, comoe.patient_class_code IN ('INPATIENT', 'OUTPATIENT'), para focar em tipos específicos de atendimento. - Desempenho: Consultas diretas no banco de dados de produção podem afetar a performance. Recomendamos executar esta extração em horários de baixo movimento ou em uma réplica de leitura do banco de dados, se disponível.
- Pré-requisitos: Este método exige uma conta de usuário com privilégios de
SELECTem todas as tabelas referenciadas. Isso inclui as tabelas de atendimentos, faturamento, cobranças (charges), contas (claims), remessas e transações financeiras. - Mapeamento de Tabelas e Colunas: O script fornecido usa nomes representativos para tabelas e colunas. Você deve validar e mapear esses nomes para os termos reais no esquema do banco de dados Oracle Health da sua organização. Por exemplo, a tabela
FINANCIAL_TRANSACTIONpode se chamarAR_TRANSACTIONSno seu sistema.
a Consulta de Exemplo sql
WITH RelevantEncounters AS (
SELECT
e.billing_event_id
FROM ENCOUNTER e
WHERE e.reg_dt_tm BETWEEN TO_DATE('[START_DATE]', 'YYYY-MM-DD') AND TO_DATE('[END_DATE]', 'YYYY-MM-DD')
)
SELECT
e.billing_event_id AS "BillingEvent",
'Patient Encounter Created' AS "ActivityName",
e.reg_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
e.total_account_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM ENCOUNTER e
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON e.reg_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON e.reg_facility_org_id = org.organization_id
LEFT JOIN PAYER pyr ON e.primary_payer_id = pyr.payer_id
UNION ALL
SELECT
cd.billing_event_id AS "BillingEvent",
'Charges Captured' AS "ActivityName",
cd.charge_entry_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
cd.charge_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM CHARGE_DETAIL cd
JOIN ENCOUNTER e ON cd.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON cd.entry_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON cd.performing_dept_org_id = org.organization_id
LEFT JOIN PAYER pyr ON e.primary_payer_id = pyr.payer_id
UNION ALL
SELECT
ch.billing_event_id AS "BillingEvent",
'Charges Coded' AS "ActivityName",
ch.coded_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
e.total_account_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM CODING_HISTORY ch
JOIN ENCOUNTER e ON ch.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON ch.coder_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON p.default_org_id = org.organization_id
LEFT JOIN PAYER pyr ON e.primary_payer_id = pyr.payer_id
UNION ALL
SELECT
cl.billing_event_id AS "BillingEvent",
'Claim Generated' AS "ActivityName",
cl.create_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
cl.claim_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM CLAIM cl
JOIN ENCOUNTER e ON cl.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON cl.create_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON cl.billing_entity_org_id = org.organization_id
LEFT JOIN PAYER pyr ON cl.payer_id = pyr.payer_id
UNION ALL
SELECT
csl.billing_event_id AS "BillingEvent",
'Claim Submitted To Payer' AS "ActivityName",
csl.submission_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
cl.claim_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM CLAIM_SUBMISSION_LOG csl
JOIN CLAIM cl ON csl.claim_id = cl.claim_id
JOIN ENCOUNTER e ON cl.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON csl.submit_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON cl.billing_entity_org_id = org.organization_id
LEFT JOIN PAYER pyr ON cl.payer_id = pyr.payer_id
WHERE csl.submission_type = 'INITIAL'
UNION ALL
SELECT
ra.billing_event_id AS "BillingEvent",
'Remittance Received' AS "ActivityName",
ra.remit_received_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
e.total_account_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM REMITTANCE_ADVICE ra
JOIN ENCOUNTER e ON ra.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON ra.processed_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON ra.processing_org_id = org.organization_id
LEFT JOIN PAYER pyr ON ra.payer_id = pyr.payer_id
UNION ALL
SELECT
ft.billing_event_id AS "BillingEvent",
'Payment Posted' AS "ActivityName",
ft.transaction_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
ft.ending_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM FINANCIAL_TRANSACTION ft
JOIN ENCOUNTER e ON ft.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON ft.post_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON ft.post_dept_org_id = org.organization_id
LEFT JOIN PAYER pyr ON ft.payer_id = pyr.payer_id
WHERE ft.transaction_type_code = 'PAYMENT'
UNION ALL
SELECT
rd.billing_event_id AS "BillingEvent",
'Denial Received' AS "ActivityName",
ra.remit_received_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
e.total_account_balance AS "OutstandingBalance",
rd.denial_reason_code AS "DenialReasonCode"
FROM REMITTANCE_DETAIL rd
JOIN REMITTANCE_ADVICE ra ON rd.remit_id = ra.remit_id
JOIN ENCOUNTER e ON ra.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON ra.processed_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON ra.processing_org_id = org.organization_id
LEFT JOIN PAYER pyr ON ra.payer_id = pyr.payer_id
WHERE rd.denial_reason_code IS NOT NULL
UNION ALL
SELECT
at.billing_event_id AS "BillingEvent",
'Denial Appealed' AS "ActivityName",
at.appeal_filed_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
e.total_account_balance AS "OutstandingBalance",
at.related_denial_code AS "DenialReasonCode"
FROM APPEAL_TRACKING at
JOIN ENCOUNTER e ON at.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON at.appeal_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON p.default_org_id = org.organization_id
LEFT JOIN PAYER pyr ON at.payer_id = pyr.payer_id
UNION ALL
SELECT
csl.billing_event_id AS "BillingEvent",
'Corrected Claim Submitted' AS "ActivityName",
csl.submission_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
cl.claim_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM CLAIM_SUBMISSION_LOG csl
JOIN CLAIM cl ON csl.claim_id = cl.claim_id
JOIN ENCOUNTER e ON cl.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON csl.submit_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON cl.billing_entity_org_id = org.organization_id
LEFT JOIN PAYER pyr ON cl.payer_id = pyr.payer_id
WHERE csl.submission_type = 'CORRECTED'
UNION ALL
SELECT
psl.billing_event_id AS "BillingEvent",
'Patient Statement Sent' AS "ActivityName",
psl.statement_sent_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
NULL AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
psl.statement_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM PATIENT_STATEMENT_LOG psl
JOIN ENCOUNTER e ON psl.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON psl.sent_by_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON p.default_org_id = org.organization_id
UNION ALL
SELECT
ash.billing_event_id AS "BillingEvent",
'Collection Activity Started' AS "ActivityName",
ash.status_change_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
NULL AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
ash.account_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM ACCOUNT_STATUS_HISTORY ash
JOIN ENCOUNTER e ON ash.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON ash.change_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON ash.responsible_org_id = org.organization_id
WHERE ash.new_status_code = 'COLLECTIONS'
UNION ALL
SELECT
ft.billing_event_id AS "BillingEvent",
'Account Adjusted' AS "ActivityName",
ft.transaction_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
ft.transaction_amount AS "AdjustmentAmount",
ft.ending_balance AS "OutstandingBalance",
ft.adjustment_reason_code AS "DenialReasonCode"
FROM FINANCIAL_TRANSACTION ft
JOIN ENCOUNTER e ON ft.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON ft.post_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON ft.post_dept_org_id = org.organization_id
LEFT JOIN PAYER pyr ON ft.payer_id = pyr.payer_id
WHERE ft.transaction_type_code = 'ADJUSTMENT'
UNION ALL
SELECT
e.billing_event_id AS "BillingEvent",
'Account Closed' AS "ActivityName",
e.account_closed_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
NULL AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
0 AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM ENCOUNTER e
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON e.closed_by_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON e.reg_facility_org_id = org.organization_id
WHERE e.total_account_balance = 0 AND e.account_closed_dt_tm IS NOT NULL;