Il Suo template dati per la gestione del ciclo del fatturato

R1 RCM
Il Suo template dati per la gestione del ciclo del fatturato

Il Suo template dati per la gestione del ciclo del fatturato

Questo template di dati fornisce una tabella di marcia chiara per raccogliere le informazioni necessarie ad analizzare il Suo processo di gestione del ciclo del fatturato. Delinea gli attributi essenziali da raccogliere e le attività critiche da monitorare. Troverà anche indicazioni su come estrarre questi dati dal Suo sistema R1 RCM, aiutandola a prepararsi per un'iniziativa di Process Mining efficiente.
  • Attributi consigliati da raccogliere
  • Attività chiave da tracciare per la scoperta dei processi
  • Guida dettagliata all'estrazione per R1 RCM
È nuovo agli event log? Impari come creare un event log di Process Mining.

Attributi di gestione del ciclo del fatturato

Questi sono i campi dati consigliati da includere nel Suo Event Log per un'analisi completa del Suo processo di gestione del ciclo del fatturato.
5 Obbligatorio 6 Consigliato 8 Facoltativo
Nome Descrizione
Billing Event
BillingEvent
L'identificatore unico per un singolo servizio o articolo fatturabile, che funge da identificatore principale del caso per tracciare l'intero ciclo del fatturato.
Descrizione

Il Billing Event ID rappresenta un'istanza distinta di erogazione di un servizio o prodotto che genera un addebito. Funge da filo conduttore che collega tutte le attività correlate, dalla prestazione iniziale e l'acquisizione dell'addebito fino all'invio della richiesta, alla registrazione del pagamento e alla chiusura finale dell'account.

Nel Process Mining, l'analisi del ciclo di vita di ogni evento di fatturazione consente una visione completa del ciclo del fatturato end-to-end. Viene utilizzato per tracciare il percorso completo di un singolo addebito, identificare i percorsi comuni, misurare i tempi di ciclo tra le pietre miliari chiave e comprendere le variazioni che portano a ritardi o dispersioni di ricavi.

Perché è importante

Questo identificatore è essenziale per raggruppare tutte le attività correlate in un unico caso, consentendo un'analisi completa e accurata del ciclo del fatturato per ogni evento fatturabile.

Dove trovare

Questa è la chiave primaria che collega le varie tabelle relative a incontri con pazienti, addebiti, richieste e pagamenti. Consulti la documentazione di R1 RCM per il campo specifico, spesso correlato a un identificatore di incontro o di richiesta.

Esempi
BE-2023-0012345BE-2023-0054321BE-2024-0098765
Nome attività
ActivityName
Il nome dello specifico evento aziendale o task che si è verificato in un dato momento all'interno del processo del ciclo del fatturato.
Descrizione

Questo attributo descrive una singola fase o pietra miliare all'interno del processo di gestione del ciclo del fatturato per un determinato evento di fatturazione. Le attività rappresentano il lavoro svolto, come "Addebiti acquisiti", "Richiesta inviata" o "Pagamento registrato".

L'analisi della sequenza delle attività è il cuore del Process Mining. Consente di scoprire il flusso reale del processo, identificare i bottleneck dove le attività impiegano troppo tempo per iniziare e rilevare loop di rilavorazione dove le attività vengono ripetute inutilmente, come "Richiesta rifiutata" seguita da "Rilavorazione rifiuto avviata".

Perché è importante

Definisce le fasi del processo, consentendo la visualizzazione della mappa di processo, il calcolo dei tempi di transizione e l'identificazione di deviazioni e rilavorazioni.

Dove trovare

Questa informazione è solitamente derivata da log degli eventi, record di cambio di stato o codici di transazione all'interno dei vari moduli R1 RCM. Potrebbe richiedere una mappatura dai codici tecnici a nomi più comprensibili per il business.

Esempi
Charges CapturedSinistro InviatoPayer Adjudication ReceivedPagamento RegistratoAccount Closed
Timestamp Evento
EventTime
Il timestamp che indica quando una specifica attività o un evento si è verificato.
Descrizione

L'Event Time fornisce la data e l'ora precise in cui un'attività è stata registrata nel sistema. Questa informazione temporale è fondamentale per comprendere il processo da un punto di vista analitico basato sul tempo.

Nel process mining, questo timestamp viene utilizzato per ordinare gli eventi cronologicamente e calcolare le durate tra le attività, il che è critico per l'analisi delle prestazioni. Consente il calcolo di metriche chiave come il tempo di ciclo, il tempo di elaborazione e il tempo di attesa, essenziali per identificare i colli di bottiglia e misurare l'efficienza.

