Il Suo template dei dati per la gestione del ciclo attivo

Ciclo dei ricavi di Oracle Health
Il Suo template dei dati per la gestione del ciclo attivo

Il Suo template dei dati per la gestione del ciclo attivo

Questo template La guida nella raccolta dei dati necessari per un’analisi completa del processo di gestione del ciclo attivo. Indica i campi dati essenziali e le fasi principali del processo da includere per creare un event log accurato. Seguendo queste indicazioni, potrà strutturare i dati in modo adeguato per il Process Mining.
  • Attributi consigliati da raccogliere
  • Attività principali da monitorare
  • Indicazioni per l’estrazione dei dati da Oracle Health Revenue Cycle
Non conosce ancora gli Event Log? Scopra come creare un Event Log per il Process Mining.

Attributi della gestione del ciclo attivo

Questi sono i campi dati essenziali da includere nell’event log per analizzare in modo approfondito e significativo il processo di gestione del ciclo attivo.
3 Obbligatorio 7 Consigliato 9 Facoltativo
Nome Descrizione
Evento di fatturazione
BillingEvent
Identificativo univoco di una singola prestazione o fornitura di prodotto che genera un addebito e funge da identificativo del caso nel processo del ciclo dei ricavi.
Descrizione

L’evento di fatturazione funge da identificativo principale del caso e collega tutte le attività, dalla registrazione degli addebiti alla chiusura del conto, per una specifica voce fatturabile. Ogni evento di fatturazione rappresenta un’istanza distinta del processo del ciclo dei ricavi e consente di seguirne l’intero percorso nelle varie fasi, come l’invio della richiesta di rimborso, la registrazione del pagamento e gli eventuali rifiuti o rettifiche.

Nell’analisi di Process Mining, questo attributo è fondamentale per ricostruire il flusso di processo da un’estremità all’altra. Consente di visualizzare le varianti del processo, calcolare i tempi di ciclo tra le attività e individuare colli di bottiglia o deviazioni associati a specifici eventi di fatturazione.

Perché è importante

È la chiave essenziale per tracciare l’intero ciclo di vita di un servizio fatturabile e consente tutte le analisi dei flussi di processo e delle prestazioni.

Dove reperirli

Questo identificativo dovrebbe essere una chiave univoca presente nelle tabelle principali di fatturazione o delle transazioni di addebito di Oracle Health Revenue Cycle. Consulti la documentazione del sistema per individuare la chiave primaria degli eventi di addebito.

Esempi
BEVNT-987654321BEVNT-987654322BEVNT-987654323
Nome dell’attività
ActivityName
Nome della specifica fase o dell’evento che si è verificato nel processo del ciclo dei ricavi.
Descrizione

Questo attributo registra il nome di ogni attività svolta durante il ciclo di vita di un evento di fatturazione. Alcuni esempi sono 'Addebiti registrati', 'Richiesta di rimborso inviata al pagatore' e 'Pagamento registrato'. Queste attività costituiscono i nodi della mappa di processo individuata.

Analizzare la sequenza e la frequenza delle attività è il fulcro del Process Mining. Questo attributo aiuta a individuare i percorsi di processo più comuni, rilevare le deviazioni dalla procedura standard e comprendere il flusso operativo del ciclo dei ricavi.

Perché è importante

Definisce le fasi del processo, consentendo di visualizzare la mappa di processo e analizzare gli schemi del flusso di lavoro.

Dove reperirli

In genere si ricava dagli Event Log, dai record delle modifiche di stato o da specifiche tabelle di transazioni associate alle diverse fasi del ciclo dei ricavi in Oracle Health.

Esempi
Richiesta di rimborso generataRendiconto del pagamento ricevutoRicorso contro il rifiuto presentatoConto chiuso
Timestamp dell’evento
EventTimestamp
Data e ora esatte in cui un’attività è stata registrata nel sistema.
Descrizione

Questo attributo fornisce il timestamp di ogni attività e ne indica il momento esatto. È essenziale per comprendere la tempistica e la sequenza degli eventi nel ciclo dei ricavi di uno specifico evento di fatturazione.

Nell’analisi, il timestamp dell’evento serve a ordinare cronologicamente le attività, calcolare durate e tempi di ciclo tra le diverse fasi e svolgere l’analisi dei colli di bottiglia. È alla base di tutte le metriche temporali del Process Mining, per esempio per individuare i ritardi tra 'Richiesta di rimborso inviata' e 'Rendiconto del pagamento ricevuto'.

