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 a acompanhar
- Orientações para extração
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 ou evento específico ocorreu. | ||
| Descrição A data e hora do evento registram o momento em que uma atividade ocorreu. Esses dados temporais são fundamentais para entender o momento e a sequência dos eventos no ciclo de receita. Na análise, os registros de data e hora são usados para calcular a duração entre atividades, como o atraso no registro de cobranças ou o tempo de lançamento de pagamentos. Eles ajudam a identificar gargalos, medir tempos de ciclo e analisar o desempenho dos processos em diferentes períodos. Registros precisos de data e hora são essenciais para quase todos os KPIs e Dashboards baseados em tempo. Por que isso importa Este atributo é essencial para calcular todas as métricas baseadas em tempo, incluindo tempos de ciclo e durações, fundamentais para identificar atrasos e ineficiências. Onde encontrar Encontrado nas tabelas de transações ou de registros de eventos do Epic Resolute, associado a cada atividade registrada. Os campos costumam ter sufixos como Dt, DTTM ou Time. Exemplos 2023-04-15T09:30:00Z2023-04-16T11:05:21Z2023-05-01T14:00:00Z | |||
| Evento de cobrança BillingEvent | Identificador exclusivo de uma prestação de serviço ou entrega de produto que gera uma cobrança e serve como identificador principal do caso. | ||
| Descrição O evento de cobrança é o identificador principal que conecta todas as atividades do ciclo de receita relacionadas a um item faturável. Ele começa quando um serviço é prestado e termina quando a conta é totalmente quitada ou encerrada. Na análise de Process Mining, esse atributo é essencial para reconstruir a jornada completa de cada cobrança. Ele permite acompanhar atividades como o registro de cobranças, o envio de solicitações de pagamento, o lançamento de pagamentos e a gestão de negativas em cada evento de cobrança, oferecendo uma visão clara do fluxo do processo e de suas variações. Por que isso importa Este é o ID do caso fundamental, essencial para conectar todas as etapas relacionadas do processo e analisar o ciclo completo de geração e recebimento de receita de cada serviço. Onde encontrar Geralmente, é um identificador exclusivo de uma conta hospitalar (HAR) ou de uma sessão de cobrança específica no Epic Resolute. Consulte a documentação do Epic Resolute para encontrar tabelas específicas, como registros HAR ou de sessões de cobrança. Exemplos BE10098765BE20012345BE30054321 | |||
| Nome da atividade ActivityName | Nome do evento ou da tarefa específica realizada no processo de gestão do ciclo de receita. | ||
| Descrição Este atributo descreve uma etapa do ciclo de receita, como 'Cobranças registradas', 'Solicitação de pagamento enviada ao pagador' ou 'Pagamento recebido'. Cada atividade representa um marco específico no processo de faturamento e recebimento pelo serviço. A análise das atividades é a base do Process Mining. Ela permite visualizar o mapa do processo, identificar caminhos comuns, descobrir gargalos entre etapas e medir a conformidade com os procedimentos operacionais padrão. Por que isso importa Define as etapas do mapa do processo e permite visualizar, analisar e otimizar o fluxo de trabalho no ciclo de receita. Onde encontrar Em geral, esse dado é obtido dos registros de eventos, trilhas de auditoria ou registros de mudança de status nos módulos de cobrança e solicitações de pagamento do Epic Resolute. Exemplos Cobranças registradasSolicitação de pagamento enviada ao pagadorPagamento recebidoConta encerrada | |||
| Código do motivo da negativa DenialReasonCode | Código padronizado que indica o motivo pelo qual o pagador negou uma solicitação de pagamento enviada. | ||
| Descrição Quando um pagador rejeita uma solicitação de pagamento, ele informa um código que explica o motivo, como 'Serviço não coberto', 'Solicitação duplicada' ou 'Requer informações adicionais'. Esses códigos costumam seguir o padrão CARC (códigos de motivo de ajuste de solicitação de pagamento). Este atributo é a base do Dashboard 'Índices e motivos de negativas de solicitações de pagamento'. Analisar a frequência dos diferentes códigos de negativa ajuda a identificar as causas raiz, como problemas de credenciamento, erros de codificação ou falta de pré-autorização, e permite direcionar iniciativas de melhoria. Por que isso importa Explica diretamente por que as solicitações de pagamento são rejeitadas e fornece insights acionáveis para reduzir as negativas, evitar perdas de receita e acelerar os pagamentos. Onde encontrar Esses dados estão nas transações de resposta às solicitações de pagamento, como um arquivo ANSI 835, recebidas dos pagadores e armazenadas no módulo de gestão de solicitações de pagamento do Epic Resolute. Exemplos CO-16: faltam informações na solicitação de pagamento ou no serviçoOA-18: solicitação de pagamento ou serviço duplicadoPR-96: cobrança(s) por serviço não coberto | |||
| Departamento de faturamento BillingDepartment | Departamento ou equipe funcional responsável pelo evento ou pela atividade de cobrança. | ||
| Descrição Este atributo indica a unidade organizacional, como 'Faturamento de internação', 'Faturamento ambulatorial' ou 'Equipe de gestão de negativas', associada ao evento de cobrança ou responsável por uma atividade específica. Essa dimensão é fundamental para o Dashboard 'Métricas de performance do departamento de faturamento', que permite comparar lado a lado métricas importantes, como índices de negativas ou tempos de registro de cobranças. Ela ajuda a gestão a identificar departamentos com melhor desempenho, padronizar boas práticas e alocar recursos com eficiência. Por que isso importa Permite comparar a performance entre departamentos, ajudando a identificar boas práticas e áreas que precisam de melhorias ou recursos adicionais. Onde encontrar Essas informações podem estar vinculadas ao registro do usuário, à conta do paciente ou ao local do serviço no Epic Resolute. Exemplos Faturamento de cardiologiaRCM de radiologiaEscritório central de faturamento | |||
| Motivo do ajuste AdjustmentReason | Motivo de um ajuste manual ou automático no saldo da conta de um paciente. | ||
| Descrição Este atributo explica por que o saldo de uma conta foi alterado fora de um pagamento ou cobrança padrão. Os motivos podem incluir descontos contratuais concedidos pelos pagadores, baixas contábeis de saldos pequenos ou correções de erros de lançamento. Este atributo é essencial para o Dashboard 'Volume de ajustes na conta por tipo'. A análise dos motivos dos ajustes ajuda as organizações a identificar fontes de perda de receita, entender o impacto dos contratos com pagadores e detectar possíveis ineficiências ou erros no processo de faturamento. Por que isso importa Ajuda a entender as perdas de receita e a precisão do faturamento, explicando por que os saldos das contas são alterados e contribuindo para reduzir baixas contábeis desnecessárias. Onde encontrar Localizado nos detalhes das transações de ajuste do módulo de contabilidade de pacientes do Epic Resolute. Exemplos Desconto contratualBaixa contábil de saldo pequenoCorreção de cobrança duplicada | |||
| Saldo pendente OutstandingBalance | Valor restante devido pelo pagador ou pelo paciente referente ao evento de cobrança. | ||
| Descrição Este atributo representa o saldo atual das contas a receber de um evento de cobrança específico no momento da atividade. Ele reflete a situação financeira do caso ao longo de todo o ciclo. O saldo pendente é fundamental para os relatórios financeiros e para o 'Relatório de envelhecimento de saldos pendentes'. Analisar esse valor ao longo do tempo e por diferentes dimensões, como pagador ou departamento, ajuda a priorizar as cobranças, gerenciar o fluxo de caixa e avaliar os riscos financeiros. Por que isso importa Mede diretamente o impacto financeiro dos atrasos no processo e é essencial para priorizar cobranças, gerenciar o fluxo de caixa e entender as contas a receber. Onde encontrar Este é um campo principal do registro da conta do paciente ou da conta hospitalar (HAR) no Epic Resolute. É um saldo acumulado atualizado pelas transações financeiras. Exemplos 1500.00250.750.00 | |||
| Tipo de serviço ServiceType | Categoria ou tipo de serviço médico prestado. | ||
| Descrição Este atributo classifica o serviço faturável, por exemplo, como “Radiologia”, “Cirurgia”, “Consulta” ou “Atendimento de emergência”. Ele fornece contexto clínico aos dados financeiros. A análise do ciclo de receita por tipo de serviço pode revelar variações no processo específicas de determinadas áreas clínicas. Procedimentos cirúrgicos, por exemplo, podem exigir uma captura de cobranças e autorizações mais complexas do que uma consulta ambulatorial padrão, o que gera comportamentos e desafios diferentes no processo. Por que isso importa Fornece contexto clínico aos dados financeiros e permite analisar como diferentes tipos de serviços médicos afetam o processo do ciclo de receita e sua eficiência. Onde encontrar Derivado do cadastro mestre de descrições de cobranças (CDM), da linha de serviço ou do departamento associado à transação de cobrança no Epic. Exemplos Cirurgia com internaçãoRadiologia ambulatorialServiços de emergência | |||
| Usuário responsável ResponsibleUser | Identificador do usuário ou funcionário que realizou a atividade. | ||
| Descrição Este atributo registra o ID, o nome ou o número de funcionário da pessoa responsável por concluir uma tarefa específica no ciclo de receita. Pode ser o profissional de saúde que inseriu as cobranças, a pessoa responsável pelo faturamento que enviou uma solicitação de pagamento ou o agente de cobrança que acompanhou uma negativa. A análise por usuário ajuda a identificar quem tem melhor desempenho, apontar necessidades de treinamento e entender a distribuição da carga de trabalho. Ela é importante para a gestão de performance e para investigar desvios do processo associados a pessoas ou funções específicas. Por que isso importa Permite analisar a performance por pessoa ou função, ajudando a identificar oportunidades de treinamento, desequilíbrios na carga de trabalho e gargalos relacionados a recursos. Onde encontrar Geralmente encontrado nas trilhas de auditoria ou nos logs de transações do Epic Resolute, muitas vezes vinculado a uma tabela de dados mestre de usuários, como o registro EMP. Exemplos j.doebsmith123User7890 | |||
| Data de vencimento do pagamento PaymentDueDate | Data limite para o pagamento do serviço faturado. | ||
| Descrição Este atributo especifica o prazo para pagamento, conforme indicado na fatura ou definido nos contratos com as operadoras. Ele serve como referência para medir a pontualidade dos pagamentos. A data de vencimento é essencial para criar o “Relatório de envelhecimento de saldos em aberto”. Ao comparar a data atual com a data de vencimento dos saldos em aberto, é possível classificar as contas por tempo de atraso, por exemplo, de 0 a 30 dias ou de 31 a 60 dias, e priorizar a cobrança das contas mais atrasadas. Por que isso importa Serve de base para a análise de envelhecimento de contas a receber, essencial para priorizar cobranças e gerenciar o risco financeiro de faturas não pagas. Onde encontrar Essa data costuma ser calculada com base na data da fatura e nas condições de pagamento registradas no contrato com a operadora ou nas informações da conta do paciente no Epic. Exemplos 2023-05-302023-06-152023-07-01 | |||
| É automatizada IsAutomated | Indicador booleano que informa se a atividade foi realizada por um sistema ou processo automatizado. | ||
| Descrição Este indicador diferencia as tarefas executadas automaticamente pelo sistema, como a geração de solicitações de pagamento ou as verificações de elegibilidade, daquelas realizadas manualmente por um usuário. A análise desse atributo ajuda a entender o nível de automação do processo. Ele pode ser usado para comparar a eficiência e as taxas de erro de atividades automatizadas e manuais, identificar oportunidades de ampliar a automação e acompanhar a performance dos bots ou das regras do sistema existentes. Por que isso importa Diferencia as atividades conduzidas pelo sistema daquelas realizadas por pessoas, algo essencial para avaliar o impacto da automação e identificar novas oportunidades de automatização. Onde encontrar Esse dado costuma ser obtido verificando se o “ResponsibleUser” de uma atividade é uma conta de sistema ou de serviço, ou marcando nomes de atividades que se sabe serem automatizadas. Exemplos truefalse | |||
| Hora de término do evento EventEndTime | Data e hora que indicam quando uma atividade foi concluída, úteis para calcular sua duração. | ||
| Descrição Este atributo registra o horário de conclusão de uma atividade. Muitas atividades são eventos instantâneos, em que StartTime e EndTime são iguais, mas algumas tarefas têm duração mensurável, como uma ligação de acompanhamento de uma negativa. Quando disponível, EndTime permite calcular diretamente o tempo de processamento da atividade (“EndTime” - “StartTime”). Esse cálculo é mais preciso do que estimar a duração com base no horário de início da atividade seguinte, pois considera o tempo ocioso entre as etapas. É um componente essencial para calcular o atributo “ProcessingTime”. Por que isso importa Permite calcular com precisão quanto tempo cada atividade leva para ser concluída, algo essencial para identificar tarefas ineficientes e medir a produtividade dos recursos. Onde encontrar Pode estar disponível em alguns módulos do Epic Resolute que registram o início e o término de tarefas, como os logs de filas de trabalho ou de gestão de atividades. Muitas vezes, esse dado não é registrado explicitamente. Exemplos 2023-04-15T09:45:00Z2023-04-16T11:15:30Z2023-05-01T14:02:00Z | |||
| ID da solicitação de pagamento ClaimId | Identificador exclusivo atribuído a uma solicitação de pagamento enviada a uma operadora de planos de saúde. | ||
| Descrição Este atributo é o ID específico do formulário da solicitação de pagamento, como CMS-1500 ou UB-04, enviado à operadora. Um único evento de faturamento pode envolver várias solicitações se os serviços forem faturados novamente ou contestados. O acompanhamento pelo ID da solicitação de pagamento é útil para analisar em detalhes os subprocessos de envio e gestão de negativas. Ele ajuda a diferenciar as atividades relacionadas à solicitação inicial daquelas ligadas a uma solicitação posterior, reenviada para o mesmo serviço. Por que isso importa Fornece um identificador detalhado para acompanhar o ciclo de vida de cada solicitação de pagamento enviada, essencial para analisar reenvios e contestações. Onde encontrar Gerado pelo módulo de gestão de solicitações de pagamento do Epic Resolute quando uma solicitação é criada. Fica armazenado nas tabelas de dados de solicitações. Exemplos CLM-2023-98765CLAIM-0012345623189A4567 | |||
| ID do paciente PatientId | Identificador exclusivo do paciente que recebe o serviço. | ||
| Descrição Este atributo é o número do prontuário médico (MRN) ou outro identificador exclusivo do paciente. Ele vincula o evento financeiro de faturamento a uma pessoa específica. Embora normalmente não seja usado como dimensão principal de análise para proteger a privacidade do paciente, é essencial para validar os dados. Também pode ser usado para agrupar todos os eventos de faturamento de um paciente e entender sua trajetória financeira completa. Além disso, é fundamental para uma possível integração com dados de processos clínicos. Por que isso importa Vincula os dados financeiros a um paciente específico, permitindo validar os dados e, potencialmente, analisar toda a trajetória do paciente. Como envolve informações privadas, deve ser tratado com cuidado. Onde encontrar Identificador fundamental encontrado em todo o Epic, vinculado aos registros de cadastro e conta do paciente. Exemplos MRN-1234567MRN-8765432MRN-5551234 | |||
| Nome do pagador PayerName | Nome da seguradora, entidade governamental ou outra parte responsável pelo pagamento. | ||
| Descrição Este atributo identifica o principal pagador associado ao evento de cobrança, como 'Blue Cross Blue Shield', 'Medicare' ou 'Aetna'. Em casos de pagamento direto pelo paciente, pode indicar o próprio paciente. Segmentar o processo por pagador é uma técnica de análise útil. Ela pode revelar que determinados pagadores têm índices mais altos de negativas, ciclos de pagamento mais longos ou requisitos mais complexos. Esse insight permite adaptar as estratégias de faturamento a cada pagador para melhorar a eficiência e acelerar os pagamentos. Por que isso importa Permite analisar a performance por pagador, revelando quais têm índices altos de negativas ou ciclos de pagamento lentos e ajudando a direcionar as estratégias de acompanhamento. Onde encontrar Essas informações fazem parte dos dados de cobertura do paciente e estão vinculadas à conta hospitalar (HAR) no Epic Resolute. Exemplos Medicare Parte BUnitedHealthcareAetna PPO | |||
| Sistema de origem SourceSystem | Sistema de informação de onde os dados se originam. | ||
| Descrição Este atributo identifica o sistema de origem do registro, que neste contexto é o Epic Resolute. Em ambientes com vários sistemas integrados, esse campo ajuda a diferenciar a origem dos dados. Embora possa parecer redundante quando há apenas um sistema, essa é uma boa prática de governança de dados e escalabilidade. Ela mantém a origem clara caso dados de outros sistemas, como uma plataforma separada de agência de cobrança, sejam integrados no futuro. Por que isso importa Fornece informações essenciais sobre a linhagem e o contexto dos dados, deixando clara sua origem, o que é fundamental para a governança de dados e a solução de problemas. Onde encontrar Em geral, é um valor estático adicionado durante a extração e transformação dos dados para identificar a origem do conjunto de dados. Exemplos Epic ResoluteEpicResolute_V2023 | |||
| Tempo total do ciclo de receita TotalRevenueCycleTime | Duração total calculada entre o primeiro evento do serviço e o pagamento final ou o encerramento da conta. | ||
| Descrição Este KPI por caso mede a duração completa do ciclo de receita de um único evento de faturamento. Em geral, é calculado pela diferença entre a atividade “Serviço prestado” e a atividade final “Pagamento recebido” ou “Conta encerrada”. Esse indicador de alto nível oferece uma visão abrangente da eficiência geral do processo de gestão do ciclo de receita (RCM). Acompanhar esse KPI ao longo do tempo ajuda a medir o impacto das iniciativas de melhoria de processos e fornece um indicador importante da velocidade de conversão em caixa. Por que isso importa Oferece uma visão completa da eficiência do processo, medindo diretamente quanto tempo leva para transformar um serviço em dinheiro. Onde encontrar Essa métrica é calculada na ferramenta de Process Mining, filtrando o primeiro e o último evento de cada caso e calculando a diferença entre eles. Exemplos 259200038880005184000 | |||
| Última atualização dos dados LastDataUpdate | Data e hora que indicam quando os dados deste evento foram atualizados ou extraídos pela última vez do sistema de origem. | ||
| Descrição Este atributo indica o nível de atualização dos dados. Ele mostra quando o registro foi extraído pela última vez do Epic Resolute para o conjunto de dados de Process Mining. Isso é importante para entender a atualidade da análise e validar os dados. Ajuda você a saber se está consultando as informações mais recentes disponíveis e é fundamental para gerenciar os ciclos de atualização dos dados. Por que isso importa Ajuda os usuários a entender se os dados analisados estão atualizados, algo fundamental para tomar decisões de negócios precisas e baseadas nas informações mais recentes. Onde encontrar Esta data e hora são adicionadas pelo processo de ETL (extração, transformação e carregamento) durante a ingestão dos dados. Exemplos 2023-06-10T02:00:00Z2023-06-11T02:00:00Z | |||
| Valor ajustado AdjustedAmount | Valor monetário de uma transação de ajuste. | ||
| Descrição Este campo registra o valor exato, em dólares, de um ajuste na conta. O valor pode ser positivo ou negativo, representando um crédito ou débito no saldo da conta. Esse é o principal indicador do Dashboard “Volume de ajustes de conta por tipo”. Somar esse valor por motivo do ajuste mostra com clareza o impacto financeiro de cada tipo de ajuste, como a receita baixada devido a obrigações contratuais em comparação com a perda causada por erros corrigíveis. Por que isso importa Quantifica o impacto financeiro dos ajustes de conta e permite medir a perda de receita e o custo de imprecisões no faturamento. Onde encontrar Localizado nas tabelas de detalhes das transações financeiras do Epic Resolute, associado a transações do tipo ajuste. Exemplos -1250.45-50.0025.10 | |||
Atividades da gestão do ciclo de receita
| Atividade | Descrição | ||
|---|---|---|---|
| Cobranças registradas | Representa o registro formal das cobranças pelos serviços prestados. No Epic, geralmente é uma transação explícita lançada na conta do paciente, gerada automaticamente a partir de ações clínicas ou inserida manualmente. | ||
| Por que isso importa Este é um marco inicial fundamental. Medir a velocidade e a precisão do registro de cobranças ajuda a acelerar o faturamento e garantir que todos os serviços prestados sejam cobrados. Onde encontrar Registrado explicitamente nos logs de transações do Resolute. Cada cobrança é um lançamento individual, com data de lançamento, data do serviço e valor. Esses dados costumam estar em tabelas como ARPB_TRANSACTIONS. Coleta Capture as transações de lançamento de cobranças no log de transações financeiras do sistema. Tipo de evento explicit | |||
| Conta encerrada | Esta é a atividade final: indica que o saldo pendente do evento de cobrança chegou a zero e não há mais atividades pendentes. Isso pode ocorrer após o pagamento integral, ajustes ou uma baixa contábil. | ||
| Por que isso importa Este evento marca a conclusão do ciclo de receita de um evento de cobrança. A duração total, do serviço ao encerramento, é um KPI fundamental para medir a eficiência geral do processo. Onde encontrar Em geral, este evento é inferido. Ele é identificado pelo momento em que o saldo da conta referente ao evento de cobrança chega a zero e permanece zerado. Coleta Inferido pelo cálculo do saldo acumulado da conta e pela identificação da data e hora da última transação que zerou o saldo. Tipo de evento inferred | |||
| Pagamento lançado na conta | Este evento ocorre quando um pagamento recebido é aplicado ou alocado a cobranças específicas na conta do paciente. Essa ação reduz o saldo pendente do evento de cobrança. | ||
| Por que isso importa O lançamento eficiente de pagamentos é essencial para manter os saldos das contas corretos e encerrar os eventos de cobrança. Isso permite identificar corretamente os saldos restantes para faturamento secundário ou cobrança. Onde encontrar Esta é uma transação explícita no Resolute. O lançamento vincula uma transação de pagamento a uma ou mais transações de cobrança, e essa relação fica registrada nas tabelas de detalhes das transações. Coleta Capture o registro da transação que aplica um pagamento a uma cobrança, identificado por tipos específicos de transação. Tipo de evento explicit | |||
| Pagamento recebido | Representa o recebimento de um pagamento do pagador ou do paciente. Em geral, o evento é registrado quando uma explicação eletrônica de pagamento (ERA) é carregada ou quando um cheque é inserido manualmente no sistema. | ||
| Por que isso importa Esta atividade é um marco importante que indica a entrada de receita. O tempo entre o envio da solicitação de pagamento e o recebimento do pagamento é uma medida fundamental do desempenho das contas a receber. Onde encontrar Registrado explicitamente como uma transação de pagamento no Resolute. Essas transações incluem data, origem e valor e costumam ser registradas antes de serem totalmente aplicadas às cobranças individuais. Coleta Capture as transações de pagamento no log de transações financeiras, geralmente identificadas por tipos específicos de transação. Tipo de evento explicit | |||
| Serviço prestado | Esta atividade marca o momento em que um serviço clínico é prestado ao paciente, dando início ao evento de cobrança. Em geral, esse registro vem do prontuário eletrônico Epic (EpicCare), quando um profissional de saúde finaliza uma consulta ou um procedimento. | ||
| Por que isso importa Este é o principal evento de início do ciclo de receita. Analisar o tempo entre esse momento e o registro da cobrança é essencial para identificar atrasos no início do faturamento e possíveis perdas de receita. Onde encontrar Este evento costuma ser inferido a partir dos registros de data e hora do serviço ou da consulta nos módulos clínicos vinculados à conta de cobrança. A data do serviço na transação de cobrança é o dado principal. Coleta Inferido a partir da data do serviço associada à primeira transação de cobrança do evento de cobrança. Tipo de evento inferred | |||
| Solicitação de pagamento enviada ao pagador | Este evento marca o envio oficial da solicitação de pagamento à seguradora para análise. No Epic, ele é acompanhado e registrado quando o arquivo eletrônico é transmitido à câmara de compensação ou ao pagador. | ||
| Por que isso importa Este marco é fundamental porque inicia a contagem do prazo de pagamento do pagador. Analisá-lo ajuda a medir a eficiência da transmissão das solicitações de pagamento e contribui para o KPI de tempo de entrega da fatura ao pagador. Onde encontrar Este evento é registrado explicitamente no Resolute. O registro da solicitação de pagamento inclui um status de envio e a data e hora em que ela foi enviada. Coleta Capture a data e a hora associadas à mudança do status da solicitação de pagamento para 'Enviada' ou 'Transmitida'. Tipo de evento explicit | |||
| Solicitação de pagamento negada pelo pagador | Representa o recebimento de uma notificação do pagador informando que a solicitação de pagamento foi negada. O registro ocorre quando o Epic processa uma explicação eletrônica de pagamento (arquivo 835) ou quando um usuário lança a negativa manualmente. | ||
| Por que isso importa Esta atividade inicia um ciclo crítico de retrabalho. Analisar os motivos e o volume de negativas é essencial para identificar as causas raiz, melhorar os índices de pagamento na primeira tentativa e reduzir atrasos nos recebimentos. Onde encontrar Registrado explicitamente como uma transação ou atualização de status da solicitação de pagamento. As informações da negativa, incluindo os códigos de motivo, geralmente são recebidas eletronicamente e lançadas na conta. Coleta Filtre tipos específicos de transação ou atualizações de status da solicitação de pagamento que indiquem uma negativa. Tipo de evento explicit | |||
| Acompanhamento da negativa iniciado | Esta atividade marca o início do processo interno de análise e resolução de uma solicitação de pagamento negada. Em geral, o registro ocorre quando um usuário assume a responsabilidade pela solicitação negada em uma fila de trabalho ou altera seu status. | ||
| Por que isso importa Acompanhar essa etapa ajuda a medir a agilidade da equipe de gestão de negativas. Atrasos entre a negativa e o início do acompanhamento podem prolongar desnecessariamente o ciclo de receita. Onde encontrar Em geral, este evento é inferido a partir de mudanças no status da solicitação de pagamento ou no histórico de atribuições nas filas de trabalho do Epic. Por exemplo, o status pode mudar de 'Negada' para 'Em análise'. Coleta Infira o evento a partir de uma mudança no status da solicitação de pagamento ou de uma entrada no log de auditoria que mostre que um usuário começou a tratar a negativa. Tipo de evento inferred | |||
| Ajuste na conta realizado | Esta atividade representa uma transação que não é um pagamento, mas altera o saldo da conta, como um ajuste contratual, a baixa de um saldo pequeno ou um desconto de cortesia. Ela é registrada com um tipo específico de transação. | ||
| Por que isso importa Analisar os ajustes é essencial para identificar perdas de receita. Um volume alto de determinados tipos de ajuste pode indicar problemas nas tabelas de preços, nos contratos ou nas políticas internas. Onde encontrar Registrado explicitamente como transação de ajuste nos logs financeiros do Resolute. Cada ajuste tem um tipo ou código de motivo específico. Coleta Filtre os tipos de transação correspondentes a ajustes financeiros ou baixas contábeis. Tipo de evento explicit | |||
| Saldo encaminhado para cobrança | Este evento marca o momento em que o saldo não pago de uma conta é transferido para um processo interno ou externo de cobrança. Em geral, ele corresponde a uma mudança explícita de status na conta ou no evento de cobrança. | ||
| Por que isso importa Esta atividade inicia a etapa final da recuperação de saldos não pagos. Acompanhar o índice de sucesso e o tempo de ciclo do processo de cobrança é essencial para reduzir a inadimplência. Onde encontrar Em geral, este é um evento explícito. O Epic tem funções para transferir contas a agências de cobrança, o que gera uma entrada no log ou uma mudança de status na conta. Coleta Identifique a mudança de status ou a transação que indica que uma conta foi encaminhada a uma agência de cobrança. Tipo de evento explicit | |||
| Solicitação de pagamento gerada | Esta atividade indica que o sistema criou uma solicitação de pagamento formal ou uma fatura com base nas cobranças registradas. É uma etapa preparatória antes do envio ao pagador ou ao paciente. | ||
| Por que isso importa Acompanhar a geração de solicitações de pagamento ajuda a identificar atrasos entre o registro das cobranças e a preparação para o envio. Essa etapa interna pode afetar o prazo geral de faturamento. Onde encontrar Em geral, o registro ocorre quando uma rotina em lote de geração de cobranças ou solicitações de pagamento é executada. O sistema registra a data e a hora em que o arquivo da solicitação, como um arquivo 837, é criado para uma conta. Coleta Identifique entradas de log ou mudanças de status que indiquem que a solicitação de pagamento foi compilada e está pronta para envio. Tipo de evento explicit | |||
| Solicitação de pagamento reenviada | Este evento ocorre depois que uma solicitação de pagamento negada é corrigida e enviada novamente ao pagador. É um novo envio, vinculado à solicitação original. | ||
| Por que isso importa Esta é uma etapa importante do ciclo de retrabalho. Medir o tempo até o reenvio e o índice de sucesso das solicitações reenviadas é essencial para entender a eficácia do processo de resolução de negativas. Onde encontrar Este evento é registrado explicitamente, de forma semelhante ao envio inicial, mas costuma ser identificado como reenvio. O registro da solicitação de pagamento mostra uma nova data e hora de envio e pode incluir um código de reenvio. Coleta Capture a data e a hora do envio de uma solicitação de pagamento identificada como correção ou reenvio. Tipo de evento explicit | |||
Guias de extração
Etapas
- Estabeleça a conexão com o banco de dados: obtenha credenciais somente para leitura para o banco de dados Epic Clarity. Use um cliente SQL padrão, como DBeaver ou Microsoft SQL Server Management Studio, para se conectar ao servidor do banco de dados.
- Identifique as tabelas principais: as principais tabelas para essa extração incluem
HSP_ACCOUNT, com informações dos casos;HSP_TRANSACTIONS, com eventos financeiros;CLP_CLAIM_INFO, com o status das solicitações; eF_ARHB_TX_SET_POST_HX, com detalhes de lançamento de pagamentos. Você também fará junções com arquivos mestres, comoCLARITY_EMP, para obter detalhes dos usuários. - Defina o escopo: antes de escrever a consulta, determine o escopo da análise. Defina um período específico, normalmente de 3 a 6 meses, e identifique as áreas de atendimento hospitalar (
SERV_AREA_ID) ou as classes de conta que deseja incluir ou excluir. - Desenvolva a consulta SQL: crie uma consulta SQL usando uma expressão de tabela comum (CTE) para selecionar primeiro os valores de
HSP_ACCOUNT_IDdentro do escopo definido. Esse será o conjunto inicial de eventos de faturamento. - Una consultas de atividades individuais: para cada uma das 12 atividades necessárias, escreva uma instrução
SELECTseparada para recuperar dados das tabelas relevantes. Faça a junção com a CTE inicial para analisar somente as contas desejadas. - Combine as consultas com UNION ALL: use o operador
UNION ALLpara combinar os resultados de todas as consultas de atividades em um único Event Log. Assim, as linhas de cada consulta são empilhadas verticalmente. - Mapeie para o esquema padrão: em cada instrução
SELECT, use aliases nas colunas para corresponder ao esquema necessário do ProcessMind:BillingEvent,ActivityName,EventTimestamp,ResponsibleUseretc. UseNULLpara atributos que não se aplicam a uma atividade específica. - Execute e refine a consulta: execute a consulta completa no banco de dados Clarity. Como as tabelas são grandes, a execução pode levar bastante tempo. Se houver problemas de performance, reduza o período ou adicione filtros mais específicos à CTE inicial.
- Revise os resultados: quando a consulta terminar, confira as primeiras centenas de linhas. Verifique se todas as colunas estão presentes, se as datas e horas seguem um formato consistente e se os diferentes valores de
ActivityNameaparecem como esperado. - Exporte para CSV: exporte todo o conjunto de resultados do cliente SQL para um arquivo CSV. Verifique se o arquivo usa codificação UTF-8 e inclui uma linha de cabeçalho com os nomes corretos das colunas.
- Prepare os dados para carregamento: antes de carregar os dados no ProcessMind, abra o arquivo CSV e confira se não há erros de formatação. Verifique se o formato de data e hora é consistente, por exemplo,
YYYY-MM-DD HH:MI:SS. O arquivo estará pronto para ser carregado.
Configuração
- Conexão com o banco de dados: é necessária uma conta de usuário somente para leitura com acesso ao banco de dados Epic Clarity.
- Parâmetros do período: a consulta fornecida usa as variáveis
@StartDatee@EndDate, que devem ser definidas para estabelecer o período da análise. Recomenda-se um intervalo de 3 a 6 meses para equilibrar o volume de dados e a performance. - Mapeamento de tabelas e colunas: a consulta pressupõe nomes padrão de tabelas e colunas do Clarity. A configuração ou versão do Epic da sua organização pode apresentar variações. Talvez seja necessário ajustar nomes de tabelas e colunas ou condições de junção.
- Códigos de transação e status: a consulta inclui marcadores como
[Your Denial Tx Type]e[Your Collections Status Code]. Consulte os administradores do sistema Epic ou verifique os arquivos mestres relevantes, comoZC_TX_TYPEouZC_ACCOUNT_STATUS, para encontrar os códigos corretos da sua instância. - Filtragem: para melhorar a performance e direcionar melhor a análise, adicione filtros à CTE inicial
BaseAccounts. Entre os filtros comuns estãoSERV_AREA_ID, para limitar a análise por área de atendimento hospitalar, eACCOUNT_CLASS_C, para focar no faturamento de pacientes internados ou ambulatoriais.
a Consulta de exemplo sql
DECLARE @StartDate DATE = '2023-01-01';
DECLARE @EndDate DATE = '2023-06-30';
WITH BaseAccounts AS (
SELECT DISTINCT
HA.HSP_ACCOUNT_ID
FROM
HSP_ACCOUNT HA
WHERE
HA.ADM_DATE_TIME >= @StartDate
AND HA.ADM_DATE_TIME <= @EndDate
-- Add additional filters here if needed, for example:
-- AND HA.SERV_AREA_ID = [Your Service Area ID]
)
-- 1. Service Rendered
SELECT
tx.HSP_ACCOUNT_ID AS BillingEvent,
'Service Rendered' AS ActivityName,
tx.SERVICE_DATE AS EventTimestamp,
emp.USER_ID AS ResponsibleUser,
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
proc.PROC_NAME AS ServiceType
FROM HSP_TRANSACTIONS tx
INNER JOIN BaseAccounts ba ON tx.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON tx.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_EMP emp ON tx.USER_ID = emp.USER_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
LEFT JOIN CLARITY_EAP proc ON tx.PROC_ID = proc.PROC_ID
WHERE tx.TX_TYPE_C = 1 -- Charge Transaction Type
AND tx.ORIG_REV_TX_ID IS NULL -- Not a reversal
UNION ALL
-- 2. Charges Captured
SELECT
tx.HSP_ACCOUNT_ID AS BillingEvent,
'Charges Captured' AS ActivityName,
tx.POST_DATE AS EventTimestamp,
emp.USER_ID AS ResponsibleUser,
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
proc.PROC_NAME AS ServiceType
FROM HSP_TRANSACTIONS tx
INNER JOIN BaseAccounts ba ON tx.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON tx.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_EMP emp ON tx.POSTING_USER_ID = emp.USER_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
LEFT JOIN CLARITY_EAP proc ON tx.PROC_ID = proc.PROC_ID
WHERE tx.TX_TYPE_C = 1 -- Charge Transaction Type
UNION ALL
-- 3. Claim Generated
SELECT
claim.HSP_ACCOUNT_ID AS BillingEvent,
'Claim Generated' AS ActivityName,
claim.GENERATED_TIME AS EventTimestamp,
NULL AS ResponsibleUser, -- Often a system process
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM CLP_CLAIM_INFO claim
INNER JOIN BaseAccounts ba ON claim.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON claim.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
WHERE claim.GENERATED_TIME IS NOT NULL
UNION ALL
-- 4. Claim Submitted to Payer
SELECT
claim.HSP_ACCOUNT_ID AS BillingEvent,
'Claim Submitted to Payer' AS ActivityName,
claim.XMIT_DATE AS EventTimestamp,
NULL AS ResponsibleUser, -- Often a system process
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM CLP_CLAIM_INFO claim
INNER JOIN BaseAccounts ba ON claim.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON claim.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
WHERE claim.XMIT_DATE IS NOT NULL
UNION ALL
-- 5. Claim Denied by Payer
SELECT
tx.HSP_ACCOUNT_ID AS BillingEvent,
'Claim Denied by Payer' AS ActivityName,
tx.POST_DATE AS EventTimestamp,
emp.USER_ID AS ResponsibleUser,
dep.DEPARTMENT_NAME AS BillingDepartment,
remit.REMIT_CODE_ID AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM HSP_TRANSACTIONS tx
INNER JOIN BaseAccounts ba ON tx.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON tx.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_EMP emp ON tx.POSTING_USER_ID = emp.USER_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
LEFT JOIN F_ARHB_TX_SET_POST_HX remit ON tx.TX_ID = remit.TX_ID
WHERE tx.TX_TYPE_C IN ([Your Denial Tx Type]) -- Placeholder for denial transaction type codes
UNION ALL
-- 6. Denial Follow-Up Initiated (assumes status change on account)
SELECT
hist.HSP_ACCOUNT_ID AS BillingEvent,
'Denial Follow-Up Initiated' AS ActivityName,
hist.CHANGE_AUDIT_DTTM AS EventTimestamp,
emp.USER_ID AS ResponsibleUser,
NULL AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM HSP_ACCT_STATUS_HX hist
INNER JOIN BaseAccounts ba ON hist.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON hist.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_EMP emp ON hist.CHANGE_AUDIT_USER_ID = emp.USER_ID
WHERE hist.ACCOUNT_STATUS_C = [Your Denial Followup Status Code] -- Placeholder for a status indicating follow-up
UNION ALL
-- 7. Claim Resubmitted
SELECT
claim.HSP_ACCOUNT_ID AS BillingEvent,
'Claim Resubmitted' AS ActivityName,
claim.RESUBMIT_DATE AS EventTimestamp,
emp.USER_ID AS ResponsibleUser,
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM CLP_CLAIM_INFO claim
INNER JOIN BaseAccounts ba ON claim.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON claim.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
LEFT JOIN CLARITY_EMP emp ON claim.RESUBMIT_USER_ID = emp.USER_ID
WHERE claim.RESUBMIT_DATE IS NOT NULL
UNION ALL
-- 8. Payment Received & 9. Payment Posted to Account (combined for this query)
SELECT
tx.HSP_ACCOUNT_ID AS BillingEvent,
'Payment Posted to Account' AS ActivityName,
tx.POST_DATE AS EventTimestamp,
emp.USER_ID AS ResponsibleUser,
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM HSP_TRANSACTIONS tx
INNER JOIN BaseAccounts ba ON tx.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON tx.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_EMP emp ON tx.POSTING_USER_ID = emp.USER_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
WHERE tx.TX_TYPE_C IN ([Your Payer Payment Tx Type], [Your Patient Payment Tx Type]) -- Placeholder for payment transaction types
UNION ALL
-- 10. Account Adjustment Made
SELECT
tx.HSP_ACCOUNT_ID AS BillingEvent,
'Account Adjustment Made' AS ActivityName,
tx.POST_DATE AS EventTimestamp,
emp.USER_ID AS ResponsibleUser,
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
zcar.NAME AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM HSP_TRANSACTIONS tx
INNER JOIN BaseAccounts ba ON tx.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON tx.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_EMP emp ON tx.POSTING_USER_ID = emp.USER_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
LEFT JOIN ZC_ADJ_REASON zcar ON tx.ADJ_REASON_C = zcar.ADJ_REASON_C
WHERE tx.TX_TYPE_C IN ([Your Adjustment Tx Type]) -- Placeholder for adjustment transaction types
UNION ALL
-- 11. Balance Sent to Collections
SELECT
acct.HSP_ACCOUNT_ID AS BillingEvent,
'Balance Sent to Collections' AS ActivityName,
hist.CHANGE_AUDIT_DTTM AS EventTimestamp,
emp.USER_ID AS ResponsibleUser,
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM HSP_ACCOUNT acct
INNER JOIN BaseAccounts ba ON acct.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
INNER JOIN HSP_ACCT_STATUS_HX hist ON acct.HSP_ACCOUNT_ID = hist.HSP_ACCOUNT_ID AND hist.ACCOUNT_STATUS_C = [Your Collections Status Code]
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
LEFT JOIN CLARITY_EMP emp ON hist.CHANGE_AUDIT_USER_ID = emp.USER_ID
WHERE acct.ACCOUNT_STATUS_C = [Your Collections Status Code] -- Placeholder for collections status
UNION ALL
-- 12. Account Closed
SELECT
acct.HSP_ACCOUNT_ID AS BillingEvent,
'Account Closed' AS ActivityName,
acct.CLOSED_DATE AS EventTimestamp,
NULL AS ResponsibleUser, -- System or Final transaction user
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM HSP_ACCOUNT acct
INNER JOIN BaseAccounts ba ON acct.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
WHERE acct.ACCT_FIN_BALANCE = 0
AND acct.CLOSED_DATE IS NOT NULL
AND acct.CLOSED_DATE BETWEEN @StartDate and @EndDate
ORDER BY
BillingEvent,
EventTimestamp; Etapas
- Confirme se há acesso autorizado ao conjunto de dados do ciclo de receita do Epic Clarity, incluindo as tabelas e visualizações de origem necessárias para consultar o histórico de contas, cobranças, solicitações de pagamento, negativas, pagamentos, ajustes, cobranças de valores em aberto e encerramentos. As tabelas disponíveis e os nomes das colunas variam entre organizações que usam o Epic. Por isso, mapeie cada marcador da consulta para o objeto Clarity correspondente no seu ambiente.
- Defina o período de extração usando [Start date parameter] e [End date parameter]. Comece com um período de três a seis meses e amplie-o somente depois de validar a performance da consulta e a integridade dos eventos.
- Defina o mapeamento de BillingEvent. Quando disponível, a consulta usa
HSP_ACCOUNT.HSP_ACCOUNT_IDcomo identificador padrão do caso. Se a sua organização definir um evento de faturamento no nível de cobrança, solicitação de pagamento ou atendimento, substitua o mapeamento pelo identificador aprovado e mantenha-o consistente em todas as fontes de atividade. - Mapeie cada atividade de origem para uma data e hora e um atributo de origem confiáveis. Para “Serviço prestado”, use a data e hora documentadas de conclusão do serviço ou atendimento. Para “Cobranças capturadas”, use a data e hora de lançamento da cobrança. Para “Solicitação de pagamento gerada” e “Solicitação enviada à operadora”, use as respectivas datas e horas do ciclo de vida da solicitação. Para negativas, acompanhamentos, reenvios, pagamentos, ajustes, cobranças de valores em aberto e encerramentos, use as datas e horas documentadas das transações ou dos status.
- Substitua todos os marcadores de origem entre colchetes na consulta, incluindo [Your service source table], [Your charge source table], [Your claim source table], [Your denial source table], [Your follow-up source table], [Your payment source table], [Your adjustment source table], [Your collections source table] e [Your account closure source table]. Não use códigos de transação sem documentação. Use os valores de transação ou status aprovados pela equipe de relatórios do Epic.
- Execute a consulta no cliente SQL ou na plataforma de relatórios aprovada pela organização. Confirme se os rótulos das doze atividades aparecem em linhas explícitas. O ProcessMind não infere eventos ausentes do ciclo de vida com base em saldos, status ou ordem dos eventos.
- Revise o esquema dos resultados. O resultado deve conter BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance e ServiceType. Preserve as datas e horas com a documentação de fuso horário ou horário local e mantenha os identificadores de origem em uma extração interna para auditoria, se permitido.
- Valide a ordem cronológica dentro de cada BillingEvent, o tratamento de duplicatas, as taxas de valores nulos, a contagem de atividades e a conciliação com os relatórios do sistema de origem. Investigue eventos fora do período solicitado que sejam necessários para interpretar casos iniciados antes ou encerrados depois desse período.
- Exporte os resultados como arquivo delimitado ou por uma conexão com banco de dados compatível com o ProcessMind. Use uma linha por evento, nomes de colunas estáveis, um formato consistente de data e hora, codificação UTF-8 e nenhuma célula mesclada ou total de apresentação. Durante o carregamento, configure BillingEvent como identificador do caso, ActivityName como atividade e EventTimestamp como data e hora do evento.
Configuração
- Mapeamento das fontes: As implementações do Epic Clarity variam. Substitua cada objeto de origem e placeholder de coluna entre colchetes por uma tabela, view ou camada de relatórios aprovada e documentada no seu ambiente. Não presuma que uma tabela ou campo existe apenas por ser comum em outra implementação do Epic.
- Identificador do caso: O mapeamento padrão da consulta usa HSP_ACCOUNT.HSP_ACCOUNT_ID. Confirme se a organização define BillingEvent como conta, atendimento, solicitação de reembolso, cobrança ou outra chave de negócio aprovada.
- Período: Comece com três a seis meses. Inclua um período anterior quando os casos puderem começar antes da janela de análise e um período posterior quando solicitações, negativas, pagamentos ou encerramentos puderem ocorrer depois da data do serviço.
- Timestamps das atividades: Configure um timestamp oficial para cada atividade. Não substitua o horário real do evento de negócio pelo horário de extração, carregamento do arquivo ou status atual, a menos que esse seja o timestamp documentado do evento no sistema de origem.
- Filtros: Aplique os filtros [Company Code filter], [Document Type filter], [Department filter], de pagador, área de atendimento e classe da conta somente quando as definições estiverem documentadas e forem necessárias para a análise. Mantenha os filtros consistentes em todas as ramificações de UNION ALL.
- Mapeamento de transações e status: Configure os valores aprovados pela organização para lançamento de cobrança, criação de solicitação, envio de solicitação, negativa, acompanhamento, reenvio, recebimento de pagamento, lançamento de pagamento, ajuste, cobrança de valores em atraso e encerramento. A consulta usa placeholders intencionalmente, pois os valores de transação e as estruturas de origem do Epic variam conforme a implementação.
- Tratamento de valores nulos: Preserve NULL para atributos que não se aplicam a uma atividade. Não substitua motivos de negativa, motivos de ajuste, usuários, departamentos ou tipos de serviço ausentes por valores inventados.
- Performance: Restrinja as linhas de origem usando colunas de data indexadas e filtros organizacionais aprovados antes de fazer a junção com HSP_ACCOUNT. Evite aplicar funções a colunas de timestamp indexadas nas condições. Se o histórico bruto for extenso, considere materializar cada atividade de origem em uma view de relatórios aprovada.
- Desduplicação: Não remova eventos duplicados sem uma regra documentada. Vários pagamentos, ajustes, envios ou mudanças de status podem ser eventos válidos para um BillingEvent.
- Pré-requisitos: O acesso necessário pode incluir autorização para relatórios do Epic Clarity, acesso a dados do ciclo de receita e do histórico de contas, um ambiente aprovado para execução de SQL e aprovação organizacional para uso de informações de saúde protegidas. A disponibilidade de históricos de solicitações, remessas, filas de trabalho, cobranças e encerramentos depende dos módulos e das interfaces do Epic licenciados e implementados.
a Consulta de exemplo sql
WITH
service_rendered AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Service Rendered' AS ActivityName,
CAST(s.[Service rendered timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(s.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(s.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(s.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(s.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your service source table] s
ON s.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE s.[Service rendered timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND s.[Service rendered timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND [Your company code filter]
),
charges_captured AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Charges Captured' AS ActivityName,
CAST(t.[Charge captured timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(t.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(t.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(t.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(t.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN AR_PB_TRANSACTIONS t
ON t.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE t.[Charge captured timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND t.[Charge captured timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND t.[Charge transaction filter]
AND [Your company code filter]
),
claim_generated AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Claim Generated' AS ActivityName,
CAST(c.[Claim generated timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(c.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(c.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(c.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(c.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your claim source table] c
ON c.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE c.[Claim generated timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND c.[Claim generated timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND c.[Claim generated status filter]
AND [Your company code filter]
),
claim_submitted AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Claim Submitted to Payer' AS ActivityName,
CAST(c.[Claim submitted timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(c.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(c.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(c.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(c.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your claim source table] c
ON c.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE c.[Claim submitted timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND c.[Claim submitted timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND c.[Claim submitted status filter]
AND [Your company code filter]
),
claim_denied AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Claim Denied by Payer' AS ActivityName,
CAST(d.[Denial timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(d.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(d.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(d.[Denial reason code column] AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(d.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(d.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your denial source table] d
ON d.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE d.[Denial timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND d.[Denial timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND d.[Denial status filter]
AND [Your company code filter]
),
denial_follow_up AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Denial Follow-Up Initiated' AS ActivityName,
CAST(f.[Follow-up timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(f.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(f.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(f.[Denial reason code column] AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(f.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(f.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your follow-up source table] f
ON f.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE f.[Follow-up timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND f.[Follow-up timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND f.[Follow-up status filter]
AND [Your company code filter]
),
claim_resubmitted AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Claim Resubmitted' AS ActivityName,
CAST(c.[Claim resubmitted timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(c.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(c.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(c.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(c.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your claim source table] c
ON c.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE c.[Claim resubmitted timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND c.[Claim resubmitted timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND c.[Claim resubmitted status filter]
AND [Your company code filter]
),
payment_received AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Payment Received' AS ActivityName,
CAST(p.[Payment received timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(p.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(p.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(p.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(p.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your payment source table] p
ON p.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE p.[Payment received timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND p.[Payment received timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND p.[Payment received status filter]
AND [Your company code filter]
),
payment_posted AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Payment Posted to Account' AS ActivityName,
CAST(p.[Payment posted timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(p.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(p.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(p.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(p.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your payment source table] p
ON p.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE p.[Payment posted timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND p.[Payment posted timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND p.[Payment posted status filter]
AND [Your company code filter]
),
account_adjustment AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Account Adjustment Made' AS ActivityName,
CAST(x.[Adjustment timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(x.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(x.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(x.[Adjustment reason column] AS VARCHAR(100)) AS AdjustmentReason,
CAST(x.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(x.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your adjustment source table] x
ON x.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE x.[Adjustment timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND x.[Adjustment timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND x.[Adjustment transaction filter]
AND [Your company code filter]
),
balance_collections AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Balance Sent to Collections' AS ActivityName,
CAST(k.[Collections timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(k.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(k.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(k.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(k.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your collections source table] k
ON k.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE k.[Collections timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND k.[Collections timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND k.[Collections status filter]
AND [Your company code filter]
),
account_closed AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Account Closed' AS ActivityName,
CAST(z.[Account closed timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(z.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(z.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(z.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(z.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your account closure source table] z
ON z.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE z.[Account closed timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND z.[Account closed timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND z.[Account closed status filter]
AND [Your company code filter]
)
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM service_rendered
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM charges_captured
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM claim_generated
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM claim_submitted
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM claim_denied
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM denial_follow_up
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM claim_resubmitted
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM payment_received
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM payment_posted
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM account_adjustment
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM balance_collections
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM account_closed
ORDER BY BillingEvent, EventTimestamp, ActivityName; Pronto para começar?
Use dados precisos para aproveitar todo o potencial do processo de gestão do ciclo de receita. Comece hoje a melhorar a eficiência e a performance financeira.
Aumente a eficiência: otimize agora a gestão do ciclo de receita
Identifique ineficiências no RCM do Epic Resolute e reduza o tempo de ciclo em 30%.
Não é necessário informar cartão de crédito. Comece a otimizar hoje.