Perché è importante

Questo timestamp è la base per tutte le analisi temporali, inclusi il calcolo dei tempi di ciclo, l'identificazione dei bottleneck e il monitoraggio delle performance del processo rispetto agli SLA.

Dove trovare

Solitamente si trova come campo "Data creazione", "Timestamp" o "Data ultimo aggiornamento" associato a ogni transazione o record di cambio di stato in R1 RCM.

Esempi
2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-11-05T09:12:45Z
Sistema di Origine
SourceSystem
Il sistema sorgente da cui sono stati estratti i dati degli eventi.
Descrizione

Questo attributo identifica l'applicazione o il modulo sorgente che ha generato i dati per un particolare evento. In un ambiente complesso come quello sanitario, i dati possono provenire da un EMR, un modulo di fatturazione, un clearinghouse per le richieste o una piattaforma di recupero crediti.

Comprendere il sistema sorgente è cruciale per la validazione dei dati e per analizzare le variazioni di processo che possono essere specifiche di certi sistemi. Aiuta a risolvere le incongruenze dei dati e a comprendere il panorama tecnologico del processo.

Perché è importante

Identifica l'origine dei dati, aspetto cruciale per la data governance, la validazione e la comprensione di come i diversi sistemi interagiscono all'interno del processo end-to-end.

Dove trovare

Si tratta spesso di un valore statico aggiunto durante il processo di estrazione dei dati, che identifica il sistema (es. "R1 RCM") da cui provengono i dati.

Esempi
R1 RCMCernerEpic
Ultimo `Data Update`
LastDataUpdate
Il timestamp del più recente data refresh o estrazione dal sistema sorgente.
Descrizione

Questo attributo indica l'ultima volta che i dati per l'analisi di Process Mining sono stati aggiornati. Fornisce un contesto sulla freschezza dei dati analizzati.

Questa informazione è importante per la reportistica e le dashboard, poiché indica all'utente quanto siano attuali gli insight sul processo. Aiuta a gestire le aspettative sulla tempestività dei dati e assicura che le decisioni siano prese sulla base di un arco temporale definito.

Perché è importante

Fornisce un contesto cruciale sulla freschezza dei dati, assicurando che analisti e stakeholder siano consapevoli di quanto siano aggiornati gli insight sul processo.

Dove trovare

Questo timestamp viene generato durante il processo di estrazione, trasformazione e caricamento (ETL) e viene solitamente applicato all'intero dataset.

Esempi
2024-05-20T08:00:00Z2024-05-21T08:00:00Z
Denial Reason Code
DenialReasonCode
Un codice standardizzato fornito dal pagatore che spiega il motivo per cui una richiesta di rimborso è stata respinta.
Descrizione

Quando un pagatore rifiuta una richiesta, fornisce un codice motivo, come un CARC (Claim Adjustment Reason Code), per spiegare la decisione. Questi codici sono standardizzati e indicano problemi come "Servizio non coperto" o "Richiesta duplicata".

Questo attributo è estremamente importante per la gestione dei rifiuti. Analizzando la frequenza dei diversi codici motivo del rifiuto, le organizzazioni possono identificare e affrontare le cause radice dei rifiuti, siano esse legate all'idoneità del paziente, a errori di codifica o alla mancanza di necessità medica. Ciò supporta direttamente gli sforzi per ridurre le rilavorazioni e accelerare il cash flow.

Perché è importante

Fornisce la ragione specifica del rifiuto della richiesta, consentendo l'analisi delle cause radice per ridurre i rifiuti futuri, diminuire le rilavorazioni e migliorare i tassi di pagamento al primo invio.

Dove trovare

Questa informazione viene ricevuta nel documento Electronic Remittance Advice (file ERA o 835) dal pagatore ed è memorizzata nel modulo di gestione delle richieste di R1 RCM.

Esempi
CO-16: La richiesta/servizio manca delle informazioni necessarie per la liquidazione.PR-97: Il beneficio per questo servizio è incluso nel pagamento/indennità di un altro servizio.CO-22: Questa prestazione potrebbe essere coperta da un altro pagatore in base alla coordinazione dei benefici.OA-18: Richiesta/servizio duplicato esatto.
Dipartimento Fatturazione
BillingDepartment
Il dipartimento o il team funzionale responsabile dell'esecuzione dell'`activity`.
Descrizione