Perché è importante

Questo timestamp è fondamentale per ordinare gli eventi, calcolare tutte le metriche di prestazione, come i tempi di ciclo e le durate, e individuare i colli di bottiglia del processo.

Dove reperirli

Ogni tabella delle transazioni o degli Event Log in Oracle Health Revenue Cycle dovrebbe includere una colonna timestamp che indichi quando è stato creato il record o si è verificato l’evento.

Esempi
2023-04-15T09:00:00Z2023-04-18T14:30:00Z2023-05-02T11:25:10Z
Categoria del paziente
PatientClass
Classificazione dell’incontro del paziente, ad esempio ricovero o visita ambulatoriale.
Descrizione

Questo attributo classifica il tipo di visita o incontro del paziente che ha generato l’addebito. Le categorie più comuni comprendono ricovero, visita ambulatoriale, pronto soccorso e paziente con accessi ricorrenti. La categoria del paziente spesso determina l’intero processo di fatturazione e invio delle richieste di rimborso.

Le diverse categorie di pazienti seguono percorsi di processo distinti e sono soggette a requisiti di conformità diversi. Analizzare il processo in base a questo attributo aiuta a comprenderne le variazioni, definire iniziative di miglioramento mirate e verificare che per ogni categoria siano seguite le procedure corrette.

Perché è importante

Distingue i flussi di processo, ad esempio ricovero e visita ambulatoriale, che presentano complessità, tempistiche e requisiti di fatturazione diversi.

Dove reperirli

È un campo standard associato a un incontro o a un record di ammissione del paziente in Oracle Health.

Esempi
RicoveroVisita ambulatorialeEmergenzaRicorrente
Codice del motivo del rifiuto
DenialReasonCode
Codice standard che indica il motivo per cui il pagatore ha respinto una richiesta di rimborso.
Descrizione

Quando un pagatore respinge una richiesta di rimborso, fornisce un codice che ne spiega il motivo, ad esempio «Servizio non coperto» o «Richiesta duplicata». Questo attributo registra il codice e la relativa descrizione.

Analizzare i motivi dei rifiuti è fondamentale per migliorare il ciclo dei ricavi. Consente all’organizzazione di individuare schemi ricorrenti, come problemi di codifica o di idoneità del paziente, e di adottare misure correttive per prevenire nuovi rifiuti. Questo incide direttamente sul tasso di richieste corrette al primo invio e riduce i costi delle rilavorazioni.

Perché è importante

Indica le cause profonde del rifiuto delle richieste, consentendo interventi mirati per aumentare il tasso di richieste corrette al primo invio e accelerare la riscossione dei ricavi.

Dove reperirli

Queste informazioni sono ricevute dal pagatore tramite il documento elettronico di rimessa (file ANSI 835) e dovrebbero essere archiviate nelle tabelle delle richieste o delle rimesse di Oracle Health.

Esempi
CO-16: alla richiesta o al servizio mancano informazioni necessarie per la valutazione.PR-96: addebito o addebiti non coperti.CO-18: richiesta o servizio duplicato.
Importo della rettifica
AdjustmentAmount
Il valore monetario delle rettifiche apportate al saldo del conto.
Descrizione

Questo attributo registra l’importo di ogni rettifica finanziaria, come agevolazioni contrattuali, stralci o correzioni, applicata all’evento di fatturazione. Le rettifiche riducono direttamente i ricavi attesi da un addebito.

La Dashboard «Impatto delle rettifiche sul conto» si basa in larga misura su questo attributo. Analizzare gli importi delle rettifiche e le relative motivazioni aiuta a individuare le cause della perdita di ricavi, le criticità nella gestione dei contratti o i problemi nella registrazione iniziale degli addebiti. È una metrica fondamentale per valutare la salute finanziaria.

Perché è importante

Quantifica la perdita di ricavi dovuta a stralci o correzioni, aiutando a individuare e affrontare le cause profonde dell’erosione finanziaria.

Dove reperirli

Si trova nelle tabelle delle transazioni finanziarie che registrano rettifiche o stralci sul conto del paziente.

