Il template dei dati per la gestione del ciclo dei ricavi
Il template dei dati per la gestione del ciclo dei ricavi
- Attributi consigliati da raccogliere
- Attività principali da monitorare
- Istruzioni per l’estrazione
Attributi della gestione del ciclo dei ricavi
| Nome | Descrizione | ||
|---|---|---|---|
| Data e ora dell’evento EventTimestamp | Data e ora esatte in cui si è verificata una specifica attività o un evento. | ||
| Descrizione La data e l’ora dell’evento registrano 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, le date e gli orari servono a calcolare la durata tra le attività, ad esempio il ritardo nella registrazione degli addebiti o il tempo necessario per registrare un pagamento. Permettono di individuare i colli di bottiglia, misurare i tempi di ciclo e analizzare le prestazioni del processo in periodi diversi. Date e orari precisi sono essenziali per quasi tutti i KPI e le Dashboard basati sul tempo. Perché è importante Questo attributo è essenziale per calcolare tutte le metriche temporali, compresi i tempi di ciclo e le durate, fondamentali per individuare ritardi e inefficienze. Dove reperirli Si trova nelle tabelle delle transazioni o degli Event Log di Epic Resolute ed è associato a ogni attività registrata. I nomi dei campi terminano spesso con suffissi come Dt, DTTM o Time. Esempi 2023-04-15T09:30:00Z2023-04-16T11:05:21Z2023-05-01T14:00:00Z | |||
| Evento di fatturazione BillingEvent | Identificativo univoco di una singola prestazione o fornitura di un prodotto che genera un addebito e funge da identificativo principale del caso. | ||
| Descrizione L’evento di fatturazione è l’identificativo principale che collega tutte le attività del ciclo dei ricavi relative a una specifica voce fatturabile. Inizia con l’erogazione di un servizio e termina quando il conto è interamente saldato o chiuso. Nell’analisi di Process Mining, questo attributo è essenziale per ricostruire l’intero percorso di ogni addebito. Permette di monitorare le attività, come la registrazione degli addebiti, l’invio delle richieste di rimborso, la registrazione dei pagamenti e la gestione dei rifiuti, per ogni singolo evento di fatturazione, offrendo una visione chiara del flusso del processo e delle sue variazioni. Perché è importante È l’ID del caso fondamentale, necessario per collegare tutti i passaggi correlati e analizzare l’intero ciclo di generazione e riscossione dei ricavi per ogni servizio. Dove reperirli Spesso è un identificativo univoco di un conto ospedaliero (HAR) o di una specifica sessione di addebito in Epic Resolute. Per informazioni sulle tabelle specifiche, come HAR o i record delle sessioni di addebito, consulti la documentazione di Epic Resolute. Esempi BE10098765BE20012345BE30054321 | |||
| Nome dell’attività ActivityName | Nome dell’evento o dell’attività specifica svolta nell’ambito del processo di gestione del ciclo dei ricavi. | ||
| Descrizione Questo attributo descrive un singolo passaggio del ciclo dei ricavi, ad esempio 'Addebiti registrati', 'Richiesta di rimborso inviata al pagatore' o 'Pagamento ricevuto'. Ogni attività rappresenta una tappa distinta del processo di fatturazione e riscossione del pagamento per un servizio. L’analisi delle attività è alla base del Process Mining. Permette di visualizzare la mappa del processo, individuare i percorsi più frequenti, rilevare i colli di bottiglia tra i passaggi e misurare l’aderenza alle procedure operative standard. Perché è importante Definisce i passaggi della mappa del processo e permette di visualizzare, analizzare e ottimizzare il flusso di lavoro nel ciclo dei ricavi. Dove reperirli In genere si ricava dagli Event Log, dai log di audit o dai record delle modifiche di stato nei moduli di fatturazione e gestione delle richieste di Epic Resolute. Esempi Addebiti registratiRichiesta di rimborso inviata al pagatorePagamento ricevutoConto chiuso | |||
| Codice motivo del rifiuto DenialReasonCode | Codice standard che indica il motivo per cui un pagatore ha rifiutato una richiesta di rimborso inviata. | ||
| Descrizione Quando rifiuta una richiesta, il pagatore fornisce un codice motivo che spiega il rifiuto, ad esempio 'Servizio non coperto', 'Richiesta duplicata' o 'Informazioni aggiuntive necessarie'. Questi codici sono spesso standardizzati come Claim Adjustment Reason Codes (CARCs). Questo attributo è alla base della Dashboard 'Percentuali e motivi dei rifiuti delle richieste'. Analizzare la frequenza dei diversi codici aiuta a individuare le cause profonde dei rifiuti, come problemi di accreditamento, errori di codifica o autorizzazioni preventive mancanti, e a definire iniziative di miglioramento mirate. Perché è importante Spiega direttamente perché le richieste vengono respinte e fornisce informazioni utili per ridurre i rifiuti, prevenire perdite di ricavi e accelerare i pagamenti. Dove reperirli Questi dati si trovano nelle transazioni di risposta alle richieste, ad esempio nei file ANSI 835 ricevuti dai pagatori e archiviati nel modulo di gestione delle richieste di Epic Resolute. Esempi CO-16: alla richiesta o al servizio mancano informazioniOA-18: richiesta o servizio duplicatoPR-96: addebito per servizi non coperti | |||
| Motivo della rettifica AdjustmentReason | Motivo di una rettifica manuale o automatica del saldo del conto di un paziente. | ||
| Descrizione Questo attributo spiega perché il saldo di un conto è stato modificato al di fuori di un normale pagamento o addebito. I motivi possono includere accordi contrattuali con i pagatori, lo stralcio di piccoli saldi o la correzione di errori di registrazione. È essenziale per la Dashboard 'Volume delle rettifiche del conto per tipo'. Analizzare i motivi delle rettifiche aiuta le organizzazioni a 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 Aiuta a comprendere le perdite di ricavi e la precisione della fatturazione, spiegando le modifiche ai saldi dei conti e contribuendo a ridurre gli stralci non necessari. Dove reperirli Si trova nei dettagli delle transazioni di rettifica del modulo di contabilità dei pazienti di Epic Resolute. Esempi Abbuono contrattualeStralcio di un piccolo saldoCorrezione di un addebito duplicato | |||
| Saldo residuo OutstandingBalance | 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 la situazione finanziaria del caso durante tutto il suo ciclo di vita. Il saldo residuo è fondamentale per la rendicontazione finanziaria e per il 'Report sull’anzianità dei saldi residui'. Analizzarne l’andamento nel tempo e in base a dimensioni diverse, come il pagatore o il reparto, aiuta a stabilire le priorità di riscossione, gestire il flusso di cassa e valutare il rischio finanziario. Perché è importante Misura direttamente l’impatto finanziario dei ritardi del processo ed è essenziale per stabilire le priorità di riscossione, gestire il flusso di cassa e comprendere i crediti verso clienti. Dove reperirli È 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 | Categoria o tipo di prestazione medica erogata. | ||
| Descrizione Questo attributo classifica la prestazione fatturabile, ad esempio come «Radiologia», «Chirurgia», «Consulenza» o «Visita al pronto soccorso». Fornisce un contesto clinico ai dati finanziari. L’analisi del ciclo dei ricavi per tipo di servizio può rivelare variazioni del processo specifiche di determinate aree cliniche. Per esempio, gli interventi chirurgici possono comportare requisiti più complessi per la registrazione degli addebiti e le autorizzazioni rispetto a una normale visita ambulatoriale, con conseguenti differenze nelle modalità operative e nelle criticità del processo. Perché è importante Fornisce un contesto clinico ai dati finanziari e consente di analizzare in che modo i diversi tipi di prestazioni mediche incidono sul processo del ciclo dei ricavi e sulla sua efficienza. Dove reperirli Deriva dal tariffario delle prestazioni (CDM), dalla linea di servizio o dal reparto associato alla transazione di addebito in Epic. Esempi Chirurgia in regime di ricoveroRadiologia ambulatorialeServizi di emergenza | |||
| Ufficio fatturazione BillingDepartment | Reparto o team funzionale responsabile dell’evento o dell’attività di fatturazione. | ||
| Descrizione Questo attributo indica l’unità organizzativa, ad esempio 'Fatturazione ricoveri', 'Fatturazione ambulatoriale' o 'Team di gestione dei rifiuti', associata all’evento di fatturazione o responsabile di una specifica attività. Questa dimensione è fondamentale per la Dashboard 'Metriche delle prestazioni dell’ufficio fatturazione', che permette di confrontare direttamente indicatori chiave come la percentuale di rifiuti o i tempi di registrazione degli addebiti. Aiuta la direzione a individuare i reparti con i risultati migliori, uniformare le buone pratiche e assegnare le risorse in modo efficace. Perché è importante Permette di confrontare le prestazioni dei diversi reparti, individuare le buone pratiche e identificare le aree che necessitano di miglioramenti o risorse aggiuntive. Dove reperirli Queste informazioni possono essere collegate al record dell’utente, al conto del paziente o alla sede del servizio in Epic Resolute. Esempi Fatturazione cardiologicaRCM radiologicoUfficio centrale di fatturazione | |||
| Utente responsabile ResponsibleUser | Identificativo dell’utente o del dipendente che ha svolto l’attività. | ||
| Descrizione Questo attributo registra l’ID utente, il nome o il numero di matricola della persona responsabile di una specifica attività del ciclo dei ricavi. Può trattarsi del medico che ha inserito gli addebiti, dell’addetto alla fatturazione che ha inviato una richiesta o dell’operatore che ha seguito un rifiuto. L’analisi per utente aiuta a individuare le persone con i risultati migliori, le esigenze di formazione e la distribuzione dei carichi di lavoro. È utile per gestire le prestazioni e analizzare le deviazioni del processo associate a specifiche persone o ruoli. Perché è importante Consente di analizzare le prestazioni per persona o ruolo e di individuare opportunità di formazione, squilibri nei carichi di lavoro e colli di bottiglia legati alle risorse. Dove reperirli In genere si trova nei log di audit o delle transazioni di Epic Resolute ed è spesso collegato a una tabella anagrafica degli utenti, ad esempio al record EMP. Esempi j.doebsmith123User7890 | |||
| Data di scadenza del pagamento PaymentDueDate | Data entro la quale è previsto il pagamento della prestazione fatturata. | ||
| Descrizione Questo attributo indica la scadenza del pagamento riportata in fattura o stabilita dai contratti con i pagatori. Costituisce un riferimento per misurare la puntualità dei pagamenti. La data di scadenza del pagamento è essenziale per creare il «Report sull’anzianità dei saldi insoluti». Confrontando la data corrente con la scadenza dei saldi aperti, i crediti verso clienti possono essere suddivisi per anzianità, ad esempio da 0 a 30 giorni o da 31 a 60 giorni di ritardo. In questo modo è possibile dare priorità al recupero dei crediti più scaduti. Perché è importante Costituisce la base per l’analisi dell’anzianità dei crediti verso clienti, fondamentale per stabilire le priorità di riscossione e gestire il rischio finanziario legato alle fatture non pagate. Dove reperirli Questa data viene spesso calcolata a partire dalla data della fattura e dai termini di pagamento registrati nel contratto con il pagatore o nelle informazioni sul conto del paziente in Epic. Esempi 2023-05-302023-06-152023-07-01 | |||
| È automatizzata IsAutomated | Indicatore booleano che specifica se l’attività è stata eseguita da un sistema o da un processo automatizzato. | ||
| Descrizione Questo indicatore distingue le attività eseguite automaticamente dal sistema, come la generazione automatica delle richieste di rimborso o i controlli di idoneità, da quelle svolte manualmente da un utente. L’analisi di questo attributo aiuta a comprendere il livello di automazione del processo. Può essere usato per confrontare l’efficienza e il tasso di errore delle attività automatizzate e manuali, individuare opportunità per ampliare l’automazione e monitorare le prestazioni dei bot o delle regole di sistema esistenti. Perché è importante Distingue le attività eseguite dal sistema da quelle svolte da persone, un aspetto fondamentale per valutare l’impatto dell’automazione e individuare nuove opportunità di automazione. Dove reperirli Spesso si ricava verificando se il valore di «ResponsibleUser» associato a un’attività corrisponde a un account di sistema o di servizio, oppure contrassegnando i nomi delle attività che si sa essere automatizzate. Esempi truefalse | |||
| ID della richiesta di rimborso ClaimId | Identificativo univoco assegnato a una richiesta di rimborso assicurativo inviata a un pagatore. | ||
| Descrizione Questo attributo è l’ID specifico del modulo di richiesta di rimborso, ad esempio CMS-1500 o UB-04, inviato a un pagatore. Un singolo evento di fatturazione può comportare più richieste se le prestazioni vengono fatturate di nuovo o se viene presentato un ricorso. Il monitoraggio tramite ID della richiesta di rimborso è utile per analizzare nel dettaglio l’invio delle richieste e i sottoprocessi di gestione dei rifiuti. Consente di distinguere le attività relative alla richiesta iniziale da quelle legate a una richiesta successiva, reinviata per la stessa prestazione. Perché è importante Fornisce un identificativo dettagliato per monitorare il ciclo di vita di ogni singola richiesta di rimborso, elemento essenziale per analizzare i reinvii e i ricorsi. Dove reperirli Viene generato dal modulo di gestione delle richieste di rimborso di Epic Resolute al momento della creazione della richiesta e memorizzato nelle tabelle dei dati relativi alle richieste. Esempi CLM-2023-98765CLAIM-0012345623189A4567 | |||
| ID paziente PatientId | Identificativo univoco del paziente che riceve la prestazione. | ||
| Descrizione Questo attributo è il numero di cartella clinica (MRN) o un altro identificativo univoco del paziente. Collega l’evento di fatturazione finanziaria a una persona specifica. Per tutelare la riservatezza del paziente, in genere non viene usato come dimensione di analisi principale, ma è essenziale per convalidare i dati e può servire ad aggregare tutti gli eventi di fatturazione di un singolo paziente, così da ricostruirne il percorso finanziario complessivo. È inoltre fondamentale per eventuali integrazioni con i dati dei processi clinici. Perché è importante Collega i dati finanziari a un paziente specifico, consentendo di convalidare i dati e, potenzialmente, di analizzare l’intero percorso del paziente. Il trattamento di queste informazioni richiede tuttavia particolare attenzione per tutelarne la riservatezza. Dove reperirli Identificativo fondamentale presente in tutto Epic, collegato ai dati di registrazione e ai conti del paziente. Esempi MRN-1234567MRN-8765432MRN-5551234 | |||
| Importo rettificato AdjustedAmount | Valore monetario di una transazione di rettifica. | ||
| Descrizione Questo campo registra l’importo esatto in dollari di una rettifica del conto. Può essere positivo o negativo e rappresentare un accredito o un addebito sul saldo del conto. Questo importo è la metrica principale della Dashboard «Volume delle rettifiche dei conti per tipo». La somma di questo valore per motivo della rettifica offre un quadro chiaro dell’impatto finanziario dei diversi tipi di rettifica, ad esempio dei ricavi stornati per obblighi contrattuali rispetto a quelli persi a causa di errori correggibili. Perché è importante Quantifica l’impatto finanziario delle rettifiche dei conti e permette di misurare le perdite di ricavi e i costi dovuti a errori di fatturazione. Dove reperirli Si trova nelle tabelle di dettaglio delle transazioni finanziarie di Epic Resolute ed è associato alle transazioni di rettifica. Esempi -1250.45-50.0025.10 | |||
| Nome del pagatore PayerName | 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 alcuni pagatori presentano percentuali di rifiuto più elevate, tempi di pagamento più lunghi o requisiti più complessi. Queste informazioni permettono 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, individuando quelli con percentuali di rifiuto elevate o tempi di pagamento lunghi e definendo strategie mirate di seguito. Dove reperirli Queste informazioni fanno parte dei dettagli della copertura sanitaria del paziente e sono collegate al conto ospedaliero (HAR) in Epic Resolute. Esempi Medicare Parte BUnitedHealthcareAetna PPO | |||
| Ora di fine dell’evento EventEndTime | Data e ora che indicano il completamento di un’attività, utili per calcolarne la durata. | ||
| Descrizione Questo attributo registra l’ora di completamento di un’attività. Molte attività sono eventi istantanei, per i quali StartTime coincide con EndTime, mentre alcune operazioni hanno una durata misurabile, come una telefonata di follow-up dopo un rifiuto. Quando disponibile, EndTime consente di calcolare direttamente il tempo di elaborazione dell’attività («EndTime» - «StartTime»). Il calcolo è più preciso rispetto alla stima della durata basata sull’ora di inizio dell’attività successiva, perché tiene conto dei tempi di inattività tra un passaggio e l’altro. È un elemento essenziale per calcolare l’attributo «ProcessingTime». Perché è importante Consente di calcolare con precisione il tempo necessario per completare ogni attività, un dato fondamentale per individuare le operazioni inefficienti e misurare la produttività delle risorse. Dove reperirli Potrebbe essere disponibile in alcuni moduli di Epic Resolute che registrano l’inizio e la fine delle attività, ad esempio nei log delle code di lavoro o della gestione delle attività. Spesso, però, non viene registrato in modo esplicito. 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. Negli ambienti con più sistemi integrati, il campo permette di distinguere la provenienza dei dati. Anche se può sembrare ridondante quando si considera un solo sistema, è una buona pratica per la governance dei dati e la scalabilità. Garantisce chiarezza nel caso in cui vengano integrati in seguito dati provenienti da altri sistemi, ad esempio da una piattaforma separata per il recupero crediti. Perché è importante Fornisce informazioni essenziali sulla provenienza e sul contesto dei dati, chiarendone l’origine, aspetto fondamentale per la governance dei dati e la risoluzione dei problemi. Dove reperirli In genere è un valore statico aggiunto durante l’estrazione e la trasformazione dei dati per indicare l’origine del set di dati. Esempi Epic ResoluteEpicResolute_V2023 | |||
| Tempo totale del ciclo dei ricavi TotalRevenueCycleTime | Durata totale calcolata dal primo evento relativo alla prestazione fino al pagamento finale o alla chiusura del conto. | ||
| Descrizione Questo KPI a livello di caso misura la durata complessiva del ciclo dei ricavi per un singolo evento di fatturazione. In genere, si calcola come differenza tra l’attività «Prestazione erogata» e l’attività finale «Pagamento ricevuto» o «Conto chiuso». Questa metrica di alto livello offre una visione complessiva dell’efficienza del processo RCM. Monitorarla nel tempo aiuta a misurare l’impatto delle iniziative di miglioramento dei processi e fornisce un indicatore chiave della velocità di conversione in liquidità. Perché è importante Offre una visione complessiva dell’efficienza del processo, dall’inizio alla fine, misurando direttamente il tempo necessario per convertire una prestazione in liquidità. Dove reperirli È una metrica calcolata nello strumento di Process Mining filtrando il primo e l’ultimo evento di ogni caso e calcolando la differenza temporale. Esempi 259200038880005184000 | |||
| Ultimo aggiornamento dei dati LastDataUpdate | Data e ora che indicano l’ultimo aggiornamento o l’ultima estrazione dei dati di questo evento dal sistema di origine. | ||
| Descrizione Questo attributo indica quanto sono aggiornati i dati e riporta l’ultima volta in cui il record è stato estratto da Epic Resolute e caricato nel set di dati per il Process Mining. È importante per valutare l’attualità dell’analisi e convalidare i dati. Aiuta a capire se si stanno consultando le informazioni più recenti disponibili ed è fondamentale per gestire i cicli di aggiornamento dei dati. Perché è importante Permette di valutare l’attualità dei dati analizzati, aspetto fondamentale per prendere decisioni aziendali precise e aggiornate. Dove reperirli Questa data e ora vengono aggiunte dal processo ETL (Extract, Transform, Load) durante l’acquisizione dei dati. Esempi 2023-06-10T02:00:00Z2023-06-11T02:00:00Z | |||
Attività della gestione del ciclo dei ricavi
| Attività | Descrizione | ||
|---|---|---|---|
| Addebiti registrati | Indica la registrazione formale degli addebiti fatturabili per i servizi erogati. In Epic si tratta in genere di una transazione esplicita registrata sul conto del paziente, spesso generata automaticamente dalle attività cliniche o inserita manualmente. | ||
| Perché è importante È una prima tappa fondamentale. Misurare la rapidità e la precisione con cui vengono registrati gli addebiti aiuta ad accelerare la fatturazione e a verificare che tutti i servizi erogati siano fatturati. Dove reperirli È registrato esplicitamente nei log delle transazioni di Resolute. Ogni addebito è una voce distinta con data di registrazione, data del servizio e importo; spesso si trova in tabelle come ARPB_TRANSACTIONS. Acquisizione Acquisisca le transazioni di registrazione degli addebiti dal log delle transazioni finanziarie del sistema. Tipo di evento explicit | |||
| Conto chiuso | È l’attività finale: indica che il saldo residuo dell’evento di fatturazione è pari a zero e che non sono previste altre attività. Può essere dovuto al pagamento integrale, a rettifiche o a uno stralcio. | ||
| Perché è importante Questo evento segna il completamento del ciclo dei ricavi per un evento di fatturazione. La durata complessiva, dall’erogazione del servizio alla chiusura, è un KPI fondamentale per valutare l’efficienza del processo. Dove reperirli In genere è un evento dedotto. Si individua il momento in cui il saldo del conto relativo all’evento di fatturazione raggiunge lo zero e vi rimane. Acquisizione Si deduce calcolando il saldo progressivo del conto e individuando la data e l’ora dell’ultima transazione che ha portato il saldo a zero. Tipo di evento inferred | |||
| Pagamento registrato sul conto | È l’evento in cui un pagamento ricevuto viene applicato o attribuito a specifici addebiti sul conto del paziente. Questa operazione riduce il saldo residuo dell’evento di fatturazione. | ||
| Perché è importante Registrare tempestivamente i pagamenti è fondamentale per mantenere saldi corretti e chiudere gli eventi di fatturazione. Consente di individuare con precisione gli importi residui da fatturare a un pagatore secondario o da riscuotere. Dove reperirli È una transazione esplicita in Resolute. La registrazione del pagamento collega una transazione di pagamento a una o più transazioni di addebito, come riportato nelle tabelle di dettaglio delle transazioni. Acquisizione Acquisisca il record della transazione che applica un pagamento a un addebito, identificabile in base a specifici tipi di transazione. Tipo di evento explicit | |||
| Pagamento ricevuto | Indica la ricezione di un pagamento da parte del pagatore o del paziente. In genere l’evento viene registrato quando viene caricato un avviso elettronico di rimessa (ERA) o inserito nel sistema un assegno ricevuto. | ||
| Perché è importante Questa attività è una tappa importante, perché indica l’arrivo di ricavi. Il tempo tra l’invio della richiesta e la ricezione del pagamento è una misura fondamentale delle prestazioni dei crediti verso clienti. Dove reperirli È registrato esplicitamente come transazione di pagamento in Resolute. Le transazioni riportano data, origine e importo e spesso vengono registrate prima di essere attribuite ai singoli addebiti. Acquisizione Acquisisca le transazioni di pagamento dal log delle transazioni finanziarie, individuandole spesso in base a specifici tipi di transazione. Tipo di evento explicit | |||
| Richiesta di rimborso inviata al pagatore | Indica il momento in cui la richiesta di rimborso viene inviata ufficialmente al pagatore assicurativo per la valutazione. In Epic, l’evento viene registrato quando il file elettronico della richiesta è trasmesso alla stanza di compensazione o al pagatore. | ||
| Perché è importante Questa tappa è fondamentale perché avvia il conteggio dei tempi di pagamento del pagatore. Analizzarla aiuta a misurare l’efficienza della trasmissione delle richieste e contribuisce al KPI Tempo di consegna della fattura al pagatore. Dove reperirli È un evento esplicito registrato in Resolute. Il record della richiesta riporta lo stato di invio e la data e l’ora della trasmissione. Acquisizione Acquisisca la data e l’ora associate al passaggio dello stato della richiesta a 'Submitted' o 'Transmitted'. Tipo di evento explicit | |||
| Richiesta di rimborso rifiutata dal pagatore | Indica la ricezione della notifica con cui il pagatore comunica il rifiuto della richiesta. L’evento viene registrato quando Epic elabora un avviso elettronico di rimessa (file 835) o quando un utente registra manualmente il rifiuto. | ||
| Perché è importante Questa attività avvia un ciclo di rilavorazione importante. Analizzare i motivi e il numero dei rifiuti è essenziale per individuarne le cause profonde, migliorare la percentuale di pagamenti al primo invio e ridurre i ritardi negli incassi. Dove reperirli È registrato esplicitamente come transazione o aggiornamento di stato della richiesta. Le informazioni sul rifiuto, compresi i codici motivo, vengono in genere ricevute elettronicamente e registrate sul conto. Acquisizione Filtri i tipi di transazione specifici o gli aggiornamenti di stato della richiesta che indicano un rifiuto. Tipo di evento explicit | |||
| Servizio erogato | Questa attività indica il momento in cui viene erogato un servizio clinico al paziente e si avvia l’evento di fatturazione. Spesso viene registrata nell’EHR Epic (EpicCare) quando un medico convalida una visita o una procedura. | ||
| Perché è importante È il principale evento di inizio del ciclo dei ricavi. Analizzare il tempo che intercorre tra questo momento e la registrazione degli addebiti è fondamentale per individuare i ritardi nell’avvio della fatturazione e le potenziali perdite di ricavi. Dove reperirli In genere si deduce dalle date e dagli orari del servizio o della visita registrati nei moduli clinici e collegati al conto di fatturazione. La data del servizio riportata nella transazione di addebito è il dato fondamentale. Acquisizione Si deduce dalla data del servizio associata alla prima transazione di addebito dell’evento di fatturazione. Tipo di evento inferred | |||
| Avvio del seguito di una richiesta rifiutata | Questa attività segna l’inizio del processo interno di revisione e risoluzione di una richiesta rifiutata. Spesso viene registrata quando un utente prende in carico la richiesta rifiutata in una coda di lavoro o ne modifica lo stato. | ||
| Perché è importante Monitorare questo passaggio aiuta a misurare la tempestività del team che gestisce i rifiuti. I ritardi tra il rifiuto e l’avvio del seguito possono allungare inutilmente il ciclo dei ricavi. Dove reperirli In genere si deduce dalle modifiche dello stato della richiesta 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 Lo deduca da una modifica dello stato della richiesta o da una voce del log di audit che indica l’avvio della gestione del rifiuto da parte di un utente. Tipo di evento inferred | |||
| Rettifica del conto effettuata | Questa attività rappresenta una transazione diversa da un pagamento che modifica il saldo del conto, ad esempio una rettifica contrattuale, lo stralcio di un piccolo saldo o uno sconto commerciale. Viene registrata con un tipo di transazione specifico. | ||
| Perché è importante Analizzare le rettifiche è fondamentale per individuare le perdite di ricavi. Un numero elevato di determinati tipi di rettifica può segnalare problemi nei tariffari, nei contratti o nelle procedure interne. Dove reperirli È registrata esplicitamente come transazione di rettifica nei log finanziari di Resolute. Ogni rettifica è associata a un tipo o a un codice motivo specifico. Acquisizione Filtri i tipi di transazione corrispondenti a rettifiche finanziarie o stralci. Tipo di evento explicit | |||
| Richiesta di rimborso generata | Questa attività indica che il sistema ha creato una richiesta di rimborso o una fattura formale sulla base degli addebiti registrati. È un passaggio preparatorio prima dell’invio al pagatore o al paziente. | ||
| Perché è importante Monitorare la generazione delle richieste di rimborso aiuta a individuare i ritardi tra la registrazione degli addebiti e la preparazione per l’invio. È un passaggio interno importante, che può influire sulla tempestività complessiva della fatturazione. Dove reperirli In genere viene registrata quando viene eseguito un processo batch di fatturazione o generazione delle richieste di rimborso. Il sistema registra la data e l’ora di creazione del file della richiesta, ad esempio un file 837, per un determinato conto. Acquisizione Individui le voci di log o le modifiche di stato che indicano che la richiesta di rimborso è stata compilata ed è pronta per l’invio. Tipo di evento explicit | |||
| Richiesta di rimborso inviata nuovamente | Questo evento si verifica dopo che una richiesta rifiutata è stata corretta e inviata di nuovo al pagatore. È un invio distinto, collegato alla richiesta originale. | ||
| Perché è importante È una fase fondamentale del ciclo di rilavorazione. Misurare il tempo necessario per il nuovo invio e la percentuale di successo delle richieste reinviate è essenziale per valutare l’efficacia del processo di risoluzione dei rifiuti. Dove reperirli È un evento esplicito simile all’invio iniziale, ma spesso contrassegnato come nuovo invio. Il record della richiesta riporta una nuova data e ora di invio e può includere un codice di reinvio. Acquisizione Acquisisca la data e l’ora di invio della richiesta contrassegnata come correzione o nuovo invio. Tipo di evento explicit | |||
| Saldo trasferito al recupero crediti | Indica il momento in cui un saldo non pagato viene trasferito a una procedura interna o esterna di recupero crediti. Spesso corrisponde a una modifica esplicita dello stato del conto o dell’evento di fatturazione. | ||
| Perché è importante Questa attività avvia la fase finale del recupero dei saldi non pagati. Monitorare la percentuale di successo e il tempo di ciclo del recupero crediti è fondamentale per ridurre al minimo i crediti inesigibili. Dove reperirli In genere è un evento esplicito. Epic consente di trasferire i conti alle agenzie di recupero crediti, generando una voce di log o una modifica dello stato del conto. Acquisizione Individui la modifica di stato o la transazione che indica che il conto è stato affidato a un’agenzia di recupero crediti. Tipo di evento explicit | |||
Guide all’estrazione
Passaggi
- Stabilisca la connessione al database: richieda credenziali di sola lettura per il database Epic Clarity. Si colleghi al server del database con un client SQL standard, ad esempio DBeaver o Microsoft SQL Server Management Studio.
- Individui le tabelle principali: le tabelle principali per questa estrazione sono
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 di registrazione dei pagamenti. Dovrà inoltre unire file master, comeCLARITY_EMP, per ottenere i dettagli degli utenti. - Definisca l’ambito: prima di scrivere la query, stabilisca 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: crei una query SQL con un’espressione di tabella comune (CTE) per selezionare innanzitutto i valori
HSP_ACCOUNT_IDche rientrano nell’ambito definito. Questo insieme 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. La colleghi alla CTE iniziale per assicurarsi di analizzare solo i conti previsti. - Combini le query con UNION ALL: usi l’operatore
UNION ALLper riunire i risultati di tutte le query delle singole attività in un unico Event Log coerente. In questo modo, le righe di ogni query vengono accodate verticalmente. - Mappi i dati allo schema standard: in ogni istruzione
SELECT, assegni alle colonne alias corrispondenti allo schema ProcessMind richiesto, ad esempioBillingEvent,ActivityName,EventTimestamp,ResponsibleUser. Per gli attributi non applicabili a una specifica attività, usiNULL. - Esegua e perfezioni la query: esegua la query completa sul database Clarity. Considerata la dimensione delle tabelle, l’operazione potrebbe richiedere molto tempo. Se le prestazioni sono insufficienti, restringa ulteriormente l’intervallo di date o aggiunga filtri più specifici nella CTE iniziale.
- Riveda i risultati: al termine dell’esecuzione, controlli le prime centinaia di righe. Verifichi che siano presenti tutte le colonne, che i timestamp abbiano un formato coerente e che i diversi valori di
ActivityNamesiano quelli previsti. - Esporti i dati in CSV: esporti l’intero insieme 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 file per il caricamento: prima di caricarlo in ProcessMind, apra il file CSV e verifichi che non contenga 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’importazione.
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, che devono essere impostate per definire il periodo di analisi. Si consiglia un intervallo da 3 a 6 mesi, per bilanciare il volume dei dati e le prestazioni. - Mappatura di tabelle e colonne: la query presuppone l’uso dei nomi standard delle tabelle e delle colonne di Clarity. La configurazione Epic o la versione in uso nella Sua organizzazione potrebbe presentare differenze. Potrebbe essere necessario modificare i nomi delle tabelle e delle colonne o le condizioni di join.
- 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 i file master pertinenti, comeZC_TX_TYPEoZC_ACCOUNT_STATUS, per individuare i codici corretti per la Sua istanza. - Filtri: per migliorare le prestazioni e concentrare l’analisi, aggiunga filtri alla CTE iniziale
BaseAccounts. Tra i filtri più comuni figuranoSERV_AREA_ID, per limitare i dati in base all’area di servizio ospedaliera, eACCOUNT_CLASS_C, per concentrarsi sulla fatturazione in regime di ricovero o ambulatoriale.
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 di disporre dell’accesso autorizzato ai dati del ciclo dei ricavi di Epic Clarity, comprese le tabelle e le viste di origine necessarie per consultare la cronologia di conti, addebiti, richieste di rimborso, rifiuti, pagamenti, rettifiche, riscossioni e chiusure. Le tabelle disponibili e i nomi delle colonne variano da un’organizzazione Epic all’altra; associ quindi ogni segnaposto della query all’oggetto Clarity corrispondente nel Suo ambiente.
- Definisca il periodo di estrazione con [Start date parameter] e [End date parameter]. Inizi con un periodo da tre a sei mesi e lo estenda solo dopo aver verificato le prestazioni della query e la completezza degli eventi.
- Definisca la mappatura di BillingEvent. Quando disponibile, la query utilizza HSP_ACCOUNT.HSP_ACCOUNT_ID come identificativo predefinito del caso. Se nella Sua organizzazione l’evento di fatturazione è definito a livello di addebito, richiesta di rimborso o incontro, sostituisca la mappatura con l’identificativo approvato e lo mantenga coerente per tutte le fonti delle attività.
- Associ ogni attività di origine a un timestamp e a un attributo di origine autorevoli. Per Service Rendered, utilizzi il timestamp documentato di completamento della prestazione o dell’incontro. Per Charges Captured, utilizzi il timestamp di registrazione dell’addebito. Per Claim Generated e Claim Submitted to Payer, utilizzi i timestamp corrispondenti del ciclo di vita della richiesta. Per rifiuti, follow-up, reinvii, pagamenti, rettifiche, riscossioni e chiusure, utilizzi i timestamp documentati delle transazioni o degli stati.
- Sostituisca tutti i 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. Verifichi che tutte le dodici etichette delle attività siano restituite come righe esplicite. ProcessMind non deduce gli eventi mancanti del ciclo di vita da saldi, stati o ordine degli eventi.
- Riveda lo schema dei risultati. L’output deve contenere BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance e ServiceType. Conservi i timestamp insieme alla documentazione relativa al fuso orario o all’ora locale e mantenga gli identificativi di origine in un’estrazione interna per audit, se consentito.
- Convalidi l’ordine cronologico degli eventi all’interno di ogni BillingEvent, la gestione dei duplicati, la percentuale di valori nulli, il numero di attività e la riconciliazione con i report del sistema di origine. Verifichi gli eventi esterni al periodo richiesto che servono a interpretare i casi iniziati prima o conclusi dopo tale periodo.
- Esporti i risultati in un file delimitato o tramite una connessione al database supportata da ProcessMind. Utilizzi una riga per evento, nomi di colonna stabili, un formato coerente per i timestamp, la 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 fonti: le implementazioni di Epic Clarity variano. Sostituisca ogni segnaposto tra parentesi quadre relativo a oggetti e colonne di origine con una tabella, una vista o un livello di reportistica approvato e documentato nel Suo ambiente. Non dia per scontato che una tabella o un campo esistano solo perché sono comuni in un’altra implementazione di Epic.
- Identificativo del caso: la mappatura predefinita della query utilizza HSP_ACCOUNT.HSP_ACCOUNT_ID. Verifichi se l’organizzazione definisce BillingEvent come account, incontro, richiesta di rimborso, addebito o un’altra chiave aziendale approvata.
- Intervallo di date: inizi con un periodo da tre a sei mesi. Includa un periodo precedente all’intervallo di reportistica quando i casi possono iniziare prima, e un periodo successivo quando le richieste di rimborso, i dinieghi, i pagamenti o la chiusura possono verificarsi dopo la data del servizio.
- Timestamp delle attività: configuri un timestamp autorevole per ogni attività. Eviti di sostituire l’ora effettiva dell’evento aziendale con l’ora di estrazione, di caricamento del file o dello stato corrente, a meno che quest’ultima non 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 dell’account solo se le relative definizioni sono documentate e necessarie per l’analisi. Mantenga coerenti i filtri in tutti i rami UNION ALL.
- Mappatura di transazioni e stati: configuri i valori approvati dall’organizzazione per la registrazione degli addebiti, la creazione e l’invio delle richieste di rimborso, i dinieghi, i solleciti, i nuovi invii, la ricezione e la registrazione dei pagamenti, le rettifiche, il recupero crediti e la chiusura. La query utilizza intenzionalmente dei segnaposto, poiché i valori delle transazioni e le strutture delle fonti Epic variano a seconda dell’implementazione.
- Gestione dei valori nulli: mantenga NULL per gli attributi non applicabili a un’attività. Non sostituisca motivi di diniego o rettifica, utenti, reparti o tipi di servizio mancanti con valori inventati.
- Prestazioni: limiti le righe di origine usando colonne di data indicizzate e filtri organizzativi approvati prima di eseguire join con HSP_ACCOUNT. Eviti di applicare funzioni alle colonne timestamp indicizzate nelle condizioni. Se lo storico grezzo è ampio, valuti la possibilità di materializzare ogni attività di origine in una vista di reportistica approvata.
- Deduplicazione: non rimuova gli eventi duplicati senza una regola documentata. Più pagamenti, rettifiche, invii o cambi di stato possono essere eventi validi per un singolo BillingEvent.
- Prerequisiti: l’accesso necessario può includere l’autorizzazione alla reportistica Epic Clarity, l’accesso ai dati del ciclo dei ricavi e allo storico degli account, un ambiente approvato per l’esecuzione di SQL e l’autorizzazione dell’organizzazione a trattare informazioni sanitarie protette. La disponibilità dello storico di richieste di rimborso, rimesse, code di lavoro, recupero crediti e chiusure dipende dai moduli e dalle interfacce Epic concessi in licenza e implementati.
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 a iniziare?
Sfrutti appieno il potenziale del processo di gestione del ciclo dei ricavi grazie a dati precisi. Inizi oggi il percorso verso una maggiore efficienza e risultati finanziari migliori.
Ottimizzi subito la gestione del ciclo dei ricavi per ottenere la massima efficienza
Individui le inefficienze RCM in Epic Resolute e riduca il tempo di ciclo del 30%.
Non è richiesta alcuna carta di credito. Inizi oggi a ottimizzare i processi.