Questo attributo specifica l'unità organizzativa, come "Inserimento addebiti", "Invio richieste" o "Gestione rifiuti", che ha eseguito una determinata fase del processo. Aiuta a comprendere come il lavoro viene passato tra i diversi team.

Questo è cruciale per analizzare il throughput dipartimentale e identificare i bottleneck interfunzionali. Filtrando la mappa di processo per dipartimento, le organizzazioni possono vedere dove i passaggi di consegne sono fluidi e dove si verificano ritardi, supportando l'allocazione delle risorse e l'ottimizzazione dei processi organizzativi.

Perché è importante

Consente l'analisi delle prestazioni del processo per unità organizzativa, aiutando a identificare colli di bottiglia specifici dei team, vincoli di risorse o best practice.

Dove trovare

Questo può essere derivato dal profilo dell'utente in R1 RCM o memorizzato come "Codice dipartimento" nei dati della transazione.

Esempi
Charge CaptureGestione SinistriDenial & AppealsRegistrazione del pagamento
Importo Fattura
InvoiceAmount
Il valore monetario totale degli addebiti in fattura o nella richiesta.
Descrizione

Questo attributo rappresenta l'importo totale fatturato per i servizi prestati in un determinato evento di fatturazione. Riflette il ricavo atteso dalla richiesta.

Analizzare l'importo della fattura è fondamentale per il Financial Process Mining. Consente di prioritizzare le richieste di alto valore, comprendere l'impatto finanziario dei ritardi o dei rifiuti di processo e segmentare il processo in base al valore. Ad esempio, un'analisi potrebbe rivelare che le richieste oltre un certo importo seguono un percorso di processo diverso e più manuale.

Perché è importante

Fornisce un contesto finanziario al processo, consentendo di analizzare come le variazioni influenzino i ricavi e aiutando a prioritizzare i casi ad alto valore per il miglioramento.

Dove trovare

Situato nella tabella principale delle testate delle richieste o fatture in R1 RCM, spesso denominata 'TotalBilledAmount' o simile.

Esempi
150.002500.7585.5012000.00
Nome Pagatore
PayerName
Il nome della compagnia assicurativa, dell'ente governativo o del paziente responsabile del pagamento.
Descrizione

Questo attributo identifica il pagatore principale per la richiesta. Potrebbe essere un'assicurazione commerciale, un ente governativo o il paziente stesso per le quote a suo carico.

L'analisi del processo per pagatore è fondamentale per la gestione del ciclo del fatturato. Può rivelare che certi pagatori hanno tassi di rifiuto più elevati, cicli di pagamento più lunghi o requisiti di invio più complessi. Questi insight permettono all'organizzazione di adattare i propri processi e risorse per gestire efficacemente i comportamenti specifici dei pagatori.

Perché è importante

Consente la segmentazione del processo per pagatore per identificare ritardi specifici, pattern di rifiuto o comportamenti di pagamento, aspetto cruciale per ottimizzare le entrate.

Dove trovare

Trovato nelle informazioni assicurative o anagrafiche del paziente collegate alla richiesta in R1 RCM.

Esempi
MedicareUnitedHealthcareBlue Cross Blue ShieldAetnaPagamento Autonomo
Stato Fattura
InvoiceStatus
Lo stato attuale della fattura o della richiesta nel suo ciclo di vita.
Descrizione

Questo attributo indica l'ultimo stato noto di un evento di fatturazione, come "Inviato", "Pagato", "Rifiutato" o "In recupero crediti". Fornisce un'istantanea di dove si trova una fattura nel processo in un dato momento.

Lo stato della fattura è vitale per creare aging report e monitorare lo stato dei crediti. Nel Process Mining, può essere utilizzato per filtrare i casi bloccati in uno stato particolare o per analizzare gli esiti di diverse varianti di processo, ad esempio confrontando i percorsi delle richieste "Pagate" rispetto a quelle "Rifiutate".

Perché è importante

Fornisce una vista dello stato attuale di ogni caso, essenziale per creare aging report e analizzare gli esiti finali dei diversi percorsi di processo.

Dove trovare

Solitamente si tratta di un campo di stato sul record principale della richiesta o dell'account in R1 RCM.

Esempi
In attesa di invioInviato al pagatoreNegatoPagato per interoIn Collections
Utente Assegnato
AssignedUser
L'ID utente o il nome del dipendente che ha eseguito l'attività.
Descrizione

Questo attributo identifica la persona responsabile dell'esecuzione di un task specifico nel processo. Potrebbe essere l'addetto alla fatturazione che ha creato la richiesta, l'analista che ha rilavorato un rifiuto o lo specialista che ha registrato un pagamento.