Esempi
-50.25-120.0025.00
Nome del pagatore
PayerName
Nome della compagnia assicurativa o del pagatore terzo responsabile del pagamento.
Descrizione

Questo attributo identifica l’ente a cui viene fatturato il servizio, come una compagnia assicurativa o un programma governativo quale Medicare. Le informazioni sul pagatore sono fondamentali per l’analisi del ciclo dei ricavi.

Analizzare il processo per pagatore può rivelare differenze significative nei tempi di pagamento, nei tassi di rifiuto e nel successo dei ricorsi. Aiuta a individuare i pagatori problematici che causano ritardi o perdite di ricavi ed è essenziale per gestire efficacemente i contratti e i rapporti con i pagatori.

Perché è importante

Consente di segmentare il processo per pagatore e di rilevare differenze nei comportamenti, nei tassi di rifiuto e nella rapidità dei pagamenti, aspetti fondamentali per i risultati finanziari.

Dove reperirli

Queste informazioni sono memorizzate nei record di fatturazione o assicurativi del paziente in Oracle Health Revenue Cycle.

Esempi
AetnaBlue Cross Blue ShieldUnitedHealthcareMedicareCigna
Reparto fatturazione
BillingDepartment
Reparto o team funzionale responsabile dell’attività.
Descrizione

Questo attributo specifica il reparto che ha svolto l’attività, ad esempio 'Registrazione degli addebiti', 'Codifica' o 'Recupero crediti'. Fornisce un contesto organizzativo al flusso di processo.

Analizzare il processo dal punto di vista dei reparti è essenziale per comprendere i passaggi di consegne tra i team e individuare le inefficienze tra le diverse funzioni. L’attributo supporta la Dashboard 'Carico di lavoro del reparto fatturazione', consentendo di aggregare le attività e le metriche di prestazione per reparto.

Perché è importante

Associa le attività alle unità organizzative, un aspetto fondamentale per analizzare i passaggi di consegne tra reparti, il carico di lavoro e le prestazioni dei team.

Dove reperirli

Queste informazioni possono essere memorizzate direttamente nei dati del profilo utente di Oracle Health oppure ricavate in base all’utente o al tipo di attività.

Esempi
Accesso dei pazientiCodificaFatturazioneRecupero crediti
Saldo residuo
OutstandingBalance
Il saldo ancora da pagare per l’evento di fatturazione in un determinato momento.
Descrizione

Questo attributo indica l’importo attualmente dovuto per un evento di fatturazione, dopo aver applicato tutti i pagamenti e le rettifiche. Rappresenta il credito ancora aperto relativo a quello specifico addebito.

È un attributo fondamentale per la Dashboard «Anzianità dei saldi residui». Analizzare questo valore nel tempo aiuta a monitorare la velocità dei flussi di cassa, valutare l’efficacia delle attività di recupero crediti e calcolare KPI finanziari chiave come i Giorni medi di incasso (DSO).

Perché è importante

Monitora i crediti ancora aperti per ciascun caso, un dato essenziale per gestire i flussi di cassa e analizzare l’efficacia delle attività di recupero crediti.

Dove reperirli

In genere, questo valore si calcola sommando tutte le transazioni finanziarie (addebiti, pagamenti e rettifiche) relative a un determinato evento di fatturazione. Può essere presente come campo in una tabella riepilogativa dei conti.

Esempi
75.000.00550.80
Utente
UserPerformingAction
ID utente o nome della persona che ha svolto l’attività.
Descrizione

Questo attributo identifica il dipendente o l’utente di sistema automatizzato responsabile di una specifica attività del processo. È fondamentale per comprendere la distribuzione del carico di lavoro e le prestazioni delle risorse e per individuare le esigenze di formazione.

Nell’analisi, consente di filtrare la mappa di processo per utente o team, confrontare le prestazioni delle diverse risorse e analizzare il carico di lavoro nella Dashboard 'Carico di lavoro del reparto fatturazione'. Può aiutare a individuare le persone con i migliori risultati o chi potrebbe aver bisogno di ulteriore supporto o formazione.

Perché è importante

Collega le attività del processo a utenti o team specifici, consentendo di analizzare il carico di lavoro, confrontare le prestazioni e individuare opportunità di formazione.

Dove reperirli

