Il Suo Template dei dati per la gestione del ciclo dei ricavi
Il Suo Template dei dati per la gestione del ciclo dei ricavi
- Attributi consigliati da raccogliere
- Attività principali da monitorare
- Indicazioni per l'estrazione
Attributi della gestione del ciclo attivo
| Nome | Descrizione | ||
|---|---|---|---|
| Evento di fatturazione BillingEvent | L'identificativo univoco di una singola erogazione di servizio o consegna di prodotto che genera un addebito e funge da identificativo principale del caso. | ||
| Descrizione Il Billing Event è l'identificativo principale che collega tutte le attività del ciclo dei ricavi relative a uno specifico elemento fatturabile. Inizia quando viene erogato un servizio e si conclude quando il conto è completamente saldato o chiuso. Nell'analisi di Process Mining, questo attributo è essenziale per ricostruire il percorso end-to-end di ogni addebito. Consente di monitorare attività quali acquisizione dell'addebito, invio della richiesta, contabilizzazione del pagamento e gestione dei rifiuti per singoli eventi di fatturazione, offrendo una visione chiara del flusso di processo e delle sue varianti. Perché è importante È il Case ID fondamentale, indispensabile per collegare tutti i passaggi correlati del processo e analizzare l'intero ciclo di vita della generazione e della riscossione dei ricavi per ciascun servizio. Dove reperirlo Spesso si tratta di un identificativo univoco per un conto ospedaliero (HAR) o per una specifica sessione di addebito in Epic Resolute. Per informazioni sulle tabelle specifiche, come i record HAR o Charge Session, consultare la documentazione di Epic Resolute. Esempi BE10098765BE20012345BE30054321 | |||
| Nome dell'attività ActivityName | Il nome dello specifico evento o task eseguito nell'ambito del processo di gestione del ciclo dei ricavi. | ||
| Descrizione Questo attributo descrive un singolo passaggio del ciclo dei ricavi, ad esempio 'Addebiti acquisiti', 'Richiesta inviata al pagatore' o 'Pagamento ricevuto'. Ogni attività rappresenta una tappa distinta nel processo di fatturazione e riscossione del pagamento per un servizio. L'analisi delle attività costituisce la base del Process Mining. Consente di visualizzare la mappa del processo, identificare i percorsi più comuni, individuare i colli di bottiglia tra i passaggi e misurare la conformità alle procedure operative standard. Perché è importante Definisce i passaggi della mappa del processo, rendendo possibile visualizzare, analizzare e ottimizzare il flusso di lavoro nel ciclo dei ricavi. Dove reperirlo Generalmente deriva da Event Log, audit trail o record delle modifiche di stato nei moduli di fatturazione e gestione delle richieste di Epic Resolute. Esempi Addebiti acquisitiRichiesta di rimborso inviata al pagatorePagamento ricevutoConto chiuso | |||
| Timestamp dell'evento EventTimestamp | La data e l'ora precise in cui si è verificata una specifica attività o un determinato evento. | ||
| Descrizione Il timestamp dell'evento registra il momento in cui si è svolta un'attività. Questi dati temporali sono fondamentali per comprendere la tempistica e la sequenza degli eventi nel ciclo dei ricavi. Nell'analisi, i timestamp vengono utilizzati per calcolare le durate tra le attività, ad esempio il ritardo nell'acquisizione degli addebiti o il tempo di contabilizzazione dei pagamenti. Consentono di individuare i colli di bottiglia, misurare i tempi di ciclo e analizzare le prestazioni del processo in periodi diversi. Timestamp accurati sono essenziali per quasi tutti i KPI e i Dashboard basati sul tempo. Perché è importante Questo attributo è essenziale per calcolare tutte le metriche basate sul tempo, inclusi tempi di ciclo e durate, fondamentali per individuare ritardi e inefficienze. Dove reperirlo Si trova nelle tabelle delle transazioni o degli Event Log di Epic Resolute, associato a ogni attività registrata. I campi presentano spesso suffissi come Dt, DTTM o Time. Esempi 2023-04-15T09:30:00Z2023-04-16T11:05:21Z2023-05-01T14:00:00Z | |||
| Causale della rettifica AdjustmentReason | Il motivo di una rettifica manuale o automatica apportata al saldo del conto di un paziente. | ||
| Descrizione Questo attributo spiega perché il saldo di un conto è stato modificato al di fuori di un pagamento o di un addebito standard. Le motivazioni possono includere accordi contrattuali con i pagatori, stralci di piccoli saldi o correzioni di errori di contabilizzazione. È essenziale per il Dashboard 'Volume delle rettifiche del conto per tipo'. Analizzando le causali delle rettifiche, le organizzazioni possono individuare le fonti di perdita di ricavi, comprendere l'impatto dei contratti con i pagatori e rilevare potenziali inefficienze o errori nel processo di fatturazione. Perché è importante Fornisce informazioni sulle perdite di ricavi e sull'accuratezza della fatturazione, spiegando perché i saldi dei conti vengono modificati e contribuendo a ridurre gli stralci non necessari. Dove reperirlo Si trova nei dettagli delle transazioni relative alle registrazioni di rettifica nel modulo di contabilità dei pazienti di Epic Resolute. Esempi Rettifica contrattualeStorno di piccoli saldiCorrezione di addebito duplicato | |||
| Codice causale del rifiuto DenialReasonCode | Un codice standardizzato che indica il motivo per cui un pagatore ha rifiutato una richiesta inviata. | ||
| Descrizione Quando un pagatore rifiuta una richiesta, fornisce un codice causale che spiega il rifiuto, ad esempio 'Servizio non coperto', 'Richiesta duplicata' o 'Richieste informazioni aggiuntive'. Questi codici sono spesso standardizzati come Claim Adjustment Reason Codes (CARC). Questo attributo è il fondamento del Dashboard 'Tassi e motivi dei rifiuti delle richieste'. Analizzare la frequenza dei diversi codici di rifiuto aiuta a individuare le cause principali, come problemi di accreditamento, errori di codifica o autorizzazioni preventive mancanti, consentendo di avviare iniziative di miglioramento mirate. Perché è importante Spiega direttamente perché le richieste vengono rifiutate, fornendo informazioni operative necessarie per ridurre i tassi di rifiuto, prevenire perdite di ricavi e accelerare i pagamenti. Dove reperirlo Questi dati si trovano nelle transazioni di risposta alle richieste, come un file ANSI 835, ricevute dai pagatori e archiviate nel modulo di gestione delle richieste di Epic Resolute. Esempi CO-16: alla richiesta di rimborso o al servizio mancano le informazioni necessarieOA-18: richiesta di rimborso o servizio duplicatoPR-96: addebito o addebiti non coperti | |||
| Reparto fatturazione BillingDepartment | Il reparto o il team funzionale responsabile dell'evento o dell'attività di fatturazione. | ||
| Descrizione Questo attributo indica l'unità organizzativa, ad esempio 'Fatturazione ricoveri', 'Fatturazione prestazioni ambulatoriali' o 'Team di gestione dei rifiuti', associata all'evento di fatturazione o responsabile dell'esecuzione di una specifica attività. Questa dimensione è fondamentale per il Dashboard 'Metriche delle prestazioni del reparto fatturazione', poiché consente di confrontare affiancati indicatori chiave come i tassi di rifiuto o i tempi di acquisizione degli addebiti. Aiuta il management a identificare i reparti più performanti, standardizzare le best practice e allocare efficacemente le risorse. Perché è importante Consente di confrontare le prestazioni tra reparti diversi, aiutando a individuare best practice, aree che necessitano di miglioramenti e risorse aggiuntive. Dove reperirlo Queste informazioni possono essere collegate al record dell'utente, al conto del paziente o alla sede di erogazione del servizio in Epic Resolute. Esempi Fatturazione cardiologicaRCM radiologicoUfficio centrale di fatturazione | |||
| Saldo residuo OutstandingBalance | L'importo ancora dovuto dal pagatore o dal paziente per l'evento di fatturazione. | ||
| Descrizione Questo attributo rappresenta il saldo corrente dei crediti verso clienti per uno specifico evento di fatturazione al momento dell'attività. Riflette lo stato finanziario del caso durante tutto il suo ciclo di vita. Il saldo residuo è fondamentale per la reportistica finanziaria e per il 'Report sull'anzianità dei saldi residui'. Analizzare questo valore nel tempo e in base a dimensioni diverse, come pagatore o reparto, aiuta a stabilire le priorità delle attività di recupero, gestire il flusso di cassa e valutare il rischio finanziario. Perché è importante Misura direttamente l'impatto finanziario dei ritardi di processo ed è essenziale per stabilire le priorità del recupero crediti, gestire il flusso di cassa e comprendere i crediti verso clienti. Dove reperirlo È un campo fondamentale del record del conto del paziente o del conto ospedaliero (HAR) in Epic Resolute. Si tratta di un saldo progressivo aggiornato dalle transazioni finanziarie. Esempi 1500.00250.750.00 | |||
| Tipo di servizio ServiceType | La categoria o il tipo di servizio medico erogato. | ||
| Descrizione Questo attributo classifica il servizio fatturabile, ad esempio come 'Radiologia', 'Chirurgia', 'Consulto' o 'Visita al pronto soccorso'. Fornisce un contesto clinico ai dati finanziari. Analizzare il ciclo dei ricavi per tipo di servizio può far emergere variazioni di processo specifiche di determinate aree cliniche. Ad esempio, le procedure chirurgiche possono richiedere processi più complessi per l'acquisizione degli addebiti e le autorizzazioni rispetto a una visita ambulatoriale standard, generando comportamenti e criticità di processo differenti. Perché è importante Fornisce un contesto clinico ai dati finanziari, consentendo di analizzare in che modo i diversi tipi di servizio medico influenzano il processo del ciclo dei ricavi e la sua efficienza. Dove reperirlo Deriva dal charge description master (CDM), dalla linea di servizio o dal reparto associato alla transazione di addebito in Epic. Esempi Intervento chirurgico in regime di ricoveroRadiologia ambulatorialeServizi di emergenza | |||
| Utente responsabile ResponsibleUser | L'identificativo dell'utente o del dipendente che ha eseguito l'attività. | ||
| Descrizione Questo attributo acquisisce l'ID utente, il nome o il numero di matricola della persona responsabile del completamento di una specifica attività nel ciclo dei ricavi. Può trattarsi del medico che ha inserito gli addebiti, dell'addetto alla fatturazione che ha inviato una richiesta o dell'addetto al recupero crediti che ha effettuato il follow-up su un rifiuto. L'analisi per utente aiuta a identificare i migliori risultati, individuare le esigenze formative e comprendere la distribuzione dei carichi di lavoro. È fondamentale per la gestione delle prestazioni e per analizzare le deviazioni dal processo associate a specifiche persone o ruoli. Perché è importante Consente di analizzare le prestazioni per persona o ruolo, aiutando a individuare opportunità formative, squilibri nei carichi di lavoro e colli di bottiglia legati alle risorse. Dove reperirlo Generalmente si trova negli audit trail o nei registri delle transazioni di Epic Resolute, spesso collegato a una tabella anagrafica degli utenti, ad esempio il record EMP. Esempi j.doebsmith123User7890 | |||
| Data di scadenza del pagamento PaymentDueDate | La data entro la quale è previsto il pagamento del servizio fatturato. | ||
| Descrizione Questo attributo specifica il termine per il pagamento, indicato in fattura o stabilito dai contratti con i pagatori. Funge da riferimento per misurare la puntualità dei pagamenti. La data di scadenza del pagamento è essenziale per creare il 'Report sull'anzianità dei saldi residui'. Confrontando la data corrente con la data di scadenza dei saldi aperti, i crediti verso clienti possono essere classificati in fasce di anzianità, ad esempio da 0 a 30 giorni o da 31 a 60 giorni oltre la scadenza, aiutando a stabilire le priorità delle attività di recupero sui conti più arretrati. Perché è importante Costituisce la base per l'analisi dell'anzianità dei crediti verso clienti, fondamentale per stabilire le priorità del recupero crediti e gestire il rischio finanziario derivante dalle fatture non pagate. Dove reperirlo Questa data viene spesso calcolata in base alla data della fattura e ai termini di pagamento memorizzati nel contratto con il pagatore o nelle informazioni sul conto del paziente in Epic. Esempi 2023-05-302023-06-152023-07-01 | |||
| È automatizzato IsAutomated | Un flag booleano che indica se l'attività è stata eseguita da un sistema o da un processo automatizzato. | ||
| Descrizione Questo flag distingue tra le attività eseguite automaticamente dal sistema, come la generazione automatica delle richieste o i controlli di idoneità, e quelle eseguite manualmente da un utente. L'analisi di questo attributo aiuta a comprendere il livello di automazione del processo. Può essere utilizzata per confrontare l'efficienza e i tassi di errore delle attività automatizzate e manuali, individuare opportunità di ulteriore automazione e monitorare le prestazioni dei bot o delle regole di sistema esistenti. Perché è importante Distingue tra attività gestite dal sistema e attività gestite da persone, aspetto fondamentale per valutare l'impatto dell'automazione e individuare nuove opportunità di automazione. Dove reperirlo Viene spesso dedotto verificando se il 'ResponsibleUser' di un'attività è un account di sistema o di servizio, oppure contrassegnando specifici nomi di attività noti per essere automatizzati. Esempi truefalse | |||
| ID del paziente PatientId | L'identificativo univoco del paziente che riceve il servizio. | ||
| Descrizione Questo attributo è il Medical Record Number (MRN) o un altro identificativo univoco del paziente. Collega l'evento finanziario di fatturazione a una persona specifica. Sebbene non venga generalmente utilizzato come dimensione primaria di analisi per tutelare la privacy del paziente, è essenziale per la convalida dei dati e può essere usato per aggregare tutti gli eventi di fatturazione di un singolo paziente, così da comprenderne il percorso finanziario complessivo. È inoltre fondamentale per eventuali integrazioni con dati relativi ai processi clinici. Perché è importante Collega i dati finanziari a un paziente specifico, consentendo la convalida dei dati e potenzialmente un'analisi più ampia dell'intero percorso del paziente, pur dovendo essere gestito con attenzione per motivi di privacy. Dove reperirlo Un identificativo fondamentale presente in tutto Epic, collegato ai record di registrazione e del conto del paziente. Esempi MRN-1234567MRN-8765432MRN-5551234 | |||
| ID della richiesta ClaimId | L'identificativo univoco assegnato a una richiesta assicurativa inviata a un pagatore. | ||
| Descrizione Questo attributo è l'ID specifico del modulo di richiesta, ad esempio CMS-1500 o UB-04, inviato a un pagatore. Un singolo evento di fatturazione può comprendere più richieste se i servizi vengono fatturati nuovamente o contestati. Il monitoraggio per Claim ID è utile per un'analisi dettagliata dei sotto-processi di invio delle richieste e gestione dei rifiuti. Aiuta a distinguere le attività relative alla richiesta iniziale da quelle relative a una richiesta successiva e reinviata per lo stesso servizio. Perché è importante Fornisce un identificativo granulare per monitorare il ciclo di vita di ogni specifico invio di una richiesta, fondamentale per analizzare reinvii e ricorsi. Dove reperirlo Generato dal modulo di gestione delle richieste di Epic Resolute quando viene creata una richiesta. Viene memorizzato nelle tabelle dei dati delle richieste. Esempi CLM-2023-98765CLAIM-0012345623189A4567 | |||
| Importo rettificato AdjustedAmount | Il valore monetario di una transazione di rettifica. | ||
| Descrizione Questo campo registra l'importo specifico in valuta della rettifica di un conto. Può avere valore positivo o negativo e rappresentare un accredito o un addebito sul saldo del conto. Questo importo è la metrica principale del Dashboard 'Volume delle rettifiche del conto per tipo'. La somma di questo valore per causale di rettifica offre un quadro chiaro dell'impatto finanziario dei diversi tipi di rettifica, ad esempio dei ricavi stralciati per obblighi contrattuali rispetto a quelli persi a causa di errori correggibili. Perché è importante Quantifica l'impatto finanziario delle rettifiche dei conti, rendendo possibile misurare le perdite di ricavi e il costo delle inesattezze nella fatturazione. Dove reperirlo Si trova nelle tabelle di dettaglio delle transazioni finanziarie di Epic Resolute, associato alle transazioni di tipo rettifica. Esempi -1250.45-50.0025.10 | |||
| Nome del pagatore PayerName | Il nome della compagnia assicurativa, dell'ente pubblico o di un'altra parte responsabile del pagamento. | ||
| Descrizione Questo attributo identifica il pagatore principale associato all'evento di fatturazione, ad esempio 'Blue Cross Blue Shield', 'Medicare' o 'Aetna'. Nei casi di pagamento diretto, può indicare il paziente. Segmentare il processo per pagatore è una tecnica di analisi efficace. Può rivelare che determinati pagatori presentano tassi di rifiuto più elevati, cicli di pagamento più lunghi o requisiti più complessi. Queste informazioni consentono di adattare le strategie di fatturazione ai singoli pagatori, migliorando l'efficienza e la rapidità dei pagamenti. Perché è importante Consente di analizzare le prestazioni per pagatore, evidenziando quelli con tassi di rifiuto elevati o cicli di pagamento lenti e permettendo di definire strategie di follow-up mirate. Dove reperirlo Queste informazioni fanno parte dei dettagli della copertura del paziente, collegati al conto ospedaliero (HAR) in Epic Resolute. Esempi Medicare Parte BUnitedHealthcareAetna PPO | |||
| Ora di fine dell'evento EventEndTime | Il timestamp che indica quando un'attività è stata completata, utile per calcolare la durata dell'attività. | ||
| Descrizione Questo attributo registra l'ora di completamento di un'attività. Sebbene molte attività siano eventi istantanei in cui StartTime coincide con EndTime, alcune attività hanno una durata misurabile, come una telefonata di follow-up su un rifiuto. Quando disponibile, EndTime consente di calcolare direttamente il tempo di elaborazione dell'attività ('EndTime' - 'StartTime'). Questo è più accurato della deduzione della durata dall'ora di inizio dell'attività successiva, poiché tiene conto del tempo di inattività tra i passaggi. È un componente fondamentale per calcolare l'attributo 'ProcessingTime'. Perché è importante Consente di calcolare con precisione il tempo necessario per completare ogni attività, aspetto fondamentale per individuare le attività inefficienti e misurare la produttività delle risorse. Dove reperirlo Può essere disponibile in alcuni moduli di Epic Resolute che monitorano l'inizio e la fine delle attività, come i registri delle code di lavoro o della gestione delle attività. Spesso non viene registrato esplicitamente. Esempi 2023-04-15T09:45:00Z2023-04-16T11:15:30Z2023-05-01T14:02:00Z | |||
| Sistema di origine SourceSystem | Il sistema informativo da cui provengono i dati. | ||
| Descrizione Questo attributo identifica il sistema di origine del record, che in questo contesto è Epic Resolute. In ambienti con più sistemi integrati, questo campo aiuta a distinguere l'origine dei dati. Sebbene possa sembrare ridondante in una vista basata su un unico sistema, rappresenta una best practice per la governance dei dati e la scalabilità. Garantisce chiarezza qualora in futuro vengano integrati dati provenienti da altri sistemi, ad esempio da una piattaforma separata per le agenzie di recupero crediti. Perché è importante Fornisce informazioni essenziali sulla provenienza dei dati e sul relativo contesto, garantendo chiarezza sull'origine dei dati, fondamentale per la governance e la risoluzione dei problemi. Dove reperirlo Generalmente si tratta di un valore statico aggiunto durante il processo di estrazione e trasformazione dei dati per indicare l'origine del dataset. Esempi Epic ResoluteEpicResolute_V2023 | |||
| Tempo totale del ciclo dei ricavi TotalRevenueCycleTime | La durata totale calcolata dal primo evento relativo al servizio fino al pagamento finale o alla chiusura del conto. | ||
| Descrizione Si tratta di un KPI a livello di caso che misura la durata end-to-end del ciclo dei ricavi per un singolo evento di fatturazione. Viene generalmente calcolato come differenza temporale tra l'attività 'Servizio erogato' e l'attività finale 'Pagamento ricevuto' o 'Conto chiuso'. Questa metrica di alto livello offre una visione completa dell'efficienza complessiva del processo RCM. Monitorare questo KPI nel tempo aiuta a misurare l'impatto delle iniziative di miglioramento del processo e fornisce un indicatore chiave della velocità di conversione in liquidità. Perché è importante Fornisce una visione end-to-end di alto livello dell'efficienza del processo e misura direttamente il tempo necessario per convertire un servizio in liquidità. Dove reperirlo È una metrica calcolata nello strumento di Process Mining filtrando il primo e l'ultimo evento di ogni caso e determinando la differenza temporale. Esempi 259200038880005184000 | |||
| Ultimo aggiornamento dei dati LastDataUpdate | Il timestamp che indica quando i dati relativi a questo evento sono stati aggiornati o estratti l'ultima volta dal sistema di origine. | ||
| Descrizione Questo attributo indica il livello di aggiornamento dei dati. Mostra l'ultima volta in cui il record è stato acquisito da Epic Resolute nel dataset di Process Mining. È importante per comprendere la tempestività dell'analisi e per convalidare i dati. Aiuta a sapere se si stanno esaminando le informazioni più aggiornate disponibili ed è fondamentale per gestire i cicli di aggiornamento dei dati. Perché è importante Consente agli utenti di comprendere l'aggiornamento dei dati analizzati, aspetto fondamentale per prendere decisioni aziendali accurate e basate sulle informazioni più recenti. Dove reperirlo Questo timestamp viene aggiunto dal processo ETL (Extract, Transform, Load) durante l'acquisizione dei dati. Esempi 2023-06-10T02:00:00Z2023-06-11T02:00:00Z | |||
Attività di gestione del ciclo attivo
| Attività | Descrizione | ||
|---|---|---|---|
| Addebiti acquisiti | Rappresenta la registrazione formale degli addebiti fatturabili relativi ai servizi erogati. In Epic, si tratta generalmente di una transazione esplicita registrata sul conto del paziente, spesso generata automaticamente dalle azioni cliniche o inserita manualmente. | ||
| Perché è importante Questo è un primo traguardo fondamentale. Misurare la velocità e l'accuratezza dell'acquisizione degli addebiti aiuta ad accelerare il processo di fatturazione e ad assicurare che tutti i servizi erogati vengano fatturati. Dove reperirlo Registrato esplicitamente nei log delle transazioni di Resolute. Ogni addebito è una voce distinta con data di registrazione, data del servizio e importo, spesso presente in tabelle come ARPB_TRANSACTIONS. Acquisizione Acquisire le transazioni di registrazione degli addebiti dal log delle transazioni finanziarie del sistema. Tipo di evento explicit | |||
| Conto chiuso | Questa è l'attività finale e indica che il saldo residuo dell'evento di fatturazione è pari a zero e non vi sono altre attività in sospeso. Ciò può dipendere da un pagamento completo, da rettifiche o da uno stralcio. | ||
| Perché è importante Questo evento indica il completamento con successo del ciclo dei ricavi per un evento di fatturazione. La durata end-to-end dal servizio alla chiusura è un KPI fondamentale dell'efficienza complessiva del processo. Dove reperirlo Si tratta generalmente di un evento dedotto. Viene determinato individuando il momento in cui il saldo del conto relativo all'evento di fatturazione diventa pari a zero e rimane tale. Acquisizione Deducibile calcolando il totale progressivo del saldo del conto e individuando il timestamp dell'ultima transazione che ha portato il saldo a zero. Tipo di evento inferred | |||
| Pagamento contabilizzato sul conto | È l'evento in cui un pagamento ricevuto viene applicato o allocato a specifici addebiti sul conto del paziente. Questa azione riduce il saldo residuo dell'evento di fatturazione. | ||
| Perché è importante La contabilizzazione efficiente dei pagamenti è fondamentale per mantenere saldi dei conti accurati e chiudere gli eventi di fatturazione. Consente di identificare correttamente i saldi residui da destinare a una fatturazione secondaria o al recupero crediti. Dove reperirlo Si tratta di una transazione esplicita in Resolute. La contabilizzazione del pagamento collega una transazione di pagamento a una o più transazioni di addebito, come registrato nelle tabelle di dettaglio delle transazioni. Acquisizione Acquisire il record della transazione che applica un pagamento a un addebito, identificabile tramite specifici tipi di transazione. Tipo di evento explicit | |||
| Pagamento ricevuto | Rappresenta la ricezione di un pagamento da parte di un pagatore o di un paziente. Questo evento viene generalmente registrato quando viene caricato un avviso elettronico di rimessa (ERA) o quando un assegno viene inserito manualmente nel sistema. | ||
| Perché è importante Questa attività rappresenta una tappa fondamentale, poiché indica l'arrivo di ricavi. Il tempo che intercorre tra l'invio della richiesta e la ricezione del pagamento è un indicatore importante delle prestazioni dei crediti verso clienti. Dove reperirlo Registrato esplicitamente come transazione di pagamento in Resolute. Queste transazioni vengono registrate con data, origine e importo, spesso prima di essere contabilizzate integralmente sulle singole voci di addebito. Acquisizione Acquisire le transazioni di pagamento dal registro delle transazioni finanziarie, spesso identificate da specifici tipi di transazione. Tipo di evento explicit | |||
| Richiesta di rimborso inviata al pagatore | Indica il momento in cui la richiesta di rimborso viene ufficialmente inviata al pagatore assicurativo per la valutazione. In Epic, è un evento monitorato e registrato quando il file elettronico della richiesta viene trasmesso al clearinghouse o al pagatore. | ||
| Perché è importante Questo traguardo è fondamentale perché avvia il conteggio dei tempi previsti dal pagatore per il pagamento. Analizzarlo aiuta a misurare l'efficienza del processo di trasmissione delle richieste di rimborso e supporta il KPI «Invoice to Payer Delivery Time». Dove reperirlo Si tratta di un evento esplicito registrato in Resolute. Il record della richiesta di rimborso contiene uno stato di invio e un timestamp che indicano quando è stata trasmessa. Acquisizione Acquisire il timestamp associato alla variazione dello stato della richiesta di rimborso a «Submitted» o «Transmitted». Tipo di evento explicit | |||
| Richiesta di rimborso respinta dal pagatore | Rappresenta la ricezione di una notifica del pagatore che comunica il diniego della richiesta di rimborso. Viene acquisita quando Epic elabora un avviso elettronico di rimessa, ovvero un file 835, o quando un utente registra manualmente un diniego. | ||
| Perché è importante Questa attività avvia un ciclo critico di rilavorazione. Analizzare le motivazioni e i volumi dei dinieghi è essenziale per individuarne le cause alla radice, migliorare i tassi di pagamento al primo invio e ridurre i ritardi nella riscossione. Dove reperirlo Registrato esplicitamente come transazione o aggiornamento dello stato della richiesta di rimborso. Le informazioni sul diniego, compresi i codici motivazionali, vengono generalmente ricevute per via elettronica e registrate sul conto. Acquisizione Filtrare i tipi di transazione specifici o gli aggiornamenti dello stato della richiesta di rimborso che indicano un diniego. Tipo di evento explicit | |||
| Servizio erogato | Questa attività indica il momento in cui un servizio clinico viene erogato al paziente, dando avvio all'evento di fatturazione. Spesso viene acquisita dall'EHR Epic (EpicCare) quando un medico convalida una visita o una procedura. | ||
| Perché è importante Questo è il principale evento di avvio del ciclo dei ricavi. Analizzare il tempo che intercorre da questo momento all'acquisizione degli addebiti è fondamentale per individuare ritardi nell'avvio della fatturazione e potenziali perdite di ricavi. Dove reperirlo Questo evento viene generalmente dedotto dai timestamp del servizio o della visita nei moduli clinici collegati al conto di fatturazione. La data del servizio nella transazione dell'addebito costituisce il dato fondamentale. Acquisizione Deducibile dalla data del servizio associata alla prima transazione di addebito dell'evento di fatturazione. Tipo di evento inferred | |||
| Avvio del follow-up del diniego | Questa attività indica l'avvio del processo interno di revisione e risoluzione di una richiesta di rimborso respinta. Viene spesso acquisita quando un utente prende in carico la richiesta respinta in una coda di lavoro o ne modifica lo stato. | ||
| Perché è importante Il monitoraggio di questa fase aiuta a misurare la reattività del team responsabile della gestione dei dinieghi. I ritardi tra il diniego e l'avvio del follow-up possono prolungare inutilmente il ciclo dei ricavi. Dove reperirlo Viene generalmente dedotto dalle variazioni dello stato della richiesta di rimborso o dalla cronologia delle assegnazioni nelle code di lavoro di Epic. Ad esempio, lo stato della richiesta può passare da «Denied» a «In Review». Acquisizione Deducibile da una variazione dello stato della richiesta di rimborso o da una voce del log di audit che dimostri l'avvio della gestione del diniego da parte di un utente. Tipo di evento inferred | |||
| Rettifica del conto effettuata | Questa attività rappresenta una transazione non di pagamento che modifica il saldo del conto, ad esempio una rettifica contrattuale, lo stralcio di un piccolo saldo o uno sconto commerciale. Viene registrata come uno specifico tipo di transazione. | ||
| Perché è importante L'analisi delle rettifiche è fondamentale per individuare perdite di ricavi. Volumi elevati di determinati tipi di rettifica possono indicare problemi relativi a tariffari, contratti o politiche interne. Dove reperirlo Registrate esplicitamente come transazioni di rettifica nei registri finanziari di Resolute. A ogni rettifica è associato uno specifico tipo o codice causale. Acquisizione Filtrare i tipi di transazione corrispondenti a rettifiche finanziarie o stralci. Tipo di evento explicit | |||
| Richiesta di rimborso generata | Questa attività indica la creazione da parte del sistema di una richiesta di rimborso o di una fattura formale sulla base degli addebiti acquisiti. È una fase preparatoria precedente all'invio della richiesta al pagatore o al paziente. | ||
| Perché è importante Monitorare la generazione delle richieste di rimborso aiuta a isolare i ritardi tra l'acquisizione degli addebiti e la loro preparazione per l'invio. Si tratta di una fase interna fondamentale, che può incidere sulla tempestività complessiva della fatturazione. Dove reperirlo Viene generalmente registrato quando viene eseguito un processo batch di generazione della fatturazione o delle richieste di rimborso. Il sistema registra un timestamp nel momento in cui viene creato il file della richiesta, ad esempio un file 837, per un determinato conto. Acquisizione Individuare le voci di log o le variazioni di stato che indicano che la richiesta di rimborso è stata compilata ed è pronta per l'invio. Tipo di evento explicit | |||
| Richiesta di rimborso reinviata | Questo evento si verifica dopo che una richiesta respinta è stata corretta e reinviata al pagatore. Si tratta di un evento di invio distinto, collegato alla richiesta originale. | ||
| Perché è importante Si tratta di una fase fondamentale del ciclo di rilavorazione. Misurare il tempo necessario per il reinvio e il tasso di successo delle richieste reinviate è essenziale per comprendere l'efficacia del processo di risoluzione dei rifiuti. Dove reperirlo È un evento esplicito simile all'invio iniziale, ma spesso contrassegnato come reinvio. Nel record della richiesta comparirà un nuovo timestamp di invio e potrebbe essere incluso un codice di reinvio. Acquisizione Acquisire il timestamp dell'invio di una richiesta contrassegnata come correzione o reinvio. Tipo di evento explicit | |||
| Saldo inviato al recupero crediti | Indica il momento in cui il saldo non pagato di un conto viene trasferito a un processo di recupero crediti interno o esterno. Spesso si tratta di un'esplicita modifica dello stato del conto o dell'evento di fatturazione. | ||
| Perché è importante Questa attività avvia la fase finale del recupero dei saldi non pagati. Monitorare il tasso di successo e il tempo di ciclo del processo di recupero crediti è essenziale per ridurre al minimo le perdite su crediti. Dove reperirlo Si tratta generalmente di un evento esplicito. Epic dispone di funzioni per trasferire i conti alle agenzie di recupero crediti, creando una voce di registro o una modifica dello stato del conto. Acquisizione Identificare la modifica dello stato o la transazione che indica che un conto è stato affidato a un'agenzia di recupero crediti. Tipo di evento explicit | |||
Guide all'estrazione
Passaggi
- Stabilisca la connessione al database: ottenga credenziali di sola lettura per il database Epic Clarity. Utilizzi un client SQL standard, come DBeaver o Microsoft SQL Server Management Studio, per connettersi al server del database.
- Individui le tabelle principali: le tabelle primarie per questa estrazione includono
HSP_ACCOUNTper le informazioni sui casi,HSP_TRANSACTIONSper gli eventi finanziari,CLP_CLAIM_INFOper lo stato delle richieste di rimborso eF_ARHB_TX_SET_POST_HXper i dettagli della registrazione dei pagamenti. Dovrà inoltre eseguire join con file master comeCLARITY_EMPper i dettagli degli utenti. - Definisca l'ambito: prima di scrivere la query, determini l'ambito dell'analisi. Definisca un intervallo di date specifico, in genere da 3 a 6 mesi, e individui le aree di servizio ospedaliere (
SERV_AREA_ID) o le classi di conto da includere o escludere. - Sviluppi la query SQL: costruisca una query SQL utilizzando una Common Table Expression (CTE) per selezionare innanzitutto l'insieme di valori
HSP_ACCOUNT_IDche rientrano nell'ambito definito. Questo costituirà la popolazione di base degli eventi di fatturazione. - Unisca le query delle singole attività: per ciascuna delle 12 attività richieste, scriva un'istruzione
SELECTseparata che recuperi i dati dalle tabelle pertinenti. Esegua il join con la CTE iniziale per assicurarsi di analizzare esclusivamente i conti previsti. - Combini le query con UNION ALL: utilizzi l'operatore
UNION ALLper combinare i risultati delle singole query in un unico Event Log coerente. In questo modo le righe di ciascuna query vengono accodate verticalmente. - Mappi i dati allo schema standard: in ogni istruzione
SELECT, assegni agli alias delle colonne nomi conformi allo schema ProcessMind richiesto:BillingEvent,ActivityName,EventTimestamp,ResponsibleUsere così via. UtilizziNULLper gli Attributi non applicabili a una specifica attività. - Esegua e perfezioni la query: esegua la query completa sul database Clarity. Considerate le dimensioni delle tabelle, l'operazione potrebbe richiedere molto tempo. Se si verificano problemi di prestazioni, restringa ulteriormente l'intervallo di date o aggiunga filtri più specifici nella CTE iniziale.
- Esamini l'output: al termine della query, controlli le prime centinaia di righe dell'output. Verifichi che tutte le colonne siano presenti, che i timestamp abbiano un formato coerente e che vengano visualizzati diversi valori di
ActivityNamecome previsto. - Esporti in CSV: esporti l'intero set di risultati dal client SQL in un file CSV. Si assicuri che il file utilizzi la codifica UTF-8 e includa una riga di intestazione con i nomi corretti delle colonne.
- Prepari il caricamento: prima di caricare il file in ProcessMind, apra il CSV per verificare che non vi siano errori di formattazione. Controlli che il formato dei timestamp sia coerente, ad esempio
YYYY-MM-DD HH:MI:SS. Il file è ora pronto per l'acquisizione.
Configurazione
- Connessione al database: è necessario un account utente di sola lettura con accesso al database Epic Clarity.
- Parametri dell'intervallo di date: la query fornita utilizza le variabili
@StartDatee@EndDate. È necessario impostarle per definire il periodo di analisi. Si consiglia un intervallo da 3 a 6 mesi, così da bilanciare il volume dei dati e le prestazioni. - Mappatura di tabelle e colonne: la query presuppone nomi standard per le tabelle e le colonne Clarity. La configurazione o la versione specifica di Epic della Sua organizzazione potrebbe presentare variazioni. Potrebbe essere necessario modificare nomi delle tabelle, nomi delle colonne o condizioni di join di conseguenza.
- Codici di transazione e di stato: la query include segnaposto come
[Your Denial Tx Type]e[Your Collections Status Code]. Consulti gli amministratori del sistema Epic o esamini i file master pertinenti, comeZC_TX_TYPEoZC_ACCOUNT_STATUS, per individuare i codici corretti per la Sua istanza. - Filtri: per migliorare le prestazioni e rendere l'analisi più mirata, aggiunga filtri alla CTE iniziale
BaseAccounts. I filtri comuni includonoSERV_AREA_IDper limitare l'analisi all'area di servizio ospedaliera oACCOUNT_CLASS_Cper concentrarsi sulla fatturazione dei pazienti ricoverati o ambulatoriali.
a Query di esempio 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; Passaggi
- Verifichi che sia disponibile l'accesso autorizzato al set di dati del ciclo dei ricavi di Epic Clarity, incluse le tabelle e le viste di origine necessarie per la cronologia di conti, addebiti, richieste di rimborso, rifiuti, pagamenti, rettifiche, recupero crediti e chiusure. Le organizzazioni che utilizzano Epic possono differire per disponibilità delle tabelle e denominazione delle colonne; mappi quindi ogni segnaposto della query all'oggetto Clarity corrispondente nel Suo ambiente.
- Definisca il periodo di estrazione utilizzando [Start date parameter] e [End date parameter]. Inizi con un periodo da tre a sei mesi e lo estenda solo dopo aver convalidato le prestazioni della query e la completezza degli eventi.
- Stabilisca la mappatura di BillingEvent. La query utilizza HSP_ACCOUNT.HSP_ACCOUNT_ID come identificativo predefinito del caso, quando disponibile. Se la Sua organizzazione definisce l'evento di fatturazione a livello di addebito, richiesta di rimborso o incontro, sostituisca la mappatura con l'identificativo approvato e lo mantenga coerente per ogni origine di attività.
- Mappi ogni attività di origine a un timestamp autorevole e a un Attributo di origine. Service Rendered deve utilizzare il timestamp documentato di completamento del servizio o dell'incontro. Charges Captured deve utilizzare il timestamp di registrazione dell'addebito. Claim Generated e Claim Submitted to Payer devono utilizzare i timestamp corrispondenti del ciclo di vita della richiesta. Rifiuti, follow-up, nuovo invio, pagamenti, rettifiche, recupero crediti e chiusura devono utilizzare i timestamp documentati delle transazioni o degli stati.
- Sostituisca ogni segnaposto di origine tra parentesi quadre nella query, inclusi [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]. Non sostituisca i codici di transazione non documentati. Utilizzi i valori di transazione o di stato approvati dal team di reporting Epic.
- Esegua la query nel client SQL o nella piattaforma di reporting approvati dall'organizzazione. Confermi che tutte le dodici etichette delle attività vengano restituite come righe esplicite. ProcessMind non deduce gli eventi mancanti del ciclo di vita da saldi, stati o ordine degli eventi.
- Esamini lo schema dell'output. Il risultato deve contenere BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance e ServiceType. Conservi i timestamp con la documentazione relativa al fuso orario o all'ora locale e mantenga gli identificativi di origine in un'estrazione di audit interna, se consentito.
- Convalidi l'ordine cronologico all'interno di ogni BillingEvent, la gestione dei duplicati, i tassi di valori nulli, il numero di attività e la riconciliazione con i report del sistema di origine. Esamini gli eventi al di fuori del periodo richiesto necessari per interpretare i casi iniziati prima o terminati dopo tale periodo.
- Esporti il risultato come file delimitato o connessione al database supportata da ProcessMind. Utilizzi una riga per evento, nomi di colonna stabili, un formato coerente per i timestamp, codifica UTF-8 e nessuna cella unita o totale di presentazione. Durante il caricamento, configuri BillingEvent come identificativo del caso, ActivityName come attività ed EventTimestamp come timestamp dell'evento.
Configurazione
- Mappatura delle origini: le implementazioni di Epic Clarity variano. Sostituisca ogni oggetto di origine e segnaposto di colonna tra parentesi quadre con una tabella, una vista o un livello di reporting documentato e approvato nel Suo ambiente. Non presuma che una tabella o un campo esista solo perché è comune in un'altra implementazione Epic.
- Identificativo del caso: la mappatura predefinita della query utilizza HSP_ACCOUNT.HSP_ACCOUNT_ID. Confermi se l'organizzazione definisce BillingEvent come conto, incontro, richiesta di rimborso, addebito o altra chiave aziendale approvata.
- Intervallo di date: inizi con un periodo da tre a sei mesi. Includa un periodo di lookback quando i casi possono iniziare prima della finestra di reporting e un periodo di follow-up quando richieste di rimborso, rifiuti, pagamenti o chiusure possono verificarsi dopo la data del servizio.
- Timestamp delle attività: configuri un timestamp autorevole per ogni attività. Eviti di sostituire l'ora dell'evento aziendale effettivo con l'ora di estrazione, di caricamento del file o dello stato corrente, salvo che quest'ultima sia il timestamp documentato dell'evento nel sistema di origine.
- Filtri: applichi i filtri [Company Code filter], [Document Type filter], [Department filter], pagatore, area di servizio e classe di conto solo quando le relative definizioni sono documentate e richieste dall'analisi. Mantenga i filtri coerenti in tutti i rami UNION ALL.
- Mappatura di transazioni e stati: configuri i valori approvati dall'organizzazione per registrazione degli addebiti, creazione delle richieste, invio delle richieste, rifiuto, follow-up, nuovo invio, ricezione dei pagamenti, registrazione dei pagamenti, rettifica, recupero crediti e chiusura. La query utilizza intenzionalmente dei segnaposto perché i valori delle transazioni Epic e le strutture delle origini differiscono a seconda dell'implementazione.
- Gestione dei valori nulli: conservi NULL per gli Attributi non applicabili a un'attività. Non sostituisca motivi di rifiuto, motivi di rettifica, utenti, reparti o tipi di servizio mancanti con valori inventati.
- Prestazioni: limiti le righe di origine utilizzando colonne di data indicizzate e filtri organizzativi approvati prima del join con HSP_ACCOUNT. Eviti di applicare funzioni alle colonne timestamp indicizzate nelle condizioni. Valuti la materializzazione di ogni attività di origine in una vista di reporting approvata quando la cronologia grezza è molto ampia.
- Deduplicazione: non rimuova gli eventi duplicati senza una regola documentata. Più pagamenti, rettifiche, invii o cambiamenti di stato possono essere eventi validi per uno stesso BillingEvent.
- Prerequisiti: l'accesso richiesto può includere l'autorizzazione al reporting Epic Clarity, l'accesso ai dati del ciclo dei ricavi e della cronologia dei conti, un ambiente approvato per l'esecuzione SQL e l'autorizzazione dell'organizzazione al trattamento di informazioni sanitarie protette. La disponibilità della cronologia di richieste, rimesse, workqueue, recupero crediti e chiusure dipende dai moduli e dalle interfacce Epic concessi in licenza e implementati.
a Query di esempio 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 per iniziare?
Sblocchi tutto il potenziale del processo di gestione del ciclo dei ricavi con dati precisi. Inizi oggi il percorso verso una maggiore efficienza e migliori risultati finanziari.
Sblocchi la massima efficienza: ottimizzi ora la gestione del ciclo dei ricavi
Individui le inefficienze dell'RCM in Epic Resolute e riduca del 30% il tempo di ciclo.
Non è richiesta alcuna carta di credito: inizi oggi a ottimizzare i Suoi processi.