L'analisi per utente aiuta a comprendere la distribuzione del carico di lavoro, le performance individuali e le esigenze di formazione. Può evidenziare quali utenti sono più efficienti o quali possono essere associati a tassi di errore più elevati, consentendo sforzi mirati di gestione e miglioramento dei processi.

Perché è importante

Consente l'analisi delle prestazioni del team e dei singoli, della distribuzione del carico di lavoro e aiuta a identificare opportunità di formazione o deviazioni di processo specifiche per l'utente.

Dove trovare

Solitamente si trova come campo "UserID", "Processore" o "AggiornatoDa" nei log delle transazioni all'interno di R1 RCM.

Esempi
jdoeasmithp.jonesBOT_RPA01
Codice servizio
ServiceCode
Il codice di fatturazione per lo specifico servizio o procedura fornita, come un codice CPT o HCPCS.
Descrizione

I codici di servizio, come i codici CPT (Current Procedural Terminology), sono codici medici standardizzati utilizzati per segnalare procedure e servizi medici, chirurgici e diagnostici ai pagatori per il rimborso.

Analizzare il processo per codice di servizio è essenziale per identificare i problemi di fatturazione relativi a tipi specifici di assistenza. Può evidenziare quali procedure vengono rifiutate più spesso, hanno i cicli di pagamento più lunghi o richiedono più rilavorazioni, consentendo miglioramenti mirati nelle pratiche di codifica e fatturazione.

Perché è importante

Consente l'analisi del processo in base al tipo di servizio reso, il che è fondamentale per identificare pattern di rifiuto o ritardi nei pagamenti associati a procedure specifiche.

Dove trovare

Questa informazione si trova a livello di singola voce per ogni addebito o richiesta all'interno di R1 RCM.

Esempi
992139928573560
Collection Outcome
CollectionOutcome
Il risultato finale delle attività di recupero crediti per un saldo in sospeso.
Descrizione

Questo attributo descrive l'esito degli sforzi per riscuotere il pagamento di un account scaduto. I possibili esiti includono "Pagato interamente", "Saldato", "Passato a perdita" o "Irrisolto".

Monitorare gli esiti della riscossione è essenziale per valutare l'efficacia del processo di recupero crediti. Analizzando quali attività portano a quali esiti, le organizzazioni possono ottimizzare le strategie di recupero, migliorare i tassi di riscossione e prendere decisioni informate su quando interrompere gli sforzi di recupero e stralciare i saldi. Questo supporta la dashboard Performance attività di recupero.

Perché è importante

Misura l'efficacia del processo di riscossione monitorando la risoluzione finale dei conti scaduti, aiutando a ottimizzare le strategie di recupero.

Dove trovare

Questo è probabilmente un campo di stato sull'account del paziente o in un modulo dedicato al recupero crediti all'interno di R1 RCM.

Esempi
Pagato per interoSaldato per un importo inferioreInviato ad agenzia esternaStralciato come credito inesigibile
È Automatizzato
IsAutomated
Un flag che indica se l'attività è stata eseguita da un sistema automatizzato o da un utente umano.
Descrizione

Questo attributo booleano distingue tra i task eseguiti tramite automazione software, come un bot RPA per l'invio delle richieste, e i task eseguiti manualmente da un dipendente.

Analizzare questo attributo è fondamentale per comprendere l'impatto e l'efficacia delle iniziative di automazione. Consente di confrontare velocità, costi e tassi di errore dei processi automatizzati rispetto a quelli manuali, aiutando a identificare nuove opportunità di automazione e a misurare il ROI dei bot esistenti.

Perché è importante

Distingue tra attività guidate dall'uomo e dal sistema, il che è fondamentale per misurare l'impatto dell'automazione su efficienza, costi e qualità del processo.

Dove trovare

Questo può essere derivato dal campo "AssignedUser", dove ID utente specifici sono riservati ai bot (es. "BOT_RPA01"). In alternativa, alcuni sistemi hanno un campo dedicato per contrassegnare le transazioni automatizzate.

Esempi
truefalse
È una Rilavorazione
IsRework
Un flag calcolato che identifica le attività che fanno parte di un ciclo di rilavorazione, come l'invio di una richiesta di rimborso precedentemente rifiutata.
Descrizione

Questo attributo è un flag booleano che viene solitamente calcolato durante l'analisi di Process Mining. Diventa "true" se un'attività è la ripetizione di una fase precedente o fa parte di una sequenza che indica la correzione di un errore, ad esempio qualsiasi attività successiva a "Richiesta rifiutata".

