Il vostro template dei dati per la Gestione del Ciclo del Reddito
Il vostro template dei dati per la Gestione del Ciclo del Reddito
- Attributi consigliati da raccogliere
- Attività chiave da tracciare
- Guida all'estrazione
Attributi del Revenue Cycle Management
| Nome | Descrizione | ||
|---|---|---|---|
| Evento di fatturazione BillingEvent | L'identificatore univoco per l'erogazione di un singolo servizio o prodotto che genera un addebito, utilizzato come ID del caso primario. | ||
| Descrizione L'Evento di Fatturazione funge da identificatore primario del caso, collegando tutte le attività relative a un singolo servizio fornito o prodotto consegnato che genera un addebito. Ciò consente un monitoraggio completo del ciclo di vita della generazione dei ricavi e dell'incasso per ogni singola voce o servizio fatturabile. Nel Process Mining, l'analisi del processo per Evento di Fatturazione permette alle organizzazioni di visualizzare l'intero percorso end-to-end, dall'erogazione del servizio al pagamento finale o alla chiusura del conto. Questa visione è cruciale per identificare i bottleneck, misurare i tempi di ciclo e comprendere le variazioni nella gestione delle diverse richieste di rimborso o fatture. Perché è importante Questo è l'ID del caso essenziale che collega tutte le attività correlate del ciclo del reddito, consentendo una visione completa ed end-to-end del processo per l'analisi. Dove trovare Questa è la chiave primaria che collega i record nelle tabelle principali di fatturazione e pratiche di Optum360. Consultare la documentazione di Optum360 per i nomi specifici delle tabelle e dei campi. Esempi BE-2023-0012345BE-2023-0012346BE-2023-0012347 | |||
| Nome attività ActivityName | Il nome di uno specifico evento o task verificatosi all'interno del processo di Gestione del Ciclo del Reddito. | ||
| Descrizione Il Nome dell'Attività descrive una fase del processo del ciclo dei ricavi, come 'Richiesta presentata al pagatore' o 'Pagamento ricevuto'. Questo attributo è fondamentale per il Process Mining, poiché definisce i nodi nella mappa del processo. Analizzando la sequenza e la frequenza delle attività, le organizzazioni possono visualizzare il flusso reale del processo, identificare le deviazioni dalla procedura standard e individuare i comuni cicli di rework. Questa analisi è fondamentale per comprendere le inefficienze del processo e i problemi di conformità. Perché è importante Questo attributo definisce le singole fasi del processo, costituendo la base della mappa del processo e consentendo tutte le analisi basate sul flusso. Dove trovare In genere deriva dagli Event Log, dai record di cambio di stato o da codici di transazione specifici all'interno delle tabelle operative di Optum360. Esempi Sinistro CreatoPratica presentata al pagatorePagamento ricevutoDiniego ricevutoPratica chiusa | |||
| Timestamp Evento EventTime | Il timestamp che indica quando una specifica attività o un evento si è verificato. | ||
| Descrizione L'Ora dell'Evento è il timestamp associato a ciascuna attività, che ne indica la data e l'ora precise. Questi dati temporali sono essenziali per costruire la sequenza cronologica degli eventi per ogni caso. Nell'analisi, l'Ora dell'Evento viene utilizzata per calcolare i tempi di ciclo tra le attività, misurare la durata del caso e identificare i colli di bottiglia dove si trascorre molto tempo in attesa. Rappresenta la spina dorsale di qualsiasi analisi di processo basata sul tempo e della misurazione delle prestazioni. Perché è importante Questo timestamp è fondamentale per sequenziare correttamente gli eventi e calcolare tutte le metriche basate sulla durata, come tempi di ciclo e colli di bottiglia. Dove trovare Queste informazioni sono solitamente memorizzate insieme a ogni transazione o record di cambio di stato nelle tabelle del database di Optum360. Esempi 2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:22:00Z | |||
| Codice motivo diniego DenialReasonCode | Un codice standard fornito dal pagatore che spiega il motivo del diniego di una richiesta. | ||
| Descrizione Quando un payer rifiuta una richiesta di rimborso, fornisce un Codice Motivo del Rifiuto (Denial Reason Code) che spiega il problema, come 'Servizio non coperto' o 'Pratica duplicata'. Questi codici sono fondamentali per comprendere le cause profonde dei ritardi nei ricavi e della rielaborazione delle pratiche. L'analisi di questi codici consente al team di gestione dei rifiuti di dare priorità al proprio lavoro, identificare le tendenze e implementare azioni correttive. Ad esempio, un'alta frequenza di rifiuti per 'Informazioni mancanti' può indicare un problema nel processo di creazione delle pratiche. Questa analisi è centrale per ridurre il tasso di rifiuto e accelerare il flusso di cassa. Perché è importante Fornisce la causa profonda dei dinieghi delle richieste, consentendo interventi mirati per prevenire futuri dinieghi e ridurre i costosi rework. Dove trovare Questo codice è incluso nei file ERA ricevuti dai payer ed è memorizzato nel modulo di gestione delle pratiche di Optum360. Esempi CO-16: Informazioni mancanti nella richiesta/servizioPR-97: Il beneficio per questo servizio è incluso nel pagamento/indennità per un altro servizio/proceduraOA-18: Richiesta/servizio duplicato | |||
| Dipartimento Fatturazione BillingDepartment | Il dipartimento interno o il team che ha gestito o eseguito l'attività di fatturazione. | ||
| Descrizione L'attributo Dipartimento di Fatturazione identifica il team specifico o l'area funzionale responsabile di un'attività all'interno del ciclo del reddito. Ad esempio, team diversi potrebbero occuparsi della codifica, della presentazione delle richieste di rimborso o della gestione dei rifiuti (denial management). Questo attributo è essenziale per il benchmarking delle prestazioni, come richiesto dalla dashboard 'Billing Department Performance Benchmarks'. Consente alla direzione di confrontare l'efficienza, la velocità e l'accuratezza dei vari team, identificando le best practice e allocando le risorse in modo efficace per colmare eventuali lacune prestazionali. Perché è importante Consente il confronto delle prestazioni tra diversi team di fatturazione, aiutando a identificare i gruppi più performanti e le aree che necessitano di miglioramenti. Dove trovare Questo valore può derivare dall'utente che esegue il task o da un campo sul conto che indica la proprietà. Consultare la documentazione di Optum360. Esempi Ufficio fatturazione centraleTeam gestione dinieghiUfficio codificaServizi finanziari pazienti | |||
| ID Pagatore PayerId | L'identificatore univoco della compagnia assicurativa o del payer responsabile della pratica. | ||
| Descrizione L'ID del Payer identifica la specifica compagnia assicurativa, il programma governativo (come Medicare o Medicaid) o un altro ente responsabile del pagamento della pratica. Ogni payer ha spesso le proprie regole, requisiti di invio e comportamenti di pagamento. Analizzare il processo per ID Payer è fondamentale per la gestione del ciclo del reddito (RCM). Aiuta a identificare quali payer hanno i cicli di pagamento più lunghi, i tassi di rifiuto più elevati o i processi di ricorso più complessi. Queste informazioni consentono ai dipartimenti di fatturazione di adattare le proprie strategie ai diversi payer per accelerare gli incassi e ridurre il carico amministrativo. Perché è importante Segmentare il processo per pagatore è essenziale per identificare quali pagatori causano ritardi o dinieghi, consentendo miglioramenti mirati nella gestione dei pagatori. Dove trovare Queste informazioni sono memorizzate in ogni record della pratica in Optum360. Consultare la documentazione di Optum360 per i nomi delle tabelle e dei campi relativi ai payer. Esempi PAYER-AETNAPAYER-BCBS-MAPAYER-MEDICAREPAYER-UHC | |||
| ID Paziente PatientId | L'identificatore univoco del paziente che ha ricevuto i servizi. | ||
| Descrizione L'ID Paziente è un identificatore univoco assegnato a ogni paziente all'interno del sistema sanitario. Collega più eventi di fatturazione a un singolo paziente, consentendo un'analisi incentrata sulla persona. Utilizzando l'ID Paziente, gli analisti possono esaminare modelli relativi a pazienti specifici, come riammissioni frequenti o una cronologia di rifiuti delle richieste di rimborso. Consente inoltre di segmentare il processo in base ai dati demografici o alla storia del paziente, rivelando insight preziosi per migliorare l'esperienza finanziaria dell'utente. Perché è importante Consente un'analisi incentrata sul paziente, aiutando a comprendere il percorso finanziario end-to-end e a identificare pattern per specifiche popolazioni di pazienti. Dove trovare Questo identificatore è un campo fondamentale nelle anagrafiche dei pazienti e nelle tabelle delle transazioni di Optum360. Consultare la documentazione di Optum360 per i dettagli. Esempi PAT-98765PAT-98766PAT-98767 | |||
| Importo Fatturato BilledAmount | Il valore monetario totale di tutti gli addebiti presentati nella richiesta di rimborso o in fattura. | ||
| Descrizione L'Importo Fatturato rappresenta l'addebito lordo per i servizi resi, prima di eventuali pagamenti, rettifiche o storni. È il valore iniziale del credito per l'evento di fatturazione. Questo attributo è fondamentale per l'analisi finanziaria nel Process Mining. Viene utilizzato per calcolare KPI chiave come il Tasso di Rettifica dei Ricavi e consente di segmentare i casi per valore per verificare se le pratiche di alto valore vengono elaborate diversamente o subiscono più ritardi rispetto a quelle di basso valore. Perché è importante Fornisce il contesto finanziario per ogni caso, consentendo analisi basate sul valore e il calcolo di KPI finanziari critici. Dove trovare Questo è un campo standard su ogni pratica o conto paziente all'interno delle tabelle finanziarie di Optum360. Esempi 150.001250.7585.50 | |||
| Importo rettificato AdjustedAmount | Il valore monetario degli storni, delle rettifiche contrattuali o delle correzioni apportate all'importo fatturato. | ||
| Descrizione L'Importo Rettificato rappresenta la quota dell'importo fatturato che non si prevede di incassare a causa di accordi contrattuali con i payer, correzioni di fatturazione o altri storni. Si tratta di una riduzione diretta dei ricavi. Questo attributo è fondamentale per la dashboard 'Revenue Adjustment Impact' e per il KPI 'Revenue Adjustment Rate'. L'analisi delle rettifiche aiuta a identificare l'impatto finanziario dei contratti con i payer e a individuare opportunità per ridurre al minimo la perdita di ricavi (revenue leakage) migliorando l'accuratezza della fatturazione o la negoziazione dei contratti. Perché è importante Misura direttamente la perdita di ricavi ed è fondamentale per calcolare i KPI di performance finanziaria e comprendere la redditività. Dove trovare Queste informazioni si trovano nei record delle transazioni di rettifica all'interno del sistema finanziario di Optum360. Esempi 30.00250.2510.00 | |||
| Codice servizio ServiceCode | Il codice procedurale (es. CPT, HCPCS) che identifica lo specifico servizio erogato. | ||
| Descrizione Il Codice Servizio è un codice medico standardizzato che identifica con precisione la procedura o il servizio fornito al paziente. Questi codici sono necessari per la fatturazione e rappresentano il fattore determinante per il rimborso. L'analisi del processo per Codice Servizio può rivelare che determinate procedure sono più soggette a rifiuti, richiedono maggiore documentazione o presentano cicli di pagamento più lunghi. Ciò consente una comprensione più granulare delle criticità del processo e può guidare le politiche di codifica e fatturazione per tipi specifici di servizi. Perché è importante Consente l'analisi in base al tipo di servizio medico, il che può rivelare pattern di dinieghi o ritardi nei pagamenti specifici per determinate procedure. Dove trovare Questo codice è una parte fondamentale dell'inserimento degli addebiti e dei record di dettaglio delle pratiche in Optum360. Esempi 992137104527447 | |||
| Durata del Caso CaseDuration | Il tempo di ciclo totale per un evento di fatturazione, dalla prima all'ultima attività. | ||
| Descrizione La Durata del Caso misura il tempo totale trascorso dal primo all'ultimo evento per un singolo Evento di Fatturazione. È un KPI di alto livello fondamentale per valutare l'efficienza complessiva del processo. Questa metrica alimenta direttamente la dashboard 'Panoramica tempi di ciclo RCM End-to-End' e il KPI 'Tempo di ciclo medio RCM'. Il monitoraggio nel tempo consente alla dirigenza di verificare l'impatto delle iniziative di miglioramento sull'intero ciclo dei ricavi. Perché è importante Rappresenta il tempo di ciclo end-to-end del processo, un KPI critico per misurare la velocità e l'efficienza complessiva del processo. Dove trovare Questo valore viene calcolato sottraendo il timestamp del primo evento da quello dell'ultimo per ogni ID del caso univoco 'Evento di Fatturazione'. Esempi 30 giorni95 giorni45 giorni | |||
| È una Rilavorazione IsRework | Un indicatore che segnala se un'attività fa parte di un ciclo di rework, come la gestione dei dinieghi o i ricorsi. | ||
| Descrizione Is Rework è un indicatore booleano che identifica le attività considerate rework senza valore aggiunto, come 'Inizio rework diniego' o 'Ricorso presentato'. Queste attività si verificano solitamente quando il processo devia dal suo percorso ideale (happy path). Questo attributo aiuta a quantificare la quantità di rework nel processo, che è un indicatore diretto di inefficienza e costo. Viene utilizzato per calcolare il KPI 'Tasso di rework per errori di fatturazione' e supporta la dashboard 'Identificazione colli di bottiglia e loop di rework' facilitando il filtraggio e la visualizzazione di questi cicli inefficienti. Perché è importante Aiuta a quantificare l'inefficienza del processo contrassegnando le attività che rappresentano un rework, rendendo più facile misurare e colpire gli sprechi. Dove trovare Questo dato viene solitamente derivato tramite la logica di business all'interno dello strumento di Process Mining. Ad esempio, qualsiasi attività successiva a un evento 'Rifiuto ricevuto' potrebbe essere contrassegnata come rielaborazione. Esempi truefalse | |||
| Fornitore di Servizi ServiceProvider | Il medico, il dipartimento o la struttura che ha erogato il servizio fatturabile. | ||
| Descrizione Questo attributo identifica lo specifico fornitore, come un medico, un terapista o un reparto ospedaliero, responsabile dell'erogazione del servizio. Fornitori diversi possono avere modelli di fatturazione o abitudini di documentazione differenti che influenzano il ciclo del reddito. L'analisi per Fornitore del Servizio può aiutare a individuare problemi relativi all'acquisizione degli addebiti, all'accuratezza della codifica o alla qualità della documentazione che hanno origine nel punto di assistenza. Può evidenziare opportunità di formazione per i fornitori o miglioramenti dei processi per garantire che le richieste di rimborso siano generate correttamente fin dall'inizio. Perché è importante Aiuta a rintracciare i problemi di fatturazione fino alla fonte, consentendo feedback e formazione mirati per il personale clinico per migliorare l'acquisizione degli addebiti e la documentazione. Dove trovare Questa informazione è una parte fondamentale del record dell'addebito o della pratica in Optum360, spesso collegata all'anagrafica dei fornitori. Esempi Dr. Emily CarterReparto radiologiaChirurgia GeneraleFisioterapia | |||
| Importo Pagato PaidAmount | Il valore monetario totale ricevuto dal payer e dal paziente per i servizi fatturati. | ||
| Descrizione L'Importo Pagato è la somma cumulativa di tutti i pagamenti registrati sul conto per uno specifico evento di fatturazione. Rappresenta l'effettivo denaro incassato ed è una misura primaria del successo del ciclo del reddito. Nell'analisi dei processi, il monitoraggio dell'importo pagato è essenziale per comprendere il flusso di cassa e la performance finanziaria complessiva. Può essere utilizzato per analizzare la velocità dei pagamenti e per confrontare gli importi fatturati con quelli riscossi, evidenziando problemi legati a sottopagamenti o crediti inesigibili. Perché è importante Rappresenta il contante effettivamente incassato, che è una metrica di risultato chiave per il processo RCM ed essenziale per l'analisi del flusso di cassa. Dove trovare Questo valore viene solitamente memorizzato nelle tabelle delle transazioni di pagamento o riepilogato a livello di conto in Optum360. Esempi 120.001000.500.00 | |||
| Ora di Fine EndTime | Il timestamp che indica quando un'attività è stata completata. | ||
| Descrizione L'Ora di Fine segna il completamento di un'attività. Mentre l'Ora di Inizio indica quando si è verificato un evento, l'Ora di Fine è necessaria per calcolare la durata delle attività che hanno un tempo di elaborazione distinto, come l'inizio e la fine della rielaborazione di una pratica rifiutata. Nell'analisi dei processi, il confronto tra Ora di Inizio e Ora di Fine consente di calcolare il tempo di elaborazione. Questo aiuta a distinguere tra il tempo di lavoro attivo (tempo di elaborazione) e il tempo di inattività (tempo di attesa tra le attività), fornendo una visione più dettagliata dell'efficienza dei processi. Perché è importante Consente il calcolo di tempi di elaborazione precisi per le attività, aiutando a distinguere il tempo di lavoro attivo dai tempi di attesa morti nel processo. Dove trovare Per alcune attività, questo potrebbe essere un campo timestamp separato nel sistema sorgente. Per altre, potrebbe dover essere dedotto dall'orario di inizio dell'attività successiva. Esempi 2023-10-26T10:15:00Z2023-10-26T11:45:00Z2023-10-27T15:00:00Z | |||
| Sistema di Origine SourceSystem | Il sistema o l'applicazione di origine in cui sono stati registrati i dati dell'evento. | ||
| Descrizione Questo attributo identifica il sistema di origine da cui sono stati estratti i dati per un particolare evento. In un panorama IT complesso, i dati RCM potrebbero provenire dalla piattaforma principale Optum360, da un sistema EHR interfacciato, da una clearinghouse o da un portale per i pazienti. Comprendere il sistema sorgente è utile per la validazione dei dati, la risoluzione dei problemi di integrazione e l'analisi delle variazioni di processo che potrebbero essere causate da diversi comportamenti del sistema o pratiche di inserimento dati. Perché è importante Identifica l'origine dei dati, fondamentale per la data governance, la valutazione della qualità e la comprensione delle variazioni di processo tra i diversi sistemi. Dove trovare Può essere un valore statico impostato durante l'estrazione dei dati o un campo all'interno delle tabelle sorgente che indica l'origine dei dati. Esempi Optum360EHR-InterfaceClearinghouse-APIPatient-Portal | |||
| Stato dell'Account AccountStatus | Lo stato attuale del conto di fatturazione all'interno del ciclo del reddito. | ||
| Descrizione Lo Stato della Pratica fornisce un'istantanea della fase in cui si trova un evento di fatturazione nel processo complessivo, ad esempio 'In attesa del pagatore', 'Saldato' o 'In recupero crediti'. Questo attributo contestualizza le attività svolte. È utile per filtrare e segmentare i casi concentrandosi su parti specifiche del processo. Ad esempio, analizzare tutte le pratiche attualmente 'In recupero crediti' può aiutare a comprenderne i fattori scatenanti e i volumi per quella specifica e costosa fase del processo, alimentando la dashboard 'Volumi e driver delle attività di recupero'. Perché è importante Fornisce un contesto di alto livello sullo stato attuale di un caso, consentendo il filtraggio e l'analisi di specifiche popolazioni di casi, come quelli in recupero crediti. Dove trovare Solitamente si tratta di un campo riepilogativo sul conto principale del paziente o sul record della pratica in Optum360. Esempi ApertoIn attesa del pagatorePagato per interoIn recupero creditiChiuso | |||
| Tempo di Elaborazione ProcessingTime | Il tempo impiegato per completare una specifica attività, calcolato dai timestamp di inizio e fine. | ||
| Descrizione Il Tempo di Elaborazione misura la durata di una singola attività, rappresentando il 'tempo di contatto' o il lavoro attivo svolto. Viene solitamente calcolato come differenza tra l'Ora di Fine e l'Ora di Inizio di un'attività. Questa metrica calcolata è fondamentale per distinguere tra il tempo trascorso lavorando attivamente su un compito rispetto al tempo trascorso in attesa della fase successiva. Nell'analisi dei colli di bottiglia, comprendere i tempi di elaborazione aiuta a determinare se un ritardo è dovuto a un'attività lunga o a una coda lunga, portando a miglioramenti del processo più efficaci. Perché è importante Misura il 'tempo di contatto' attivo per le attività, aiutando a distinguere il lavoro a valore aggiunto dai tempi di attesa inutili nell'analisi dei colli di bottiglia. Dove trovare Questo valore viene calcolato sottraendo l'ora di inizio ('EventTime' o StartTime) dall'ora di fine ('EndTime') per un determinato record di attività. Esempi 15 minuti2 ore1 giorno 4 ore | |||
| Ultimo `Data Update` LastDataUpdate | Il timestamp del più recente data refresh o estrazione dal sistema sorgente. | ||
| Descrizione Questo attributo registra la data e l'ora in cui i dati sono stati estratti per l'ultima volta dal sistema sorgente e caricati nello strumento di Process Mining. Fornisce il contesto sulla freschezza dei dati analizzati. Ciò è importante per consentire ad analisti e utenti aziendali di capire se stanno visualizzando le informazioni più aggiornate. Aiuta a gestire le aspettative sulla latenza dei dati e rappresenta un metadato chiave per qualsiasi progetto di analisi. Perché è importante Fornisce un contesto fondamentale sulla freschezza dei dati, assicurando che gli utenti comprendano quanto sia aggiornata l'analisi. Dove trovare Questo timestamp viene solitamente generato e memorizzato dal processo di estrazione, trasformazione e caricamento dei dati (ETL). Esempi 2023-11-01T02:00:00Z2023-11-02T02:00:00Z | |||
| Utente User | L'identificatore dell'utente o dell'agente di sistema che ha eseguito l'attività. | ||
| Descrizione L'attributo Utente identifica la persona fisica, il team o il bot automatizzato responsabile dell'esecuzione di una determinata attività. Ciò consente l'analisi delle prestazioni a livello individuale o di gruppo. Comprendere quale utente o team abbia eseguito un'azione è prezioso per valutare la produttività, la qualità e l'adesione alle procedure standard. Può aiutare a identificare le esigenze di formazione o a premiare gli individui e i team più performanti. Inoltre, permette di distinguere tra i task eseguiti manualmente e quelli gestiti dall'automazione. Perché è importante Attribuisce la responsabilità delle fasi del processo e consente l'analisi delle prestazioni per individuo o team, aspetto fondamentale per la gestione delle risorse e la formazione. Dove trovare Gli ID utente vengono solitamente acquisiti negli Audit Log o nella cronologia delle transazioni per i record in Optum360. Esempi j.doem.smithAutoBillerBots.jones | |||
Attività di Revenue Cycle Management
| Activity | Descrizione | ||
|---|---|---|---|
| Avviso di Pagamento Ricevuto | Il sistema ha ricevuto un file di notifica di pagamento elettronica (ERA) dal payer, contenente i dettagli di pagamenti, rettifiche e rifiuti. Si tratta di un evento esplicito acquisito quando il sistema elabora un file EDI 835. | ||
| Perché è importante Questa attività è una tappa fondamentale che indica che il payer ha elaborato la pratica. Il contenuto di questo file determina tutte le azioni successive, come la registrazione del pagamento o la gestione del rifiuto. Dove trovare Registrato nei log delle transazioni EDI per i file ANSI 835 in entrata. Il timestamp riflette il momento in cui il file è stato ricevuto ed elaborato dal sistema. Acquisisci Timestamp associato all'acquisizione del file EDI 835 (Notifica di pagamento elettronica). Tipo di evento explicit | |||
| Dati servizio ricevuti | Segna l'avvio dell'evento di fatturazione quando le informazioni sul servizio clinico vengono ricevute dalla cartella clinica elettronica (EHR) o da un altro sistema sorgente. Questo evento viene solitamente acquisito tramite una voce di log esplicita o un record di transazione creato da un'interfaccia di integrazione al momento dell'importazione corretta dei dati. | ||
| Perché è importante Questo è l'evento di inizio primario per il ciclo del reddito. Analizzare il tempo che intercorre tra questa attività e l'acquisizione dell'addebito è fondamentale per identificare i ritardi nei dati iniziali che influenzano l'intero processo. Dove trovare Registrato nei log di interfaccia o nelle tabelle di transazione che gestiscono i dati dei servizi pazienti in arrivo da sistemi esterni come un EHR. Cerchi i timestamp dei messaggi HL7 o i log delle chiamate API. Acquisisci Acquisito dai log di integrazione o dalle tabelle di transazione con timestamp al ricevimento dei dati. Tipo di evento explicit | |||
| Diniego ricevuto | Una richiesta di rimborso è stata respinta dal pagatore, come indicato nell'avviso di pagamento ricevuto. Questo evento viene dedotto analizzando i dati dell'avviso di pagamento per individuare specifici codici di errore associati alle voci della pratica. | ||
| Perché è importante Il monitoraggio dei rifiuti è fondamentale per identificare le cause alla radice delle perdite di ricavi e delle inefficienze dei processi. Questa attività è il punto di partenza per tutti i cicli di gestione dei rifiuti e di rielaborazione dei ricorsi. Dove trovare Dedotto dai dati dell'Electronic Remittance Advice (EDI 835). Il sistema identifica i codici motivo della rettifica della richiesta (CARC) che indicano un diniego. Acquisisci Dedotto rilevando codici di diniego specifici (CARC/RARC) nei dati di rimessa EDI 835 analizzati. Tipo di evento inferred | |||
| Pagamento Registrato | Un pagamento ricevuto è stato applicato con successo alla specifica pratica del paziente e alle linee di servizio. Si tratta di un'azione esplicita, utente o automatizzata, che riconcilia il pagamento con gli addebiti in sospeso. | ||
| Perché è importante Questa attività è fondamentale per misurare l'efficienza del processo di back-office per l'applicazione degli incassi. I ritardi nella registrazione possono falsare i report sui crediti verso clienti e ritardare la chiusura dei conti. Dove trovare Si trova nelle tabelle delle transazioni di pagamento. Il timestamp della transazione per l'azione di registrazione funge da ora dell'evento. Acquisisci Il timestamp di creazione del record della transazione di pagamento applicata a uno specifico addebito. Tipo di evento explicit | |||
| Pratica chiusa | L'evento di fatturazione è considerato concluso quando il saldo è pari a zero e non è prevista alcuna attività ulteriore. Questo evento viene dedotto quando il saldo del conto si azzera e lo stato dell'account viene aggiornato a 'Chiuso' o a uno stato finale simile. | ||
| Perché è importante Questo è l'evento finale primario del processo. Misurare il tempo di ciclo totale fino a questo punto fornisce una visione completa dell'efficienza complessiva della gestione del ciclo del reddito (RCM). Dove trovare Dedotto dalla combinazione del saldo della pratica che raggiunge lo zero e del campo stato pratica impostato su 'Chiuso', 'Saldato' o uno stato finale equivalente. Acquisisci Il timestamp più recente tra la registrazione del pagamento finale (che determina un saldo zero) e il cambio di stato in 'Chiuso'. Tipo di evento inferred | |||
| Pratica presentata al pagatore | La richiesta di rimborso generata è stata inviata elettronicamente al payer assicurativo per la valutazione. Questo evento viene registrato esplicitamente dal modulo di invio delle richieste o dall'interfaccia della clearinghouse a seguito dell'avvenuta trasmissione. | ||
| Perché è importante Questo è un traguardo critico che avvia il conteggio dei tempi di risposta dei payer. Aiuta a misurare l'efficienza del processo di invio delle pratiche e a identificare eventuali ritardi. Dove trovare Si trova nei log delle transazioni delle richieste o nelle tabelle delle transazioni EDI (Electronic Data Interchange), monitorando specificamente l'invio dei file di richiesta 837. Cerchi un 'timestamp di invio' o una 'data di trasmissione'. Acquisisci Timestamp del log delle transazioni EDI 837 che indica l'invio riuscito. Tipo di evento explicit | |||
| Addebiti acquisiti | Rappresenta il punto in cui specifici servizi e forniture fatturabili vengono inseriti formalmente nel sistema di fatturazione. Si tratta di un'azione esplicita dell'utente o del sistema che crea i record delle transazioni di addebito. | ||
| Perché è importante Questa attività è essenziale per misurare il ritardo di addebito (charge lag), ovvero l'intervallo tra l'erogazione del servizio e l'inizio della fatturazione. Ridurre questo ritardo accelera direttamente il ciclo del reddito. Dove trovare Si trova nelle tabelle delle transazioni di addebito, spesso etichettate come inserimento addebiti o tabelle delle linee di servizio. Il timestamp di creazione del record di addebito funge da ora dell'evento. Acquisisci L'evento è il timestamp di creazione di un record nel listino prezzi o nella tabella delle transazioni di addebito. Tipo di evento explicit | |||
| Attività di recupero avviata | Il conto del paziente è stato inserito in un processo di recupero crediti attivo a causa del mancato pagamento. In genere, ciò si deduce da un cambiamento nella classe finanziaria o nello stato dell'account. | ||
| Perché è importante Questo identifica i conti che richiedono un follow-up più intenso. L'analisi della frequenza e dei driver di questa attività aiuta a migliorare le strategie di riscossione iniziali. Dove trovare Dedotto da un cambio di stato della pratica in 'Recupero crediti', 'Credito inesigibile' o 'Affidato ad agenzia'. La data di questo cambio di stato è il timestamp dell'evento. Acquisisci Timestamp di un campo dello stato del conto che cambia in un valore relativo al recupero crediti. Tipo di evento inferred | |||
| Codifica completata | Indica che i codificatori medici hanno esaminato la documentazione clinica e assegnato i codici CPT, HCPCS e ICD appropriati. Si tratta solitamente di un evento esplicito contrassegnato da un utente o da un motore di codifica automatizzato che completa l'attività. | ||
| Perché è importante La codifica è un collo di bottiglia frequente che può ritardare la presentazione della richiesta. Il monitoraggio di questa attività aiuta a misurare la produttività dei codificatori e a identificare i ritardi nella coda di codifica. Dove trovare Registrato in un modulo di workflow di codifica o tramite un cambio di stato dell'evento di fatturazione da 'In attesa di codifica' a 'Codificato'. Viene utilizzato il timestamp di questo cambio di stato o del completamento dell'attività. Acquisisci Timestamp di un aggiornamento di stato o di una voce di log quando un utente o il sistema finalizza la codifica per la prestazione. Tipo di evento explicit | |||
| Conto Rettificato | È stata registrata una rettifica contrattuale, uno storno o un'altra correzione finanziaria sulla pratica. Si tratta di una transazione finanziaria esplicita registrata nel libro mastro del sistema. | ||
| Perché è importante Le rettifiche influiscono direttamente sulla realizzazione dei ricavi. Analizzare le ragioni e la tempistica delle rettifiche è fondamentale per identificare problemi con i tariffari, la contrattualistica o l'accuratezza della fatturazione. Dove trovare Situato nella tabella delle transazioni finanziarie, identificabile tramite codici transazione specifici per storni o rettifiche. La data della transazione è l'ora dell'evento. Acquisisci La data della transazione di una voce nel libro mastro con uno specifico codice di rettifica. Tipo di evento explicit | |||
| Estratto conto paziente inviato | È stato generato e inviato al paziente l'estratto conto relativo alla quota a suo carico. Si tratta di un evento esplicito registrato dal modulo di fatturazione pazienti al momento della creazione del documento. | ||
| Perché è importante Questa attività avvia la parte del ciclo del reddito relativa ai pagamenti diretti dei pazienti (self-pay). Il monitoraggio aiuta ad analizzare l'efficienza e l'efficacia delle riscossioni dai pazienti. Dove trovare Registrato in una tabella di corrispondenza pazienti o di cronologia generazione estratti conto. Il timestamp indica quando l'estratto conto è stato creato o inviato. Acquisisci Timestamp proveniente da un log di generazione dell'estratto conto del paziente o da una tabella cronologica. Tipo di evento explicit | |||
| Pagamento ricevuto | Indica che un pagamento è stato ricevuto da un pagatore o da un paziente, spesso registrato come parte dell'avviso di pagamento. Questo evento può essere acquisito esplicitamente dai file di rimessa elettronici o dai registri manuali degli incassi. | ||
| Perché è importante Questa è un'attività fondamentale per l'analisi del flusso di cassa e la misurazione della velocità dei pagamenti. Funge da trigger per il processo di registrazione dei pagamenti. Dove trovare Derivato dalle informazioni di pagamento all'interno del file di rimessa EDI 835 o dai file lockbox di una banca. Spesso viene utilizzata la data dell'assegno o la data di elaborazione nel file. Acquisisci Estratto dal segmento BPR di un file EDI 835 o dal file dati lockbox di una banca. Tipo di evento explicit | |||
| Rework diniego avviato | Un utente o un workflow automatizzato ha avviato il processo di revisione e risoluzione di una richiesta respinta. Questo evento può essere registrato esplicitamente da un'azione utente o dedotto da un cambio di stato della pratica. | ||
| Perché è importante Questa attività avvia il ciclo di rielaborazione dei rifiuti. Misurare il tempo che intercorre tra la ricezione del rifiuto e l'inizio della rielaborazione aiuta a identificare gli arretrati nella coda di gestione dei rifiuti. Dove trovare Si trova nei moduli di gestione dei dinieghi o delle code di lavoro. Può essere un timestamp esplicito di quando un utente 'apre' o 'prende in carico' un'attività di diniego, oppure dedotto da un cambio di stato da 'Respinto' a 'In Rework'. Acquisisci Dedotto da un cambio di stato della pratica in 'Rework' o 'In revisione', o da un log di azione utente esplicito. Tipo di evento inferred | |||
| Ricorso presentato | È stato presentato formalmente un ricorso al pagatore per contestare una richiesta respinta. Si tratta di un'azione esplicita registrata da un utente nel modulo di gestione dei dinieghi o dei ricorsi. | ||
| Perché è importante Questa attività rappresenta un passaggio chiave nel processo di recupero dei ricavi. Il monitoraggio della presentazione dei ricorsi e dei relativi tempi di ciclo è fondamentale per comprendere l'efficacia della strategia di risoluzione dei rifiuti. Dove trovare Registrato in un modulo di tracciamento dei ricorsi o come tipo di transazione specifica sulla richiesta. Cerchi un campo 'data ricorso' o 'data ripresentazione'. Acquisisci Timestamp esplicito registrato quando un utente registra la presentazione di un ricorso. Tipo di evento explicit | |||
| Sinistro Creato | Il sistema ha generato una pratica fatturabile, raccogliendo tutti gli addebiti, i codici e le informazioni anagrafiche in un formato standardizzato. Si tratta di un evento esplicito generato dal sistema con un relativo timestamp di creazione. | ||
| Perché è importante Questa attività segna il passaggio dall'acquisizione dell'addebito al processo formale di fatturazione. È un prerequisito per l'invio ed è fondamentale per monitorare i tempi di elaborazione interna. Dove trovare Situato nella tabella delle richieste o nel log delle transazioni. Il timestamp di creazione del record di intestazione della richiesta indica l'evento. Acquisisci Acquisito dal timestamp di creazione del record principale nella tabella del database delle richieste. Tipo di evento explicit | |||
Guide all'Estrazione
I metodi di estrazione per questo processo sono attualmente in fase di convalida. La preghiamo di controllare più tardi oppure ci contatti per assistenza.