I campi ID utente, ad esempio 'CREATED_BY' e 'USER_ID', sono in genere presenti nelle tabelle delle transazioni dei vari moduli di Oracle Health.

Esempi
j.doeasmithBillingBot_AUTOk.williams
È automatizzata
IsAutomated
Indicatore che specifica se l’attività è stata svolta da un sistema automatizzato o da una persona.
Descrizione

Questo attributo booleano distingue le attività eseguite da automazioni software, come bot o processi batch di sistema, da quelle svolte manualmente da una persona. Ad esempio, «Richiesta generata» potrebbe essere un passaggio automatizzato, mentre «Ricorso contro il rifiuto» è probabilmente manuale.

Analizzare questo attributo aiuta a comprendere il livello di automazione del processo e il suo impatto sull’efficienza e sul tasso di errore. È possibile confrontare i percorsi automatizzati con quelli manuali e individuare nuove opportunità di automazione.

Perché è importante

Distingue le attività svolte da persone da quelle gestite dai sistemi, un aspetto fondamentale per analizzare l’efficacia dell’automazione e individuare nuove opportunità.

Dove reperirli

In genere, si ricava dall’attributo UserPerformingAction. Ad esempio, le attività svolte da ID utente come «SYSTEM» o «RPA_BOT» vengono contrassegnate come automatizzate.

Esempi
truefalse
È una rilavorazione
IsRework
Indicatore che identifica le attività che comportano una rilavorazione o la ripetizione di un’attività.
Descrizione

Questo attributo calcolato contrassegna le attività che si discostano dal «percorso ottimale» e comportano una rilavorazione. Tra gli esempi figurano «Richiesta corretta e inviata» o «Ricorso contro il rifiuto», passaggi che non sarebbero necessari se il processo si svolgesse correttamente al primo tentativo.

Individuare e quantificare le rilavorazioni è uno degli obiettivi principali del Process Mining. Questo indicatore permette di filtrare e analizzare facilmente tutti i cicli di rilavorazione, contribuendo a misurare la frequenza, i costi e le cause delle inefficienze. È essenziale per comprendere il costo effettivo della qualità nel ciclo dei ricavi.

Perché è importante

Aiuta a quantificare la frequenza e l’impatto dei cicli di rilavorazione, mettendo in evidenza le inefficienze del processo e il costo della scarsa qualità.

Dove reperirli

È un attributo derivato, calcolato durante la trasformazione dei dati applicando regole aziendali che contrassegnano specifici nomi di attività come rilavorazioni.

Esempi
truefalse
ID paziente
PatientId
Identificativo univoco del paziente associato all’evento di fatturazione.
Descrizione

Questo attributo è l’identificativo univoco del paziente che ha ricevuto il servizio, spesso noto come numero di cartella clinica (MRN). Collega la transazione finanziaria a una persona specifica.

Pur non essendo l’ID caso del processo, l’ID paziente è utile per aggregare tutti gli eventi di fatturazione relativi a una persona e ricostruirne l’intero percorso finanziario. Se associato ai dati anagrafici dei pazienti, consente inoltre di segmentare i dati in base alle caratteristiche demografiche o alla storia clinica.

Perché è importante

Collega gli eventi finanziari a un paziente specifico e consente analisi incentrate sul paziente e l’aggregazione di tutte le sue attività di fatturazione.

Dove reperirli

Questo identificativo è un elemento centrale dell’anagrafica del paziente ed è presente in tutte le tabelle delle transazioni correlate, ad esempio quelle relative ad addebiti, richieste e pagamenti.

Esempi
MRN-1002345MRN-1002346MRN-1002347
ID richiesta
ClaimId
Identificativo univoco della richiesta di rimborso assicurativo inviata a un pagatore.
Descrizione

Questo attributo è l’ID univoco assegnato a una richiesta generata e inviata a un pagatore per ottenere un rimborso. Nel corso del suo ciclo di vita, un singolo evento di fatturazione può generare una o più richieste, ad esempio quando è necessario apportare una correzione.

L’ID richiesta consente di tracciare uno specifico invio al pagatore e di collegarlo direttamente alla risposta, come un pagamento o un rifiuto. Permette quindi un monitoraggio più dettagliato all’interno del processo complessivo del ciclo dei ricavi.

Perché è importante

Fornisce un identificativo specifico per seguire il percorso di una richiesta presso un pagatore, con un livello di dettaglio maggiore rispetto all’evento di fatturazione complessivo.