Identificare la rilavorazione (rework) è una delle funzionalità più potenti del Process Mining. Quantifica lo sforzo, il tempo e le risorse sprecate in un processo. Segnalando la rilavorazione, le organizzazioni possono concentrare i propri sforzi di miglioramento sulla prevenzione degli errori che la causano, portando a significativi guadagni di efficienza.

Perché è importante

Aiuta a quantificare la frequenza e l'impatto delle rilavorazioni, come i rifiuti delle richieste di rimborso, consentendo un'analisi mirata per ridurre inefficienze e sforzi inutili.

Dove trovare

Questo non è un campo nel sistema sorgente. Viene calcolato dallo strumento di Process Mining in base alla sequenza delle attività, ad esempio rilevando quando un'attività "Richiesta inviata" si verifica più di una volta per lo stesso caso.

Esempi
truefalse
ID Paziente
PatientId
L'identificatore unico per il paziente che ha ricevuto il servizio.
Descrizione

Questo attributo è l'ID unico assegnato a un paziente all'interno del sistema sanitario, spesso indicato come Medical Record Number (MRN).

Sebbene l'assistenza al singolo paziente non sia il focus principale, l'ID Paziente può essere utilizzato per analizzare problemi di fatturazione ricorrenti per lo stesso paziente nel tempo. Può anche aiutare a segmentare il processo in base alla demografia o alla storia del paziente se collegato ad altri dati, scoprendo potenzialmente problemi sistemici che interessano determinati gruppi di pazienti.

Perché è importante

Consente l'analisi degli eventi di fatturazione a livello di paziente, aiutando a identificare problemi ricorrenti o pattern per pazienti specifici attraverso molteplici incontri.

Dove trovare

Questo identificatore è una parte fondamentale dei dati demografici del paziente collegati a ogni incontro e richiesta in R1 RCM.

Esempi
MRN837262MRN937281MRN103847
Importo della rettifica
AdjustmentAmount
Il valore monetario di una rettifica apportata al saldo dell'account.
Descrizione

Questo attributo acquisisce il valore di eventuali rettifiche finanziarie apportate all'account di un paziente dopo la fatturazione iniziale. Le rettifiche possono essere positive o negative e includono abbuoni contrattuali, stralci o correzioni.

Il monitoraggio degli importi delle rettifiche è fondamentale per comprendere l'integrità dei ricavi. Elevati livelli di rettifiche negative possono indicare perdite di entrate dovute a problemi come l'acquisizione errata degli addebiti o crediti inesigibili. L'analisi di questi dati aiuta a identificare l'impatto finanziario degli errori di fatturazione e delle inefficienze nel recupero crediti.

Perché è importante

Quantifica la dispersione dei ricavi (revenue leakage) e le correzioni finanziarie, aiutando a individuare l'impatto monetario delle imprecisioni di fatturazione, degli obblighi contrattuali o dei crediti inesigibili.

Dove trovare

Trovato nei log delle transazioni relativi alle rettifiche dei conti o alla registrazione dei pagamenti in R1 RCM.

Esempi
-50.2520.00-1200.00
Motivo della Rettifica
AdjustmentReason
Il motivo fornito per una rettifica finanziaria, come "Abbuono contrattuale" o "Stralcio crediti inesigibili".
Descrizione

Questo attributo fornisce il contesto sul motivo per cui è stata apportata una rettifica finanziaria a un account. I motivi sono spesso codici standardizzati o descrizioni che categorizzano il tipo di rettifica.

Analizzare i motivi delle rettifiche aiuta a diagnosticare le cause radice delle dispersioni di ricavi. Ad esempio, un'elevata frequenza di "Stralcio piccoli saldi" potrebbe suggerire un processo di recupero inefficiente per importi minimi, mentre frequenti "Abbuoni contrattuali" sono una parte attesa delle negoziazioni con i pagatori. Questa analisi supporta la dashboard Audit conformità e rettifiche fatturazione.

Perché è importante

Spiega il 'perché' dietro le rettifiche delle entrate, aiutando a identificare le cause radice della perdita di ricavi, come problemi contrattuali, errori di fatturazione o fallimenti nella riscossione.

Dove trovare

Si tratta solitamente di un campo di testo o codice nello stesso record di transazione di AdjustmentAmount in R1 RCM.

