Il Suo template dati per la gestione del ciclo del fatturato
Il Suo template dati per la gestione del ciclo del fatturato
- Attributi consigliati da raccogliere
- Attività chiave da tracciare per la scoperta dei processi
- Guida dettagliata all'estrazione per R1 RCM
Attributi di gestione del ciclo del fatturato
| 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 | |||
Attività di gestione del ciclo del fatturato
| 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 | |||
Guide all'Estrazione
Fasi
- Effettui l'accesso alla piattaforma R1 RCM con un account utente che abbia i permessi per accedere ai moduli di business intelligence o di reporting.
- Navighi nella sezione reporting della piattaforma. Potrebbe essere etichettata come "Business Intelligence", "Reporting Portal" o "Analytics".
- Individui lo strumento per creare un nuovo report o una query personalizzata. Questo le consente di definire i campi dati specifici e la logica per l'estrazione.
- Poiché R1 RCM non fornisce un log eventi predefinito e unificato, deve costruirne uno combinando dati da diverse fonti. La configurazione della query fornita utilizza un approccio UNION ALL per unire gli eventi di vari oggetti aziendali in un unico log cronologico.
- Copi la query completa fornita nella sezione "Query" di questo documento e la incolli nell'editor di query o nell'interfaccia di configurazione del report personalizzato.
- Configuri i parametri del report, in particolare l'intervallo di date. Imposti i segnaposto
'{StartDate}'e'{EndDate}'nella query per definire il periodo di tempo per l'estrazione, ad esempio gli ultimi 6 mesi. - Aggiunga altri filtri necessari alla configurazione del report, come il filtraggio per strutture, dipartimenti o gruppi di pagatori specifici per limitare l'ambito dei dati.
- Esegua il report. Questo avvierà la query sul database R1 RCM e genererà i risultati in base ai parametri specificati.
- Una volta completata l'esecuzione del report, cerchi l'opzione per esportare i dati. Selezioni CSV (Comma Separated Values) come formato di esportazione, poiché è direttamente compatibile con ProcessMind.
- Scarichi il file CSV generato e lo apra per un rapido controllo. Si assicuri che le intestazioni delle colonne corrispondano agli attributi richiesti:
BillingEvent,ActivityName,EventTime,SourceSystemeLastDataUpdate. - Verifichi che i formati di data e ora nelle colonne
EventTimeeLastDataUpdatesiano coerenti prima di caricare il file su ProcessMind.
Configurazione
- Prerequisiti: È necessario un account utente con permessi sufficienti per accedere e creare report personalizzati all'interno del modulo Business Intelligence di R1 RCM.
- Tipo di Report: Utilizzi una query personalizzata o un generatore di report avanzato che consenta il recupero di dati complessi e l'uso di istruzioni UNION ALL per combinare diversi set di dati.
- Intervallo di Date: Per gestire le prestazioni e il volume dei dati, è fondamentale filtrare per un periodo di tempo specifico. Consigliamo di iniziare con una finestra da 3 a 6 mesi per l'analisi iniziale. Applichi il filtro data al campo timestamp principale di ogni attività.
- Filtri Chiave: Oltre all'intervallo di date, consideri l'applicazione di filtri per
Facility ID,Payer TypeoBilling Departmentper focalizzare l'analisi su aree operative specifiche e ridurre le dimensioni dell'esportazione. - Formato di Esportazione: Selezioni sempre CSV come formato di output. Questo garantisce un file pulito e strutturato che può essere facilmente analizzato dagli strumenti di process mining.
- Pianificazione: Se il modulo di reporting R1 RCM lo consente, valuti di pianificare l'esecuzione periodica di questo report (ad esempio, settimanale o mensile) per automatizzare l'aggiornamento dei dati per il monitoraggio continuo.
a Query di Esempio config
SELECT
c.ClaimID AS BillingEvent,
'Service Rendered' AS ActivityName,
c.ServiceDate AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
c.ClinicianID AS AssignedUser,
d.DepartmentName AS BillingDepartment,
c.TotalChargeAmount AS InvoiceAmount,
p.PayerName AS PayerName,
'Rendered' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [ServiceAndChargeData] c
JOIN [Departments] d ON c.DepartmentID = d.DepartmentID
JOIN [Payers] p ON c.PayerID = p.PayerID
WHERE c.ServiceDate BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
c.ClaimID AS BillingEvent,
'Charges Captured' AS ActivityName,
c.ChargeEntryTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
c.ChargeEntryUserID AS AssignedUser,
d.DepartmentName AS BillingDepartment,
c.TotalChargeAmount AS InvoiceAmount,
p.PayerName AS PayerName,
'Open' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [ServiceAndChargeData] c
JOIN [Departments] d ON c.DepartmentID = d.DepartmentID
JOIN [Payers] p ON c.PayerID = p.PayerID
WHERE c.ChargeEntryTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
cl.ClaimID AS BillingEvent,
'Claim Created' AS ActivityName,
cl.CreationTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
cl.CreatedByUserID AS AssignedUser,
cl.BillingDepartment AS BillingDepartment,
cl.TotalAmount AS InvoiceAmount,
cl.PayerName AS PayerName,
'Created' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [ClaimsData] cl
WHERE cl.CreationTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
cl.ClaimID AS BillingEvent,
'Claim Submitted' AS ActivityName,
cl.SubmissionTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
cl.SubmittedByUserID AS AssignedUser,
cl.BillingDepartment AS BillingDepartment,
cl.TotalAmount AS InvoiceAmount,
cl.PayerName AS PayerName,
'Submitted' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [ClaimsData] cl
WHERE cl.SubmissionTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
era.ClaimID AS BillingEvent,
'Payer Adjudication Received' AS ActivityName,
era.ReceivedTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
'System' AS AssignedUser,
pa.BillingDepartment AS BillingDepartment,
pa.InvoiceAmount AS InvoiceAmount,
era.PayerName AS PayerName,
'Adjudicated' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [RemittanceAdvice] era
JOIN [PatientAccounts] pa ON era.ClaimID = pa.BillingEvent
WHERE era.ReceivedTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
d.ClaimID AS BillingEvent,
'Claim Denied' AS ActivityName,
d.DenialTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
'System' AS AssignedUser,
cl.BillingDepartment AS BillingDepartment,
cl.TotalAmount AS InvoiceAmount,
cl.PayerName AS PayerName,
'Denied' AS InvoiceStatus,
d.ReasonCode AS DenialReasonCode
FROM [DenialsLog] d
JOIN [ClaimsData] cl ON d.ClaimID = cl.ClaimID
WHERE d.DenialTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
dr.ClaimID AS BillingEvent,
'Denial Rework Started' AS ActivityName,
dr.ReworkStartTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
dr.AssignedUserID AS AssignedUser,
cl.BillingDepartment AS BillingDepartment,
cl.TotalAmount AS InvoiceAmount,
cl.PayerName AS PayerName,
'In Rework' AS InvoiceStatus,
dr.OriginalDenialCode AS DenialReasonCode
FROM [DenialRework] dr
JOIN [ClaimsData] cl ON dr.ClaimID = cl.ClaimID
WHERE dr.ReworkStartTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
ps.PatientAccountID AS BillingEvent,
'Patient Statement Generated' AS ActivityName,
ps.GenerationTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
ps.GeneratedByUserID AS AssignedUser,
pa.BillingDepartment AS BillingDepartment,
ps.StatementBalance AS InvoiceAmount,
'Patient' AS PayerName,
'Patient Billed' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [PatientStatements] ps
JOIN [PatientAccounts] pa ON ps.PatientAccountID = pa.BillingEvent
WHERE ps.GenerationTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
p.AssociatedClaimID AS BillingEvent,
'Payment Received' AS ActivityName,
p.ReceiptTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
p.ProcessedByUserID AS AssignedUser,
pa.BillingDepartment AS BillingDepartment,
p.PaymentAmount AS InvoiceAmount,
p.PayerName AS PayerName,
'Payment Pending' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [PaymentsLog] p
JOIN [PatientAccounts] pa ON p.AssociatedClaimID = pa.BillingEvent
WHERE p.ReceiptTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
pt.ClaimID AS BillingEvent,
'Payment Posted' AS ActivityName,
pt.PostingTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
pt.PostedByUserID AS AssignedUser,
pa.BillingDepartment AS BillingDepartment,
pt.PostedAmount AS InvoiceAmount,
pt.PayerName AS PayerName,
'Partially Paid' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [PaymentTransactions] pt
JOIN [PatientAccounts] pa ON pt.ClaimID = pa.BillingEvent
WHERE pt.PostingTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
a.ClaimID AS BillingEvent,
'Account Adjustment Made' AS ActivityName,
a.AdjustmentTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
a.AdjusterID AS AssignedUser,
pa.BillingDepartment AS BillingDepartment,
a.AdjustmentAmount AS InvoiceAmount,
pa.PayerName AS PayerName,
'Adjusted' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [Adjustments] a
JOIN [PatientAccounts] pa ON a.ClaimID = pa.BillingEvent
WHERE a.AdjustmentTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
ca.PatientAccountID AS BillingEvent,
'Collection Activity Started' AS ActivityName,
ca.ActivityTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
ca.AssignedAgentID AS AssignedUser,
'Collections' AS BillingDepartment,
pa.CurrentBalance AS InvoiceAmount,
'Patient' AS PayerName,
'In Collections' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [CollectionsActivity] ca
JOIN [PatientAccounts] pa ON ca.PatientAccountID = pa.BillingEvent
WHERE ca.ActivityTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
pa.BillingEvent AS BillingEvent,
'Account Placed in Bad Debt' AS ActivityName,
pa.BadDebtPlacementDate AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
pa.BadDebtUserID AS AssignedUser,
'Finance' AS BillingDepartment,
pa.CurrentBalance AS InvoiceAmount,
'Patient' AS PayerName,
'Bad Debt' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [PatientAccounts] pa
WHERE pa.BadDebtPlacementDate BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
pa.BillingEvent AS BillingEvent,
'Account Closed' AS ActivityName,
pa.ClosureDate AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
'System' AS AssignedUser,
pa.BillingDepartment AS BillingDepartment,
0 AS InvoiceAmount,
pa.PayerName AS PayerName,
'Closed' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [PatientAccounts] pa
WHERE pa.ClosureDate BETWEEN '{StartDate}' AND '{EndDate}' AND pa.CurrentBalance = 0;