Dove reperirli

Questo ID viene generato da Oracle Health al momento della creazione della richiesta e archiviato nella tabella principale delle richieste.

Esempi
CLM-2023-55489CLM-2023-55490CLM-2023-55491-C1
Importo addebitato
ChargeAmount
Il valore monetario lordo del servizio o prodotto fatturato.
Descrizione

Questo attributo rappresenta l’importo iniziale, al lordo degli sconti, addebitato per un servizio prima di applicare rettifiche, agevolazioni contrattuali o pagamenti. È il valore finanziario di partenza dell’evento di fatturazione.

Monitorare l’importo addebitato è fondamentale per l’analisi finanziaria, ad esempio per calcolare il valore totale dei servizi erogati e comprendere l’impatto economico delle rettifiche o degli stralci successivi. Costituisce la base di riferimento per misurare la realizzazione dei ricavi.

Perché è importante

Definisce il valore finanziario iniziale del caso, fondamentale per tutte le analisi finanziarie e le valutazioni d’impatto successive.

Dove reperirli

Si trova nelle tabelle dei dettagli degli addebiti o delle transazioni di addebito di Oracle Health.

Esempi
150.001250.7585.50
Motivo della contestazione
DisputeReason
Il motivo indicato dal cliente o dal paziente per contestare una fattura o un addebito.
Descrizione

Questo attributo registra il motivo per cui un paziente o un’altra persona responsabile ha contestato una fattura. Tra le possibili motivazioni figurano addebiti errati, servizi non erogati o problemi nella gestione assicurativa.

Queste informazioni sono essenziali per la Dashboard «Metriche di risoluzione delle contestazioni delle fatture». Conoscere i motivi più frequenti delle contestazioni aiuta a individuare problemi sistemici nella registrazione degli addebiti, nella codifica o nei processi di fatturazione. Intervenire sulle cause profonde può ridurre sensibilmente il tasso di contestazione e il carico amministrativo necessario per risolverle.

Perché è importante

Spiega perché vengono contestate le fatture e offre indicazioni dirette sui problemi di accuratezza o chiarezza della fatturazione da correggere.

Dove reperirli

Probabilmente queste informazioni sono archiviate in un modulo di gestione dei casi o di assistenza clienti di Oracle Health, collegato al conto del paziente.

Esempi
Servizio fatturato erroneamenteAddebito duplicatoFatturazione errata all’assicurazioneServizio non erogato
Ora di fine dell’evento
EventEndTime
Timestamp che indica il completamento di un’attività, se disponibile.
Descrizione

Mentre StartTime indica l’inizio di un’attività, EventEndTime ne indica la conclusione. Non tutte le attività hanno un orario di fine distinto, poiché molti eventi sono istantanei. Tuttavia, questo campo è molto utile per le attività che hanno una durata, come 'Ricorso contro il rifiuto presentato', la cui gestione può richiedere tempo.

Questo attributo consente di calcolare con maggiore precisione il tempo di elaborazione delle singole attività e di distinguere il tempo di attesa, cioè quello tra un’attività e l’altra, dal tempo di elaborazione, ovvero quello dedicato all’attività.

Perché è importante

Consente di calcolare direttamente il tempo necessario per completare un’attività, distinguendo il tempo di elaborazione da quello di attesa.

Dove reperirli

Alcune tabelle delle transazioni di Oracle Health Revenue Cycle possono contenere sia il timestamp di inizio sia quello di fine per specifiche attività di lunga durata.

Esempi
2023-04-15T09:05:14Z2023-04-18T16:00:00Z
Sistema di origine
SourceSystem
Il sistema da cui sono stati estratti i dati dell’evento.
Descrizione

Questo attributo identifica l’applicazione o il modulo di origine dei dati. Per questo processo, in genere sarà 'Oracle Health Revenue Cycle', ma può anche indicare moduli diversi dello stesso sistema se i dati provengono da più fonti.

Questa informazione è utile per la governance dei dati e la risoluzione dei problemi. Aiuta a verificare la provenienza dei dati ed è importante negli ambienti in cui più sistemi contribuiscono a un unico processo da un’estremità all’altra.

Perché è importante

