Il vostro template dati per il Revenue Cycle Management
Il vostro template dati per il Revenue Cycle Management
- Attributi consigliati da raccogliere
- Attività chiave da tracciare
- Guida all'estrazione
Attributi di Revenue Cycle Management
| Nome | Descrizione | ||
|---|---|---|---|
| Evento di fatturazione BillingEvent | L'identificatore univoco per l'erogazione di un singolo servizio o prodotto che genera un addebito, utilizzato come identificatore principale del case. | ||
| Descrizione Il Billing Event è l'identificatore principale che collega tutte le attività all'interno del ciclo dei ricavi per un 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 tracciare attività come la registrazione dell'addebito, la presentazione della pratica, la registrazione del pagamento e la gestione dei rifiuti per i singoli eventi di fatturazione, fornendo una visione chiara del flusso di processo e delle sue varianti. Perché è importante Questo è il Case ID fondamentale, cruciale per collegare tra loro tutte le fasi del processo e analizzare il ciclo di vita completo della generazione dei ricavi e dell'incasso per ogni servizio. Dove trovare Spesso si tratta di un identificatore univoco per un account ospedaliero (HAR) o una specifica sessione di addebito in Epic Resolute. Consultare la documentazione di Epic Resolute per tabelle specifiche come i record HAR o Charge Session. Esempi BE10098765BE20012345BE30054321 | |||
| Nome attività ActivityName | Il nome dello specifico evento o task eseguito all'interno del processo di gestione del ciclo dei ricavi. | ||
| Descrizione Questo attributo descrive una singola fase del ciclo dei ricavi, come 'Charges Captured', 'Claim Submitted to Payer' o 'Payment Received'. Ogni attività rappresenta una pietra miliare distinta nel processo di fatturazione e incasso per un servizio. L'analisi delle attività è il fondamento del process mining. Consente la visualizzazione della mappa di processo, l'identificazione dei percorsi comuni, la scoperta di colli di bottiglia tra le fasi e la misurazione della conformità alle procedure operative standard. Perché è importante Definisce le fasi nella mappa di processo, rendendo possibile visualizzare e ottimizzare il flusso di lavoro del ciclo del fatturato. Dove trovare Questo viene solitamente ricavato da log degli eventi, audit trail o record di cambio di stato all'interno dei moduli di fatturazione e gestione pratiche di Epic Resolute. Esempi Oneri acquisitiRichiesta presentata al pagatorePagamento ricevutoConto chiuso | |||
| Timestamp Evento EventTimestamp | La data e l'ora precise in cui si è verificata una specifica attività o un evento. | ||
| Descrizione L'Event Timestamp registra il momento esatto in cui si è svolta un'attività. Questo dato temporale è fondamentale per comprendere la tempistica e la sequenza degli eventi nel ciclo dei ricavi. In fase di analisi, i timestamp vengono utilizzati per calcolare le durate tra le attività, come il ritardo nella registrazione dell'addebito o i tempi di registrazione del pagamento. Permettono di scoprire colli di bottiglia, misurare i tempi di ciclo e analizzare le prestazioni del processo in diversi periodi. Timestamp accurati sono essenziali per quasi tutti i KPI basati sul tempo e per le dashboard. Perché è importante Questo attributo è essenziale per calcolare tutte le metriche basate sul tempo, inclusi i tempi di ciclo e le durate, fondamentali per identificare ritardi e inefficienze. Dove trovare Presente nelle tabelle di log in Epic Resolute, associato a ogni attività. I campi spesso terminano in Dt, DTTM o Time. Esempi 2023-04-15T09:30:00Z2023-04-16T11:05:21Z2023-05-01T14:00:00Z | |||
| Codice motivo del diniego DenialReasonCode | Un codice standardizzato che indica il motivo per cui un pagatore ha respinto una richiesta di rimborso. | ||
| Descrizione Quando un ente pagatore rifiuta una pratica, fornisce un codice motivo che spiega il diniego, come 'Non-Covered Service', 'Duplicate Claim' o 'Requires Additional Information'. Questi codici sono spesso standardizzati come Claim Adjustment Reason Codes (CARC). Questo attributo è il pilastro della dashboard 'Tassi e motivi di rifiuto pratiche'. Analizzare la frequenza dei diversi codici aiuta a identificare le cause profonde dei rifiuti, come problemi di accreditamento, errori di codifica o mancanza di pre-autorizzazioni, consentendo iniziative di miglioramento mirate. Perché è importante Spiega direttamente perché le richieste vengono respinte, offrendo insight operativi per ridurre i tassi di diniego e accelerare gli incassi. Dove trovare Questi dati si trovano nelle transazioni di risposta alle pratiche (come un file ANSI 835) ricevute dai pagatori e archiviate nel modulo di gestione pratiche di Epic Resolute. Esempi CO-16: Richiesta/servizio privo di informazioniOA-18: Richiesta/servizio duplicatoPR-96: Oneri non coperti | |||
| Dipartimento Fatturazione BillingDepartment | Il reparto o il team funzionale responsabile dell'evento o dell'attività di fatturazione. | ||
| Descrizione Questo attributo indica l'unità organizzativa, come 'Inpatient Billing', 'Outpatient Billing' o il 'Denial Management Team', associata all'evento di fatturazione o che ha eseguito una specifica attività. Questa dimensione è cruciale per la dashboard delle metriche di performance del dipartimento fatturazione, consentendo confronti diretti su metriche chiave come i tassi di rifiuto o i tempi di registrazione degli addebiti. Aiuta il management a identificare i dipartimenti più efficienti, standardizzare le best practice e allocare le risorse in modo efficace. Perché è importante Consente il benchmarking delle prestazioni tra diversi dipartimenti, aiutando a identificare le best practice. Dove trovare Queste informazioni potrebbero essere collegate al record utente, al conto del paziente o alla sede del servizio all'interno di Epic Resolute. Esempi Fatturazione cardiologiaRCM RadiologiaUfficio fatturazione centrale | |||
| Motivo 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. I motivi possono includere abbuoni contrattuali con gli enti pagatori, storni di piccoli saldi o correzioni per errori di registrazione. Questo dato è essenziale per la dashboard 'Volume di rettifiche per tipo'. Analizzando i motivi delle rettifiche, le organizzazioni possono identificare le fonti di perdita di ricavi, comprendere l'impatto dei contratti con i pagatori e individuare potenziali inefficienze o errori nel processo di fatturazione. Perché è importante Fornisce insight sulla perdita di ricavi e sull'accuratezza della fatturazione spiegando perché i saldi dei conti vengono modificati, aiutando a ridurre gli storni non necessari. Dove trovare Presente nei dettagli delle transazioni per le voci di rettifica nel modulo contabile di Epic Resolute. Esempi Indennità contrattualeStorno di piccoli saldiCorrezione oneri duplicati | |||
| Saldo residuo OutstandingBalance | L'importo residuo dovuto dall'ente pagatore o dal paziente per l'evento di fatturazione. | ||
| Descrizione Questo attributo rappresenta il saldo corrente dei crediti per un specifico evento di fatturazione al momento dell'attività. Riflette lo stato finanziario del case durante il suo ciclo di vita. Il saldo residuo è fondamentale per il reporting finanziario e per l'Aging Report dei saldi in sospeso. Analizzare questo valore nel tempo e secondo diverse dimensioni, come ente pagatore o dipartimento, aiuta a dare priorità agli sforzi di recupero, gestire il flusso di cassa e valutare il rischio finanziario. Perché è importante Misura l'impatto finanziario dei ritardi ed è essenziale per dare priorità al recupero crediti e gestire il flusso di cassa. Dove trovare Questo è un campo fondamentale nel record del conto del paziente o dell'account 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 che è stato erogato. | ||
| Descrizione Questo attributo classifica il servizio fatturabile, ad esempio come 'Radiology', 'Surgery', 'Consultation' o 'Emergency Room Visit'. Fornisce un contesto clinico ai dati finanziari. Analizzare il ciclo dei ricavi per tipo di servizio può rivelare variazioni di processo specifiche per alcune aree cliniche. Ad esempio, le procedure chirurgiche possono avere requisiti di registrazione degli addebiti e di autorizzazione più complessi rispetto a una normale visita ambulatoriale, portando a comportamenti e sfide differenti nel processo. Perché è importante Fornisce un contesto clinico ai dati finanziari, consentendo di analizzare come i diversi tipi di servizi medici impattino sul processo del ciclo dei ricavi e sulla sua efficienza. Dove trovare Derivato dal catalogo prestazioni (CDM), dalla linea di servizio o dal dipartimento associato alla transazione in Epic. Esempi Chirurgia ospedalieraRadiologia ambulatorialeServizi di emergenza | |||
| Utente Responsabile ResponsibleUser | L'identificativo dell'utente o del dipendente che ha eseguito l'attività. | ||
| Descrizione Questo attributo rileva l'ID utente, il nome o il numero di matricola della persona responsabile del completamento di un task specifico nel ciclo dei ricavi. Potrebbe trattarsi del medico che ha inserito gli addebiti, dell'addetto alla fatturazione che ha inviato una pratica o dell'esattore che ha gestito un rifiuto. L'analisi per utente aiuta a identificare i top performer, individuare le esigenze di formazione e comprendere la distribuzione del carico di lavoro. È fondamentale per la gestione delle prestazioni e per indagare le deviazioni del processo associate a individui o ruoli specifici. Perché è importante Consente l'analisi delle performance per individuo o ruolo, aiutando a identificare opportunità di formazione, squilibri nel carico di lavoro e colli di bottiglia legati alle risorse. Dove trovare Solitamente reperibile negli audit trail o nei log delle transazioni di Epic Resolute, spesso collegato a una tabella anagrafica utenti (es. record EMP). Esempi j.doebsmith123User7890 | |||
| Data Scadenza Pagamento PaymentDueDate | La data entro la quale è previsto il pagamento per il servizio fatturato. | ||
| Descrizione Questo attributo specifica la scadenza per il pagamento, come indicato in fattura o stabilito dai contratti con gli enti pagatori. Funge da benchmark per misurare la puntualità dei pagamenti. La data di scadenza del pagamento è essenziale per creare l'Aging Report. Confrontando la data corrente con la scadenza dei saldi aperti, i crediti possono essere suddivisi in fasce di anzianità (es. 0-30 giorni, 31-60 giorni di ritardo), il che aiuta a dare priorità al recupero crediti sugli account più scaduti. Perché è importante Funge da base per l'analisi dell'anzianità dei crediti (aging), fondamentale per dare priorità ai recuperi e gestire il rischio finanziario derivante dalle fatture non pagate. Dove trovare Questa data è spesso calcolata in base alla data della fattura e ai termini di pagamento memorizzati nel contratto del pagatore o nelle informazioni del 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 i task eseguiti automaticamente dal sistema, come la generazione automatica delle pratiche o i controlli di idoneità, e quelli eseguiti manualmente da un utente. L'analisi di questo attributo aiuta a comprendere il livello di automazione del processo. Può essere utilizzato per confrontare l'efficienza e i tassi di errore delle attività automatizzate rispetto a quelle manuali, identificare opportunità per un'ulteriore automazione e monitorare le prestazioni dei bot o delle regole di sistema esistenti. Perché è importante Distingue tra attività guidate dal sistema e attività umane, fondamentale per valutare l'impatto dell'automazione. Dove trovare Questo viene spesso dedotto verificando se il 'ResponsibleUser' di un'attività è un account di sistema o di servizio, oppure contrassegnando nomi di attività specifici noti per essere automatizzati. Esempi truefalse | |||
| ID Paziente PatientId | L'identificatore univoco del paziente che riceve il servizio. | ||
| Descrizione Questo attributo è il Medical Record Number (MRN) o un altro identificatore univoco del paziente. Collega l'evento di fatturazione finanziaria a un individuo specifico. Sebbene non sia tipicamente utilizzato come dimensione di analisi primaria per proteggere la privacy dei pazienti, è essenziale per la validazione dei dati e può essere utilizzato per aggregare tutti gli eventi di fatturazione di un singolo paziente per comprenderne il percorso finanziario complessivo. È inoltre cruciale per l'integrazione con i dati dei processi clinici. Perché è importante Collega i dati finanziari a un paziente specifico, permettendo la convalida e l'analisi dell'intero percorso del paziente (da gestire con cura per la privacy). Dove trovare Un identificativo fondamentale presente in tutto il sistema Epic, collegato alla registrazione del paziente e ai record del conto. Esempi MRN-1234567MRN-8765432MRN-5551234 | |||
| ID Sinistro ClaimId | L'identificatore univoco assegnato a una pratica assicurativa inviata a un ente pagatore. | ||
| Descrizione Questo attributo è l'ID specifico per il modulo della pratica (es. CMS-1500 o UB-04) inviato a un ente pagatore. Un singolo evento di fatturazione potrebbe comportare più pratiche se i servizi vengono rifatturati o contestati. Il tracciamento tramite Claim ID è utile per l'analisi dettagliata dei sottoprocessi di invio pratiche e gestione dei rifiuti. Aiuta a distinguere le attività relative alla pratica iniziale da quelle relative a una successiva pratica ripresentata per lo stesso servizio. Perché è importante Fornisce un identificatore granulare per tracciare il ciclo di vita di ogni specifica presentazione della pratica, fondamentale per analizzare i rinvii e i ricorsi. Dove trovare Generato dal modulo di gestione richieste di Epic Resolute alla creazione della pratica. Esempi CLM-2023-98765CLAIM-0012345623189A4567 | |||
| Importo rettificato AdjustedAmount | Il valore monetario di una transazione di rettifica. | ||
| Descrizione Questo campo registra l'importo specifico di una rettifica del conto. Può essere un valore positivo o negativo, che rappresenta un credito o un debito sul saldo. Questo importo è la metrica principale per la dashboard 'Volume di rettifiche per tipo'. Sommando questo valore per motivo della rettifica si ottiene un quadro chiaro dell'impatto finanziario dei vari tipi di rettifiche, come quanti ricavi vengono stornati a causa di obblighi contrattuali rispetto a quanto viene perso per errori correggibili. Perché è importante Quantifica l'impatto finanziario delle rettifiche dei conti, rendendo possibile la misurazione della perdita di ricavi e dei costi derivanti da inesattezze nella fatturazione. Dove trovare Presente nelle tabelle di dettaglio delle transazioni finanziarie in Epic Resolute. Esempi -1250.45-50.0025.10 | |||
| Nome Pagatore PayerName | Il nome della compagnia assicurativa, dell'ente pubblico o dell'altra parte responsabile del pagamento. | ||
| Descrizione Questo attributo identifica l'ente pagatore principale associato all'evento di fatturazione, come 'Blue Cross Blue Shield', 'Medicare' o 'Aetna'. In caso di pagamento diretto, può indicare il paziente. Segmentare il processo per ente pagatore è una tecnica di analisi potente. Può rivelare che alcuni pagatori hanno tassi di rifiuto più elevati, cicli di pagamento più lunghi o requisiti più complessi. Questo insight consente di adattare le strategie di fatturazione a specifici pagatori per migliorare l'efficienza e la velocità degli incassi. Perché è importante Consente l'analisi per pagatore, rivelando quali hanno tassi di diniego elevati o cicli di pagamento lenti, permettendo strategie di follow-up mirate. Dove trovare Queste informazioni fanno parte dei dettagli di copertura del paziente, collegati all'account ospedaliero (HAR) in Epic Resolute. Esempi Medicare Part BUnitedHealthcareAetna PPO | |||
| Ora Fine Evento EventEndTime | Il timestamp che indica quando un'attività è stata completata, utile per calcolare la durata dell'attività. | ||
| Descrizione Questo attributo registra l'orario di completamento di un'attività. Mentre molte attività sono eventi istantanei in cui StartTime coincide con EndTime, alcuni task hanno una durata misurabile, come una chiamata di follow-up per un rifiuto. Quando disponibile, l'EndTime permette il calcolo diretto del tempo di elaborazione dell'attività ('EndTime' - 'StartTime'). Questo è più accurato rispetto all'inferire la durata dall'orario di inizio dell'attività successiva, poiché tiene conto del tempo di inattività tra le fasi. È una componente chiave per calcolare l'attributo 'ProcessingTime'. Perché è importante Consente il calcolo preciso della durata di ogni attività, fondamentale per identificare i compiti inefficienti. Dove trovare Questo potrebbe essere disponibile in alcuni moduli di Epic Resolute che tracciano l'inizio e la fine dei task, come i log delle code di lavoro o della gestione attività. Spesso non è tracciato 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 sorgente del record, che in questo contesto è Epic Resolute. In ambienti con più sistemi integrati, questo campo aiuta a differenziare le origini dei dati. Anche se può sembrare ridondante in una vista a sistema singolo, è una best practice per la data governance e la scalabilità. Garantisce chiarezza nel caso in cui vengano integrati successivamente dati provenienti da altri sistemi, come una piattaforma esterna di recupero crediti. Perché è importante Fornisce lineage e contesto dei dati cruciali, garantendo chiarezza sull'origine delle informazioni, aspetto vitale per la data governance e la risoluzione dei problemi. Dove trovare Questo è tipicamente un valore statico aggiunto durante il processo di estrazione e trasformazione dei dati per etichettare l'origine del dataset. Esempi Epic ResoluteEpicResolute_V2023 | |||
| Tempo di Elaborazione ProcessingTime | La durata calcolata del tempo trascorso lavorando attivamente su un'attività. | ||
| Descrizione Il tempo di elaborazione, noto anche come handling time, misura la durata di un'attività dal suo inizio alla sua conclusione. Rappresenta il tempo in cui una risorsa è stata attivamente impegnata nello svolgimento del task. Questa metrica viene calcolata come differenza tra 'EventEndTime' e 'EventTimestamp'. L'analisi del tempo di elaborazione aiuta a identificare quali attività specifiche richiedano più tempo, consentendo di concentrare gli sforzi sull'ottimizzazione e sul miglioramento dell'efficienza. È una misura fondamentale della produttività delle risorse. Perché è importante Misura la durata effettiva delle attività, aiutando a identificare i compiti più lunghi e valutare l'efficienza delle risorse. Dove trovare Questo non è un campo nel sistema sorgente. Viene calcolato durante la trasformazione dei dati utilizzando la formula: EventEndTime - EventTimestamp. Esempi 900605120 | |||
| Tempo totale del ciclo dei ricavi TotalRevenueCycleTime | La durata totale calcolata dal primo evento di servizio fino al pagamento finale o alla chiusura del conto. | ||
| Descrizione Questo è un KPI a livello di case che misura la durata end-to-end del ciclo dei ricavi per un singolo evento di fatturazione. Di solito viene calcolato come differenza temporale tra l'attività 'Service Rendered' e l'attività finale 'Payment Received' o 'Account Closed'. Questa metrica di alto livello offre una visione olistica dell'efficienza complessiva del processo RCM. Monitorare questo KPI 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 end-to-end di alto livello sull'efficienza del processo, misurando direttamente quanto tempo occorre per convertire un servizio in liquidità. Dove trovare Si tratta di una metrica calcolata all'interno dello strumento di process mining filtrando il primo e l'ultimo evento di ogni case e calcolando la differenza temporale. Esempi 259200038880005184000 | |||
| Ultimo `Data Update` LastDataUpdate | Il `timestamp` che indica l'ultima volta che i `dati` per questo `evento` sono stati aggiornati o estratti dal sistema di origine. | ||
| Descrizione Questo attributo mostra l'aggiornamento dei dati. Indica l'ultima volta che il record è stato estratto da Epic Resolute nel dataset di process mining. Questo è importante per comprendere la tempestività dell'analisi e per scopi di validazione. Aiuta gli utenti a sapere se stanno consultando le informazioni più recenti disponibili ed è fondamentale per gestire i cicli di aggiornamento dei dati. Perché è importante Garantisce che gli utenti comprendano l'attualità dei dati analizzati, fondamentale per prendere decisioni di business corrette. Dove trovare Questo timestamp viene aggiunto dal processo ETL (Extract, Transform, Load) durante l'importazione dei dati. Esempi 2023-06-10T02:00:00Z2023-06-11T02:00:00Z | |||
Attività di Revenue Cycle Management
| Activity | Descrizione | ||
|---|---|---|---|
| Conto chiuso | Questa è l'attività finale, che indica che il saldo residuo dell'evento di fatturazione ha raggiunto lo zero e non ci sono più attività in sospeso. Ciò può essere dovuto a un pagamento completo, a rettifiche o a uno storno. | ||
| Perché è importante Questo evento segna il completamento con successo del ciclo dei ricavi per un evento di fatturazione. La durata end-to-end dal servizio alla chiusura è un KPI critico per l'efficienza complessiva del processo. Dove trovare Si tratta solitamente di un evento dedotto. Viene determinato identificando il momento in cui il saldo del conto per l'evento di fatturazione diventa zero e rimane tale. Acquisisci Dedotto calcolando il saldo progressivo e identificando il timestamp dell'ultima transazione che ha azzerato il saldo. Tipo di evento inferred | |||
| Oneri acquisiti | Rappresenta la registrazione formale degli addebiti fatturabili per i servizi resi. In Epic, si tratta solitamente di una transazione esplicita registrata sul conto del paziente, spesso generata automaticamente da azioni cliniche o inserita manualmente. | ||
| Perché è importante Questa è una prima tappa fondamentale. Misurare la velocità e l'accuratezza della registrazione degli addebiti aiuta ad accelerare il processo di fatturazione e garantisce che tutte le prestazioni fornite siano fatturate. Dove trovare Registrato nei log di transazione di Resolute come voce discreta con data e importo. Acquisisci Acquisizione delle transazioni di addebito dal log delle transazioni finanziarie del sistema. Tipo di evento explicit | |||
| Pagamento contabilizzato sul conto | Questo è 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 Una contabilizzazione efficiente dei pagamenti è cruciale per mantenere saldi accurati e chiudere gli eventi di fatturazione, permettendo di identificare correttamente i crediti residui. Dove trovare Questa è una transazione esplicita in Resolute. La registrazione del pagamento collega una transazione di pagamento a una o più transazioni di addebito, registrate nelle tabelle di dettaglio delle transazioni. Acquisisci Acquisizione del record di transazione che applica un pagamento a un onere specifico. Tipo di evento explicit | |||
| Pagamento ricevuto | Rappresenta la ricezione del pagamento da parte di un ente pagatore o di un paziente. Questo evento viene solitamente registrato quando viene caricato un avviso di rimessa elettronico (ERA) o quando viene inserito nel sistema un assegno manuale. | ||
| Perché è importante Questa attività è una tappa fondamentale che indica l'entrata di ricavi. Il tempo che intercorre tra l'invio della pratica e la ricezione del pagamento è una misura chiave delle prestazioni dei crediti verso i clienti. Dove trovare Registrato come transazione di pagamento in Resolute, con data, fonte e importo. Acquisisci Acquisizione delle transazioni di pagamento dal log, identificate da tipi di transazione specifici. Tipo di evento explicit | |||
| Richiesta presentata al pagatore | Questo segna l'evento in cui la pratica viene ufficialmente inviata all'ente pagatore assicurativo per la liquidazione. In Epic, questo è un evento tracciato, registrato quando il file elettronico della pratica viene trasmesso alla clearinghouse o al pagatore. | ||
| Perché è importante Questo traguardo è fondamentale poiché avvia il conteggio dei tempi di pagamento del pagatore. Analizzare questo dato aiuta a misurare l'efficienza del processo di trasmissione delle pratiche e supporta il KPI 'Invoice to Payer Delivery Time'. Dove trovare Questo è un evento esplicito registrato in Resolute. Il record della pratica avrà uno stato di invio e un timestamp che indica quando è stata spedita. Acquisisci Acquisizione del timestamp associato al passaggio dello stato della richiesta a 'Inviata' o 'Trasmessa'. Tipo di evento explicit | |||
| Richiesta respinta dal pagatore | Rappresenta la ricezione di una notifica da parte dell'ente pagatore che comunica il rifiuto della richiesta. Questo viene rilevato quando Epic elabora un avviso di rimessa elettronico (file 835) o quando un utente registra manualmente un rifiuto. | ||
| Perché è importante Questa attività avvia un ciclo critico di rilavorazione. Analizzare i motivi e i volumi dei rifiuti è essenziale per identificare le cause profonde, migliorare i tassi di pagamento al primo invio e ridurre i ritardi negli incassi. Dove trovare Registrato come transazione o aggiornamento di stato. Le informazioni sui dinieghi vengono solitamente ricevute elettronicamente. Acquisisci Filtro per tipi di transazione o aggiornamenti di stato che indicano un diniego. Tipo di evento explicit | |||
| Servizio Erogato | Questa attività segna il momento in cui un servizio clinico viene fornito al paziente, avviando l'evento di fatturazione. Viene spesso acquisita dall'EHR Epic (EpicCare) quando un medico convalida una visita o una procedura. | ||
| Perché è importante Questo è l'evento di inizio principale per il ciclo dei ricavi. Analizzare il tempo che intercorre da questo punto alla registrazione dell'addebito è fondamentale per identificare ritardi nell'avvio della fatturazione e potenziali perdite di ricavi. Dove trovare Questo evento viene solitamente dedotto dai timestamp del servizio o della visita nei moduli clinici collegati al conto di fatturazione. La data del servizio sulla transazione di addebito è il punto dati chiave. Acquisisci Dedotto dalla data del servizio associata alla prima transazione di addebito dell'evento. Tipo di evento inferred | |||
| Follow-up del diniego avviato | Questa attività segna l'inizio del processo interno per esaminare e risolvere una pratica rifiutata. Viene spesso registrata quando un utente prende in carico la pratica rifiutata in una workqueue o ne cambia lo stato. | ||
| Perché è importante Tracciare questo dato aiuta a misurare la reattività del team di gestione dei rifiuti. Ritardi tra la ricezione di un rifiuto e l'inizio del follow-up possono allungare inutilmente il ciclo dei ricavi. Dove trovare Questo viene solitamente dedotto dai cambiamenti nello stato della pratica o dalla cronologia delle assegnazioni all'interno delle workqueue di Epic. Ad esempio, lo stato della pratica potrebbe passare da 'Denied' a 'In Review'. Acquisisci Deduzione da un cambio di stato della pratica o da una voce di audit log che mostra l'inizio dell'elaborazione del diniego. Tipo di evento inferred | |||
| Rettifica conto effettuata | Questa attività rappresenta una transazione non di pagamento che modifica il saldo del conto, come una rettifica contrattuale, uno storno di un piccolo saldo o uno sconto di cortesia. Viene registrata come un tipo di transazione specifico. | ||
| Perché è importante Analizzare le rettifiche è fondamentale per identificare perdite di ricavi. Volumi elevati di rettifiche possono indicare problemi con i tariffari, i contratti o le policy interne. Dove trovare Registrato come transazione di rettifica nei log finanziari di Resolute, con un codice motivo specifico. Acquisisci Filtro per tipi di transazione che corrispondono a rettifiche finanziarie o storni. Tipo di evento explicit | |||
| Richiesta generata | Questa attività indica la creazione da parte del sistema di una pratica formale o di una fattura basata sugli addebiti registrati. È una fase preparatoria prima dell'invio della pratica all'ente pagatore o al paziente. | ||
| Perché è importante Tracciare la generazione della pratica aiuta a isolare i ritardi tra la registrazione degli addebiti e la loro preparazione per l'invio. È una fase interna fondamentale che può influire sulla tempestività complessiva della fatturazione. Dove trovare Questo viene solitamente registrato quando viene eseguito un processo batch di generazione di fatture o pratiche. Il sistema registra un timestamp quando viene creato il file della pratica (come un file 837) per un determinato conto. Acquisisci Identificazione delle voci di log o dei cambi di stato che indicano che la pratica è pronta per l'invio. Tipo di evento explicit | |||
| Richiesta presentata nuovamente | Questo evento si verifica dopo che una pratica rifiutata è stata corretta e rispedita all'ente pagatore. Si tratta di un evento di invio distinto collegato alla pratica originale. | ||
| Perché è importante Questa è una parte chiave del ciclo di rilavorazione. Misurare il tempo di rinvio e il tasso di successo delle pratiche ripresentate è vitale per comprendere l'efficacia del processo di risoluzione dei rifiuti. Dove trovare Questo è un evento esplicito simile all'invio iniziale, ma spesso contrassegnato come nuovo invio (resubmission). Il record della pratica mostrerà un nuovo timestamp di invio e potrebbe includere un codice di resubmission. Acquisisci Acquisizione del timestamp per l'invio di una pratica contrassegnata come correzione o nuovo invio. Tipo di evento explicit | |||
| Saldo inviato al recupero crediti | Questo segna il momento in cui un saldo non pagato viene trasferito a un processo di recupero crediti interno o esterno. Spesso si tratta di un cambio di stato esplicito sul conto o sull'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 è vitale per ridurre al minimo i crediti inesigibili. Dove trovare Si tratta in genere di un evento esplicito. Epic dispone di funzioni per trasferire i conti alle agenzie di recupero crediti, il che crea una voce di log o un cambio di stato sul conto. Acquisisci Identificazione del cambio di stato che indica il passaggio dell'account a un'agenzia di recupero crediti. Tipo di evento explicit | |||
Guide all'Estrazione
Fasi
- Configurazione della connessione al database: Ottenere le credenziali di sola lettura per il database Epic Clarity. Utilizzare un client SQL standard, come DBeaver o Microsoft SQL Server Management Studio.
- Identificazione delle tabelle principali: Le tabelle primarie includono
HSP_ACCOUNTper i casi,HSP_TRANSACTIONSper gli eventi finanziari,CLP_CLAIM_INFOper lo stato delle richieste di rimborso eF_ARHB_TX_SET_POST_HXper i dettagli dei pagamenti. Saranno necessari join con file master comeCLARITY_EMP. - Definizione dell'ambito: Determinare lo scope dell'analisi definendo un intervallo di date (solitamente 3-6 mesi) e identificando aree di servizio (
SERV_AREA_ID) o classi di account specifiche da includere. - Sviluppo della query SQL: Costruire una query SQL utilizzando una Common Table Expression (CTE) per selezionare inizialmente i valori
HSP_ACCOUNT_IDnell'ambito definito. - Unione delle query sulle singole attività: Per ciascuna delle 12 attività richieste, scrivere un'istruzione
SELECTseparata che estragga i dati dalle tabelle pertinenti, collegandoli alla CTE iniziale. - Combinazione delle query con UNION ALL: Utilizzare l'operatore
UNION ALLper combinare i risultati di tutte le query in un unico log degli eventi coerente. - Mappatura allo schema standard: In ogni
SELECT, assegnare alias alle colonne per corrispondere allo schema di ProcessMind:BillingEvent,ActivityName,EventTimestamp,ResponsibleUser, ecc. - Esecuzione e perfezionamento: Eseguire la query sul database Clarity. Se le prestazioni sono basse dato il volume dei dati, restringere l'intervallo di date o aggiungere filtri nella CTE iniziale.
- Revisione dell'output: Verificare le prime righe dell'output per assicurarsi che tutte le colonne siano presenti, i timestamp siano coerenti e i valori
ActivityNamecorretti. - Esportazione in CSV: Esportare i risultati in un file CSV con codifica UTF-8, includendo l'intestazione con i nomi delle colonne corretti.
- Preparazione per l'upload: Controllare che il formato dei timestamp nel CSV sia coerente (es.
YYYY-MM-DD HH:MI:SS) prima di procedere al caricamento in ProcessMind.
Configurazione
- Connessione al database: È necessario un account utente in sola lettura con accesso al database Epic Clarity.
- Parametri dell'intervallo di date: La query fornita utilizza le variabili
@StartDatee@EndDate. Queste devono essere impostate per definire il periodo di analisi. Si consiglia un intervallo da 3 a 6 mesi per bilanciare il volume dei dati con le prestazioni. - Mappatura di tabelle e colonne: La query presuppone nomi standard per tabelle e colonne di Clarity. La configurazione specifica di Epic o la versione della propria organizzazione potrebbero presentare variazioni. Potrebbe essere necessario adattare i nomi delle tabelle, 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]. È necessario consultare gli amministratori del sistema Epic o consultare i file master pertinenti, comeZC_TX_TYPEoZC_ACCOUNT_STATUS, per trovare i codici corretti per la propria istanza. - Filtraggio: Per prestazioni migliori e un'analisi più mirata, aggiungere filtri alla CTE iniziale
BaseAccounts. I filtri comuni includonoSERV_AREA_IDper limitare l'analisi a un'area di assistenza 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; Fasi
- Configurazione della connessione al database: Ottenere le credenziali di sola lettura per il database Epic Clarity. Utilizzare un client SQL standard, come DBeaver o Microsoft SQL Server Management Studio.
- Identificazione delle tabelle principali: Le tabelle primarie includono
HSP_ACCOUNTper i casi,HSP_TRANSACTIONSper gli eventi finanziari,CLP_CLAIM_INFOper lo stato delle richieste di rimborso eF_ARHB_TX_SET_POST_HXper i dettagli dei pagamenti. Saranno necessari join con file master comeCLARITY_EMP. - Definizione dell'ambito: Determinare lo scope dell'analisi definendo un intervallo di date (solitamente 3-6 mesi) e identificando aree di servizio (
SERV_AREA_ID) o classi di account specifiche da includere. - Sviluppo della query SQL: Costruire una query SQL utilizzando una Common Table Expression (CTE) per selezionare inizialmente i valori
HSP_ACCOUNT_IDnell'ambito definito. - Unione delle query sulle singole attività: Per ciascuna delle 12 attività richieste, scrivere un'istruzione
SELECTseparata che estragga i dati dalle tabelle pertinenti, collegandoli alla CTE iniziale. - Combinazione delle query con UNION ALL: Utilizzare l'operatore
UNION ALLper combinare i risultati di tutte le query in un unico log degli eventi coerente. - Mappatura allo schema standard: In ogni
SELECT, assegnare alias alle colonne per corrispondere allo schema di ProcessMind:BillingEvent,ActivityName,EventTimestamp,ResponsibleUser, ecc. - Esecuzione e perfezionamento: Eseguire la query sul database Clarity. Se le prestazioni sono basse dato il volume dei dati, restringere l'intervallo di date o aggiungere filtri nella CTE iniziale.
- Revisione dell'output: Verificare le prime righe dell'output per assicurarsi che tutte le colonne siano presenti, i timestamp siano coerenti e i valori
ActivityNamecorretti. - Esportazione in CSV: Esportare i risultati in un file CSV con codifica UTF-8, includendo l'intestazione con i nomi delle colonne corretti.
- Preparazione per l'upload: Controllare che il formato dei timestamp nel CSV sia coerente (es.
YYYY-MM-DD HH:MI:SS) prima di procedere al caricamento in ProcessMind.
Configurazione
- Connessione al database: È necessario un account utente in sola lettura con accesso al database Epic Clarity.
- Parametri dell'intervallo di date: La query fornita utilizza le variabili
@StartDatee@EndDate. Queste devono essere impostate per definire il periodo di analisi. Si consiglia un intervallo da 3 a 6 mesi per bilanciare il volume dei dati con le prestazioni. - Mappatura di tabelle e colonne: La query presuppone nomi standard per tabelle e colonne di Clarity. La configurazione specifica di Epic o la versione della propria organizzazione potrebbero presentare variazioni. Potrebbe essere necessario adattare i nomi delle tabelle, 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]. È necessario consultare gli amministratori del sistema Epic o consultare i file master pertinenti, comeZC_TX_TYPEoZC_ACCOUNT_STATUS, per trovare i codici corretti per la propria istanza. - Filtraggio: Per prestazioni migliori e un'analisi più mirata, aggiungere filtri alla CTE iniziale
BaseAccounts. I filtri comuni includonoSERV_AREA_IDper limitare l'analisi a un'area di assistenza 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;