Esempi
Contractual AllowanceCancellazione Credito InesigibileStorno di Saldo MinoreBilling Error Correction
Tempo di ciclo da prestazione a pagamento
ServiceToPaymentCycleTime
La durata totale calcolata dal momento in cui un servizio è stato prestato al momento in cui è stato registrato il pagamento finale.
Descrizione

Questa metrica misura la durata end-to-end del ciclo del fatturato per un singolo evento di fatturazione. Rappresenta il tempo totale impiegato da un'organizzazione per convertire un servizio fornito in cassa.

Questo è un indicatore chiave di prestazione (KPI) critico per la salute finanziaria. Analizzare questa durata aiuta a identificare le aree principali per l'accelerazione del processo. Scomponendo il tempo di ciclo nelle sue parti costitutive, come "tempo per fatturare" e "tempo per incassare", le organizzazioni possono individuare le maggiori opportunità per migliorare il cash flow.

Perché è importante

Si tratta di un KPI critico di alto livello che misura l'efficienza complessiva del ciclo di conversione della cassa, con un impatto diretto sul cash flow dell'organizzazione.

Dove trovare

Questa è una metrica calcolata. È la differenza temporale tra il timestamp dell'attività "Servizio prestato" e l'attività "Pagamento registrato" per un determinato evento di fatturazione.

Esempi
35 giorni 8 ore92 giorni 4 ore15 giorni 12 ore
Obbligatorio Consigliato Facoltativo

Attività di gestione del ciclo del fatturato

Questi sono i passaggi chiave del processo e le pietre miliari da acquisire nel Suo Event Log per una Process Discovery accurata nella gestione del ciclo del fatturato.
6 Consigliato 8 Facoltativo
Activity Descrizione
Account Closed
L'evento di fatturazione è completamente risolto con un saldo pari a zero e l'account viene formalmente chiuso. Ciò segna il completamento con successo del ciclo del fatturato per questo specifico incontro.
Perché è importante

Questo è l'evento finale principale del percorso ideale del processo. Misurare il tempo di ciclo della chiusura dell'account aiuta a garantire che i task amministrativi siano completati in modo efficiente e che i record siano finalizzati.

Dove trovare

Questo evento viene dedotto quando il saldo dell'account raggiunge lo zero e viene applicato uno stato finale di "Chiuso" o "Pagato interamente". Il timestamp viene preso dall'ultima transazione finanziaria che ha azzerato il saldo.

Acquisisci

Dedotto quando il saldo del conto diventa zero e viene applicato lo stato 'Closed', insieme a un timestamp di attività finale.

Tipo di evento inferred
Charges Captured
Questa attività segna la registrazione formale di tutti i servizi, le procedure e le forniture fatturabili per un incontro con il paziente. È una fase critica di inserimento dati che traduce le attività cliniche in transazioni finanziarie.
Perché è importante

Segna il passaggio dalle operazioni cliniche a quelle finanziarie. È il punto di partenza per misurare i tempi di ciclo della generazione di fatture e richieste e aiuta a identificare gli arretrati nell'inserimento degli addebiti.

Dove trovare

Rilevato all'interno del modulo di inserimento addebiti di R1 RCM o ricevuto tramite un'interfaccia da un EHR. L'evento è solitamente contrassegnato da un log di transazione specifico o dal timestamp di creazione del record di addebito.

Acquisisci

Identificato dal timestamp di creazione del record di transazione dell'addebito nella tabella di fatturazione.

Tipo di evento explicit
Pagamento Registrato
Il pagamento ricevuto viene applicato ufficialmente all'account del paziente, riducendo il saldo residuo. Questa è la fase finale della riconciliazione di un pagamento con i servizi fatturati.
Perché è importante

Questa attività costituisce il punto finale per il calcolo dei tempi di ciclo da prestazione a pagamento e registrazione del pagamento. Conferma che il ricavo è riconosciuto e gli account sono aggiornati accuratamente.

Dove trovare

Viene registrato come una transazione finanziaria esplicita nel modulo di contabilità pazienti di R1 RCM. Ogni registrazione include una data, un importo e una sorgente.

Acquisisci

Registrato come una transazione specifica con una data di registrazione quando un utente o un processo automatizzato applica il pagamento.

Tipo di evento explicit
Pagamento ricevuto
Viene ricevuto un pagamento da un pagatore o da un paziente. Questo evento segna la ricezione dei fondi, che però non sono ancora stati applicati allo specifico conto o alle linee di servizio.
Perché è importante