Fornisce informazioni sull’origine dei dati, fondamentali per la convalida e la governance dei dati e per comprendere le variazioni del processo che possono dipendere dal sistema.

Dove reperirli

Spesso è un valore statico aggiunto durante il processo di estrazione, trasformazione e caricamento dei dati (ETL) per indicare l’origine del set di dati.

Esempi
OracleHealth-RCMOracleHealth-CernerOH-RevCycle-PROD
Ultimo aggiornamento dei dati
LastDataUpdate
Timestamp che indica l’ultimo aggiornamento o l’ultima estrazione dei dati relativi a questo evento.
Descrizione

Questo attributo indica quando il set di dati è stato aggiornato l’ultima volta. Fornisce informazioni sull’aggiornamento dei dati analizzati, importanti per valutare quanto siano recenti le informazioni ricavate dall’analisi di Process Mining.

Può consultare questo attributo per verificare che stia visualizzando le informazioni di processo più aggiornate. Aiuta a valutare la recenza dei dati ed è un elemento importante della governance e del controllo qualità dei dati.

Perché è importante

Indica quanto sono aggiornati i dati, affinché analisi e decisioni si basino su informazioni recenti.

Dove reperirli

È un campo di metadati, in genere generato e compilato durante il processo ETL che carica i dati nella piattaforma di Process Mining.

Esempi
2023-10-27T02:00:00Z2023-10-28T02:00:00Z
Obbligatorio Consigliato Facoltativo

Attività della gestione del ciclo attivo

Queste sono le fasi e le tappe fondamentali del processo da registrare nell’event log per visualizzare e analizzare con precisione il ciclo attivo.
5 Consigliato 9 Facoltativo
Attività Descrizione
Conto chiuso
Attività finale, che indica che il saldo del conto è pari a zero e che non sono previste ulteriori attività. Spesso si deduce quando il saldo raggiunge lo zero.
Perché è importante

Segna il completamento del ciclo dei ricavi. Il tempo necessario per raggiungere questo stato è un indicatore importante dell’efficienza complessiva del processo.

Dove reperirli

In genere si deduce individuando il primo momento in cui il saldo residuo del conto diventa zero e vi rimane dopo la registrazione di tutti i pagamenti e le rettifiche.

Acquisizione

Calcolato quando il saldo del conto raggiunge per la prima volta lo zero dopo la registrazione di tutti gli addebiti e i pagamenti.

Tipo di evento calculated
Incontro del paziente creato
Indica la creazione di un conto paziente per una visita o un servizio specifico. In genere è un evento esplicito, generato dal sistema di registrazione o da un flusso Admit/Discharge/Transfer (ADT).
Perché è importante

È il punto di partenza dell’intero ciclo dei ricavi per un determinato evento di fatturazione e consente di analizzare la durata complessiva del processo e l’accuratezza della registrazione.

Dove reperirli

I dati provengono dai log del modulo Patient Registration o ADT. Cerchi gli eventi di creazione dell’incontro o il timestamp più remoto associato all’incontro o al numero finanziario.

Acquisizione

Evento registrato al momento della registrazione o dell’ammissione del paziente.

Tipo di evento explicit
Pagamento registrato
Indica l’attribuzione del pagamento ricevuto dal pagatore agli addebiti corrispondenti sul conto del paziente. È una transazione finanziaria registrata da un utente o da un processo automatizzato.
Perché è importante

L’efficienza nella registrazione dei pagamenti incide sull’accuratezza dei crediti verso clienti. I ritardi in questa fase possono alterare il quadro finanziario e ritardare la fatturazione secondaria.

Dove reperirli

Si trova nelle tabelle delle transazioni di pagamento. Ogni registrazione di pagamento ha un ID transazione univoco e un timestamp associato.

Acquisizione

Transazione finanziaria registrata quando il pagamento viene attribuito al conto.

Tipo di evento explicit
Richiesta di rimborso generata
Indica il momento in cui i singoli addebiti vengono riuniti in una richiesta di rimborso formale, come un modulo UB-04 o CMS-1500. È un evento generato dal sistema che crea la fattura iniziale.
Perché è importante

È una tappa fondamentale che indica che la richiesta è pronta per essere inviata al pagatore. Segna il termine del periodo interno tra la registrazione degli addebiti e la fatturazione.

Dove reperirli

