Seu Template de dados para gestão do ciclo de receita
Seu Template de dados para gestão do ciclo de receita
- Atributos recomendados para coleta
- Principais atividades para acompanhar
- Orientações para extração no Oracle Health Revenue Cycle
Atributos da gestão do ciclo de receita
| Nome | Descrição | ||
|---|---|---|---|
| Data e hora do evento EventTimestamp | Data e hora exatas em que uma atividade foi registrada no sistema. | ||
| Descrição Esse atributo registra a data e a hora de cada atividade, indicando o momento exato em que ela ocorreu. É essencial para entender o momento e a sequência dos eventos no ciclo de receitas de um evento de faturamento específico. Na análise, a data e a hora do evento são usadas para ordenar as atividades cronologicamente, calcular durações e tempos de ciclo entre etapas e realizar análises de gargalos. Esse atributo é a base de todas as métricas de Process Mining relacionadas ao tempo, como a identificação de atrasos entre 'Reivindicação enviada' e 'Remessa recebida'. Por que isso importa Esse registro de data e hora é essencial para ordenar os eventos, calcular métricas de performance, como tempos de ciclo e durações, e identificar gargalos no processo. Onde encontrar Cada tabela de transações ou de registros de eventos do Oracle Health Revenue Cycle deve ter uma coluna de data e hora que indique quando o registro foi criado ou quando o evento ocorreu. Exemplos 2023-04-15T09:00:00Z2023-04-18T14:30:00Z2023-05-02T11:25:10Z | |||
| Evento de faturamento BillingEvent | Identificador exclusivo de uma prestação de serviço ou entrega de produto que gera uma cobrança e identifica o caso no processo do ciclo de receitas. | ||
| Descrição O evento de faturamento funciona como o principal identificador do caso, vinculando todas as atividades, do registro da cobrança ao encerramento da conta, para um item faturável específico. Cada evento de faturamento representa uma ocorrência única do processo do ciclo de receitas e permite acompanhar todo o percurso por etapas como envio da reivindicação, lançamento do pagamento e possíveis negativas ou ajustes. Na análise de Process Mining, esse atributo é fundamental para reconstruir o fluxo do processo de ponta a ponta. Ele permite visualizar as variantes do processo, calcular os tempos de ciclo entre atividades e identificar gargalos ou desvios associados a eventos de faturamento específicos. Por que isso importa Essa é a chave essencial para acompanhar todo o ciclo de vida de um serviço faturável e viabilizar a análise do fluxo do processo e a medição da performance. Onde encontrar Esse identificador deve ser uma chave exclusiva presente nas principais tabelas de faturamento ou de transações de cobrança do Oracle Health Revenue Cycle. Consulte a documentação do sistema para identificar a chave primária dos eventos de cobrança. Exemplos BEVNT-987654321BEVNT-987654322BEVNT-987654323 | |||
| Nome da atividade ActivityName | Nome da etapa ou do evento específico ocorrido no processo do ciclo de receitas. | ||
| Descrição Esse atributo registra o nome de cada atividade realizada durante o ciclo de vida de um evento de faturamento. Alguns exemplos são 'Cobranças registradas', 'Reivindicação enviada ao pagador' e 'Pagamento lançado'. Essas atividades formam os nós do mapa de processos descoberto. Analisar a sequência e a frequência das atividades é a base de Process Mining. Esse atributo ajuda a identificar os caminhos mais comuns do processo, descobrir desvios do procedimento padrão e entender o fluxo operacional do ciclo de receitas. Por que isso importa Define as etapas do processo, permitindo visualizar o mapa de processos e analisar os padrões do fluxo de trabalho. Onde encontrar Geralmente, é obtido dos registros de eventos, dos registros de mudanças de status ou de tabelas de transações específicas associadas às diferentes etapas do ciclo de receitas no Oracle Health. Exemplos Reivindicação geradaRemessa recebidaNegativa contestadaConta encerrada | |||
| Classe do paciente PatientClass | Classificação do atendimento do paciente, como internação ou atendimento ambulatorial. | ||
| Descrição Esse atributo classifica o tipo de consulta ou atendimento que gerou a cobrança. As classificações comuns incluem internação, atendimento ambulatorial, emergência e atendimento recorrente. A classe do paciente costuma determinar todo o processo de faturamento e envio de reivindicações. Cada classe de paciente segue caminhos de processo distintos e tem requisitos de conformidade próprios. Analisar o processo com base nesse atributo ajuda a entender essas diferenças, direcionar iniciativas de melhoria e garantir que os procedimentos corretos sejam seguidos em cada classe. Por que isso importa Separa fluxos de processo distintos, como internação e atendimento ambulatorial, que têm diferentes níveis de complexidade, prazos e requisitos de faturamento. Onde encontrar Esse é um campo padrão associado a um atendimento ou registro de admissão de paciente no Oracle Health. Exemplos InternaçãoAtendimento ambulatorialEmergencialRecorrente | |||
| Código do motivo da negativa DenialReasonCode | Código padronizado que indica por que a operadora negou uma solicitação de reembolso. | ||
| Descrição Quando uma operadora nega uma solicitação de reembolso, ela informa um código que explica o motivo, como "Serviço não coberto" ou "Solicitação duplicada". Este atributo registra o código e a descrição correspondente. Analisar os motivos das negativas é fundamental para melhorar o ciclo de receita. Isso permite que a organização identifique padrões recorrentes, como problemas de codificação ou de elegibilidade do paciente, e implemente ações corretivas para evitar novas negativas. Isso afeta diretamente a taxa de solicitações sem erros e reduz o custo do retrabalho. Por que isso importa Aponta a causa raiz das negativas de solicitações, permitindo melhorias direcionadas para aumentar a taxa de solicitações sem erros e acelerar o recebimento da receita. Onde encontrar Essas informações são recebidas da operadora no aviso eletrônico de pagamento (arquivo ANSI 835) e devem ser armazenadas nas tabelas de solicitações ou de remessas do Oracle Health. Exemplos CO-16: Faltam informações necessárias para analisar a solicitação de serviço.PR-96: Cobrança(s) por serviço não coberto.CO-18: Solicitação de serviço duplicada. | |||
| Departamento de faturamento BillingDepartment | Departamento ou equipe funcional responsável pela atividade. | ||
| Descrição Esse atributo especifica o departamento, como 'Registro de cobranças', 'Codificação' ou 'Cobrança', que realizou a atividade. Ele fornece contexto organizacional ao fluxo do processo. Analisar o processo por departamento é essencial para entender as transferências entre equipes e identificar ineficiências entre áreas. Esse atributo também dá suporte ao Dashboard 'Carga de trabalho do departamento de faturamento', permitindo agrupar atividades e métricas de performance por departamento. Por que isso importa Atribui atividades às unidades organizacionais, o que é essencial para analisar as transferências entre departamentos, a carga de trabalho e a performance das equipes. Onde encontrar Essas informações podem estar armazenadas diretamente nos dados do perfil do usuário no Oracle Health ou ser inferidas com base no usuário ou no tipo de atividade. Exemplos Acesso do pacienteCodificaçãoFaturamentoCobrança | |||
| Nome do pagador PayerName | Nome da seguradora ou do pagador terceirizado responsável pelo pagamento. | ||
| Descrição Esse atributo identifica a entidade, como uma seguradora ou um programa governamental como o Medicare, para a qual o serviço é faturado. As informações do pagador são fundamentais para analisar o ciclo de receitas. Analisar o processo por pagador pode revelar diferenças importantes nos prazos de pagamento, nas taxas de negativas e nas taxas de sucesso das contestações. Isso ajuda a identificar pagadores problemáticos que causam atrasos ou perdas de receita e é essencial para gerenciar contratos e relacionamentos com pagadores. Por que isso importa Permite segmentar o processo por pagador e identificar diferenças de comportamento, taxas de negativas e velocidade dos pagamentos, aspectos essenciais para a performance financeira. Onde encontrar Essas informações ficam armazenadas nos registros de faturamento ou de seguro do paciente no Oracle Health Revenue Cycle. Exemplos AetnaBlue Cross Blue ShieldUnitedHealthcareMedicareCigna | |||
| Saldo em aberto OutstandingBalance | O saldo ainda não pago do evento de cobrança em determinado momento. | ||
| Descrição Este atributo mostra o valor atualmente devido por um evento de cobrança, após a aplicação de todos os pagamentos e ajustes. Ele representa o contas a receber ativo daquela cobrança específica. Este atributo é essencial para o Dashboard "Envelhecimento do saldo em aberto". Analisar esse valor ao longo do tempo ajuda a acompanhar a velocidade do fluxo de caixa, avaliar a eficácia dos esforços de cobrança e calcular KPIs financeiros importantes, como o Prazo médio de recebimento de vendas (DSO). Por que isso importa Acompanha o contas a receber atual de cada caso, essencial para gerenciar o fluxo de caixa e analisar a eficácia das cobranças. Onde encontrar Esse valor costuma ser calculado pela soma de todas as transações financeiras (cobranças, pagamentos e ajustes) de um evento de cobrança. Também pode existir como campo em uma tabela de resumo da conta. Exemplos 75.000.00550.80 | |||
| Usuário UserPerformingAction | ID ou nome do usuário que realizou a atividade. | ||
| Descrição Esse atributo identifica o funcionário ou usuário do sistema automatizado responsável por realizar uma atividade específica do processo. É essencial para entender a distribuição da carga de trabalho, a performance dos recursos e as necessidades de treinamento. Na análise, esse atributo permite filtrar o mapa de processos por usuário ou equipe, comparar a performance de diferentes recursos e analisar a carga de trabalho no Dashboard 'Carga de trabalho do departamento de faturamento'. Ele pode ajudar a identificar quem tem melhor performance e quem pode precisar de mais apoio ou treinamento. Por que isso importa Vincula as atividades do processo a usuários ou equipes específicos, permitindo analisar a carga de trabalho, comparar a performance e identificar oportunidades de treinamento. Onde encontrar Os campos de ID do usuário (por exemplo, 'CREATED_BY', 'USER_ID') geralmente estão presentes nas tabelas de transações dos módulos do Oracle Health. Exemplos j.doeasmithBillingBot_AUTOk.williams | |||
| Valor do ajuste AdjustmentAmount | O valor monetário de qualquer ajuste feito no saldo da conta. | ||
| Descrição Este atributo registra o valor de qualquer ajuste financeiro, como abatimentos contratuais, baixas ou correções, aplicado ao evento de cobrança. Os ajustes reduzem diretamente a receita esperada de uma cobrança. O Dashboard "Impacto dos ajustes na conta" depende bastante deste atributo. Analisar os valores dos ajustes e os motivos associados ajuda a identificar fontes de perda de receita, problemas na gestão de contratos ou falhas no processo inicial de registro das cobranças. É uma métrica importante para a saúde financeira. Por que isso importa Quantifica a perda de receita causada por baixas ou correções, ajudando a identificar e tratar as causas raiz da erosão financeira. Onde encontrar Encontrado nas tabelas de transações financeiras que registram ajustes ou baixas na conta do paciente. Exemplos -50.25-120.0025.00 | |||
| É automatizada IsAutomated | Indicador que informa se a atividade foi realizada por um sistema automatizado ou por uma pessoa. | ||
| Descrição Este atributo booleano diferencia as atividades executadas por automações de software, como bots ou rotinas em lote do sistema, daquelas realizadas manualmente por uma pessoa. Por exemplo, "Solicitação gerada" pode ser uma etapa automatizada, enquanto "Recurso contra negativa enviado" 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. Ele pode ser usado para comparar a performance dos fluxos automatizados e manuais e identificar oportunidades de ampliar a automação. Por que isso importa Diferencia atividades realizadas por pessoas daquelas executadas pelo sistema, algo essencial para analisar a eficácia da automação e identificar novas oportunidades de automatização. Onde encontrar Normalmente, este atributo é derivado do atributo UserPerformingAction. Por exemplo, atividades realizadas por IDs de usuário como "SYSTEM" ou "RPA_BOT" são marcadas como automatizadas. Exemplos truefalse | |||
| É retrabalho IsRework | Indicador que identifica atividades que representam retrabalho ou esforço repetido. | ||
| Descrição Este atributo calculado marca atividades que indicam um desvio do "Caminho ideal" e representam retrabalho. Alguns exemplos são "Solicitação corrigida e enviada" ou "Recurso contra negativa enviado", etapas que não ocorreriam se o processo tivesse funcionado perfeitamente na primeira vez. Identificar e quantificar o retrabalho é um dos principais objetivos do Process Mining. Este indicador facilita a filtragem e a análise de todos os ciclos de retrabalho, ajudando a medir a frequência, o custo e as causas das ineficiências do processo. É essencial para entender o custo real da qualidade no ciclo de receita. Por que isso importa Ajuda a quantificar a frequência e o impacto dos ciclos de retrabalho, destacando ineficiências do processo e o custo da baixa qualidade. Onde encontrar Este atributo é derivado. Ele é calculado durante a transformação dos dados, aplicando regras de negócio que marcam atividades específicas como retrabalho. Exemplos truefalse | |||
| Horário de término do evento EventEndTime | Data e hora que indicam a conclusão de uma atividade, quando disponíveis. | ||
| Descrição Enquanto StartTime indica o início de uma atividade, EventEndTime indica sua conclusão. Nem todas as atividades têm um horário de término específico, pois muitas são eventos instantâneos. No entanto, esse campo é muito útil para atividades com duração, como 'Negativa contestada', que pode levar algum tempo para ser processada. Esse atributo permite calcular com mais precisão o tempo de processamento de cada atividade. Ele ajuda a diferenciar o tempo de espera, ou seja, o intervalo entre atividades, do tempo de processamento, isto é, o tempo dedicado a uma atividade. Por que isso importa Permite calcular diretamente quanto tempo uma atividade leva para ser concluída, separando o tempo de processamento do tempo de espera. Onde encontrar Algumas tabelas de transações do Oracle Health Revenue Cycle podem incluir as datas e horas de início e término de tarefas específicas e demoradas. Exemplos 2023-04-15T09:05:14Z2023-04-18T16:00:00Z | |||
| ID da solicitação ClaimId | Identificador único da solicitação de reembolso enviada à operadora. | ||
| Descrição Este atributo é o ID único atribuído a uma solicitação gerada e enviada à operadora para reembolso. Um único evento de cobrança pode gerar uma ou mais solicitações ao longo do ciclo, por exemplo, quando é necessário fazer uma correção. O ID da solicitação permite rastrear um envio específico à operadora e vinculá-lo diretamente à resposta, como um pagamento ou uma negativa. Assim, o acompanhamento fica mais detalhado dentro do processo mais amplo do ciclo de receita. Por que isso importa Fornece um identificador específico para acompanhar o percurso de uma solicitação junto à operadora, com mais detalhes do que o evento de cobrança geral. Onde encontrar O Oracle Health gera este ID quando uma solicitação é criada e o armazena na tabela principal de solicitações. Exemplos CLM-2023-55489CLM-2023-55490CLM-2023-55491-C1 | |||
| ID do paciente PatientId | Identificador único do paciente associado ao evento de cobrança. | ||
| Descrição Este atributo é o identificador único do paciente que recebeu o serviço, geralmente chamado de número do prontuário médico (MRN). Ele vincula a transação financeira a uma pessoa específica. Embora não seja o ID do caso do processo, o ID do paciente é útil para agrupar todos os eventos de cobrança de uma pessoa e entender toda a sua trajetória financeira. Se combinado com os dados mestres dos pacientes, também permite segmentar os dados por características demográficas ou histórico. Por que isso importa Vincula eventos financeiros a um paciente específico, permitindo análises centradas no paciente e a consolidação de todas as atividades de cobrança relacionadas a ele. Onde encontrar Este identificador é um elemento central do registro mestre do paciente e estará presente em todas as tabelas de transações relacionadas, como cobranças, solicitações e pagamentos. Exemplos MRN-1002345MRN-1002346MRN-1002347 | |||
| Motivo da contestação DisputeReason | O motivo informado pelo cliente ou paciente para contestar uma fatura ou cobrança. | ||
| Descrição Este atributo registra por que um paciente ou outra parte responsável contestou uma conta. Os motivos podem incluir cobranças incorretas, serviços não prestados ou problemas no processamento do plano de saúde. Essas informações são essenciais para o Dashboard "Métricas de resolução de contestações de faturas". Entender os motivos mais comuns das contestações ajuda a identificar problemas sistêmicos no registro de cobranças, na codificação ou no faturamento. Tratar essas causas raiz pode reduzir significativamente a taxa de contestações e o esforço administrativo necessário para resolvê-las. Por que isso importa Explica por que as faturas estão sendo contestadas e revela problemas na precisão ou na clareza do faturamento que precisam ser corrigidos. Onde encontrar Essas informações provavelmente ficam em um módulo de gestão de casos ou atendimento ao cliente do Oracle Health, vinculado à conta do paciente. Exemplos Serviço cobrado incorretamenteCobrança duplicadaCobrança incorreta ao plano de saúdeServiço não prestado | |||
| Sistema de origem SourceSystem | Sistema do qual os dados do evento foram extraídos. | ||
| Descrição Esse atributo identifica o aplicativo ou módulo de origem dos dados. Neste processo, normalmente será 'Oracle Health Revenue Cycle', mas também poderá indicar diferentes módulos do sistema se os dados vierem de várias fontes. Essa informação é útil para a governança de dados e a solução de problemas. Ela ajuda a confirmar a linhagem dos dados e é importante em ambientes nos quais vários sistemas contribuem para um único processo de ponta a ponta. Por que isso importa Fornece contexto sobre a origem dos dados, essencial para validar e governar os dados e entender variações do processo que podem depender do sistema. Onde encontrar Geralmente, é um valor estático adicionado durante o processo de extração, transformação e carregamento (ETL) para identificar a origem do conjunto de dados. Exemplos OracleHealth-RCMOracleHealth-CernerOH-RevCycle-PROD | |||
| Última atualização dos dados LastDataUpdate | Data e hora que indicam a última atualização ou extração dos dados deste evento. | ||
| Descrição Esse atributo mostra quando o conjunto de dados foi atualizado pela última vez. Ele informa o nível de atualização dos dados analisados, o que é importante para entender a atualidade dos insights obtidos com a análise de Process Mining. Você pode consultar esse atributo para confirmar se está visualizando as informações mais recentes do processo. Ele ajuda a alinhar as expectativas sobre a atualização dos dados e é um componente importante da governança e da garantia da qualidade dos dados. Por que isso importa Indica o nível de atualização dos dados, garantindo que as análises e decisões se baseiem em informações atualizadas. Onde encontrar Esse campo de metadados geralmente é 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 bruto cobrado pelo serviço ou produto. | ||
| Descrição Este atributo representa o valor inicial, sem descontos, cobrado por um serviço antes da aplicação de ajustes, abatimentos contratuais ou pagamentos. É o valor financeiro de partida do evento de cobrança. Acompanhar o valor da cobrança é essencial para análises financeiras, como calcular o valor total dos serviços prestados e entender o impacto financeiro de ajustes ou baixas posteriores. Ele serve como referência para medir a realização da receita. Por que isso importa Define o valor financeiro inicial do caso, fundamental para todas as análises financeiras e avaliações de impacto posteriores. Onde encontrar Localizado nas tabelas de detalhes de cobrança ou de transações de cobrança do Oracle Health. Exemplos 150.001250.7585.50 | |||
Atividades da gestão do ciclo de receita
| Atividade | Descrição | ||
|---|---|---|---|
| Atendimento do paciente criado | Indica a criação de uma conta de paciente para uma consulta ou serviço específico. Em geral, é um evento explícito, acionado pelo sistema de registro ou por um feed de admissão, alta e transferência (ADT). | ||
| Por que isso importa Esse evento marca o início de todo o ciclo de receitas de um evento de faturamento e permite analisar a duração total do processo e a precisão do registro. Onde encontrar Os dados vêm dos registros do módulo de registro de pacientes ou ADT. Procure eventos de criação de atendimento ou o registro de data e hora mais antigo associado ao atendimento ou ao número financeiro. Coleta Evento registrado no momento do registro ou da admissão do paciente. Tipo de evento explicit | |||
| Conta encerrada | Atividade final, que indica que o saldo da conta é zero e não são esperadas novas movimentações. Muitas vezes, isso é inferido quando o saldo da conta chega a zero. | ||
| Por que isso importa Indica a conclusão bem-sucedida do ciclo de receitas. O tempo até chegar a esse estado é uma medida importante da eficiência geral do processo. Onde encontrar Em geral, é inferido identificando a primeira vez em que o saldo em aberto da conta chega a zero e permanece zerado após todos os pagamentos e ajustes. Coleta Calculado quando o saldo da conta chega a zero pela primeira vez, após o lançamento de todas as cobranças e pagamentos. Tipo de evento calculated | |||
| Pagamento lançado | Representa a aplicação do pagamento recebido do pagador às cobranças correspondentes na conta do paciente. Essa transação financeira é registrada por um usuário ou por um processo automatizado. | ||
| Por que isso importa A eficiência no lançamento de pagamentos afeta a precisão das contas a receber. Atrasos nessa etapa podem distorcer a situação financeira e atrasar o faturamento secundário. Onde encontrar Encontrado nas tabelas de transações de pagamento. Cada lançamento de pagamento tem um ID de transação exclusivo e um registro de data e hora associado. Coleta Uma transação financeira é registrada quando o pagamento é aplicado à conta. Tipo de evento explicit | |||
| Reivindicação enviada ao pagador | Representa o envio eletrônico ou em papel da reivindicação gerada à seguradora ou ao pagador. O sistema deve registrar a data e a hora dessa transmissão. | ||
| Por que isso importa Essa atividade inicia a contagem do ciclo de pagamento. Analisar o tempo entre o envio e o pagamento é essencial para entender a performance do pagador e o prazo médio de recebimento de vendas (DSO). Onde encontrar Os dados vêm do módulo de gestão de reivindicações, que registra os eventos de transmissão. Procure o registro de data e hora do envio ou uma mudança de status para 'Enviada' no histórico da reivindicação. Coleta Evento registrado quando a reivindicação é transmitida com sucesso pela câmara de compensação. Tipo de evento explicit | |||
| Reivindicação gerada | Indica o momento em que as cobranças individuais são reunidas em uma reivindicação formal de pagamento, como um formulário UB-04 ou CMS-1500. Esse evento, gerado pelo sistema, cria a fatura inicial. | ||
| Por que isso importa Esse é um marco importante, pois indica que a cobrança está pronta para ser enviada ao pagador. É o ponto final usado para medir o intervalo interno entre o registro da cobrança e o faturamento. Onde encontrar Evento explícito registrado nos logs ou nas tabelas de geração de reivindicações. Procure o registro de data e hora de criação do registro principal da reivindicação associado ao atendimento. Coleta Evento registrado quando o registro da reivindicação é criado. Tipo de evento explicit | |||
| Cobrança iniciada | Indica que a conta do paciente foi encaminhada para cobrança por falta de pagamento. Em geral, isso é registrado por uma mudança na classificação financeira ou de status da conta. | ||
| Por que isso importa Essa é uma etapa crítica na gestão de dívidas não pagas. Analisar o que leva a essa etapa e sua taxa de sucesso é essencial para a saúde financeira. Onde encontrar Inferido a partir da mudança do campo de status da conta para 'Em cobrança' ou 'Dívida não paga'. Essa mudança de status deve ter um registro de data e hora associado. Coleta Inferido a partir da mudança do status da conta para 'Em cobrança' ou um estado semelhante. Tipo de evento inferred | |||
| Cobranças codificadas | Representa o processo em que os codificadores médicos atribuem códigos padronizados, como CPT ou ICD-10, às cobranças registradas. Em geral, isso é acompanhado por uma mudança de status da cobrança ou do atendimento. | ||
| Por que isso importa Atrasos na codificação são um gargalo comum. Acompanhar essa atividade ajuda a identificar ineficiências no fluxo de trabalho de codificação e seus efeitos nos prazos de faturamento. Onde encontrar Geralmente, é inferido a partir de uma mudança de status do atendimento do paciente ou do lote de cobranças, por exemplo, de 'Não codificado' para 'Codificado'. É necessário ter o registro de data e hora dessa mudança. Coleta Inferido a partir da mudança do status do atendimento ou da cobrança para 'Codificado' ou 'Pronto para faturar'. Tipo de evento inferred | |||
| Cobranças registradas | Representa o registro de serviços ou itens faturáveis na conta do paciente. Isso pode ocorrer automaticamente nos sistemas clínicos ou por meio de um lançamento manual feito pela equipe. | ||
| Por que isso importa Essa atividade é essencial para medir o atraso no registro das cobranças, ou seja, o tempo entre a prestação do serviço e o início do faturamento. Esse intervalo afeta diretamente o fluxo de caixa e a integridade das receitas. Onde encontrar Os dados são obtidos das tabelas de transações de cobrança, identificando-se o registro de data e hora de criação de cada item. No Oracle Health, essas informações costumam estar em tabelas relacionadas a cobranças. Coleta Registro de transação criado para cada nova cobrança. Tipo de evento explicit | |||
| Conta ajustada | Representa um ajuste financeiro no saldo da conta, como um abatimento contratual, uma baixa contábil ou um desconto. Cada ajuste é uma transação financeira individual. | ||
| Por que isso importa Os ajustes afetam diretamente as receitas. Analisar sua frequência, tipo e valor ajuda a identificar perdas de receita e imprecisões no faturamento. Onde encontrar Encontrado nas tabelas de transações financeiras. Cada ajuste é registrado como um item separado, com um código de transação específico e um registro de data e hora. Coleta Uma transação financeira é registrada com um código de ajuste específico. Tipo de evento explicit | |||
| Demonstrativo enviado ao paciente | Indica o momento em que uma cobrança pelo valor restante sob responsabilidade do paciente é gerada e enviada a ele. Essa ação explícita é registrada pelo módulo de faturamento de pacientes. | ||
| Por que isso importa Essa etapa inicia a parte do ciclo de receitas relacionada ao pagamento pelo paciente. Acompanhar esse evento ajuda a analisar a eficácia das cobranças feitas aos pacientes. Onde encontrar Os dados vêm dos registros de faturamento de pacientes ou de correspondências. O sistema deve registrar a data em que cada demonstrativo foi gerado ou enviado. Coleta Evento registrado quando um demonstrativo do paciente é gerado e impresso ou enviado eletronicamente. Tipo de evento explicit | |||
| Negativa contestada | Ação de um usuário ou do sistema que indica que uma reivindicação negada está sendo contestada. Em geral, isso é registrado como uma atualização de status ou como uma tarefa específica criada em uma fila de trabalho. | ||
| Por que isso importa Essa atividade inicia um ciclo de retrabalho. Analisar a frequência e a taxa de sucesso das contestações é essencial para otimizar a recuperação de receitas. Onde encontrar Pode ser um evento explícito iniciado por um usuário ou ser inferido a partir de uma mudança de status da reivindicação, como 'Contestada' ou 'Em análise'. Coleta Mudança de status ou evento registrado quando um usuário inicia a contestação de uma reivindicação negada. Tipo de evento explicit | |||
| Negativa recebida | Indica que o pagador rejeitou uma reivindicação ou itens específicos, conforme informado no aviso de remessa. Muitas vezes, esse evento é inferido a partir dos códigos de negativa presentes nos dados da remessa. | ||
| Por que isso importa Acompanhar as negativas é essencial para identificar causas raiz, como erros de codificação ou problemas de elegibilidade, e melhorar a taxa de reivindicações sem erros. Onde encontrar Inferido a partir dos dados da remessa (ERA/835). O evento é acionado quando uma reivindicação ou um item tem um valor de negativa diferente de zero e um código de motivo correspondente. Coleta Inferido a partir dos dados da remessa que contêm códigos de motivo de negativa (CARCs/RARCs). Tipo de evento inferred | |||
| Reivindicação corrigida enviada | Representa o envio de uma reivindicação revisada ou corrigida ao pagador, geralmente após uma negativa ou uma solicitação de mais informações. É identificada por um novo envio de reivindicação com um indicador de correção. | ||
| Por que isso importa Essa atividade é uma etapa importante do ciclo de retrabalho da gestão de negativas. Uma frequência alta indica problemas de precisão nas reivindicações iniciais. Onde encontrar Obtido dos logs de envio de reivindicações. Procure um novo envio para um atendimento existente, geralmente identificado por um código de reenvio ou por um número de iteração maior. Coleta Evento registrado para o reenvio de uma reivindicação, geralmente identificado por um código específico de tipo de frequência da reivindicação. Tipo de evento explicit | |||
| Remessa recebida | Indica o recebimento de um aviso eletrônico de remessa (ERA) ou de uma explicação de benefícios em papel (EOB) do pagador. Esse documento detalha quais cobranças foram pagas, negadas ou ajustadas. | ||
| Por que isso importa Essa é a primeira resposta do pagador e é fundamental para entender a velocidade dos pagamentos e identificar tendências de negativas com antecedência. Onde encontrar Registrado no módulo de processamento de remessas. Procure a data e a hora de importação ou criação do arquivo ERA, como um arquivo de transação 835, vinculado à reivindicação. Coleta Evento registrado após a importação e o processamento do arquivo de remessa do pagador (por exemplo, ANSI 835). Tipo de evento explicit | |||
Guias de extração
Etapas
- Solicite acesso ao banco de dados: Obtenha credenciais somente para leitura do banco de dados Oracle Health Revenue Cycle. Você precisará acessar os esquemas que contêm dados de pacientes, atendimentos, faturamento e transações financeiras. Em geral, isso exige aprovação das equipes de segurança de TI e administração de banco de dados.
- Identifique os nomes dos esquemas e das tabelas: Trabalhe com um administrador de banco de dados ou analista de sistemas para confirmar os nomes exatos dos esquemas e das tabelas da sua instância Oracle Health. Os nomes usados na consulta são exemplos comuns e precisam ser associados aos objetos do seu ambiente.
- Instale um cliente SQL: Instale na sua estação de trabalho um cliente SQL compatível, como Oracle SQL Developer ou DBeaver. Você usará essa ferramenta para se conectar ao banco de dados e executar o script de extração.
- Conecte-se ao banco de dados: Configure uma nova conexão no cliente SQL usando o host, a porta, o nome do serviço e as credenciais fornecidas. Teste a conexão para confirmar que ela funciona.
- Personalize a consulta SQL: Copie o script SQL fornecido para uma nova janela do editor de consultas. Localize os valores de exemplo, como
[START_DATE]e[END_DATE], e substitua-os pelo período desejado para a análise, por exemplo, '2023-01-01'. Ajuste os filtros conforme suas necessidades de análise, como o filtro por uma classe específica de paciente. - Execute o script de extração: Execute o script SQL personalizado. A consulta foi criada para abranger muitos dados e pode levar de alguns minutos a várias horas, dependendo do período e do tamanho do banco de dados.
- Confira os resultados iniciais: Quando a consulta terminar, confira as primeiras centenas de linhas na grade de resultados do cliente SQL. Procure erros evidentes, como colunas totalmente nulas ou formatos de dados incorretos, para confirmar que o script foi executado corretamente.
- Exporte os dados para CSV: Exporte todo o conjunto de resultados para um arquivo CSV. Use a codificação UTF-8 para evitar problemas com caracteres. Verifique se o arquivo exportado inclui uma linha de cabeçalho com os nomes de coluna definidos nos aliases da consulta, por exemplo, "BillingEvent" e "ActivityName".
- Prepare o arquivo para carregamento: Antes de carregar o arquivo em uma ferramenta de mineração de processos, abra o CSV e confira sua integridade. Verifique se o formato de timestamp é consistente e se os cabeçalhos das colunas correspondem exatamente aos atributos necessários. O arquivo estará pronto para ser carregado.
Configuração
- Período: A consulta usa os marcadores
[START_DATE]e[END_DATE]. É fundamental definir um período específico e razoável para controlar o volume de dados. Para a análise inicial, recomendamos um período de 3 a 6 meses. - Filtragem: Na seção
RelevantEncounters, os dados iniciais são filtrados pela data de registro do atendimento (reg_dt_tm). Você pode adicionar outras cláusulasWHEREnessa seção para restringir o escopo. Por exemplo,e.patient_class_code IN ('INPATIENT', 'OUTPATIENT')permite focar em tipos específicos de atendimento. - Performance: Consultas diretas ao banco de dados em um sistema de produção podem afetar a performance. Recomendamos executar a extração fora dos horários de pico ou em uma réplica somente para leitura do banco de produção, se houver uma disponível.
- Pré-requisitos: Este método exige uma conta de usuário do banco de dados com privilégios
SELECTem todas as tabelas mencionadas na consulta. Elas incluem tabelas de atendimentos, faturamento, cobranças, solicitações de reembolso, remessas, pagamentos e transações financeiras. - Mapeamento de tabelas e colunas: O script fornecido usa nomes comuns e representativos para tabelas e colunas. Você precisa validar esses nomes e mapeá-los para os nomes reais do esquema do banco de dados Oracle Health da sua organização. Por exemplo,
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; Pronto para começar?
Use este Template para preparar seus dados e obter bons resultados. Comece hoje a transformar seu processo de gestão do ciclo de receita.
Otimize seu ciclo de receita para receber mais rápido
Elimine gargalos, reduza o tempo de ciclo em 30% e aumente o fluxo de caixa.
Não é necessário informar cartão de crédito. Configure tudo em poucos minutos.