Il Suo Template dei dati per la gestione del ciclo dei ricavi
Il Suo Template dei dati per la gestione del ciclo dei ricavi
- Attributi dei dati consigliati per un'analisi completa
- Attività chiave del processo da monitorare in modo efficace
- Indicazioni pratiche per estrarre i dati da Waystar
Attributi della gestione del ciclo attivo
| Nome | Descrizione | ||
|---|---|---|---|
| Evento di fatturazione BillingEvent | L’identificativo univoco di una singola erogazione di servizio o consegna di prodotto che genera un addebito e costituisce il caso del processo del ciclo dei ricavi. | ||
| Descrizione Il Billing Event funge da identificativo principale del caso e collega tutte le attività, dall’acquisizione dell’addebito alla chiusura del conto, relative a uno specifico servizio fatturabile. Rappresenta l’intero ciclo di vita di una singola richiesta o fattura del paziente. Nel Process Mining, analizzare il percorso di ogni Billing Event consente di ottenere una visione completa del ciclo dei ricavi. Aiuta a individuare i percorsi di processo più comuni, le deviazioni e i colli di bottiglia che interessano le singole richieste. Questo livello di granularità è essenziale per comprendere le performance del processo e individuare aree specifiche di miglioramento, come i ritardi nell’invio delle richieste o nella registrazione dei pagamenti. Perché è importante Questo è il Case ID essenziale che collega tutte le attività correlate del ciclo dei ricavi, rendendo possibile tracciare il processo end-to-end per ogni voce fatturabile. Dove reperirlo In genere corrisponde alla chiave primaria della principale tabella delle transazioni di fatturazione o delle richieste in Waystar. Consulti la documentazione di Waystar per conoscere il nome specifico della tabella e del campo. Esempi BE-2024-0012345BE-2024-0012346BE-2024-0012347 | |||
| Nome dell’attività ActivityName | Il nome dello specifico evento o passaggio aziendale che si è verificato nel processo del ciclo dei ricavi, come «Claim Submitted» o «Payment Posted». | ||
| Descrizione Questo Attributo descrive le singole attività che compongono il processo end-to-end del ciclo dei ricavi. Ogni valore rappresenta un passaggio, una milestone o un’attività distinta eseguita su un evento di fatturazione, come la creazione di una richiesta, la ricezione di un diniego o la registrazione di un pagamento. Analizzare la sequenza e la frequenza di queste attività costituisce la base del Process Mining. Consente di visualizzare la mappa del processo, identificare i cicli di rielaborazione, ad esempio «Claim Denied» seguito da «Claim Corrected», e misurare i tempi di transizione tra i passaggi. È fondamentale per comprendere l’efficienza del processo e la Conformità. Perché è importante Questo Attributo definisce i passaggi nella mappa del processo, elemento fondamentale per visualizzare e analizzare il Workflow del ciclo dei ricavi. Dove reperirlo Generato dagli Event Log, dai record delle modifiche di stato o dai tipi di transazione nei moduli di Waystar dedicati alle richieste e alla fatturazione. Esempi Richiesta inviata al payerRichiesta di rimborso respintaPagamento registratoConto chiuso | |||
| Timestamp dell’evento EventTimestamp | La data e l’ora precise in cui si è verificata l’attività. | ||
| Descrizione L’Event Timestamp registra il momento esatto in cui si è svolta un’attività. Questo timestamp è fondamentale per ordinare cronologicamente gli eventi e calcolare la durata tra i diversi passaggi del processo. Nell’analisi dei processi, i timestamp vengono utilizzati per calcolare indicatori chiave della performance, come tempi di ciclo, tempi di attesa e tempi di elaborazione. Ad esempio, la differenza tra il timestamp di «Claim Submitted» e quello di «Payment Posted» determina la durata complessiva del ciclo di pagamento. Timestamp accurati sono essenziali per l’analisi dei colli di bottiglia e il monitoraggio delle performance. Perché è importante I timestamp sono necessari per ordinare gli eventi, calcolare i tempi di ciclo e analizzare le performance del processo, costituendone la struttura temporale di riferimento. Dove reperirlo È un campo standard associato a quasi ogni transazione o record di modifica dello stato in Waystar, spesso denominato «Creation Date», «Transaction Date» o in modo analogo. Esempi 2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-11-05T09:15:00Z | |||
| Sistema di origine SourceSystem | Il sistema o l’applicazione da cui hanno avuto origine i dati dell’evento. | ||
| Descrizione Questo Attributo identifica il sistema di origine che ha generato i dati dell’evento. In un panorama IT complesso, gli eventi del ciclo dei ricavi possono avere origine da moduli diversi di Waystar o persino da sistemi esterni integrati, come un Electronic Health Record (EHR). Comprendere il sistema di origine è importante per la convalida dei dati, la risoluzione dei problemi e l’analisi delle variazioni del processo che possono dipendere da comportamenti diversi dei sistemi. Aiuta ad attribuire i problemi di processo all’applicazione o all’interfaccia corretta. Perché è importante Identifica l’origine dei dati, aspetto fondamentale per la governance dei dati, la garanzia della qualità e la comprensione delle variazioni del processo tra sistemi diversi. Dove reperirlo Spesso è un valore statico («Waystar») aggiunto durante l’estrazione dei dati oppure può essere ricavato da moduli o tabelle specifici del sistema. Esempi Waystar RCMModulo di fatturazione WaystarInterfaccia EHR | |||
| Ultimo aggiornamento dei dati LastDataUpdate | Il timestamp che indica l’ultima volta in cui i dati relativi a questo evento sono stati aggiornati o estratti. | ||
| Descrizione Questo Attributo fornisce il timestamp dell’ultima estrazione dei dati dal sistema di origine. Non indica il momento in cui si è verificato l’evento aziendale, bensì quello in cui il record è stato acquisito per l’analisi. Questa informazione è fondamentale per la governance dei dati e per comprendere il livello di aggiornamento dei dati nell’analisi di Process Mining. Aiuta a sapere se le informazioni esaminate sono aggiornate ed è essenziale per gestire i caricamenti incrementali dei dati. Perché è importante Garantisce la trasparenza dei dati indicando il livello di aggiornamento del dataset, aspetto essenziale per report e analisi accurati e tempestivi. Dove reperirlo Questo timestamp viene generalmente generato e aggiunto a ogni riga dal processo ETL (Extract, Transform, Load) durante l’acquisizione dei dati. Esempi 2024-01-15T02:00:00Z2024-01-16T02:00:00Z | |||
| Codice del motivo del diniego DenialReasonCode | Un codice standardizzato che indica il motivo per cui il payer ha respinto una richiesta. | ||
| Descrizione Quando un payer respinge una richiesta, fornisce un codice motivazionale che spiega il rifiuto. Questi codici possono indicare problemi quali informazioni mancanti, servizi non coperti o errori di codifica. Questo Attributo acquisisce il codice specifico. Analizzare i Denial Reason Codes è fondamentale per migliorare il ciclo dei ricavi. Consente all’organizzazione di individuare le cause principali dei dinieghi, come errori frequenti di uno specifico reparto o problemi legati ai requisiti di un determinato payer. Questi dati alimentano direttamente la Dashboard «Claim Denial Rate and Reasons» e sono essenziali per sviluppare strategie che prevengano futuri dinieghi e migliorino i tassi di pagamento al primo invio. Perché è importante Questo Attributo è essenziale per l’analisi delle cause principali dei dinieghi, consentendo di definire azioni mirate per ridurre la perdita di ricavi e la rielaborazione. Dove reperirlo Viene valorizzato nel record della richiesta quando si verifica un evento di diniego. L’informazione viene ricevuta dal payer nella remittance advice. Esempi CO-16: alla richiesta o al servizio mancano informazioniPR-96: addebiti non copertiCO-22: questa prestazione potrebbe essere coperta da un altro pagatore | |||
| Importo fatturato BilledAmount | L’importo totale addebitato per i servizi erogati indicati nella richiesta. | ||
| Descrizione Billed Amount rappresenta l’addebito lordo per i servizi erogati al paziente prima dell’applicazione di rettifiche, abbuoni contrattuali o pagamenti. È il valore iniziale della richiesta inviata al payer. Questo Attributo è fondamentale per l’analisi finanziaria e per comprendere il valore monetario che attraversa il processo. Può essere utilizzato per segmentare l’analisi in base al valore della richiesta, individuare tendenze negli addebiti per servizi diversi e calcolare l’impatto finanziario complessivo delle inefficienze di processo, come dinieghi o ritardi nei pagamenti. È una metrica di base per la maggior parte delle Dashboard finanziarie. Perché è importante Rappresenta il valore totale di una richiesta e consente di analizzare l’impatto finanziario dei ritardi di processo, dei dinieghi e delle rettifiche. Dove reperirlo È un campo finanziario standard nella schermata di inserimento della richiesta o dell’addebito in Waystar. Esempi 150.001250.75540.50 | |||
| Nome del payer PayerName | Il nome della compagnia assicurativa o del payer terzo responsabile della richiesta. | ||
| Descrizione Questo Attributo identifica il payer specifico, ad esempio una compagnia assicurativa, un programma pubblico come Medicare o un’altra entità responsabile della valutazione e del pagamento della richiesta. Ogni payer può avere requisiti di invio, tempistiche di pagamento e modelli di diniego diversi. Analizzare il processo per Nome del payer è essenziale per individuare quali payer presentano i cicli di pagamento più lunghi, i tassi di diniego più elevati o i processi più complessi. Ciò consente alle organizzazioni di definire strategie mirate, dare priorità ai solleciti verso i payer problematici e negoziare contratti migliori. Perché è importante Segmentare il processo per payer è fondamentale per individuare colli di bottiglia specifici, motivi dei dinieghi e ritardi nei pagamenti. Dove reperirlo Si trova nelle informazioni relative alla richiesta o alla fatturazione, collegate ai dati assicurativi del paziente in Waystar. Esempi AetnaBlue Cross Blue ShieldCignaMedicare Parte B | |||
| Saldo residuo OutstandingBalance | L’importo residuo ancora da riscuotere per l’evento di fatturazione. | ||
| Descrizione Outstanding Balance rappresenta l’importo corrente dei crediti verso clienti relativo a un determinato evento di fatturazione. Viene calcolato come importo fatturato meno i pagamenti e le rettifiche applicati fino a quel momento. È una metrica finanziaria fondamentale per la gestione del flusso di cassa e dei crediti verso clienti. Costituisce l’Attributo principale della Dashboard «Outstanding Balances and Aging» e consente all’organizzazione di monitorare i crediti complessivi, individuare i conti con saldo elevato e stabilire le priorità delle attività di riscossione. Monitorare questo valore nel tempo mostra l’efficacia del processo di riscossione. Perché è importante Misura direttamente i crediti verso clienti, elemento essenziale per gestire il flusso di cassa, stabilire le priorità della riscossione e valutare la salute finanziaria. Dove reperirlo È generalmente un campo calcolato nei moduli di reporting di Waystar (Billed Amount - Paid Amount - Adjustments). Potrebbe essere necessario calcolarlo durante l’estrazione dei dati se non è disponibile un campo diretto. Esempi 30.00270.25540.50 | |||
| Stato della richiesta ClaimStatus | Lo stato attuale della richiesta nel suo ciclo di vita, ad esempio «Submitted», «Pending», «Paid» o «Denied». | ||
| Descrizione Claim Status fornisce una fotografia della posizione di uno specifico evento di fatturazione nel ciclo dei ricavi in un determinato momento. Indica l’ultima milestone raggiunta, ad esempio se la richiesta è stata inviata, è in fase di revisione da parte del payer, è stata pagata o è stata respinta. Questo Attributo è fondamentale per il reporting finanziario e la gestione operativa. Nel Process Mining aiuta a comprendere lo stato attuale di tutti i casi aperti e può essere utilizzato per analizzare quanto tempo i casi trascorrono in determinati stati, come «Pending Payer Adjudication». Supporta direttamente la Dashboard «Outstanding Balances and Aging». Perché è importante Fornisce una visione dello stato attuale di tutte le richieste in corso, consentendo di analizzare i colli di bottiglia e stabilire le priorità operative. Dove reperirlo È un campo standard del record della richiesta o della fatturazione in Waystar, aggiornato man mano che la richiesta avanza nel ciclo. Esempi InviataPresa in carico dal pagatoreRifiutataPagata integralmente | |||
| Tipo di servizio ServiceType | La categoria o il tipo di servizio medico erogato, come «Radiology», «Consultation» o «Surgical Procedure». | ||
| Descrizione Service Type classifica la natura del servizio fatturabile erogato al paziente. Tipi diversi di servizio presentano spesso codici di fatturazione, tariffe di rimborso e complessità di processo distinti. Questo Attributo consente un’analisi granulare del ciclo dei ricavi in base al reparto clinico o alla linea di servizio. Aiuta a rispondere a domande come «Quali linee di servizio registrano i maggiori ritardi di fatturazione?» oppure «I tassi di diniego sono più elevati per le procedure chirurgiche rispetto alle consulenze?». È fondamentale per analizzare le performance dei reparti e definire interventi di miglioramento mirati. Perché è importante Consente di analizzare le performance del processo per reparto clinico o linea di servizio, evidenziando variazioni in termini di efficienza e redditività. Dove reperirlo In genere deriva dai codici delle procedure (CPT/HCPCS) oppure è collegato al reparto che ha erogato il servizio in Waystar. Esempi RadiologiaConsulto cardiologicoAccesso al pronto soccorsoIntervento chirurgico ambulatoriale | |||
| Classe del paziente PatientClass | Indica lo stato del paziente per l’episodio assistenziale, ad esempio «Inpatient» o «Outpatient». | ||
| Descrizione Patient Class categorizza il tipo di episodio assistenziale del paziente, che spesso determina le regole di fatturazione e le tariffe di rimborso. Le classi comuni includono Inpatient, Outpatient ed Emergency. Analizzare il ciclo dei ricavi per Patient Class può evidenziare differenze significative nel processo. Ad esempio, le richieste relative a pazienti ricoverati sono spesso più complesse e presentano cicli di pagamento più lunghi rispetto a quelle dei pazienti ambulatoriali. Questa segmentazione è importante per definire obiettivi realistici di performance e adattare le iniziative di miglioramento alle esigenze specifiche di ciascuna classe. Perché è importante Aiuta a segmentare il processo in base alla complessità dell’episodio, ad esempio paziente ricoverato o ambulatoriale, spesso correlata a regole di fatturazione e tempi di ciclo diversi. Dove reperirlo È un campo standard nei dati di registrazione del paziente o dell’episodio assistenziale in Waystar o nell’EHR di origine. Esempi RicoveroAmbulatorialeEmergenza | |||
| Codice del motivo della rettifica AdjustmentReasonCode | Un codice che spiega il motivo di una rettifica finanziaria del saldo del conto. | ||
| Descrizione Quando il saldo di un conto cambia per motivi diversi da un pagamento, come un abbuono contrattuale o uno stralcio, viene utilizzato un Adjustment Reason Code per documentarne la causa. Questo Attributo acquisisce tale codice. Analizzare questi codici è essenziale per la Dashboard «Account Adjustment Rate and Impact». Aiuta a individuare le cause principali delle perdite di ricavi, come frequenti rettifiche contrattuali con determinati payer o stralci dovuti a errori di fatturazione. Comprendere queste motivazioni è il primo passo per ridurre al minimo le perdite di ricavi evitabili. Perché è importante Spiega perché i ricavi sono stati rettificati o stornati, fornendo informazioni fondamentali sulle perdite di ricavi e sulle performance dei contratti con i payer. Dove reperirlo Associato alle transazioni di rettifica nel modulo di registrazione dei pagamenti o dei crediti verso clienti di Waystar. Esempi Obbligo contrattualeStralcio di piccoli saldiCorrezione di un errore di fatturazione | |||
| Data di scadenza del pagamento PaymentDueDate | La data entro la quale è previsto il pagamento della fattura o della richiesta. | ||
| Descrizione Payment Due Date è la data stabilita dall’erogatore o prevista dai contratti con i payer entro la quale il pagamento dovrebbe essere ricevuto. Funge da riferimento per misurare la puntualità dei pagamenti. Questo Attributo è essenziale per la Dashboard «Outstanding Balances and Aging». Viene utilizzato per calcolare l’anzianità dei crediti, classificandoli in fasce come «0-30 giorni», «31-60 giorni» e così via. Questa analisi dell’anzianità è una pratica finanziaria standard per gestire i crediti verso clienti e stabilire le priorità delle attività di riscossione sui conti scaduti. Perché è importante Fornisce il riferimento per calcolare l’anzianità dei crediti, elemento fondamentale per gestire la riscossione e comprendere la puntualità del flusso di cassa. Dove reperirlo Può essere presente nel record della fattura o della richiesta. Potrebbe essere calcolata in base alla data della fattura e ai termini di pagamento. Esempi 2023-11-252023-12-152024-01-30 | |||
| ID del paziente PatientId | L’identificativo univoco del paziente che ha ricevuto il servizio. | ||
| Descrizione Questo Attributo è l’identificativo univoco del paziente associato all’evento di fatturazione. Collega la transazione finanziaria alla persona che ha ricevuto l’assistenza. Sebbene il Billing Event rappresenti il caso, Patient ID consente un’analisi incentrata sul paziente. Può aiutare a identificare i pazienti ricorrenti, comprendere il percorso finanziario end-to-end del paziente attraverso più visite e analizzare se determinati dati demografici siano associati a problemi di pagamento o a tassi di diniego più elevati. Permette di aggregare tutte le attività di fatturazione relative a una singola persona. Perché è importante Consente un’analisi incentrata sul paziente e una visione dell’intero percorso finanziario di una persona attraverso più eventi di fatturazione. Dove reperirlo È un campo standard del record della richiesta o di registrazione del paziente in Waystar, oppure è collegato da un EHR. Esempi MRN-887654MRN-902101MRN-123456 | |||
| Importo pagato PaidAmount | L’importo totale ricevuto e registrato dai payer o dal paziente per la richiesta. | ||
| Descrizione Questo Attributo registra l’importo cumulativo effettivamente riscosso per un evento di fatturazione. Include i pagamenti dei payer assicurativi primari e secondari, nonché quelli del paziente. Paid Amount è una metrica chiave di risultato per il ciclo dei ricavi. Viene utilizzato per calcolare il rendimento finale degli addebiti fatturati e misurare l’efficacia dell’intero processo. Il confronto tra Billed Amount e Paid Amount evidenzia la performance finanziaria e mette in luce le aree di perdita di ricavi. È essenziale per le Dashboard relative all’efficacia della riscossione e alla salute finanziaria complessiva. Perché è importante Misura la liquidità effettivamente riscossa, una metrica di risultato primaria per valutare il successo complessivo del processo del ciclo dei ricavi. Dove reperirlo Derivato dalle transazioni di registrazione dei pagamenti collegate alla richiesta in Waystar. Potrebbe essere necessario sommare più record di pagamento. Esempi 120.00980.500.00 | |||
| Importo rettificato AdjustedAmount | L’importo finanziario totale rettificato o stornato per l’evento di fatturazione. | ||
| Descrizione Adjusted Amount rappresenta la somma di tutte le rettifiche finanziarie applicate al saldo di un evento di fatturazione. Include gli abbuoni contrattuali previsti dagli accordi con i payer, oltre ad altri stralci o correzioni. È una metrica chiave per la Dashboard «Account Adjustment Rate and Impact». Sommare questo importo per diversi codici motivazionali o payer evidenzia l’impatto finanziario delle perdite di ricavi. Aiuta a quantificare le perdite e fornisce una base economica per intervenire sulle cause principali delle rettifiche. Perché è importante Quantifica l’importo dei ricavi persi a causa di stralci e rettifiche, evidenziando l’impatto finanziario dei problemi di fatturazione e dei termini contrattuali. Dove reperirlo Proviene dalle transazioni di rettifica finanziaria in Waystar. Potrebbe essere necessario sommare più registrazioni di rettifica per un singolo evento di fatturazione. Esempi 250.2550.0015.80 | |||
| Pagamento al primo invio IsFirstPassPayment | Un indicatore che segnala se la richiesta è stata pagata correttamente al primo invio, senza dinieghi o rettifiche. | ||
| Descrizione Questo Attributo booleano calcolato indica se una richiesta è stata pagata senza eventi negativi intermedi, come un diniego, un rifiuto o una richiesta di ulteriori informazioni. Un valore «true» indica un processo regolare ed efficiente per quella richiesta. Questo Attributo supporta direttamente il KPI «First Pass Payment Rate», una misura fondamentale dell’efficienza complessiva del ciclo dei ricavi. Analizzare le caratteristiche delle richieste non pagate al primo invio, ad esempio per payer o tipo di servizio, aiuta a individuare i principali fattori che determinano la rielaborazione e i ritardi nei pagamenti. Migliorare questo tasso accelera il flusso di cassa e riduce i costi operativi. Perché è importante Misura direttamente la qualità della fatturazione e dell’elaborazione delle richieste. Un tasso elevato di pagamento al primo invio indica un processo efficiente, con una rielaborazione minima. Dove reperirlo Si tratta di un attributo derivato calcolato durante la trasformazione dei dati. La logica verifica se si verifica un evento 'Payment Posted' senza essere preceduto da eventi come 'Claim Denied' o 'Account Adjusted'. Esempi truefalse | |||
| Tempo da servizio a fatturazione ServiceToInvoiceCycleTime | Il tempo trascorso dal completamento di un servizio alla registrazione degli addebiti e alla creazione di una richiesta di rimborso. | ||
| Descrizione Questa metrica, nota anche come 'charge lag', misura l'efficienza del processo di fatturazione iniziale. Viene calcolata come differenza temporale tra l'evento 'Service Provided/Completed' e l'evento 'Charges Captured' o 'Claim Created'. Questo attributo supporta direttamente la Dashboard 'Service To Invoice Cycle Time'. I ritardi in questa fase del processo, noti come charge lag, posticipano direttamente l'inizio del ciclo di pagamento, rallentando il flusso di cassa. Il monitoraggio di questo indicatore aiuta a garantire che tutti i servizi vengano fatturati in modo tempestivo e accurato, evitando perdite di ricavi e accelerando l'intero ciclo dei ricavi. Perché è importante Misura l'efficienza della fatturazione iniziale. Ridurre questo 'charge lag' è fondamentale per accelerare l'intero ciclo dei ricavi ed evitare la perdita di addebiti. Dove reperirlo Calcolato durante la trasformazione dei dati sottraendo il timestamp dell'evento relativo al servizio dal timestamp dell'evento di registrazione dell'addebito o di creazione della richiesta di rimborso. Esempi 2 giorni 8 ore1 giorno 0 ore5 giorni 1 ora | |||
| Tipo di payer PayerType | La categoria del payer, ad esempio «Commercial», «Medicare» o «Self-Pay». | ||
| Descrizione Payer Type raggruppa i singoli payer in categorie più ampie in base alla loro natura. Fornisce una visione di livello superiore rispetto allo specifico Payer Name. Questo Attributo è utile per l’analisi strategica e il reporting. Consente al management di comprendere le tendenze delle performance tra le principali categorie di payer, ad esempio confrontando le performance complessive dei payer pubblici con quelle degli assicuratori commerciali. Può orientare le decisioni strategiche relative alla contrattualizzazione dei payer e all’allocazione delle risorse. Perché è importante Consente un’analisi di alto livello raggruppando i payer in categorie come Commercial o Government, che spesso presentano comportamenti e regole di pagamento distinti. Dove reperirlo In genere deriva dalla mappatura del Payer Name su un elenco predefinito di categorie. Questa logica può essere presente in Waystar oppure deve essere implementata durante la trasformazione dei dati. Esempi CommercialeMedicareMedicaidPagamento diretto | |||
| Utente responsabile ResponsibleUser | L’utente o l’operatore che ha eseguito l’attività, ad esempio un addetto alla fatturazione, un codificatore o uno specialista della riscossione. | ||
| Descrizione Questo Attributo identifica lo specifico dipendente o utente di sistema che ha eseguito una determinata attività nel processo. Ad esempio, può indicare quale addetto ha inviato una richiesta o quale operatore della riscossione ha avviato una telefonata di sollecito. Analizzare il processo per utente aiuta a comprendere la distribuzione del carico di lavoro, le performance individuali e le esigenze formative. Può evidenziare se determinati utenti presentano tassi di errore più elevati o sono più efficienti nella risoluzione dei dinieghi. È utile per la gestione del team e il controllo della qualità nel reparto del ciclo dei ricavi. Perché è importante Attribuisce la responsabilità dei passaggi del processo, consentendo di analizzare le performance a livello individuale o di team e di individuare opportunità formative. Dove reperirlo Si trova nella traccia di audit o nei log delle transazioni degli eventi in Waystar, spesso con nomi quali «UserID», «ProcessedBy» o simili. Esempi jsmithadavisbilling_bot_01 | |||
Attività di gestione del ciclo attivo
| Attività | Descrizione | ||
|---|---|---|---|
| Addebiti registrati | Indica l'inserimento dei servizi fatturabili nel sistema del ciclo dei ricavi. Questo evento viene generalmente registrato esplicitamente quando un utente finalizza l'inserimento di un addebito o quando i dati vengono ricevuti da un sistema clinico. | ||
| Perché è importante Questo è il punto di partenza del processo di fatturazione. Analizzare il tempo che intercorre tra il completamento del servizio e la registrazione dell'addebito è fondamentale per identificare perdite di ricavi e ritardi nelle fasi iniziali. Dove reperirlo Questo evento viene registrato in una tabella degli inserimenti degli addebiti o delle transazioni all'interno di Waystar e contiene generalmente un timestamp di creazione, corrispondente al momento in cui l'addebito viene salvato o finalizzato. Acquisizione Evento registrato al salvataggio o alla finalizzazione di un inserimento di addebito. Tipo di evento explicit | |||
| Conto chiuso | Il ciclo di vita dell’evento di fatturazione è completo e il saldo del conto è arrivato a zero tramite pagamenti e rettifiche. Questo indica la conclusione positiva del ciclo dei ricavi per il caso in questione. | ||
| Perché è importante Questo è il principale punto di chiusura del processo. Misurare il tempo necessario alla chiusura e la percentuale di conti chiusi con successo rappresenta un indicatore chiave della performance complessiva. Dove reperirlo Si tratta di un evento calcolato, generalmente inferito quando il campo del saldo residuo relativo all’evento di fatturazione diventa pari a zero nel sistema di contabilità dei pazienti. Acquisizione Calcolato quando la somma dei pagamenti e delle rettifiche è uguale all’importo totale addebitato. Tipo di evento calculated | |||
| Pagamento registrato | Un pagamento ricevuto viene applicato o riconciliato con lo specifico conto del paziente e con la relativa richiesta. Questa attività trasferisce il saldo dai crediti verso clienti alla liquidità. | ||
| Perché è importante Questo è un passaggio finale fondamentale del ciclo del payer. Supporta i KPI relativi al volume dei pagamenti registrati e ai tempi di attesa, assicurando che i conti vengano aggiornati correttamente e tempestivamente. Dove reperirlo Questa è un’azione esplicita registrata in Waystar quando un utente registra il pagamento proveniente dall’ERA. Molti sistemi dispongono anche di funzionalità di registrazione automatica che acquisiscono lo stesso evento. Acquisizione Evento registrato quando il pagamento proveniente da un’ERA viene applicato a una richiesta, manualmente o tramite registrazione automatica. Tipo di evento explicit | |||
| Richiesta di rimborso respinta | Il payer ha respinto la richiesta di rimborso e non effettuerà il pagamento, come indicato nell’Electronic Remittance Advice (ERA). Questo evento attiva il Workflow di gestione dei dinieghi o il ciclo di rielaborazione. | ||
| Perché è importante Supporta direttamente il KPI «Claim Denial Rate». Identificare la frequenza e le cause dei dinieghi è fondamentale per migliorare il processo e recuperare i ricavi. Dove reperirlo Viene inferito da specifici codici di diniego, denominati Claim Adjustment Reason Codes (CARC), presenti nell’ERA ricevuto (file 835). Acquisizione Derivato dai codici di motivazione dell’aggiustamento della richiesta (CARC) presenti nel file ERA, che indicano un diniego. Tipo di evento inferred | |||
| Richiesta inviata al payer | L'invio elettronico della richiesta di fatturazione al payer assicurativo per la valutazione. Si tratta di un passaggio di consegne critico dal sistema del fornitore a quello del payer tramite il clearinghouse. | ||
| Perché è importante Una tappa fondamentale che avvia il conteggio dei tempi di risposta del payer. È essenziale per misurare i KPI del ciclo dei pagamenti e identificare gli arretrati negli invii. Dove reperirlo La funzionalità clearinghouse di Waystar registra esplicitamente la data e l'ora di trasmissione del file della richiesta. Cerchi i log di invio o lo storico dello stato della richiesta. Acquisizione Registrato nello storico degli invii delle richieste o nel log delle transazioni al completamento della trasmissione. Tipo di evento explicit | |||
| Richiesta valutata | Il payer ha elaborato la richiesta di rimborso e ha preso una decisione sul pagamento. Questo evento viene acquisito quando dal payer si riceve un Electronic Remittance Advice (ERA), ovvero un file 835. | ||
| Perché è importante Questo è il principale punto decisionale del processo. Determina se la richiesta di rimborso verrà pagata o respinta, incidendo direttamente sul flusso dei ricavi e sui Workflow di gestione dei dinieghi. Dove reperirlo Inferito dalla data di ricezione dell’ERA (file 835) associato alla richiesta di rimborso in Waystar. Il file ERA contiene la decisione dettagliata del payer. Acquisizione Inferito dalla data di elaborazione del file ERA/835 ricevuto dal payer. Tipo di evento inferred | |||
| Attività di riscossione avviata | Il conto del paziente è diventato insoluto e sono iniziate le attività di riscossione. Queste possono includere promemoria automatici o il trasferimento a un’agenzia di recupero crediti esterna. | ||
| Perché è importante Supporta la Dashboard «Collection Activity Effectiveness». Aiuta ad analizzare il costo e il tasso di successo delle attività di riscossione sui crediti scaduti. Dove reperirlo In genere viene inferito da una modifica dello stato del conto in Waystar a «Collections» o «Bad Debt», che attiva un Workflow diverso. Acquisizione Inferito dalla modifica dello stato del conto a «Collections» o «Bad Debt». Tipo di evento inferred | |||
| Conferma di ricezione del payer ricevuta | Il sistema del payer conferma la ricezione del file della richiesta inviato. Di norma si tratta di una risposta automatica, come un report 277CA o 999, che indica che la richiesta è stata accettata per l'elaborazione. | ||
| Perché è importante Conferma l'avvenuta trasmissione e aiuta a isolare i rifiuti nelle fasi iniziali dovuti a errori di formattazione o dei dati prima dell'avvio della valutazione, consentendo correzioni più rapide. Dove reperirlo Registrato nelle tabelle dello stato della richiesta o dei file di risposta all'interno del modulo clearinghouse di Waystar, dopo l'elaborazione di un file di conferma di ricezione del payer. Acquisizione Evento registrato dopo l'elaborazione di un file elettronico di conferma di ricezione proveniente dal payer. Tipo di evento explicit | |||
| Conto rettificato | Al saldo del conto viene applicata una rettifica manuale o contrattuale. Questa può includere stralci, abbuoni contrattuali, sconti al paziente o altre correzioni. | ||
| Perché è importante È essenziale per comprendere le perdite di ricavi. Analizzare le rettifiche aiuta a individuare problemi relativi ai tariffari, alla gestione dei contratti o ai crediti inesigibili. Dove reperirlo Ogni rettifica finanziaria deve essere registrata come transazione a fini di audit. Si tratterà di un evento esplicito nella tabella delle transazioni del conto. Acquisizione Registrato come specifico tipo di transazione nel libro mastro del conto. Tipo di evento explicit | |||
| Diniego contestato | Un utente ha intrapreso un’azione per contestare il diniego di una richiesta, spesso inviandola nuovamente dopo aver apportato correzioni oppure presentando un ricorso formale. Questa attività rappresenta un passaggio fondamentale del processo di rielaborazione. | ||
| Perché è importante Misura l’efficienza del team di gestione dei dinieghi. Monitorare il tempo che intercorre tra il diniego e il ricorso, nonché il tasso di successo dei ricorsi, è importante per ottimizzare le attività di recupero. Dove reperirlo Può essere registrato come azione esplicita dell’utente o come nota nel modulo di gestione dei dinieghi. In alternativa, può essere inferito da una modifica dello stato della richiesta respinta. Acquisizione Evento registrato quando un utente documenta un’azione di ricorso o aggiorna lo stato della richiesta a «Appealed». Tipo di evento explicit | |||
| Estratto conto del paziente inviato | Dopo la valutazione da parte dell’assicurazione, viene generato e inviato al paziente un estratto conto relativo all’eventuale saldo residuo. L’attenzione della riscossione si sposta così dal payer al paziente. | ||
| Perché è importante Questo evento avvia il ciclo di pagamento del paziente. Analizzare l’efficacia e la tempistica degli estratti conto è fondamentale per gestire i crediti verso i pazienti e migliorare la loro esperienza. Dove reperirlo Si tratta di un evento esplicito registrato dal modulo di fatturazione dei pazienti quando un lotto di estratti conto viene generato o inviato elettronicamente oppure a un fornitore di servizi di stampa. Acquisizione Evento registrato nella cronologia delle comunicazioni con il paziente quando viene generato un estratto conto. Tipo di evento explicit | |||
| Richiesta corretta e inviata nuovamente | Dopo un diniego o un rifiuto, la richiesta è stata corretta e inviata nuovamente al payer. Questo indica il riavvio del ciclo di valutazione per una specifica richiesta. | ||
| Perché è importante Questo è un ciclo di rielaborazione critico. Analizzare la frequenza e le cause dei nuovi invii aiuta a individuare le cause principali degli errori iniziali, come errori di codifica o anagrafici. Dove reperirlo Inferito dall’identificazione di un nuovo evento «Claim Submitted To Payer» per una richiesta precedentemente respinta. Il sistema potrebbe inoltre disporre di uno stato specifico per le richieste inviate nuovamente. Acquisizione Inferito da un nuovo evento di invio collegato a un identificativo di richiesta precedentemente respinta. Tipo di evento inferred | |||
| Richiesta creata | Rappresenta la generazione di una richiesta formale di fatturazione a partire dagli addebiti registrati. Si tratta di una fase interna in cui il sistema raccoglie le informazioni prima dell'invio al payer. | ||
| Perché è importante Monitora l'efficienza interna della generazione delle richieste. I ritardi in questa fase possono posticipare l'intero ciclo dei pagamenti, ancora prima che la richiesta lasci il sistema del fornitore. Dove reperirlo Può trattarsi di un evento esplicito, ma spesso viene dedotto dal primo timestamp associato a un record della richiesta nel modulo di gestione delle richieste di Waystar. Acquisizione Deducibile dalla data di creazione del record della richiesta nella tabella principale delle richieste. Tipo di evento inferred | |||
Guide all'estrazione
I metodi di estrazione per questo processo sono attualmente in fase di convalida. Torni a consultare la pagina più avanti oppure ci contatti per ricevere assistenza.
Pronto a iniziare?
Faccia il prossimo passo verso l'ottimizzazione della gestione del ciclo dei ricavi. Inizi oggi stesso a sfruttare questi insight sui dati per aumentare l'efficienza e migliorare il flusso di cassa.
Ottimizzi la gestione del ciclo dei ricavi e aumenti subito il flusso di cassa
Individui con precisione le inefficienze, riduca del 30% i tempi di ciclo e aumenti il flusso di cassa.
Non è richiesta alcuna carta di credito: inizi oggi stesso a ottimizzare i Suoi processi.