Evento esplicito registrato nei log o nelle tabelle di generazione delle richieste di rimborso. Cerchi il timestamp di creazione del record principale della richiesta associato all’incontro.

Acquisizione

Evento registrato alla creazione del record della richiesta di rimborso.

Tipo di evento explicit
Richiesta di rimborso inviata al pagatore
Indica l’invio elettronico o cartaceo della richiesta di rimborso generata alla compagnia assicurativa o al pagatore. Il sistema dovrebbe registrare la data e l’ora della trasmissione.
Perché è importante

Questa attività avvia il ciclo di pagamento. Analizzare il tempo che intercorre tra l’invio e il pagamento è fondamentale per comprendere le prestazioni dei pagatori e i giorni medi di incasso.

Dove reperirli

I dati provengono dal modulo di gestione delle richieste di rimborso, che registra gli eventi di trasmissione. Cerchi il timestamp di invio o la modifica dello stato in 'Submitted' nella cronologia della richiesta.

Acquisizione

Evento registrato quando la richiesta di rimborso viene trasmessa correttamente tramite la clearinghouse.

Tipo di evento explicit
Addebiti codificati
Indica il processo in cui i codificatori medici assegnano agli addebiti registrati codici standard, come CPT o ICD-10. Spesso è tracciato tramite una modifica dello stato dell’addebito o dell’incontro.
Perché è importante

I ritardi nella codifica sono un collo di bottiglia frequente. Tracciare questa attività aiuta a individuare le inefficienze nel flusso di lavoro di codifica e il loro impatto sulle tempistiche di fatturazione.

Dove reperirli

Spesso si deduce da una modifica dello stato dell’incontro del paziente o del gruppo di addebiti, per esempio da 'Uncoded' a 'Coded'. È necessario disporre del timestamp della modifica.

Acquisizione

Deducibile dalla modifica dello stato dell’incontro o dell’addebito in 'Coded' o 'Ready for Billing'.

Tipo di evento inferred
Addebiti registrati
Indica l’inserimento nel conto del paziente di servizi o articoli fatturabili. Può avvenire automaticamente dai sistemi clinici oppure tramite inserimento manuale da parte del personale.
Perché è importante

Questa attività è fondamentale per misurare il ritardo nella registrazione degli addebiti, ovvero il tempo tra l’erogazione del servizio e l’avvio della fatturazione, che incide direttamente sul flusso di cassa e sull’integrità dei ricavi.

Dove reperirli

I dati provengono dalle tabelle delle transazioni di addebito; ogni voce è identificata dal timestamp di creazione. In Oracle Health, si trovano spesso nelle tabelle relative agli addebiti.

Acquisizione

Voce del registro delle transazioni creata per ogni nuovo addebito.

Tipo di evento explicit
Conto rettificato
Indica una rettifica finanziaria del saldo del conto, come un abbuono contrattuale, uno stralcio o uno sconto. Ogni rettifica costituisce una transazione finanziaria distinta.
Perché è importante

Le rettifiche incidono direttamente sui ricavi. Analizzarne frequenza, tipologia e importo aiuta a individuare perdite di ricavi e imprecisioni nella fatturazione.

Dove reperirli

Si trova nelle tabelle delle transazioni finanziarie. Ogni rettifica è registrata come voce separata, con un codice transazione specifico e un timestamp.

Acquisizione

Transazione finanziaria registrata con un codice di rettifica specifico.

Tipo di evento explicit
Estratto conto inviato al paziente
Indica la generazione e l’invio al paziente della fattura per l’importo residuo a suo carico. È un’azione esplicita registrata dal modulo di fatturazione ai pazienti.
Perché è importante

Avvia la fase del ciclo dei ricavi relativa ai pagamenti del paziente. Tracciarla aiuta ad analizzare l’efficacia delle attività di riscossione.

Dove reperirli

I dati provengono dai log di fatturazione ai pazienti o di corrispondenza. Il sistema dovrebbe registrare la data di generazione o invio di ogni estratto conto.

Acquisizione

Evento registrato quando l’estratto conto del paziente viene generato e stampato o inviato elettronicamente.

Tipo di evento explicit
Recupero crediti avviato
Indica che, a causa del mancato pagamento, il conto del paziente è stato inserito in una procedura di recupero crediti. In genere si rileva da una modifica della categoria finanziaria o dello stato del conto.
Perché è importante

