Seu Template de Dados de Gestão do Ciclo de Receita
Seu Template de Dados de Gestão do Ciclo de Receita
- Atributos recomendados para coletar
- Atividades-chave a monitorizar
- Orientação para Extração
Atributos de Gestão do Ciclo de Receita
| Nome | Descrição | ||
|---|---|---|---|
| Event Timestamp EventTimestamp | A data e hora exatas em que uma atividade ou evento específico ocorreu. | ||
| Descrição O Event Timestamp registra o momento em que uma atividade ocorreu. Esses dados temporais so crticos para entender o cronograma e a sequncia dos eventos no ciclo de receita. Na anlise, os timestamps so usados para calcular duraes entre atividades, como o atraso na captura de cobranas ou o tempo de lanamento de pagamentos. Eles permitem a descoberta de gargalos, medio de tempos de ciclo e anlise do desempenho do processo em diferentes perodos. Timestamps precisos so essenciais para quase todos os KPIs e Dashboards baseados em tempo. Por que é importante Este atributo essencial para calcular todas as m tricas baseadas em tempo, incluindo tempos de ciclo e duraes, fundamentais para identificar atrasos e ineficincias. Onde obter Encontrado nas tabelas de transação ou event log 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 Faturamento BillingEvent | O identificador exclusivo para uma nica entrega de servio ou produto que gera uma cobrana, servindo como o identificador de caso principal. | ||
| Descrição O Evento de Faturamento o identificador central que conecta todas as atividades dentro do ciclo de receita para um item faturvel especfico. Ele comea quando um servio prestado e termina quando a conta totalmente liquidada ou fechada. Na anlise de Process Mining, esse atributo essencial para reconstruir a jornada de ponta a ponta de cada cobrana. Ele permite o rastreamento de atividades como captura de cobrana, envio de reivindicao, lanamento de pagamento e gesto de negativas para eventos de faturamento individuais, fornecendo uma viso clara do fluxo do processo e suas variaes. Por que é importante Este o Case ID fundamental, crucial para vincular todas as etapas do processo relacionadas e analisar o ciclo de vida completo da gerao e coleta de receita para cada servio. Onde obter Este frequentemente um identificador exclusivo para uma conta hospitalar (HAR) ou uma sesso de cobrana especfica no Epic Resolute. Consulte a documentao do Epic Resolute para tabelas especficas como registros de HAR ou Sesso de Cobrana. Exemplos BE10098765BE20012345BE30054321 | |||
| Nome da Atividade ActivityName | O nome do evento ou tarefa especfica realizada no processo de gesto do ciclo de receita. | ||
| Descrição Este atributo descreve uma nica etapa no ciclo de receita, como 'Charges Captured', 'Claim Submitted to Payer' ou 'Payment Received'. Cada atividade representa um marco distinto no processo de faturamento e recebimento de pagamento por um servio. Analisar as atividades a base do Process Mining. Ele permite a visualizao do mapa do processo, identificao de caminhos comuns, descoberta de gargalos entre as etapas e medio da conformidade com os procedimentos operacionais padro. Por que é importante Define as etapas no mapa de processos, possibilitando visualizar, analisar e otimizar o fluxo de trabalho no ciclo de receita. Onde obter Isso normalmente derivado de logs de eventos, trilhas de auditoria ou registros de alterao de status dentro dos mdulos de faturamento e reivindicaes do Epic Resolute. Exemplos Itens CapturadosGuia Submetida ao PagadorPagamento RecebidoConta Fechada | |||
| Código do Motivo da Glosa DenialReasonCode | Um código padronizado que indica o motivo pelo qual o pagador glosou uma guia enviada. | ||
| Descrição Quando uma operadora rejeita uma reivindicao, ela fornece um cdigo de motivo que explica a negativa, como 'Servio no Coberto', 'Reivindicao Duplicada' ou 'Requer Informaes Adicionais'. Esses cdigos so frequentemente padronizados como Cdigos de Motivo de Ajuste de Reivindicao (CARCs). Este atributo a pea fundamental do dashboard 'Taxas e Motivos de Negativa de Reivindicao'. Analisar a frequncia de diferentes cdigos de negativa ajuda a identificar as causas raiz das glosas, como problemas de credenciamento, erros de codificao ou falta de pr -autorizaes, permitindo iniciativas de melhoria direcionadas. Por que é importante Explica diretamente por que as guias estão sendo rejeitadas, fornecendo insights acionáveis para reduzir taxas de glosa, evitar perdas de receita e acelerar recebimentos. Onde obter Esses dados so encontrados nas transaes de resposta de reivindicao (como um arquivo ANSI 835) recebidas das operadoras e armazenadas no mdulo de gesto de reivindicaes do Epic Resolute. Exemplos CO-16: Guia/serviço com falta de informaçõesOA-18: Guia/serviço duplicadoPR-96: Cobrança(s) não coberta(s) | |||
| Departamento de Faturamento BillingDepartment | O departamento ou equipe funcional responsvel pelo evento ou atividade de faturamento. | ||
| Descrição Este atributo indica a unidade organizacional, como 'Faturamento de Internao', 'Faturamento Ambulatorial' ou 'Equipe de Gesto de Negativas', que est associada ao evento de faturamento ou realizou uma atividade especfica. Esta dimenso crucial para o dashboard 'M tricas de Desempenho do Departamento de Faturamento', permitindo comparaes lado a lado de m tricas principais, como taxas de negativa ou tempos de captura de cobranas. Ajuda a gerncia a identificar departamentos de alto desempenho, padronizar as melhores prticas e alocar recursos de forma eficaz. Por que é importante Permite benchmarking de desempenho entre diferentes departamentos, ajudando a identificar melhores práticas e áreas que precisam de melhoria ou mais recursos. Onde obter Esta informao pode estar vinculada ao registro do usurio, conta do paciente ou ao local do servio dentro do Epic Resolute. Exemplos Faturamento CardiologiaRCM de RadiologiaEscritório Central de Faturamento | |||
| Motivo do Ajuste AdjustmentReason | O motivo de um ajuste manual ou automatizado feito 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 cobrana padro. Os motivos podem incluir descontos contratuais com operadoras, baixas de pequenos saldos ou correes de erros de lanamento. Isso essencial para o dashboard 'Volume de Ajuste de Conta por Tipo'. Ao analisar os motivos de ajuste, as organizaes podem identificar fontes de perda de receita, entender o impacto dos contratos com operadoras e detectar potenciais ineficincias ou erros no processo de faturamento. Por que é importante Oferece insights sobre perda de receita e preciso de faturamento, explicando por que os saldos das contas esto sendo modificados, ajudando a reduzir baixas desnecessrias. Onde obter Localizado nos detalhes da transação para entradas de ajuste no módulo de contabilidade de pacientes do Epic Resolute. Exemplos Abatimento ContratualBaixa de Pequeno SaldoCorreção de Cobrança Duplicada | |||
| Saldo Pendente OutstandingBalance | O valor restante devido pela operadora ou paciente para o evento de faturamento. | ||
| Descrição Este atributo representa o saldo atual de contas a receber para um evento de faturamento especfico no momento da atividade. Ele reflete o status financeiro do caso ao longo de seu ciclo de vida. O saldo devedor crtico para relatrios financeiros e para o 'Relatrio de Aging de Saldo Devedor'. Analisar esse valor ao longo do tempo e por diferentes dimenses como operadora ou departamento ajuda a priorizar os esforos de cobrana, gerenciar o fluxo de caixa e avaliar o risco financeiro. Por que é importante Mede diretamente o impacto financeiro de atrasos nos processos e é essencial para priorizar cobranças, gerir fluxo de caixa e entender o contas a receber. Onde obter Este um campo central no registro da conta do paciente ou da conta hospitalar (HAR) no Epic Resolute. um saldo corrente que atualizado por transaes financeiras. Exemplos 1500.00250.750.00 | |||
| Tipo de Serviço ServiceType | A categoria ou tipo de servio m dico que foi prestado. | ||
| Descrição Este atributo classifica o servio faturvel, por exemplo, como 'Radiologia', 'Cirurgia', 'Consulta' ou 'Visita ao Pronto-Socorro'. Ele fornece contexto clnico aos dados financeiros. Analisar o ciclo de receita por tipo de servio pode revelar variaes de processo especficas para certas reas clnicas. Por exemplo, procedimentos cirrgicos podem ter requisitos de captura de cobrana e autorizao mais complexos do que uma consulta padro, levando a diferentes comportamentos e desafios no processo. Por que é importante Fornece contexto clnico aos dados financeiros, permitindo analisar como diferentes tipos de servios m dicos impactam o processo do ciclo de receita e sua eficincia. Onde obter Derivado do mestre de descrição de cobranças (CDM), linha de serviço ou departamento associado à transação de cobrança no Epic. Exemplos Cirurgia em Paciente InternadoRadiologia AmbulatorialServiços de Emergência | |||
| Usuário Responsável ResponsibleUser | O identificador do usurio ou funcionrio que realizou a atividade. | ||
| Descrição Este atributo captura o ID do usurio, nome ou nmero do funcionrio responsvel por concluir uma tarefa especfica no ciclo de receita. Pode ser o m dico que inseriu as cobranas, o faturista que enviou uma reivindicao ou o cobrador que acompanhou uma negativa. Analisar por usurio ajuda a identificar os melhores profissionais, apontar necessidades de treinamento e entender a distribuio da carga de trabalho. fundamental para a gesto de desempenho e para investigar desvios de processo associados a indivduos ou cargos especficos. Por que é importante Permite analisar o desempenho por indivíduo ou função, ajudando a identificar necessidades de treinamento, desequilíbrio na carga de trabalho e gargalos de recursos. Onde obter Normalmente encontrado na trilha de auditoria ou logs de transao dentro do Epic Resolute, muitas vezes vinculado a uma tabela de dados mestre de usurio (ex: registro EMP). Exemplos j.doebsmith123User7890 | |||
| Data de Vencimento do Pagamento PaymentDueDate | A data em que se espera o pagamento pelo servio faturado. | ||
| Descrição Este atributo especifica o prazo para pagamento, conforme indicado na fatura ou determinado pelos contratos com as operadoras. Serve como referncia para medir pagamentos pontuais. A data de vencimento do pagamento essencial para a criao do 'Relatrio de Aging de Saldo Devedor'. Ao comparar a data atual com a data de vencimento dos saldos abertos, as contas a receber podem ser categorizadas em faixas de atraso (ex: 0-30 dias, 31-60 dias de atraso), o que ajuda a priorizar os esforos de cobrana nas contas mais atrasadas. Por que é importante Serve como base para a anlise de envelhecimento de contas a receber (aging), fundamental para priorizar cobranas e gerenciar o risco financeiro de faturas no pagas. Onde obter Esta data frequentemente calculada com base na data da fatura e nos termos de pagamento armazenados no contrato da operadora ou nas informaes da conta do paciente no Epic. Exemplos 2023-05-302023-06-152023-07-01 | |||
| É Automatizado IsAutomated | Um sinalizador booleano indicando se a atividade foi realizada por um sistema ou processo automatizado. | ||
| Descrição Este marcador distingue entre tarefas executadas automaticamente pelo sistema, como gerao automtica de reivindicaes ou verificaes de elegibilidade, e aquelas realizadas manualmente por um usurio. Analisar este atributo ajuda a entender o nvel de automao no processo. Pode ser usado para comparar a eficincia e as taxas de erro de atividades automatizadas versus manuais, identificar oportunidades para automao adicional e monitorar o desempenho de robs ou regras de sistema existentes. Por que é importante Distingue entre atividades realizadas pelo sistema e por humanos, o que é fundamental para avaliar o impacto da automação e identificar novas oportunidades automatizáveis. Onde obter Isso frequentemente derivado ao verificar se o 'ResponsibleUser' de uma atividade uma conta de sistema ou de servio, ou ao marcar nomes de atividades especficas conhecidas por serem automatizadas. Exemplos verdadeirofalse | |||
| Event End Time EventEndTime | O timestamp que indica quando uma atividade foi concluda, til para calcular a durao da atividade. | ||
| Descrição Este atributo registra o tempo de concluso de uma atividade. Embora muitas atividades sejam eventos instantneos onde o StartTime igual ao EndTime, algumas tarefas tm uma durao mensurvel, como uma chamada de acompanhamento de negativa. Quando disponvel, o EndTime permite o clculo direto do tempo de processamento da atividade ('EndTime' - 'StartTime'). Isso mais preciso do que inferir a durao a partir do horrio de incio da prxima atividade, pois considera o tempo ocioso entre as etapas. um componente chave para o clculo do atributo 'ProcessingTime'. Por que é importante Possibilita o cálculo preciso do tempo de conclusão de cada atividade, o que é vital para identificar tarefas ineficientes e medir a produtividade dos recursos. Onde obter Isso pode estar disponvel em alguns mdulos do Epic Resolute que rastreiam o incio e o fim da tarefa, como logs de fila de trabalho ou gesto de atividades. Muitas vezes, no rastreado explicitamente. Exemplos 2023-04-15T09:45:00Z2023-04-16T11:15:30Z2023-05-01T14:02:00Z | |||
| ID do Paciente PatientId | O identificador exclusivo do paciente que recebe o servio. | ||
| Descrição Este atributo o Pronturio M dico (MRN) ou outro identificador exclusivo do paciente. Ele vincula o evento de faturamento financeiro a um indivduo especfico. Embora normalmente no seja usado como uma dimenso de anlise primria para proteger a privacidade do paciente, essencial para a validao de dados e pode ser usado para agregar todos os eventos de faturamento de um nico paciente para entender sua jornada financeira geral. Tamb m crucial para qualquer integrao potencial com dados de processos clnicos. Por que é importante Vincula dados financeiros a um paciente específico, permitindo a validação de dados e potencial para análises mais amplas de toda a jornada do paciente (deve ser tratado com cuidado devido à LGPD/privacidade). Onde obter Identificador fundamental encontrado em todo o sistema Epic, vinculado ao registro do paciente e aos dados da conta. Exemplos MRN-1234567MRN-8765432MRN-5551234 | |||
| ID do Sinistro ClaimId | O identificador exclusivo atribudo a uma reivindicao de seguro enviada a uma operadora. | ||
| Descrição Este atributo o ID especfico para o formulrio de reivindicao enviado a uma operadora. Um nico evento de faturamento pode envolver vrias reivindicaes se os servios forem refaturados ou houver recursos. Rastrear pelo ID da Reivindicao til para uma anlise detalhada dos subprocessos de envio de reivindicao e gesto de negativas. Ajuda a distinguir atividades relacionadas reivindicao inicial daquelas relacionadas a uma reivindicao subsequente e reenviada para o mesmo servio. Por que é importante Fornece um identificador granular para rastrear o ciclo de vida de cada envio de reivindicao especfico, o que crucial para analisar reenvios e recursos. Onde obter Gerado pelo módulo de gestão de guias do Epic Resolute quando uma guia é criada. Fica armazenado nas tabelas de dados de guias (claims). Exemplos CLM-2023-98765CLAIM-0012345623189A4567 | |||
| Nome do Pagador PayerName | O nome da seguradora, entidade governamental ou outra parte responsvel pelo pagamento. | ||
| Descrição Este atributo identifica a operadora principal associada ao evento de faturamento, como 'Amil', 'Bradesco Sade' ou 'Unimed'. Em casos de pagamento direto, pode indicar o paciente. Segmentar o processo por pagador uma t cnica de anlise poderosa. Pode revelar que certas operadoras tm taxas de negativa mais altas, ciclos de pagamento mais longos ou requisitos mais complexos. Esse insight permite a personalizao das estrat gias de faturamento para operadoras especficas para melhorar a eficincia e a velocidade do pagamento. Por que é importante Permite analisar a performance por pagador, revelando quais convênios têm altas taxas de glosa ou ciclos lentos de pagamento, possibilitando estratégias de acompanhamento focadas. Onde obter Esta informao faz parte dos detalhes de cobertura do paciente, vinculada conta hospitalar (HAR) no Epic Resolute. Exemplos Medicare Part BUnitedHealthcareAetna PPO | |||
| Sistema de Origem SourceSystem | O sistema de informao de onde os dados se originam. | ||
| Descrição Este atributo identifica o sistema de origem do registro, que para este contexto o Epic Resolute. Em ambientes com mltiplos sistemas integrados, este campo ajuda a diferenciar as origens dos dados. Embora possa parecer redundante em uma viso de sistema nico, uma prtica recomendada para governana e escalabilidade de dados. Garante clareza se dados de outros sistemas, como uma plataforma de agncia de cobrana separada, forem integrados posteriormente. Por que é importante Fornece linhagem e contexto de dados cruciais, garantindo clareza sobre a origem dos dados, o que vital para governana de dados e resoluo de problemas. Onde obter Este é tipicamente um valor estático adicionado durante o processo de extração e transformação de dados para rotular a origem do dataset. Exemplos Epic ResoluteEpicResolute_V2023 | |||
| Tempo Total do Ciclo de Receita TotalRevenueCycleTime | A durao total calculada desde o primeiro evento de servio at o pagamento final ou fechamento da conta. | ||
| Descrição Este um KPI ao nvel do caso que mede a durao de ponta a ponta do ciclo de receita para um nico evento de faturamento. Normalmente calculado como a diferena de tempo entre a atividade 'Service Rendered' e a atividade final 'Payment Received' ou 'Account Closed'. Essa m trica de alto nvel fornece uma viso holstica da eficincia geral do processo de RCM. Acompanhar esse KPI ao longo do tempo ajuda a medir o impacto das iniciativas de melhoria de processos e fornece um indicador chave da velocidade de converso de caixa. Por que é importante Oferece uma viso de alto nvel de ponta a ponta da eficincia do processo, medindo diretamente quanto tempo leva para converter um servio em dinheiro. Onde obter Esta uma m trica calculada dentro da ferramenta de Process Mining, filtrando os primeiros e ltimos eventos de cada caso e encontrando a diferena de tempo. Exemplos 259200038880005184000 | |||
| Última Atualização de Dados LastDataUpdate | O timestamp que indica quando os dados deste evento foram atualizados ou extraídos do sistema de origem pela última vez. | ||
| Descrição Este atributo mostra a atualidade dos dados. Indica a ltima vez que o registro foi extrado do Epic Resolute para o conjunto de dados de Process Mining. Isso importante para entender o quo atual a anlise e para fins de validao de dados. Ajuda os usurios a saberem se esto olhando para as informaes mais recentes disponveis e crtico para gerenciar os ciclos de atualizao de dados. Por que é importante Garante que os usuários entendam a atualidade dos dados analisados, algo crítico para tomar decisões de negócios precisas e atualizadas. Onde obter Este timestamp adicionado pelo processo ETL (Extrao, Transformao e Carga) durante a ingesto dos dados. Exemplos 2023-06-10T02:00:00Z2023-06-11T02:00:00Z | |||
| Valor Ajustado AdjustedAmount | O valor monetrio de uma transao de ajuste. | ||
| Descrição Este campo registra o valor monetrio especfico de um ajuste de conta. Pode ser um valor positivo ou negativo, representando um cr dito ou d bito no saldo da conta. Este valor a m trica principal para o dashboard 'Volume de Ajuste de Conta por Tipo'. Somar este valor por motivo de ajuste fornece uma imagem clara do impacto financeiro de diferentes tipos de ajustes, como quanta receita baixada devido a obrigaes contratuais versus quanto perdido por erros corrigveis. Por que é importante Quantifica o impacto financeiro dos ajustes de conta, tornando possvel medir a perda de receita e o custo das imprecises de faturamento. Onde obter Localizado nas tabelas de detalhes de transações financeiras no Epic Resolute, associado a transações do tipo ajuste. Exemplos -1250.45-50.0025.10 | |||
Atividades de Gestão do Ciclo de Receita
| Atividade | Descrição | ||
|---|---|---|---|
| Conta Fechada | Esta a atividade final, significando que o saldo devedor do evento de faturamento chegou a zero e no h mais atividades pendentes. Isso pode ser devido ao pagamento integral, ajustes ou uma baixa. | ||
| Por que é importante Este evento marca a concluso bem-sucedida do ciclo de receita para um evento de faturamento. A durao de ponta a ponta, do servio ao fechamento, um KPI crtico para a eficincia geral do processo. Onde obter Este normalmente um evento inferido. determinado pela identificao do momento em que o saldo da conta para o evento de faturamento se torna zero e permanece zero. Captura Inferido ao calcular o total acumulado do saldo da conta e identificar o timestamp da última transação que zerou o saldo. Tipo de evento inferred | |||
| Guia Glosada pelo Pagador | Representa o recebimento de uma notificao da operadora informando que a reivindicao foi negada. Isso capturado quando o Epic processa um aviso de remessa eletrnico (arquivo 835) ou quando um usurio lana manualmente uma negativa. | ||
| Por que é importante Esta atividade inicia um loop de retrabalho crtico. Analisar os motivos e volumes de negativas essencial para identificar as causas raiz, melhorar as taxas de pagamento na primeira tentativa e reduzir os atrasos de cobrana. Onde obter Registrado explicitamente como transação ou atualização de status na guia. As informações de glosa, incluindo códigos de motivo, costumam ser recebidas eletronicamente e lançadas na conta. Captura Filtre por tipos específicos de transação ou atualizações de status de guia que indicam glosa. Tipo de evento explicit | |||
| Guia Submetida ao Pagador | Isso marca o evento onde a reivindicao oficialmente enviada operadora de sade para adjudicao. No Epic, este um evento rastreado, registrado quando o arquivo eletrnico da reivindicao transmitido para a cmara de compensao (clearinghouse) ou operadora. | ||
| Por que é importante Este marco crucial, pois inicia a contagem do tempo para o pagamento pela operadora. Analisar isso ajuda a medir a eficincia do processo de transmisso de reivindicaes e apoia o KPI de Tempo de Entrega da Fatura Operadora. Onde obter Este um evento explcito registrado no Resolute. O registro da reivindicao ter um status de envio e um timestamp indicando quando foi enviada. Captura Capture o timestamp associado à mudança de status da guia para 'Enviada' ou 'Transmitida'. Tipo de evento explicit | |||
| Itens Capturados | Representa o registro formal de cobranas faturveis pelos servios prestados. No Epic, isso geralmente uma transao explcita lanada na conta do paciente, muitas vezes gerada automaticamente a partir de aes clnicas ou inserida manualmente. | ||
| Por que é importante Este um primeiro marco crtico. Medir a velocidade e a preciso da captura de cobranas ajuda a acelerar o processo de faturamento e a garantir que todos os servios prestados sejam faturados. Onde obter Registrado explicitamente nos logs de transação do Resolute. Cada cobrança é uma entrada discreta com data de lançamento, data do serviço e valor, geralmente nas tabelas como ARPB_TRANSACTIONS. Captura Capture transações de lançamento de cobranças a partir do log de transações financeiras do sistema. Tipo de evento explicit | |||
| Pagamento Lançado na Conta | Este o evento onde um pagamento recebido aplicado ou alocado a cobranas especficas na conta do paciente. Esta ao reduz o saldo devedor do evento de faturamento. | ||
| Por que é importante O lançamento eficiente de pagamentos é crucial para manter saldos precisos e encerrar eventos de faturamento. Isso permite identificar corretamente saldos remanescentes para faturamento secundário ou cobrança. Onde obter Esta uma transao explcita no Resolute. O lanamento do pagamento vincula uma transao de pagamento a uma ou mais transaes de cobrana, o que registrado nas tabelas de detalhes da transao. Captura Capture o registro de transação que vincula um pagamento a uma cobrança, identificável por tipos específicos de transação. Tipo de evento explicit | |||
| Pagamento Recebido | Representa o recebimento de pagamento de uma operadora ou paciente. Esse evento normalmente registrado quando um aviso de remessa eletrnico (ERA) carregado ou um cheque manual inserido no sistema. | ||
| Por que é importante Esta atividade um marco importante que indica que a receita est entrando. O tempo entre o envio da reivindicao e o recebimento do pagamento uma medida fundamental do desempenho das contas a receber. Onde obter Registrado explicitamente como uma transação de pagamento no Resolute. Essas transações têm data, origem e valor, geralmente antes de serem totalmente vinculadas a cobranças individuais. Captura Capture transações de pagamento do log financeiro, geralmente identificadas por tipos específicos de transação. Tipo de evento explicit | |||
| Serviço Prestado | Esta atividade marca o momento em que um servio clnico prestado ao paciente, o que inicia o evento de faturamento. Isso geralmente capturado a partir do Epic EHR (EpicCare) quando um m dico finaliza uma consulta ou procedimento. | ||
| Por que é importante Este o principal evento de incio do ciclo de receita. Analisar o tempo deste ponto at a captura da cobrana crtico para identificar atrasos no incio do faturamento e potenciais perdas de receita. Onde obter Este evento normalmente inferido a partir de timestamps de servio ou consulta nos mdulos clnicos que esto vinculados conta de faturamento. A data do servio na transao de cobrana o ponto de dados principal. Captura Inferido a partir da data do serviço associada à primeira transação de cobrança do evento de faturamento. Tipo de evento inferred | |||
| Acompanhamento de Glosa Iniciado | Esta atividade marca o incio do processo interno de reviso e resoluo de uma reivindicao negada. Geralmente capturada quando um usurio assume a responsabilidade pela reivindicao negada em uma fila de trabalho ou altera seu status. | ||
| Por que é importante Rastrear isso ajuda a medir a capacidade de resposta da equipe de gesto de negativas. Atrasos entre uma negativa e o incio do acompanhamento podem estender o ciclo de receita desnecessariamente. Onde obter Isso normalmente inferido a partir de mudanas no status da reivindicao ou no histrico de atribuio dentro das filas de trabalho do Epic. Por exemplo, o status da reivindicao pode mudar de 'Denied' para 'In Review'. Captura Inferir a partir de uma mudança no status da guia ou entrada de audit log que mostra que um usuário começou a tratar a glosa. Tipo de evento inferred | |||
| Ajuste de Conta Realizado | Esta atividade representa uma transao que no de pagamento e que altera o saldo da conta, como um ajuste contratual, uma baixa de pequeno saldo ou um desconto de cortesia. Isso registrado como um tipo de transao especfico. | ||
| Por que é importante Analisar ajustes é fundamental para identificar perdas de receita. Volumes altos de certos tipos de ajuste podem indicar problemas com tabelas de preços, contratos ou políticas internas. Onde obter Registrado explicitamente como transações de ajuste nos logs financeiros do Resolute. Cada ajuste terá um tipo específico ou código de motivo associado. Captura Filtre por tipos de transação que correspondem a ajustes financeiros ou baixas (write-offs). Tipo de evento explicit | |||
| Guia Gerada | Esta atividade significa a criao pelo sistema de uma reivindicao formal ou fatura com base nas cobranas capturadas. uma etapa preparatria antes de a reivindicao ser enviada operadora ou ao paciente. | ||
| Por que é importante Rastrear a gerao de reivindicaes ajuda a isolar atrasos entre a captura de cobranas e a preparao delas para envio. uma etapa interna fundamental que pode impactar a pontualidade geral do faturamento. Onde obter Isso geralmente registrado quando um job em lote de faturamento ou gerao de reivindicaes executado. O sistema registrar um timestamp quando o arquivo de reivindicao (como um arquivo 837) for criado para uma determinada conta. Captura Identifique entradas de log ou mudanças de status que indiquem que a guia foi compilada e está pronta para submissão. Tipo de evento explicit | |||
| Guia Reapresentada | Este evento ocorre aps uma reivindicao negada ter sido corrigida e enviada de volta operadora. Este um evento de envio distinto que est vinculado reivindicao original. | ||
| Por que é importante Esta uma parte fundamental do loop de retrabalho. Medir o tempo para reenvio e a taxa de sucesso das reivindicaes reenviadas vital para entender a eficcia do processo de resoluo de negativas. Onde obter Este um evento explcito semelhante ao envio inicial, mas frequentemente marcado como um reenvio. O registro da reivindicao mostrar um novo timestamp de envio e pode incluir um cdigo de reenvio. Captura Capture o timestamp de uma submissão de guia marcada como correção ou reenvio. Tipo de evento explicit | |||
| Saldo Enviado para Cobrança | Isso marca o momento em que um saldo de conta no pago transferido para um processo de cobrana interno ou externo. Geralmente uma alterao de status explcita na conta ou no evento de faturamento. | ||
| Por que é importante Esta atividade inicia o estgio final de recuperao de saldos no pagos. Acompanhar a taxa de sucesso e o tempo de ciclo do processo de cobrana vital para minimizar a inadimplncia. Onde obter Este normalmente um evento explcito. O Epic possui funes para transferir contas para agncias de cobrana, o que cria uma entrada de log ou uma alterao de status na conta. Captura Identifique a mudança de status ou transação que indica que uma conta foi enviada para uma agência de cobrança externa. Tipo de evento explicit | |||
Guias de Extração
Etapas
- Estabeleça a Conexão com o Banco de Dados: Obtenha credenciais de apenas leitura para o banco de dados Epic Clarity. Use um cliente SQL padrão, como o DBeaver ou Microsoft SQL Server Management Studio, para se conectar ao servidor.
- Identifique as Tabelas Principais: As tabelas fundamentais para esta extração incluem
HSP_ACCOUNTpara informações do caso,HSP_TRANSACTIONSpara eventos financeiros,CLP_CLAIM_INFOpara o status das guias eF_ARHB_TX_SET_POST_HXpara detalhes de lançamento de pagamentos. Você também fará joins com arquivos mestres comoCLARITY_EMPpara detalhes do usuário. - Defina o Escopo: Antes de escrever a consulta, determine o escopo da análise. Defina um intervalo de datas específico (geralmente de 3 a 6 meses) e identifique áreas de serviço hospitalar (
SERV_AREA_ID) ou classes de conta que deseja incluir ou excluir. - Desenvolva a Consulta SQL: Construa uma consulta SQL usando uma Common Table Expression (CTE) para selecionar primeiro o conjunto de valores
HSP_ACCOUNT_IDdentro do escopo definido. Esta será a população base dos eventos de faturamento. - Una as Consultas de Atividades Individuais: Para cada uma das 12 atividades exigidas, escreva um comando
SELECTseparado que busque dados das tabelas relevantes. Faça o join com sua CTE inicial para garantir que está analisando apenas as contas pretendidas. - 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 coeso. Isso empilha as linhas de cada consulta verticalmente. - Mapeie para o Esquema Padrão: Em cada comando
SELECT, use aliases nas colunas para corresponder ao esquema do ProcessMind:BillingEvent,ActivityName,EventTimestamp,ResponsibleUser, etc. UseNULLpara atributos que não se aplicam a uma atividade específica. - Execute e Refine a Consulta: Rode a consulta completa no banco Clarity. Devido ao tamanho das tabelas, isso pode levar um tempo considerável. Se a performance for um problema, restrinja o intervalo de datas ou adicione filtros mais específicos na CTE inicial.
- Revise a Saída: Quando a consulta terminar, inspecione as primeiras centenas de linhas. Verifique se todas as colunas estão presentes, se os timestamps estão em formato consistente e se os diferentes valores de
ActivityNameaparecem como esperado. - Exporte para CSV: Exporte todo o conjunto de resultados do seu cliente SQL para um arquivo CSV. Certifique-se de que o arquivo use codificação UTF-8 e inclua um cabeçalho com os nomes de coluna corretos.
- Prepare para o Upload: Antes de carregar no ProcessMind, abra o arquivo CSV para confirmar que não há erros de formatação. Verifique se o formato do timestamp está consistente (ex:
YYYY-MM-DD HH:MI:SS). O arquivo está pronto para ingestão.
Configuração
- Conexão com Banco de Dados: É necessária uma conta de usuário com permissão de apenas leitura e acesso ao banco de dados Epic Clarity.
- Parâmetros de Intervalo de Datas: A consulta fornecida utiliza as variáveis
@StartDatee@EndDate. Elas devem ser configuradas para definir o período da análise. Recomendamos um intervalo de 3 a 6 meses para equilibrar o volume de dados e a performance. - Mapeamento de Tabelas e Colunas: A consulta assume nomes padrão de tabelas e colunas do Clarity. Como a configuração ou versão do Epic na sua organização pode variar, pode ser necessário ajustar nomes de tabelas, colunas ou condições de join.
- Códigos de Transação e Status: A consulta inclui espaços reservados como
[Your Denial Tx Type]e[Your Collections Status Code]. Consulte os administradores do sistema Epic ou revise os arquivos mestres, comoZC_TX_TYPEouZC_ACCOUNT_STATUS, para encontrar os códigos corretos da sua instância. - Filtragem: Para melhor performance e análises específicas, adicione filtros na CTE inicial
BaseAccounts. Filtros comuns incluemSERV_AREA_IDpara limitar por área de serviço hospitalar ouACCOUNT_CLASS_Cpara focar em faturamentos 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
- Estabeleça a Conexão com o Banco de Dados: Obtenha credenciais de apenas leitura para o banco de dados Epic Clarity. Use um cliente SQL padrão, como o DBeaver ou Microsoft SQL Server Management Studio, para se conectar ao servidor.
- Identifique as Tabelas Principais: As tabelas fundamentais para esta extração incluem
HSP_ACCOUNTpara informações do caso,HSP_TRANSACTIONSpara eventos financeiros,CLP_CLAIM_INFOpara o status das guias eF_ARHB_TX_SET_POST_HXpara detalhes de lançamento de pagamentos. Você também fará joins com arquivos mestres comoCLARITY_EMPpara detalhes do usuário. - Defina o Escopo: Antes de escrever a consulta, determine o escopo da análise. Defina um intervalo de datas específico (geralmente de 3 a 6 meses) e identifique áreas de serviço hospitalar (
SERV_AREA_ID) ou classes de conta que deseja incluir ou excluir. - Desenvolva a Consulta SQL: Construa uma consulta SQL usando uma Common Table Expression (CTE) para selecionar primeiro o conjunto de valores
HSP_ACCOUNT_IDdentro do escopo definido. Esta será a população base dos eventos de faturamento. - Una as Consultas de Atividades Individuais: Para cada uma das 12 atividades exigidas, escreva um comando
SELECTseparado que busque dados das tabelas relevantes. Faça o join com sua CTE inicial para garantir que está analisando apenas as contas pretendidas. - 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 coeso. Isso empilha as linhas de cada consulta verticalmente. - Mapeie para o Esquema Padrão: Em cada comando
SELECT, use aliases nas colunas para corresponder ao esquema do ProcessMind:BillingEvent,ActivityName,EventTimestamp,ResponsibleUser, etc. UseNULLpara atributos que não se aplicam a uma atividade específica. - Execute e Refine a Consulta: Rode a consulta completa no banco Clarity. Devido ao tamanho das tabelas, isso pode levar um tempo considerável. Se a performance for um problema, restrinja o intervalo de datas ou adicione filtros mais específicos na CTE inicial.
- Revise a Saída: Quando a consulta terminar, inspecione as primeiras centenas de linhas. Verifique se todas as colunas estão presentes, se os timestamps estão em formato consistente e se os diferentes valores de
ActivityNameaparecem como esperado. - Exporte para CSV: Exporte todo o conjunto de resultados do seu cliente SQL para um arquivo CSV. Certifique-se de que o arquivo use codificação UTF-8 e inclua um cabeçalho com os nomes de coluna corretos.
- Prepare para o Upload: Antes de carregar no ProcessMind, abra o arquivo CSV para confirmar que não há erros de formatação. Verifique se o formato do timestamp está consistente (ex:
YYYY-MM-DD HH:MI:SS). O arquivo está pronto para ingestão.
Configuração
- Conexão com Banco de Dados: É necessária uma conta de usuário com permissão de apenas leitura e acesso ao banco de dados Epic Clarity.
- Parâmetros de Intervalo de Datas: A consulta fornecida utiliza as variáveis
@StartDatee@EndDate. Elas devem ser configuradas para definir o período da análise. Recomendamos um intervalo de 3 a 6 meses para equilibrar o volume de dados e a performance. - Mapeamento de Tabelas e Colunas: A consulta assume nomes padrão de tabelas e colunas do Clarity. Como a configuração ou versão do Epic na sua organização pode variar, pode ser necessário ajustar nomes de tabelas, colunas ou condições de join.
- Códigos de Transação e Status: A consulta inclui espaços reservados como
[Your Denial Tx Type]e[Your Collections Status Code]. Consulte os administradores do sistema Epic ou revise os arquivos mestres, comoZC_TX_TYPEouZC_ACCOUNT_STATUS, para encontrar os códigos corretos da sua instância. - Filtragem: Para melhor performance e análises específicas, adicione filtros na CTE inicial
BaseAccounts. Filtros comuns incluemSERV_AREA_IDpara limitar por área de serviço hospitalar ouACCOUNT_CLASS_Cpara focar em faturamentos 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;