Il Suo template dei dati per la gestione del ciclo dei ricavi
Il Suo template dei dati per la gestione del ciclo dei ricavi
- Attributi consigliati da raccogliere
- Attività principali da monitorare
- Indicazioni per l’estrazione
Attributi per la gestione del ciclo dei ricavi
| Nome | Descrizione | ||
|---|---|---|---|
| Evento di fatturazione BillingEvent | Identificativo univoco di una singola prestazione o fornitura di un prodotto che genera un addebito e funge da ID principale del caso. | ||
| Descrizione L’evento di fatturazione funge da identificativo principale del caso e collega tutte le attività relative a una singola prestazione o fornitura di un prodotto che genera un addebito. Consente di monitorare in modo completo l’intero ciclo di generazione e riscossione dei ricavi per ogni singola prestazione o voce fatturabile. Nel Process Mining, analizzare il processo per evento di fatturazione consente alle organizzazioni di osservare l’intero percorso, dall’erogazione del servizio al pagamento finale o alla chiusura del conto. Questa prospettiva è fondamentale per individuare i colli di bottiglia, misurare i tempi di ciclo e comprendere le differenze nella gestione delle varie richieste di rimborso o fatture. Perché è importante È l’ID del caso essenziale che collega tutte le attività correlate del ciclo dei ricavi e consente di analizzare il processo nel suo complesso, dall’inizio alla fine. Dove reperirli È la chiave primaria che collega i record nelle tabelle principali di fatturazione e delle richieste di rimborso di Optum360. Per conoscere i nomi specifici di tabelle e campi, consulti la documentazione di Optum360. Esempi BE-2023-0012345BE-2023-0012346BE-2023-0012347 | |||
| Nome dell’attività ActivityName | Nome di uno specifico evento o attività che si è verificato nel processo di gestione del ciclo dei ricavi. | ||
| Descrizione Il nome dell’attività descrive un passaggio del processo del ciclo dei ricavi, ad esempio 'Richiesta di rimborso inviata al pagatore' o 'Pagamento ricevuto'. Questo attributo è fondamentale per il Process Mining, perché definisce i nodi della mappa del processo. Analizzando la sequenza e la frequenza delle attività, le organizzazioni possono visualizzare il flusso effettivo del processo, individuare le deviazioni dalla procedura standard e identificare i cicli di rilavorazione più frequenti. Questa analisi è essenziale per comprendere le inefficienze del processo e i problemi di conformità. Perché è importante Questo attributo definisce i singoli passaggi del processo, costituisce la base della mappa del processo e consente tutte le analisi basate sui flussi. Dove reperirli In genere, si ricava dagli Event Log, dai record delle modifiche di stato o da specifici codici di transazione nelle tabelle operative di Optum360. Esempi Richiesta di rimborso creataRichiesta di rimborso inviata al pagatorePagamento ricevutoRifiuto ricevutoConto chiuso | |||
| Ora dell’evento EventTime | Data e ora che indicano quando si è verificata una specifica attività o un evento. | ||
| Descrizione L’ora dell’evento è la data e ora associata a ciascuna attività e ne indica il momento esatto. Questi dati temporali sono essenziali per ricostruire la sequenza cronologica degli eventi di ogni caso. Nell’analisi, l’ora dell’evento viene utilizzata per calcolare i tempi di ciclo tra le attività, misurare la durata dei casi e individuare i colli di bottiglia in cui si accumulano attese significative. È alla base di qualsiasi analisi dei processi basata sul tempo e della misurazione dei risultati. Perché è importante Questa data e ora è fondamentale per ordinare correttamente gli eventi e calcolare tutte le metriche basate sulla durata, come i tempi di ciclo e i colli di bottiglia. Dove reperirli Queste informazioni sono in genere memorizzate insieme a ciascun record di transazione o di modifica dello stato nelle tabelle del database di Optum360. Esempi 2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:22:00Z | |||
| Codice del motivo del rifiuto DenialReasonCode | Codice standard fornito dal pagatore per spiegare il motivo del rifiuto di una richiesta di rimborso. | ||
| Descrizione Quando un pagatore rifiuta una richiesta di rimborso, fornisce un codice del motivo del rifiuto che spiega il problema, ad esempio «Servizio non coperto» o «Richiesta duplicata». Questi codici sono essenziali per comprendere le cause profonde dei ritardi nei ricavi e delle rilavorazioni. Analizzarli consente al team che gestisce i rifiuti di stabilire le priorità, individuare tendenze e adottare misure correttive. Per esempio, una frequenza elevata di rifiuti per «Informazioni mancanti» può indicare un problema nella creazione delle richieste. Questa analisi è fondamentale per ridurre il tasso di rifiuto e accelerare il flusso di cassa. Perché è importante Indica la causa profonda del rifiuto delle richieste e consente interventi mirati per prevenirne di futuri e ridurre le costose rilavorazioni. Dove reperirli Il codice è incluso nei file Electronic Remittance Advice (ERA) ricevuti dai pagatori e viene registrato nel modulo di gestione delle richieste di Optum360. Esempi CO-16: alla richiesta o al servizio mancano informazioniPR-97: la prestazione per questo servizio è inclusa nel pagamento o nell’indennità di un altro servizio o interventoOA-18: richiesta o servizio duplicato | |||
| ID del pagatore PayerId | Identificativo univoco della compagnia assicurativa o del pagatore responsabile della richiesta di rimborso. | ||
| Descrizione L’ID del pagatore identifica la specifica compagnia assicurativa, un programma governativo come Medicare o Medicaid oppure un altro ente responsabile del pagamento della richiesta. Spesso ogni pagatore applica regole proprie, requisiti specifici per l’invio delle richieste e modalità di pagamento diverse. In RCM, analizzare il processo in base all’ID del pagatore è fondamentale. Consente di individuare i pagatori con i tempi di pagamento più lunghi, i tassi di rifiuto più elevati o le procedure di ricorso più complesse. Queste informazioni aiutano gli uffici amministrativi a definire strategie mirate per ciascun pagatore, accelerando gli incassi e riducendo il carico amministrativo. Perché è importante Segmentare il processo per pagatore è essenziale per individuare quelli che causano ritardi o rifiuti e intervenire in modo mirato sulla loro gestione. Dove reperirli Queste informazioni sono registrate in ogni richiesta di rimborso in Optum360. Per conoscere i nomi delle tabelle e dei campi relativi ai pagatori, consulti la documentazione di Optum360. Esempi PAYER-AETNAPAYER-BCBS-MAPAYER-MEDICAREPAYER-UHC | |||
| ID paziente PatientId | Identificativo univoco del paziente che ha ricevuto i servizi. | ||
| Descrizione L’ID paziente è un identificativo univoco assegnato a ogni paziente all’interno del sistema sanitario. Collega più eventi di fatturazione allo stesso paziente e consente di svolgere analisi incentrate sulla persona. Utilizzando l’ID paziente, gli analisti possono individuare schemi relativi a pazienti specifici, come frequenti nuovi ricoveri o una storia di richieste di rimborso rifiutate. Consente inoltre di segmentare il processo in base alle caratteristiche demografiche o alla storia del paziente, facendo emergere informazioni utili per migliorare la sua esperienza finanziaria. Perché è importante Consente di svolgere analisi incentrate sul paziente, comprendere l’intero percorso finanziario e individuare schemi relativi a specifici gruppi di pazienti. Dove reperirli Questo identificativo è un campo fondamentale nei dati anagrafici principali dei pazienti e nelle tabelle delle transazioni di Optum360. Per maggiori dettagli, consulti la documentazione di Optum360. Esempi PAT-98765PAT-98766PAT-98767 | |||
| Importo fatturato BilledAmount | Valore monetario complessivo degli addebiti inviati con la richiesta di rimborso o la fattura. | ||
| Descrizione L’importo fatturato rappresenta l’addebito lordo per i servizi erogati, prima di pagamenti, rettifiche o stralci. È il valore iniziale del credito registrato per l’evento di fatturazione. Questo attributo è fondamentale per l’analisi finanziaria nell’ambito del Process Mining. Serve a calcolare KPI importanti, come il tasso di rettifica dei ricavi, e a segmentare i casi per valore, per verificare se le richieste di importo elevato seguono iter diversi o subiscono più ritardi rispetto a quelle di importo inferiore. Perché è importante Fornisce il contesto finanziario di ogni caso e consente analisi basate sul valore e il calcolo di KPI finanziari fondamentali. Dove reperirli È un campo standard in ogni richiesta di rimborso o account paziente nelle tabelle finanziarie di Optum360. Esempi 150.001250.7585.50 | |||
| Importo rettificato AdjustedAmount | Valore monetario degli stralci, delle rettifiche contrattuali o delle correzioni apportate all’importo fatturato. | ||
| Descrizione L’importo rettificato rappresenta la quota dell’importo fatturato che non si prevede di incassare a causa di accordi contrattuali con i pagatori, correzioni di fatturazione o altri stralci. Riduce direttamente i ricavi. Questo attributo è fondamentale per la Dashboard «Impatto delle rettifiche sui ricavi» e per il KPI «Tasso di rettifica dei ricavi». Analizzare le rettifiche aiuta a misurare l’impatto finanziario dei contratti con i pagatori e a individuare opportunità per limitare le perdite di ricavi, migliorando la precisione della fatturazione o rinegoziando i contratti. Perché è importante Misura direttamente le perdite di ricavi ed è fondamentale per calcolare i KPI finanziari e comprendere la redditività. Dove reperirli Queste informazioni sono disponibili nelle registrazioni delle transazioni di rettifica del sistema finanziario di Optum360. Esempi 30.00250.2510.00 | |||
| Ufficio fatturazione BillingDepartment | Il reparto o il team interno che ha gestito o svolto l’attività di fatturazione. | ||
| Descrizione L’attributo Ufficio fatturazione identifica il team o l’area funzionale specifica, all’interno delle attività del ciclo dei ricavi, responsabile di un’attività. Per esempio, team diversi possono occuparsi della codifica, dell’invio delle richieste di rimborso e della gestione dei rifiuti. Questo attributo è essenziale per confrontare le prestazioni dei team, come richiesto dalla Dashboard «Parametri di riferimento delle prestazioni dell’ufficio fatturazione». Consente alla dirigenza di confrontarne efficienza, rapidità e precisione, individuare le pratiche più efficaci e assegnare le risorse in modo mirato per colmare le lacune. Perché è importante Consente di confrontare le prestazioni dei diversi team di fatturazione, individuando quelli più efficaci e le aree che richiedono miglioramenti. Dove reperirli Il dato può essere ricavato dall’utente che ha svolto l’attività o da un campo dell’account che ne indica il responsabile. Consulti la documentazione di Optum360. Esempi Ufficio centrale di fatturazioneTeam di gestione dei rifiutiReparto di codificaServizi finanziari per i pazienti | |||
| Codice del servizio ServiceCode | Codice della procedura, ad esempio CPT o HCPCS, che identifica lo specifico servizio erogato. | ||
| Descrizione Il codice del servizio è un codice medico standardizzato che identifica con precisione la procedura o il servizio fornito al paziente. È necessario per la fatturazione e determina in larga misura il rimborso. Analizzare il processo per codice del servizio può rivelare che alcune procedure sono più soggette a rifiuti, richiedono più documentazione o comportano tempi di pagamento più lunghi. In questo modo è possibile comprendere meglio le criticità del processo e definire le politiche di codifica e fatturazione per specifiche tipologie di servizio. Perché è importante Consente di analizzare i dati in base alla tipologia di servizio medico e di individuare schemi ricorrenti di rifiuti o ritardi nei pagamenti per determinate procedure. Dove reperirli Questo codice è un elemento fondamentale delle registrazioni degli addebiti e dei dettagli delle richieste di rimborso in Optum360. Esempi 992137104527447 | |||
| Durata del caso CaseDuration | Tempo di ciclo complessivo di un evento di fatturazione, dalla prima all’ultima attività. | ||
| Descrizione La durata del caso misura il tempo totale trascorso tra il primo e l’ultimo evento di un singolo evento di fatturazione. È un KPI di alto livello per valutare l’efficienza complessiva del processo. Questa metrica alimenta direttamente la Dashboard «Panoramica dei tempi di ciclo RCM dall’inizio alla fine» e il KPI «Tempo medio di ciclo RCM». Monitorarla nel tempo consente alla dirigenza di valutare l’impatto delle iniziative di miglioramento sull’intero ciclo dei ricavi. Perché è importante Rappresenta il tempo di ciclo complessivo del processo ed è un KPI fondamentale per misurarne la velocità e l’efficienza generali. Dove reperirli Si calcola sottraendo l’indicazione temporale del primo evento da quella dell’ultimo per ogni ID caso univoco «BillingEvent». Esempi 30 giorni95 giorni45 giorni | |||
| È una rilavorazione IsRework | Indicatore che segnala se un’attività fa parte di un ciclo di rilavorazione, per esempio la gestione dei rifiuti o dei ricorsi. | ||
| Descrizione È una rilavorazione è un indicatore booleano che identifica le attività considerate rilavorazioni senza valore aggiunto, come «Rilavorazione per rifiuto avviata» o «Ricorso inviato». Queste attività si verificano in genere quando il processo si discosta dal suo «percorso ottimale». Questo attributo aiuta a quantificare le rilavorazioni nel processo, un indicatore diretto di inefficienza e costi. Serve a calcolare il KPI «Tasso di rilavorazione per errori di fatturazione» e supporta la Dashboard «Individuazione dei colli di bottiglia e dei cicli di rilavorazione», consentendo di filtrare e visualizzare facilmente questi percorsi inefficienti. Perché è importante Aiuta a quantificare le inefficienze del processo segnalando le attività che comportano rilavorazioni, così da misurare e ridurre più facilmente gli sprechi. Dove reperirli In genere, il dato viene ricavato applicando la logica aziendale nello strumento di Process Mining. Per esempio, tutte le attività successive all’evento «Rifiuto ricevuto» possono essere contrassegnate come rilavorazioni. Esempi truefalse | |||
| Erogatore del servizio ServiceProvider | Il professionista sanitario, il reparto o la struttura che ha erogato il servizio fatturabile. | ||
| Descrizione Questo attributo identifica il professionista o la struttura che ha erogato il servizio, ad esempio un medico, un terapista o un reparto ospedaliero. Le modalità di fatturazione e le abitudini di documentazione possono variare da un erogatore all’altro e incidere sul ciclo dei ricavi. L’analisi per erogatore del servizio aiuta a individuare problemi nella registrazione degli addebiti, nella precisione della codifica o nella qualità della documentazione, riconducibili al momento dell’assistenza. Può inoltre mettere in luce opportunità di formazione per gli erogatori o di miglioramento dei processi, affinché le richieste di rimborso siano corrette fin dall’inizio. Perché è importante Aiuta a ricondurre i problemi di fatturazione alla loro origine e a fornire riscontri e formazione mirati al personale clinico, migliorando la registrazione degli addebiti e la documentazione. Dove reperirli Queste informazioni sono una componente essenziale della registrazione dell’addebito o della richiesta di rimborso in Optum360 e sono spesso collegate ai dati anagrafici degli erogatori. Esempi Dott.ssa Emily CarterReparto di radiologiaChirurgia generaleFisioterapia | |||
| Importo pagato PaidAmount | Valore monetario complessivo ricevuto dal pagatore e dal paziente per i servizi fatturati. | ||
| Descrizione L’importo pagato è la somma cumulativa di tutti i pagamenti registrati sull’account per uno specifico evento di fatturazione. Rappresenta gli incassi effettivi ed è una misura primaria dei risultati del ciclo dei ricavi. Nell’analisi dei processi, monitorare l’importo pagato è essenziale per comprendere il flusso di cassa e i risultati finanziari complessivi. Il dato permette di analizzare la velocità dei pagamenti e confrontare gli importi fatturati con quelli incassati, mettendo in evidenza pagamenti insufficienti o crediti inesigibili. Perché è importante Rappresenta gli incassi effettivi: un indicatore chiave dei risultati del processo RCM e un dato essenziale per analizzare il flusso di cassa. Dove reperirli In genere, questo valore è registrato nelle tabelle delle transazioni di pagamento oppure riepilogato a livello di account in Optum360. Esempi 120.001000.500.00 | |||
| Ora di fine EndTime | Data e ora che indicano quando è stata completata un’attività. | ||
| Descrizione L’ora di fine indica il completamento di un’attività. Mentre l’ora di inizio indica quando si è verificato un evento, l’ora di fine è necessaria per calcolare la durata delle attività con un tempo di elaborazione definito, come 'Rilavorazione del rifiuto avviata' e il relativo completamento. Nell’analisi dei processi, confrontare l’ora di inizio e l’ora di fine delle attività consente di calcolare il tempo di elaborazione. In questo modo è possibile distinguere il tempo di lavoro effettivo dal tempo di inattività, ovvero l’attesa tra un’attività e l’altra, e ottenere una visione più dettagliata dell’efficienza del processo. Perché è importante Consente di calcolare con precisione i tempi di elaborazione delle attività e di distinguere il tempo di lavoro effettivo dalle attese nel processo. Dove reperirli Per alcune attività, può essere disponibile un campo separato con la data e ora nel sistema di origine. Per altre, potrebbe essere necessario dedurla dall’ora di inizio dell’attività successiva. Esempi 2023-10-26T10:15:00Z2023-10-26T11:45:00Z2023-10-27T15:00:00Z | |||
| Sistema di origine SourceSystem | Sistema o applicazione di origine in cui sono stati registrati i dati dell’evento. | ||
| Descrizione Questo attributo identifica il sistema di origine da cui sono stati estratti i dati di un determinato evento. In un ambiente IT complesso, i dati RCM possono provenire dalla piattaforma Optum360 principale, da una cartella clinica elettronica (EHR) collegata, da una clearinghouse o da un portale per i pazienti. Conoscere il sistema di origine è utile per convalidare i dati, risolvere i problemi di integrazione e analizzare le differenze nei processi che possono dipendere dal comportamento dei diversi sistemi o dalle modalità di inserimento dei dati. Perché è importante Identifica l’origine dei dati, un’informazione fondamentale per la governance dei dati, la valutazione della qualità e la comprensione delle differenze tra i processi nei diversi sistemi. Dove reperirli Può essere un valore statico impostato durante l’estrazione dei dati oppure un campo nelle tabelle di origine che ne indica la provenienza. Esempi Optum360Interfaccia EHRAPI della clearinghousePortale per i pazienti | |||
| Stato dell’account AccountStatus | Stato corrente dell’account di fatturazione nel ciclo dei ricavi. | ||
| Descrizione Lo stato dell’account indica a che punto si trova un evento di fatturazione nel processo complessivo, per esempio «In attesa del pagatore», «Interamente pagato» o «In recupero crediti». Questo attributo fornisce il contesto delle attività svolte. È utile per filtrare e segmentare i casi, concentrandosi su fasi specifiche del processo. Per esempio, analizzare tutti gli account attualmente «In recupero crediti» aiuta a comprendere i fattori che incidono su questa fase, particolarmente onerosa, e il volume di attività associato, fornendo dati utili alla Dashboard «Volume e fattori delle attività di recupero crediti». Perché è importante Fornisce una visione d’insieme dello stato corrente del caso e consente di filtrare e analizzare gruppi specifici, come gli account in recupero crediti. Dove reperirli In genere, è un campo riepilogativo nella registrazione principale dell’account paziente o della richiesta di rimborso in Optum360. Esempi ApertoIn attesa del pagatoreInteramente pagatoIn recupero creditiChiuso | |||
| Ultimo aggiornamento dei dati LastDataUpdate | Data e ora dell’ultimo aggiornamento o dell’ultima estrazione dei dati dal sistema di origine. | ||
| Descrizione Questo attributo registra la data e l’ora dell’ultima estrazione dei dati dal sistema di origine e del loro caricamento nello strumento di Process Mining. Fornisce informazioni sull’aggiornamento dei dati analizzati. È importante che analisti e utenti aziendali sappiano se stanno consultando le informazioni più recenti. Aiuta a gestire le aspettative sui ritardi nell’aggiornamento dei dati ed è un metadato essenziale per qualsiasi progetto di analisi. Perché è importante Fornisce informazioni essenziali sull’aggiornamento dei dati, aiutando gli utenti a capire quanto sia recente l’analisi. Dove reperirli Questa data e ora viene in genere generata e memorizzata dal processo di estrazione, trasformazione e caricamento dei dati (ETL). Esempi 2023-11-01T02:00:00Z2023-11-02T02:00:00Z | |||
| Utente User | Identificativo dell’utente o dell’agente di sistema che ha svolto l’attività. | ||
| Descrizione L’attributo Utente identifica la persona, il team o il bot automatizzato responsabile dell’esecuzione di una determinata attività. Consente di analizzare i risultati a livello individuale o di gruppo. Sapere quale utente o team ha svolto un’azione è utile per valutare produttività, qualità e rispetto delle procedure standard. Può aiutare a individuare esigenze di formazione o a riconoscere le persone e i team con i risultati migliori. Permette inoltre di distinguere le attività svolte manualmente da quelle gestite tramite automazione. Perché è importante Attribuisce la responsabilità delle fasi del processo e consente di analizzare i risultati per persona o team, un aspetto fondamentale per la gestione delle risorse e la formazione. Dove reperirli Gli ID utente sono in genere registrati nei log di audit o nella cronologia delle transazioni di Optum360. Esempi j.doem.smithAutoBillerBots.jones | |||
Attività di gestione del ciclo dei ricavi
| Attività | Descrizione | ||
|---|---|---|---|
| Avviso di pagamento ricevuto | Il sistema ha ricevuto dal pagatore un file elettronico di avviso di pagamento (ERA), con i dettagli di pagamenti, rettifiche e rifiuti. L’evento viene registrato esplicitamente quando il sistema acquisisce un file EDI 835. | ||
| Perché è importante Questa attività è una tappa fondamentale che indica che il pagatore ha elaborato la richiesta. Il contenuto del file determina tutte le azioni successive, come la registrazione del pagamento o la gestione del rifiuto. Dove reperirli Registrato nei log delle transazioni EDI per i file ANSI 835 in ingresso. La data e ora indicano quando il file è stato ricevuto ed elaborato dal sistema. Acquisizione Data e ora associate all’acquisizione del file EDI 835 (Electronic Remittance Advice). Tipo di evento explicit | |||
| Conto chiuso | L’evento di fatturazione è considerato concluso: il saldo è pari a zero e non sono previste ulteriori attività. L’evento viene dedotto quando il saldo del conto raggiunge lo zero e lo stato viene aggiornato a 'Chiuso' o a un altro stato finale equivalente. | ||
| Perché è importante Questo è l’evento finale principale del processo. Misurare il tempo di ciclo totale fino a questo momento offre una visione completa dell’efficienza complessiva dell’RCM. Dove reperirli Dedotto dalla combinazione di un saldo del conto pari a zero e del campo dello stato del conto impostato su 'Chiuso', 'Interamente pagato' o uno stato finale equivalente. Acquisizione La data e ora più recente tra quella dell’ultimo pagamento registrato che porta il saldo a zero e quella della modifica dello stato a 'Chiuso'. Tipo di evento inferred | |||
| Dati del servizio ricevuti | Segna l’avvio dell’evento di fatturazione, quando vengono ricevute le informazioni sul servizio clinico dalla cartella clinica elettronica (EHR) o da un altro sistema di origine. In genere, l’evento viene registrato tramite una voce esplicita nel registro o un record di transazione creato da un’interfaccia di integrazione dopo l’acquisizione dei dati. | ||
| Perché è importante Questo è l’evento di inizio principale del ciclo dei ricavi. Analizzare il tempo che intercorre tra questa attività e la registrazione degli addebiti è fondamentale per individuare i ritardi iniziali nei dati che incidono sull’intero processo. Dove reperirli Registrato nei log delle interfacce o nelle tabelle delle transazioni che gestiscono i dati in ingresso sui servizi ai pazienti provenienti da sistemi esterni, come una EHR. Cerchi le date e ore dei messaggi HL7 o i log delle chiamate API. Acquisizione Acquisito dai log di integrazione o dalle tabelle delle transazioni, con data e ora registrate al momento della ricezione dei dati. Tipo di evento explicit | |||
| Pagamento registrato | Un pagamento ricevuto è stato correttamente attribuito al conto specifico del paziente e alle relative righe di servizio. Si tratta di un’azione esplicita, eseguita da un utente o automaticamente, che riconcilia il pagamento con gli addebiti ancora da saldare. | ||
| Perché è importante Questa attività è fondamentale per misurare l’efficienza del processo di registrazione dei pagamenti in back office. I ritardi nella registrazione possono falsare i dati dei crediti verso clienti e posticipare la chiusura del conto. Dove reperirli Si trova nelle tabelle delle transazioni di pagamento. La data e ora della transazione di registrazione corrisponde all’ora dell’evento. Acquisizione La data e ora di creazione del record della transazione di pagamento attribuita a uno specifico addebito. Tipo di evento explicit | |||
| Richiesta di rimborso inviata al pagatore | La richiesta di rimborso generata è stata inviata elettronicamente al pagatore assicurativo per la valutazione. L’evento viene registrato esplicitamente dal modulo di invio delle richieste o dall’interfaccia della clearinghouse al momento della trasmissione riuscita. | ||
| Perché è importante È una tappa fondamentale, perché da questo momento inizia il conteggio dei tempi di risposta del pagatore. Aiuta a misurare l’efficienza del processo di invio delle richieste e a individuare eventuali ritardi. Dove reperirli Si trova nei log delle transazioni delle richieste di rimborso o nelle tabelle delle transazioni EDI (Electronic Data Interchange), che registrano in particolare l’invio dei file 837. Cerchi un campo come 'data e ora di invio' o 'data di trasmissione'. Acquisizione Data e ora del log della transazione EDI 837 che indicano l’avvenuto invio. Tipo di evento explicit | |||
| Rifiuto ricevuto | Il pagatore ha rifiutato una richiesta di rimborso, come indicato nell’avviso di pagamento ricevuto. L’evento viene dedotto analizzando i dati dell’avviso per individuare i codici specifici del motivo del rifiuto associati alle singole righe della richiesta. | ||
| Perché è importante Monitorare i rifiuti è fondamentale per individuare le cause profonde delle perdite di ricavi e delle inefficienze del processo. Questa attività segna l’inizio di tutti i cicli di gestione dei rifiuti e delle relative rilavorazioni per i ricorsi. Dove reperirli Dedotto dai dati dell’avviso elettronico di pagamento (EDI 835). Il sistema individua i codici CARC (Claim Adjustment Reason Codes) che indicano un rifiuto. Acquisizione Dedotto individuando specifici codici di rifiuto (CARC/RARC) nei dati analizzati dell’avviso EDI 835. Tipo di evento inferred | |||
| Addebiti registrati | Indica il momento in cui i servizi e i materiali fatturabili vengono inseriti formalmente nel sistema di fatturazione. Si tratta di un’azione esplicita dell’utente o del sistema che crea i record delle transazioni di addebito. | ||
| Perché è importante Questa attività è essenziale per misurare il ritardo nella registrazione degli addebiti, ovvero il tempo che intercorre tra l’erogazione del servizio e l’avvio della fatturazione. Ridurre questo ritardo accelera direttamente il ciclo dei ricavi. Dove reperirli Si trova nelle tabelle delle transazioni di addebito, spesso denominate tabelle di inserimento degli addebiti o delle righe di servizio. La data e ora di creazione del record dell’addebito corrisponde all’ora dell’evento. Acquisizione L’evento corrisponde alla data e ora di creazione di un record nella tabella principale degli addebiti o in quella delle transazioni di addebito. Tipo di evento explicit | |||
| Attività di riscossione avviata | A causa del mancato pagamento, il conto del paziente è stato inserito in un processo attivo di riscossione. In genere, l’evento viene dedotto da una modifica della classe finanziaria o dello stato del conto. | ||
| Perché è importante Individua i conti che richiedono un’attività di sollecito più intensa. Analizzare la frequenza e i fattori che determinano questa attività aiuta a migliorare le strategie di riscossione iniziali. Dove reperirli Dedotto da una modifica dello stato del conto a 'Riscossione', 'Credito inesigibile' o 'Inviato a un’agenzia'. La data della modifica di stato corrisponde alla data e ora dell’evento. Acquisizione Data e ora della modifica del campo relativo allo stato del conto a un valore associato alla riscossione. Tipo di evento inferred | |||
| Codifica completata | Indica che i codificatori medici hanno esaminato la documentazione clinica e assegnato i codici CPT, HCPCS e ICD appropriati. In genere, l’evento è registrato esplicitamente quando un utente o un motore di codifica automatizzato completa l’attività di codifica. | ||
| Perché è importante La codifica è spesso un collo di bottiglia che può ritardare l’invio delle richieste di rimborso. Monitorare questa attività aiuta a misurare la produttività dei codificatori e a individuare i ritardi nella coda di codifica. Dove reperirli Registrato in un modulo del flusso di lavoro di codifica oppure tramite una modifica dello stato dell’evento di fatturazione da 'In attesa di codifica' a 'Codificato'. Si utilizza la data e ora della modifica di stato o del completamento dell’attività. Acquisizione Data e ora di un aggiornamento di stato o di una voce nel registro, quando un utente o il sistema completa la codifica dell’episodio di cura. Tipo di evento explicit | |||
| Conto rettificato | Sul conto è stata registrata una rettifica contrattuale, uno stralcio o un’altra correzione finanziaria. Si tratta di una transazione finanziaria esplicita, registrata nel libro mastro del sistema. | ||
| Perché è importante Le rettifiche incidono direttamente sui ricavi realizzati. Analizzarne i motivi e i tempi è essenziale per individuare problemi nei tariffari, nei contratti o nella precisione della fatturazione. Dove reperirli Si trova nella tabella delle transazioni finanziarie ed è identificabile tramite codici specifici per gli stralci o le rettifiche. La data della transazione corrisponde all’ora dell’evento. Acquisizione La data della transazione relativa a una voce del libro mastro finanziario con uno specifico codice di rettifica. Tipo di evento explicit | |||
| Estratto conto inviato al paziente | È stato generato e inviato al paziente un estratto conto relativo alla quota a suo carico. L’evento viene registrato esplicitamente dal modulo di fatturazione ai pazienti al momento della creazione dell’estratto conto. | ||
| Perché è importante Questa attività avvia la parte del ciclo dei ricavi relativa ai pagamenti a carico del paziente. Monitorarla aiuta ad analizzare l’efficienza e l’efficacia delle attività di riscossione presso i pazienti. Dove reperirli Registrato nella tabella della corrispondenza con i pazienti o nella cronologia di generazione degli estratti conto. La data e ora indicano quando l’estratto conto è stato creato o inviato. Acquisizione Data e ora ricavate dal log o dalla tabella cronologica di generazione degli estratti conto dei pazienti. Tipo di evento explicit | |||
| Pagamento ricevuto | Indica che è stato ricevuto un pagamento da un pagatore o da un paziente, spesso registrato nell’avviso di pagamento. L’evento può essere acquisito esplicitamente dai file elettronici di rimessa o dai log manuali delle ricevute di cassa. | ||
| Perché è importante È un’attività fondamentale per analizzare il flusso di cassa e misurare la velocità dei pagamenti. Avvia il processo di registrazione dei pagamenti. Dove reperirli Ricavato dalle informazioni di pagamento contenute nel file di rimessa EDI 835 o dai file lockbox di una banca. Spesso si utilizza la data dell’assegno o quella di elaborazione riportata nel file. Acquisizione Estratto dal segmento BPR di un file EDI 835 o dal file di dati lockbox di una banca. Tipo di evento explicit | |||
| Richiesta di rimborso creata | Il sistema ha generato una richiesta di rimborso fatturabile, riunendo tutti gli addebiti, i codici e le informazioni demografiche in un formato standard. Si tratta di un evento generato esplicitamente dal sistema, con la relativa data e ora di creazione. | ||
| Perché è importante Questa attività segna il passaggio dalla registrazione degli addebiti al processo formale di fatturazione. È un prerequisito per l’invio e un dato essenziale per monitorare i tempi di elaborazione interni. Dove reperirli Si trova nella tabella delle richieste di rimborso o nel registro delle transazioni. L’evento corrisponde alla data e ora di creazione del record principale della richiesta. Acquisizione Acquisito dalla data e ora di creazione del record principale nella tabella del database delle richieste di rimborso. Tipo di evento explicit | |||
| Ricorso inviato | È stato presentato formalmente al pagatore un ricorso contro una richiesta di rimborso rifiutata. Si tratta di un’azione esplicita registrata da un utente nel modulo di gestione dei rifiuti o dei ricorsi. | ||
| Perché è importante Questa attività è un passaggio fondamentale nel recupero dei ricavi. Monitorare l’invio dei ricorsi e i relativi tempi di ciclo è essenziale per valutare l’efficacia della strategia di risoluzione dei rifiuti. Dove reperirli Registrato in un modulo di monitoraggio dei ricorsi o come tipo di transazione specifico associato alla richiesta. Cerchi un campo come 'data del ricorso' o 'data del nuovo invio'. Acquisizione Data e ora esplicite registrate quando un utente inserisce l’invio di un ricorso. Tipo di evento explicit | |||
| Rilavorazione del rifiuto avviata | Un utente o un flusso di lavoro automatizzato ha avviato la revisione e la risoluzione di una richiesta di rimborso rifiutata. L’evento può essere registrato esplicitamente tramite un’azione dell’utente oppure dedotto da una modifica dello stato della richiesta. | ||
| Perché è importante Questa attività avvia il ciclo di rilavorazione dei rifiuti. Misurare il tempo che intercorre tra la ricezione del rifiuto e l’avvio della rilavorazione aiuta a individuare gli arretrati nella coda di gestione dei rifiuti. Dove reperirli Si trova nei moduli di gestione dei rifiuti o delle code di lavoro. Può essere una data e ora esplicita, registrata quando un utente 'apre' o 'prende in carico' un’attività relativa a un rifiuto, oppure può essere dedotta da una modifica di stato, ad esempio da 'Rifiutato' a 'In rilavorazione'. Acquisizione Dedotto da una modifica dello stato della richiesta a 'Rilavorazione' o 'In revisione', oppure dal log esplicito di un’azione dell’utente. Tipo di evento inferred | |||
Guide all’estrazione
I metodi di estrazione per questo processo sono in fase di convalida. Torni a consultare questa pagina più avanti oppure ci contatti per ricevere assistenza.
È pronto a iniziare?
Utilizzi questo template per semplificare la raccolta dei dati e iniziare a migliorare i processi di gestione del ciclo dei ricavi. Ottenga informazioni utili e migliori l’efficienza con sicurezza.
Migliori la gestione del ciclo dei ricavi e riduca subito i ritardi
Si unisca alle organizzazioni che hanno ridotto del 30% il tempo di ciclo e migliorato la propria solidità finanziaria.
Non è richiesta alcuna carta di credito. La configurazione richiede pochi minuti.