È una fase fondamentale nella gestione dei crediti inesigibili. Analizzare cosa porta a questo punto e il tasso di successo delle attività è essenziale per la salute finanziaria.

Dove reperirli

Deducibile dalla modifica del campo dello stato del conto in 'Collections' o 'Bad Debt'. La modifica dovrebbe avere un timestamp associato.

Acquisizione

Deducibile dalla modifica dello stato del conto in 'Collections' o in uno stato analogo.

Tipo di evento inferred
Rendiconto del pagamento ricevuto
Indica la ricezione dal pagatore di un Electronic Remittance Advice (ERA) o di un Explanation of Benefits (EOB) cartaceo. Il documento specifica quali addebiti sono stati pagati, respinti o rettificati.
Perché è importante

È la prima risposta del pagatore ed è fondamentale per comprendere la rapidità dei pagamenti e individuare tempestivamente le tendenze nei rifiuti.

Dove reperirli

Registrato nel modulo di elaborazione dei rendiconti. Cerchi il timestamp di importazione o creazione del file ERA, ad esempio un file di transazione 835, collegato alla richiesta.

Acquisizione

Evento registrato all’importazione e all’elaborazione del file di rendicontazione del pagatore, ad esempio ANSI 835.

Tipo di evento explicit
Richiesta di rimborso corretta inviata
Indica l’invio al pagatore di una richiesta di rimborso rivista o corretta, spesso in seguito a un rifiuto o a una richiesta di ulteriori informazioni. Si identifica tramite un nuovo invio con un indicatore di correzione.
Perché è importante

Questa attività è una fase importante del ciclo di rilavorazione per la gestione dei rifiuti. Una frequenza elevata segnala problemi di accuratezza nelle richieste iniziali.

Dove reperirli

I dati provengono dai log di invio delle richieste. Cerchi un nuovo invio per un incontro esistente, spesso contrassegnato da un codice di reinvio o da un numero di iterazione superiore.

Acquisizione

Evento registrato per il reinvio di una richiesta, spesso identificabile tramite uno specifico codice del tipo di frequenza della richiesta.

Tipo di evento explicit
Ricorso contro il rifiuto presentato
Azione di un utente o del sistema che indica la presentazione di un ricorso contro una richiesta di rimborso rifiutata. In genere viene registrata come aggiornamento di stato o come attività specifica creata in una coda di lavoro.
Perché è importante

Questa attività avvia un ciclo di rilavorazione. Analizzare la frequenza e il tasso di successo dei ricorsi è fondamentale per ottimizzare il recupero dei ricavi.

Dove reperirli

Può trattarsi di un evento esplicito avviato dall’utente oppure dedotto da una modifica dello stato della richiesta, ad esempio in 'Appealed' o 'In Review'.

Acquisizione

Modifica di stato o evento registrato quando un utente avvia la procedura di ricorso contro una richiesta di rimborso rifiutata.

Tipo di evento explicit
Rifiuto ricevuto
Indica il rifiuto, da parte del pagatore, di una richiesta di rimborso o di specifiche voci, come riportato nel rendiconto. Spesso l’evento si deduce dai codici di rifiuto presenti nei dati del rendiconto.
Perché è importante

Tracciare i rifiuti è essenziale per individuarne le cause profonde, come errori di codifica o problemi di idoneità, e migliorare il tasso di richieste corrette al primo invio.

Dove reperirli

Deducibile dai dati del rendiconto (ERA/835). L’evento si verifica quando una richiesta o una voce presenta un importo di rifiuto diverso da zero e il relativo codice motivo.

Acquisizione

Deducibile dai dati del rendiconto che contengono codici motivo di rifiuto (CARC/RARC).

Tipo di evento inferred
Consigliato Facoltativo

Guide all’estrazione

Come estrarre i dati da Oracle Health Revenue Cycle

È pronto a iniziare?

Utilizzi questo template per preparare i dati e ottenere risultati affidabili. Inizi oggi a migliorare il processo di gestione del ciclo attivo.

Ottimizzi il ciclo attivo per ricevere i pagamenti più rapidamente

Elimini i colli di bottiglia, riduca del 30% il tempo di ciclo e migliori il flusso di cassa.

Inizi la prova gratuita

Non è richiesta la carta di credito. La configurazione richiede pochi minuti.