Rappresenta l'afflusso di cassa. Il divario temporale tra "Pagamento ricevuto" e "Pagamento registrato" è una metrica chiave per comprendere l'efficienza del back-office e i ritardi nella riconciliazione della cassa.

Dove trovare

Rilevato dai file di rimesse elettroniche dei pagatori o dall'elaborazione dei pagamenti dei pazienti. L'evento corrisponde alla data di deposito o alla data di ricezione del file.

Acquisisci

Registrato dalla data effettiva di pagamento del file ERA o dalla data della transazione di un pagamento di un paziente.

Tipo di evento explicit
Servizio Erogato
Rappresenta il momento in cui viene completato un servizio o una procedura fatturabile per un paziente. Questo evento viene spesso acquisito da un sistema clinico o di pianificazione e funge da trigger per il ciclo del fatturato.
Perché è importante

Questo è il punto di partenza per il KPI del tempo di ciclo da prestazione a pagamento. L'analisi del tempo a partire da questo evento aiuta a identificare i ritardi iniziali nel ciclo del fatturato.

Dove trovare

Solitamente proviene da una cartella clinica elettronica (EHR) o da un sistema di gestione dello studio integrato con R1 RCM. Viene spesso dedotto da un timestamp "Data servizio" o "Procedura completata" nel record del paziente.

Acquisisci

Dedotto dal timestamp 'Date of Service' associato all'incontro con il paziente.

Tipo di evento inferred
Sinistro Inviato
La richiesta generata viene inviata elettronicamente al pagatore responsabile, come una compagnia assicurativa. Questo segna la prima comunicazione esterna nel processo di fatturazione per ottenere il rimborso.
Perché è importante

Una pietra miliare critica che avvia il conteggio dei tempi per il rimborso del pagatore. Monitorare questo evento aiuta a controllare gli arretrati delle sottomissioni e garantisce il rispetto dei termini di invio con i pagatori.

Dove trovare

Questo evento viene registrato come una transazione esplicita quando la richiesta viene trasmessa a un clearinghouse. Il sistema registra il timestamp dell'invio e i dettagli della conferma.

Acquisisci

Registrato esplicitamente come transazione con un timestamp di sottomissione quando la richiesta viene inviata tramite il clearinghouse.

Tipo di evento explicit
Account Adjustment Made
Sul conto viene registrata una transazione non di pagamento per modificare il saldo. Questa può includere rettifiche contrattuali basate sugli accordi con i pagatori, storni di piccoli saldi o correzioni.
Perché è importante

Volumi elevati di rettifiche possono indicare problemi con i tariffari, la gestione dei contratti o errori di fatturazione. Monitorare le rettifiche è fondamentale per analizzare l'integrità delle entrate.

Dove trovare

Registrato come un tipo di transazione specifico nel modulo di contabilità pazienti di R1 RCM. Ogni rettifica ha un codice, un importo e una data di registrazione.

Acquisisci

Registrato come una transazione di rettifica distinta, identificabile da un codice transazione univoco.

Tipo di evento explicit
Account classificato come credito inesigibile
Tutti gli sforzi di riscossione sono stati esauriti e il saldo rimanente del conto è considerato inesigibile. Il saldo viene stornato come credito inesigibile, rappresentando una perdita definitiva di entrate.
Perché è importante

Questo rappresenta un esito negativo del processo e una perdita diretta di entrate. Analizzare quali casi finiscono in crediti inesigibili può rivelare pattern nei mancati pagamenti e opportunità per migliorare il recupero crediti.

Dove trovare

Si tratta solitamente di una transazione esplicita in R1 RCM in cui il saldo residuo viene spostato in una specifica categoria di crediti inesigibili, spesso attivata da un utente o da regole di aging automatizzate.

Acquisisci

Registrato come una transazione finanziaria specifica per stornare il saldo, spesso associata a un trasferimento a un'agenzia di riscossione esterna.

Tipo di evento explicit
Collection Activity Started
L'account del paziente è diventato moroso e vengono avviate attività di recupero proattive. Queste possono variare da lettere di sollecito automatiche all'assegnazione a uno specialista del recupero crediti.
Perché è importante

Segna l'inizio del processo di riscossione, ad alta intensità di costi. Analizzare l'efficacia e il tempo di ciclo di queste attività aiuta a ottimizzare le strategie per il recupero dei crediti inesigibili.

Dove trovare

Questo evento è probabilmente registrato o dedotto da un cambio di stato quando un account viene spostato in una coda di lavoro di recupero crediti o gli viene assegnato un codice di stato di recupero all'interno di R1 RCM.

Acquisisci

Dedotto da un cambiamento di stato sul conto in 'Collections' o 'Delinquent'.

Tipo di evento inferred
Denial Rework Started
Un utente o un workflow automatizzato inizia a esaminare e risolvere una richiesta respinta. Questo può comportare la correzione della codifica, l'invio di documentazione o il ricorso contro la decisione del pagatore.
Perché è importante

Traccia l'inizio del costoso loop di rilavorazione per le richieste rifiutate. Misurare il tempo trascorso in questa fase è fondamentale per comprendere l'efficienza del team di gestione dei rifiuti.

Dove trovare

Questo evento viene spesso dedotto da un cambiamento nello stato della richiesta rifiutata in "Rilavorazione in corso" o "In revisione" all'interno di una coda di lavoro R1 RCM o di un modulo di gestione dei rifiuti.

Acquisisci

Dedotto da un cambiamento di stato in una coda di lavoro di gestione dei rifiuti o dalla prima azione dell'utente su una richiesta respinta.

Tipo di evento inferred
Patient Statement Generated
Dopo la liquidazione dell'assicurazione, viene creato un estratto conto per il paziente che dettaglia il saldo rimanente a suo carico. Questo può riguardare ticket, franchigie o servizi non coperti.
Perché è importante

Questa attività avvia la parte del ciclo del fatturato relativa al pagamento del paziente. Analizzarne tempistiche e frequenza è importante per gestire il recupero crediti dai pazienti e il cash flow.

Dove trovare

Solitamente acquisito come un evento registrato quando viene eseguito un processo batch per creare e stampare o inviare elettronicamente gli estratti conto dei pazienti. R1 RCM registrerebbe la data in cui l'estratto conto è stato generato.

Acquisisci

Registrato come transazione quando viene eseguito il processo batch per generare gli estratti conto dei pazienti.

Tipo di evento explicit
Payer Adjudication Received
Il sistema riceve una risposta dal pagatore in merito alla richiesta inviata, spesso in un file Electronic Remittance Advice (ERA). Questa risposta specifica cosa è stato pagato, rifiutato o rettificato.
Perché è importante

Questo evento è un bivio cruciale nel processo, che determina se la fase successiva sarà la registrazione del pagamento o la gestione del rifiuto. Analizzare questo aspetto aiuta a comprendere il comportamento del pagatore e la velocità dei pagamenti.

Dove trovare

Rilevato quando un file di rimessa elettronica, come un file ANSI 835, del pagatore viene elaborato da R1 RCM. L'evento è contrassegnato dal timestamp di elaborazione di questo file.

Acquisisci

Registrato all'acquisizione e all'elaborazione del file Electronic Remittance Advice (ERA/835).

Tipo di evento explicit
Sinistro Creato
Nel sistema viene generata una richiesta di fatturazione formale basata sugli addebiti registrati. Ciò comporta la compilazione di dati anagrafici del paziente, informazioni assicurative e codici di servizio in un formato standardizzato.
Perché è importante

Questa è una pietra miliare interna fondamentale prima dell'invio esterno. I ritardi qui possono indicare problemi di codifica, validazione dei dati o configurazione del sistema che rallentano l'intero processo di fatturazione.

Dove trovare

Questo è un evento di sistema interno a R1 RCM. Viene probabilmente acquisito come un cambio di stato sull'account di fatturazione o tramite il timestamp di creazione dell'entità della richiesta stessa.

Acquisisci

Dedotto dal cambiamento di stato in 'Claim Generated' o dal timestamp di creazione del record della richiesta.

Tipo di evento inferred
Sinistro Negato
Il pagatore si è rifiutato di pagare la richiesta, in tutto o per voci specifiche. Viene acquisito il motivo del rifiuto, avviando un processo di rilavorazione e ricorso.
Perché è importante

Questa attività evidenzia la dispersione dei ricavi e l'inefficienza del processo. L'analisi dei motivi di rifiuto è essenziale per identificare le cause radice e migliorare i tassi di accettazione delle richieste al primo invio.

Dove trovare

Questo non è un evento discreto, ma piuttosto uno stato dedotto dai dettagli all'interno di un file ERA elaborato. Specifici codici di rifiuto all'interno dei dati della rimessa attivano un cambio di stato della richiesta.

Acquisisci

Dedotto dai codici di rifiuto presenti nel file ERA elaborato, che cambiano lo stato della richiesta in 'Denied'.

Tipo di evento inferred
Consigliato Facoltativo

Guide all'Estrazione

Come ottenere i dati da R1 RCM