Il Suo template dei dati per la gestione del ciclo attivo
Il Suo template dei dati per la gestione del ciclo attivo
- Attributi consigliati da raccogliere
- Attività principali da monitorare
- Indicazioni per l’estrazione dei dati da Oracle Health Revenue Cycle
Attributi della gestione del ciclo attivo
| Nome | Descrizione | ||
|---|---|---|---|
| Evento di fatturazione BillingEvent | Identificativo univoco di una singola prestazione o fornitura di prodotto che genera un addebito e funge da identificativo del caso nel processo del ciclo dei ricavi. | ||
| Descrizione L’evento di fatturazione funge da identificativo principale del caso e collega tutte le attività, dalla registrazione degli addebiti alla chiusura del conto, per una specifica voce fatturabile. Ogni evento di fatturazione rappresenta un’istanza distinta del processo del ciclo dei ricavi e consente di seguirne l’intero percorso nelle varie fasi, come l’invio della richiesta di rimborso, la registrazione del pagamento e gli eventuali rifiuti o rettifiche. Nell’analisi di Process Mining, questo attributo è fondamentale per ricostruire il flusso di processo da un’estremità all’altra. Consente di visualizzare le varianti del processo, calcolare i tempi di ciclo tra le attività e individuare colli di bottiglia o deviazioni associati a specifici eventi di fatturazione. Perché è importante È la chiave essenziale per tracciare l’intero ciclo di vita di un servizio fatturabile e consente tutte le analisi dei flussi di processo e delle prestazioni. Dove reperirli Questo identificativo dovrebbe essere una chiave univoca presente nelle tabelle principali di fatturazione o delle transazioni di addebito di Oracle Health Revenue Cycle. Consulti la documentazione del sistema per individuare la chiave primaria degli eventi di addebito. Esempi BEVNT-987654321BEVNT-987654322BEVNT-987654323 | |||
| Nome dell’attività ActivityName | Nome della specifica fase o dell’evento che si è verificato nel processo del ciclo dei ricavi. | ||
| Descrizione Questo attributo registra il nome di ogni attività svolta durante il ciclo di vita di un evento di fatturazione. Alcuni esempi sono 'Addebiti registrati', 'Richiesta di rimborso inviata al pagatore' e 'Pagamento registrato'. Queste attività costituiscono i nodi della mappa di processo individuata. Analizzare la sequenza e la frequenza delle attività è il fulcro del Process Mining. Questo attributo aiuta a individuare i percorsi di processo più comuni, rilevare le deviazioni dalla procedura standard e comprendere il flusso operativo del ciclo dei ricavi. Perché è importante Definisce le fasi del processo, consentendo di visualizzare la mappa di processo e analizzare gli schemi del flusso di lavoro. Dove reperirli In genere si ricava dagli Event Log, dai record delle modifiche di stato o da specifiche tabelle di transazioni associate alle diverse fasi del ciclo dei ricavi in Oracle Health. Esempi Richiesta di rimborso generataRendiconto del pagamento ricevutoRicorso contro il rifiuto presentatoConto chiuso | |||
| Timestamp dell’evento EventTimestamp | Data e ora esatte in cui un’attività è stata registrata nel sistema. | ||
| Descrizione Questo attributo fornisce il timestamp di ogni attività e ne indica il momento esatto. È essenziale per comprendere la tempistica e la sequenza degli eventi nel ciclo dei ricavi di uno specifico evento di fatturazione. Nell’analisi, il timestamp dell’evento serve a ordinare cronologicamente le attività, calcolare durate e tempi di ciclo tra le diverse fasi e svolgere l’analisi dei colli di bottiglia. È alla base di tutte le metriche temporali del Process Mining, per esempio per individuare i ritardi tra 'Richiesta di rimborso inviata' e 'Rendiconto del pagamento ricevuto'. Perché è importante Questo timestamp è fondamentale per ordinare gli eventi, calcolare tutte le metriche di prestazione, come i tempi di ciclo e le durate, e individuare i colli di bottiglia del processo. Dove reperirli Ogni tabella delle transazioni o degli Event Log in Oracle Health Revenue Cycle dovrebbe includere una colonna timestamp che indichi quando è stato creato il record o si è verificato l’evento. Esempi 2023-04-15T09:00:00Z2023-04-18T14:30:00Z2023-05-02T11:25:10Z | |||
| Categoria del paziente PatientClass | Classificazione dell’incontro del paziente, ad esempio ricovero o visita ambulatoriale. | ||
| Descrizione Questo attributo classifica il tipo di visita o incontro del paziente che ha generato l’addebito. Le categorie più comuni comprendono ricovero, visita ambulatoriale, pronto soccorso e paziente con accessi ricorrenti. La categoria del paziente spesso determina l’intero processo di fatturazione e invio delle richieste di rimborso. Le diverse categorie di pazienti seguono percorsi di processo distinti e sono soggette a requisiti di conformità diversi. Analizzare il processo in base a questo attributo aiuta a comprenderne le variazioni, definire iniziative di miglioramento mirate e verificare che per ogni categoria siano seguite le procedure corrette. Perché è importante Distingue i flussi di processo, ad esempio ricovero e visita ambulatoriale, che presentano complessità, tempistiche e requisiti di fatturazione diversi. Dove reperirli È un campo standard associato a un incontro o a un record di ammissione del paziente in Oracle Health. Esempi RicoveroVisita ambulatorialeEmergenzaRicorrente | |||
| Codice del motivo del rifiuto DenialReasonCode | Codice standard che indica il motivo per cui il pagatore ha respinto una richiesta di rimborso. | ||
| Descrizione Quando un pagatore respinge una richiesta di rimborso, fornisce un codice che ne spiega il motivo, ad esempio «Servizio non coperto» o «Richiesta duplicata». Questo attributo registra il codice e la relativa descrizione. Analizzare i motivi dei rifiuti è fondamentale per migliorare il ciclo dei ricavi. Consente all’organizzazione di individuare schemi ricorrenti, come problemi di codifica o di idoneità del paziente, e di adottare misure correttive per prevenire nuovi rifiuti. Questo incide direttamente sul tasso di richieste corrette al primo invio e riduce i costi delle rilavorazioni. Perché è importante Indica le cause profonde del rifiuto delle richieste, consentendo interventi mirati per aumentare il tasso di richieste corrette al primo invio e accelerare la riscossione dei ricavi. Dove reperirli Queste informazioni sono ricevute dal pagatore tramite il documento elettronico di rimessa (file ANSI 835) e dovrebbero essere archiviate nelle tabelle delle richieste o delle rimesse di Oracle Health. Esempi CO-16: alla richiesta o al servizio mancano informazioni necessarie per la valutazione.PR-96: addebito o addebiti non coperti.CO-18: richiesta o servizio duplicato. | |||
| Importo della rettifica AdjustmentAmount | Il valore monetario delle rettifiche apportate al saldo del conto. | ||
| Descrizione Questo attributo registra l’importo di ogni rettifica finanziaria, come agevolazioni contrattuali, stralci o correzioni, applicata all’evento di fatturazione. Le rettifiche riducono direttamente i ricavi attesi da un addebito. La Dashboard «Impatto delle rettifiche sul conto» si basa in larga misura su questo attributo. Analizzare gli importi delle rettifiche e le relative motivazioni aiuta a individuare le cause della perdita di ricavi, le criticità nella gestione dei contratti o i problemi nella registrazione iniziale degli addebiti. È una metrica fondamentale per valutare la salute finanziaria. Perché è importante Quantifica la perdita di ricavi dovuta a stralci o correzioni, aiutando a individuare e affrontare le cause profonde dell’erosione finanziaria. Dove reperirli Si trova nelle tabelle delle transazioni finanziarie che registrano rettifiche o stralci sul conto del paziente. Esempi -50.25-120.0025.00 | |||
| Nome del pagatore PayerName | Nome della compagnia assicurativa o del pagatore terzo responsabile del pagamento. | ||
| Descrizione Questo attributo identifica l’ente a cui viene fatturato il servizio, come una compagnia assicurativa o un programma governativo quale Medicare. Le informazioni sul pagatore sono fondamentali per l’analisi del ciclo dei ricavi. Analizzare il processo per pagatore può rivelare differenze significative nei tempi di pagamento, nei tassi di rifiuto e nel successo dei ricorsi. Aiuta a individuare i pagatori problematici che causano ritardi o perdite di ricavi ed è essenziale per gestire efficacemente i contratti e i rapporti con i pagatori. Perché è importante Consente di segmentare il processo per pagatore e di rilevare differenze nei comportamenti, nei tassi di rifiuto e nella rapidità dei pagamenti, aspetti fondamentali per i risultati finanziari. Dove reperirli Queste informazioni sono memorizzate nei record di fatturazione o assicurativi del paziente in Oracle Health Revenue Cycle. Esempi AetnaBlue Cross Blue ShieldUnitedHealthcareMedicareCigna | |||
| Reparto fatturazione BillingDepartment | Reparto o team funzionale responsabile dell’attività. | ||
| Descrizione Questo attributo specifica il reparto che ha svolto l’attività, ad esempio 'Registrazione degli addebiti', 'Codifica' o 'Recupero crediti'. Fornisce un contesto organizzativo al flusso di processo. Analizzare il processo dal punto di vista dei reparti è essenziale per comprendere i passaggi di consegne tra i team e individuare le inefficienze tra le diverse funzioni. L’attributo supporta la Dashboard 'Carico di lavoro del reparto fatturazione', consentendo di aggregare le attività e le metriche di prestazione per reparto. Perché è importante Associa le attività alle unità organizzative, un aspetto fondamentale per analizzare i passaggi di consegne tra reparti, il carico di lavoro e le prestazioni dei team. Dove reperirli Queste informazioni possono essere memorizzate direttamente nei dati del profilo utente di Oracle Health oppure ricavate in base all’utente o al tipo di attività. Esempi Accesso dei pazientiCodificaFatturazioneRecupero crediti | |||
| Saldo residuo OutstandingBalance | Il saldo ancora da pagare per l’evento di fatturazione in un determinato momento. | ||
| Descrizione Questo attributo indica l’importo attualmente dovuto per un evento di fatturazione, dopo aver applicato tutti i pagamenti e le rettifiche. Rappresenta il credito ancora aperto relativo a quello specifico addebito. È un attributo fondamentale per la Dashboard «Anzianità dei saldi residui». Analizzare questo valore nel tempo aiuta a monitorare la velocità dei flussi di cassa, valutare l’efficacia delle attività di recupero crediti e calcolare KPI finanziari chiave come i Giorni medi di incasso (DSO). Perché è importante Monitora i crediti ancora aperti per ciascun caso, un dato essenziale per gestire i flussi di cassa e analizzare l’efficacia delle attività di recupero crediti. Dove reperirli In genere, questo valore si calcola sommando tutte le transazioni finanziarie (addebiti, pagamenti e rettifiche) relative a un determinato evento di fatturazione. Può essere presente come campo in una tabella riepilogativa dei conti. Esempi 75.000.00550.80 | |||
| Utente UserPerformingAction | ID utente o nome della persona che ha svolto l’attività. | ||
| Descrizione Questo attributo identifica il dipendente o l’utente di sistema automatizzato responsabile di una specifica attività del processo. È fondamentale per comprendere la distribuzione del carico di lavoro e le prestazioni delle risorse e per individuare le esigenze di formazione. Nell’analisi, consente di filtrare la mappa di processo per utente o team, confrontare le prestazioni delle diverse risorse e analizzare il carico di lavoro nella Dashboard 'Carico di lavoro del reparto fatturazione'. Può aiutare a individuare le persone con i migliori risultati o chi potrebbe aver bisogno di ulteriore supporto o formazione. Perché è importante Collega le attività del processo a utenti o team specifici, consentendo di analizzare il carico di lavoro, confrontare le prestazioni e individuare opportunità di formazione. Dove reperirli I campi ID utente, ad esempio 'CREATED_BY' e 'USER_ID', sono in genere presenti nelle tabelle delle transazioni dei vari moduli di Oracle Health. Esempi j.doeasmithBillingBot_AUTOk.williams | |||
| È automatizzata IsAutomated | Indicatore che specifica se l’attività è stata svolta da un sistema automatizzato o da una persona. | ||
| Descrizione Questo attributo booleano distingue le attività eseguite da automazioni software, come bot o processi batch di sistema, da quelle svolte manualmente da una persona. Ad esempio, «Richiesta generata» potrebbe essere un passaggio automatizzato, mentre «Ricorso contro il rifiuto» è probabilmente manuale. Analizzare questo attributo aiuta a comprendere il livello di automazione del processo e il suo impatto sull’efficienza e sul tasso di errore. È possibile confrontare i percorsi automatizzati con quelli manuali e individuare nuove opportunità di automazione. Perché è importante Distingue le attività svolte da persone da quelle gestite dai sistemi, un aspetto fondamentale per analizzare l’efficacia dell’automazione e individuare nuove opportunità. Dove reperirli In genere, si ricava dall’attributo UserPerformingAction. Ad esempio, le attività svolte da ID utente come «SYSTEM» o «RPA_BOT» vengono contrassegnate come automatizzate. Esempi truefalse | |||
| È una rilavorazione IsRework | Indicatore che identifica le attività che comportano una rilavorazione o la ripetizione di un’attività. | ||
| Descrizione Questo attributo calcolato contrassegna le attività che si discostano dal «percorso ottimale» e comportano una rilavorazione. Tra gli esempi figurano «Richiesta corretta e inviata» o «Ricorso contro il rifiuto», passaggi che non sarebbero necessari se il processo si svolgesse correttamente al primo tentativo. Individuare e quantificare le rilavorazioni è uno degli obiettivi principali del Process Mining. Questo indicatore permette di filtrare e analizzare facilmente tutti i cicli di rilavorazione, contribuendo a misurare la frequenza, i costi e le cause delle inefficienze. È essenziale per comprendere il costo effettivo della qualità nel ciclo dei ricavi. Perché è importante Aiuta a quantificare la frequenza e l’impatto dei cicli di rilavorazione, mettendo in evidenza le inefficienze del processo e il costo della scarsa qualità. Dove reperirli È un attributo derivato, calcolato durante la trasformazione dei dati applicando regole aziendali che contrassegnano specifici nomi di attività come rilavorazioni. Esempi truefalse | |||
| ID paziente PatientId | Identificativo univoco del paziente associato all’evento di fatturazione. | ||
| Descrizione Questo attributo è l’identificativo univoco del paziente che ha ricevuto il servizio, spesso noto come numero di cartella clinica (MRN). Collega la transazione finanziaria a una persona specifica. Pur non essendo l’ID caso del processo, l’ID paziente è utile per aggregare tutti gli eventi di fatturazione relativi a una persona e ricostruirne l’intero percorso finanziario. Se associato ai dati anagrafici dei pazienti, consente inoltre di segmentare i dati in base alle caratteristiche demografiche o alla storia clinica. Perché è importante Collega gli eventi finanziari a un paziente specifico e consente analisi incentrate sul paziente e l’aggregazione di tutte le sue attività di fatturazione. Dove reperirli Questo identificativo è un elemento centrale dell’anagrafica del paziente ed è presente in tutte le tabelle delle transazioni correlate, ad esempio quelle relative ad addebiti, richieste e pagamenti. Esempi MRN-1002345MRN-1002346MRN-1002347 | |||
| ID richiesta ClaimId | Identificativo univoco della richiesta di rimborso assicurativo inviata a un pagatore. | ||
| Descrizione Questo attributo è l’ID univoco assegnato a una richiesta generata e inviata a un pagatore per ottenere un rimborso. Nel corso del suo ciclo di vita, un singolo evento di fatturazione può generare una o più richieste, ad esempio quando è necessario apportare una correzione. L’ID richiesta consente di tracciare uno specifico invio al pagatore e di collegarlo direttamente alla risposta, come un pagamento o un rifiuto. Permette quindi un monitoraggio più dettagliato all’interno del processo complessivo del ciclo dei ricavi. Perché è importante Fornisce un identificativo specifico per seguire il percorso di una richiesta presso un pagatore, con un livello di dettaglio maggiore rispetto all’evento di fatturazione complessivo. Dove reperirli Questo ID viene generato da Oracle Health al momento della creazione della richiesta e archiviato nella tabella principale delle richieste. Esempi CLM-2023-55489CLM-2023-55490CLM-2023-55491-C1 | |||
| Importo addebitato ChargeAmount | Il valore monetario lordo del servizio o prodotto fatturato. | ||
| Descrizione Questo attributo rappresenta l’importo iniziale, al lordo degli sconti, addebitato per un servizio prima di applicare rettifiche, agevolazioni contrattuali o pagamenti. È il valore finanziario di partenza dell’evento di fatturazione. Monitorare l’importo addebitato è fondamentale per l’analisi finanziaria, ad esempio per calcolare il valore totale dei servizi erogati e comprendere l’impatto economico delle rettifiche o degli stralci successivi. Costituisce la base di riferimento per misurare la realizzazione dei ricavi. Perché è importante Definisce il valore finanziario iniziale del caso, fondamentale per tutte le analisi finanziarie e le valutazioni d’impatto successive. Dove reperirli Si trova nelle tabelle dei dettagli degli addebiti o delle transazioni di addebito di Oracle Health. Esempi 150.001250.7585.50 | |||
| Motivo della contestazione DisputeReason | Il motivo indicato dal cliente o dal paziente per contestare una fattura o un addebito. | ||
| Descrizione Questo attributo registra il motivo per cui un paziente o un’altra persona responsabile ha contestato una fattura. Tra le possibili motivazioni figurano addebiti errati, servizi non erogati o problemi nella gestione assicurativa. Queste informazioni sono essenziali per la Dashboard «Metriche di risoluzione delle contestazioni delle fatture». Conoscere i motivi più frequenti delle contestazioni aiuta a individuare problemi sistemici nella registrazione degli addebiti, nella codifica o nei processi di fatturazione. Intervenire sulle cause profonde può ridurre sensibilmente il tasso di contestazione e il carico amministrativo necessario per risolverle. Perché è importante Spiega perché vengono contestate le fatture e offre indicazioni dirette sui problemi di accuratezza o chiarezza della fatturazione da correggere. Dove reperirli Probabilmente queste informazioni sono archiviate in un modulo di gestione dei casi o di assistenza clienti di Oracle Health, collegato al conto del paziente. Esempi Servizio fatturato erroneamenteAddebito duplicatoFatturazione errata all’assicurazioneServizio non erogato | |||
| Ora di fine dell’evento EventEndTime | Timestamp che indica il completamento di un’attività, se disponibile. | ||
| Descrizione Mentre StartTime indica l’inizio di un’attività, EventEndTime ne indica la conclusione. Non tutte le attività hanno un orario di fine distinto, poiché molti eventi sono istantanei. Tuttavia, questo campo è molto utile per le attività che hanno una durata, come 'Ricorso contro il rifiuto presentato', la cui gestione può richiedere tempo. Questo attributo consente di calcolare con maggiore precisione il tempo di elaborazione delle singole attività e di distinguere il tempo di attesa, cioè quello tra un’attività e l’altra, dal tempo di elaborazione, ovvero quello dedicato all’attività. Perché è importante Consente di calcolare direttamente il tempo necessario per completare un’attività, distinguendo il tempo di elaborazione da quello di attesa. Dove reperirli Alcune tabelle delle transazioni di Oracle Health Revenue Cycle possono contenere sia il timestamp di inizio sia quello di fine per specifiche attività di lunga durata. Esempi 2023-04-15T09:05:14Z2023-04-18T16:00:00Z | |||
| Sistema di origine SourceSystem | Il sistema da cui sono stati estratti i dati dell’evento. | ||
| Descrizione Questo attributo identifica l’applicazione o il modulo di origine dei dati. Per questo processo, in genere sarà 'Oracle Health Revenue Cycle', ma può anche indicare moduli diversi dello stesso sistema se i dati provengono da più fonti. Questa informazione è utile per la governance dei dati e la risoluzione dei problemi. Aiuta a verificare la provenienza dei dati ed è importante negli ambienti in cui più sistemi contribuiscono a un unico processo da un’estremità all’altra. Perché è importante Fornisce informazioni sull’origine dei dati, fondamentali per la convalida e la governance dei dati e per comprendere le variazioni del processo che possono dipendere dal sistema. Dove reperirli Spesso è un valore statico aggiunto durante il processo di estrazione, trasformazione e caricamento dei dati (ETL) per indicare l’origine del set di dati. Esempi OracleHealth-RCMOracleHealth-CernerOH-RevCycle-PROD | |||
| Ultimo aggiornamento dei dati LastDataUpdate | Timestamp che indica l’ultimo aggiornamento o l’ultima estrazione dei dati relativi a questo evento. | ||
| Descrizione Questo attributo indica quando il set di dati è stato aggiornato l’ultima volta. Fornisce informazioni sull’aggiornamento dei dati analizzati, importanti per valutare quanto siano recenti le informazioni ricavate dall’analisi di Process Mining. Può consultare questo attributo per verificare che stia visualizzando le informazioni di processo più aggiornate. Aiuta a valutare la recenza dei dati ed è un elemento importante della governance e del controllo qualità dei dati. Perché è importante Indica quanto sono aggiornati i dati, affinché analisi e decisioni si basino su informazioni recenti. Dove reperirli È un campo di metadati, in genere generato e compilato durante il processo ETL che carica i dati nella piattaforma di Process Mining. Esempi 2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
Attività della gestione del ciclo attivo
| Attività | Descrizione | ||
|---|---|---|---|
| Conto chiuso | Attività finale, che indica che il saldo del conto è pari a zero e che non sono previste ulteriori attività. Spesso si deduce quando il saldo raggiunge lo zero. | ||
| Perché è importante Segna il completamento del ciclo dei ricavi. Il tempo necessario per raggiungere questo stato è un indicatore importante dell’efficienza complessiva del processo. Dove reperirli In genere si deduce individuando il primo momento in cui il saldo residuo del conto diventa zero e vi rimane dopo la registrazione di tutti i pagamenti e le rettifiche. Acquisizione Calcolato quando il saldo del conto raggiunge per la prima volta lo zero dopo la registrazione di tutti gli addebiti e i pagamenti. Tipo di evento calculated | |||
| Incontro del paziente creato | Indica la creazione di un conto paziente per una visita o un servizio specifico. In genere è un evento esplicito, generato dal sistema di registrazione o da un flusso Admit/Discharge/Transfer (ADT). | ||
| Perché è importante È il punto di partenza dell’intero ciclo dei ricavi per un determinato evento di fatturazione e consente di analizzare la durata complessiva del processo e l’accuratezza della registrazione. Dove reperirli I dati provengono dai log del modulo Patient Registration o ADT. Cerchi gli eventi di creazione dell’incontro o il timestamp più remoto associato all’incontro o al numero finanziario. Acquisizione Evento registrato al momento della registrazione o dell’ammissione del paziente. Tipo di evento explicit | |||
| Pagamento registrato | Indica l’attribuzione del pagamento ricevuto dal pagatore agli addebiti corrispondenti sul conto del paziente. È una transazione finanziaria registrata da un utente o da un processo automatizzato. | ||
| Perché è importante L’efficienza nella registrazione dei pagamenti incide sull’accuratezza dei crediti verso clienti. I ritardi in questa fase possono alterare il quadro finanziario e ritardare la fatturazione secondaria. Dove reperirli Si trova nelle tabelle delle transazioni di pagamento. Ogni registrazione di pagamento ha un ID transazione univoco e un timestamp associato. Acquisizione Transazione finanziaria registrata quando il pagamento viene attribuito al conto. Tipo di evento explicit | |||
| Richiesta di rimborso generata | Indica il momento in cui i singoli addebiti vengono riuniti in una richiesta di rimborso formale, come un modulo UB-04 o CMS-1500. È un evento generato dal sistema che crea la fattura iniziale. | ||
| Perché è importante È una tappa fondamentale che indica che la richiesta è pronta per essere inviata al pagatore. Segna il termine del periodo interno tra la registrazione degli addebiti e la fatturazione. Dove reperirli Evento esplicito registrato nei log o nelle tabelle di generazione delle richieste di rimborso. Cerchi il timestamp di creazione del record principale della richiesta associato all’incontro. Acquisizione Evento registrato alla creazione del record della richiesta di rimborso. Tipo di evento explicit | |||
| Richiesta di rimborso inviata al pagatore | Indica l’invio elettronico o cartaceo della richiesta di rimborso generata alla compagnia assicurativa o al pagatore. Il sistema dovrebbe registrare la data e l’ora della trasmissione. | ||
| Perché è importante Questa attività avvia il ciclo di pagamento. Analizzare il tempo che intercorre tra l’invio e il pagamento è fondamentale per comprendere le prestazioni dei pagatori e i giorni medi di incasso. Dove reperirli I dati provengono dal modulo di gestione delle richieste di rimborso, che registra gli eventi di trasmissione. Cerchi il timestamp di invio o la modifica dello stato in 'Submitted' nella cronologia della richiesta. Acquisizione Evento registrato quando la richiesta di rimborso viene trasmessa correttamente tramite la clearinghouse. Tipo di evento explicit | |||
| Addebiti codificati | Indica il processo in cui i codificatori medici assegnano agli addebiti registrati codici standard, come CPT o ICD-10. Spesso è tracciato tramite una modifica dello stato dell’addebito o dell’incontro. | ||
| Perché è importante I ritardi nella codifica sono un collo di bottiglia frequente. Tracciare questa attività aiuta a individuare le inefficienze nel flusso di lavoro di codifica e il loro impatto sulle tempistiche di fatturazione. Dove reperirli Spesso si deduce da una modifica dello stato dell’incontro del paziente o del gruppo di addebiti, per esempio da 'Uncoded' a 'Coded'. È necessario disporre del timestamp della modifica. Acquisizione Deducibile dalla modifica dello stato dell’incontro o dell’addebito in 'Coded' o 'Ready for Billing'. Tipo di evento inferred | |||
| Addebiti registrati | Indica l’inserimento nel conto del paziente di servizi o articoli fatturabili. Può avvenire automaticamente dai sistemi clinici oppure tramite inserimento manuale da parte del personale. | ||
| Perché è importante Questa attività è fondamentale per misurare il ritardo nella registrazione degli addebiti, ovvero il tempo tra l’erogazione del servizio e l’avvio della fatturazione, che incide direttamente sul flusso di cassa e sull’integrità dei ricavi. Dove reperirli I dati provengono dalle tabelle delle transazioni di addebito; ogni voce è identificata dal timestamp di creazione. In Oracle Health, si trovano spesso nelle tabelle relative agli addebiti. Acquisizione Voce del registro delle transazioni creata per ogni nuovo addebito. Tipo di evento explicit | |||
| Conto rettificato | Indica una rettifica finanziaria del saldo del conto, come un abbuono contrattuale, uno stralcio o uno sconto. Ogni rettifica costituisce una transazione finanziaria distinta. | ||
| Perché è importante Le rettifiche incidono direttamente sui ricavi. Analizzarne frequenza, tipologia e importo aiuta a individuare perdite di ricavi e imprecisioni nella fatturazione. Dove reperirli Si trova nelle tabelle delle transazioni finanziarie. Ogni rettifica è registrata come voce separata, con un codice transazione specifico e un timestamp. Acquisizione Transazione finanziaria registrata con un codice di rettifica specifico. Tipo di evento explicit | |||
| Estratto conto inviato al paziente | Indica la generazione e l’invio al paziente della fattura per l’importo residuo a suo carico. È un’azione esplicita registrata dal modulo di fatturazione ai pazienti. | ||
| Perché è importante Avvia la fase del ciclo dei ricavi relativa ai pagamenti del paziente. Tracciarla aiuta ad analizzare l’efficacia delle attività di riscossione. Dove reperirli I dati provengono dai log di fatturazione ai pazienti o di corrispondenza. Il sistema dovrebbe registrare la data di generazione o invio di ogni estratto conto. Acquisizione Evento registrato quando l’estratto conto del paziente viene generato e stampato o inviato elettronicamente. Tipo di evento explicit | |||
| Recupero crediti avviato | Indica che, a causa del mancato pagamento, il conto del paziente è stato inserito in una procedura di recupero crediti. In genere si rileva da una modifica della categoria finanziaria o dello stato del conto. | ||
| Perché è importante È una fase fondamentale nella gestione dei crediti inesigibili. Analizzare cosa porta a questo punto e il tasso di successo delle attività è essenziale per la salute finanziaria. Dove reperirli Deducibile dalla modifica del campo dello stato del conto in 'Collections' o 'Bad Debt'. La modifica dovrebbe avere un timestamp associato. Acquisizione Deducibile dalla modifica dello stato del conto in 'Collections' o in uno stato analogo. Tipo di evento inferred | |||
| Rendiconto del pagamento ricevuto | Indica la ricezione dal pagatore di un Electronic Remittance Advice (ERA) o di un Explanation of Benefits (EOB) cartaceo. Il documento specifica quali addebiti sono stati pagati, respinti o rettificati. | ||
| Perché è importante È la prima risposta del pagatore ed è fondamentale per comprendere la rapidità dei pagamenti e individuare tempestivamente le tendenze nei rifiuti. Dove reperirli Registrato nel modulo di elaborazione dei rendiconti. Cerchi il timestamp di importazione o creazione del file ERA, ad esempio un file di transazione 835, collegato alla richiesta. Acquisizione Evento registrato all’importazione e all’elaborazione del file di rendicontazione del pagatore, ad esempio ANSI 835. Tipo di evento explicit | |||
| Richiesta di rimborso corretta inviata | Indica l’invio al pagatore di una richiesta di rimborso rivista o corretta, spesso in seguito a un rifiuto o a una richiesta di ulteriori informazioni. Si identifica tramite un nuovo invio con un indicatore di correzione. | ||
| Perché è importante Questa attività è una fase importante del ciclo di rilavorazione per la gestione dei rifiuti. Una frequenza elevata segnala problemi di accuratezza nelle richieste iniziali. Dove reperirli I dati provengono dai log di invio delle richieste. Cerchi un nuovo invio per un incontro esistente, spesso contrassegnato da un codice di reinvio o da un numero di iterazione superiore. Acquisizione Evento registrato per il reinvio di una richiesta, spesso identificabile tramite uno specifico codice del tipo di frequenza della richiesta. Tipo di evento explicit | |||
| Ricorso contro il rifiuto presentato | Azione di un utente o del sistema che indica la presentazione di un ricorso contro una richiesta di rimborso rifiutata. In genere viene registrata come aggiornamento di stato o come attività specifica creata in una coda di lavoro. | ||
| Perché è importante Questa attività avvia un ciclo di rilavorazione. Analizzare la frequenza e il tasso di successo dei ricorsi è fondamentale per ottimizzare il recupero dei ricavi. Dove reperirli Può trattarsi di un evento esplicito avviato dall’utente oppure dedotto da una modifica dello stato della richiesta, ad esempio in 'Appealed' o 'In Review'. Acquisizione Modifica di stato o evento registrato quando un utente avvia la procedura di ricorso contro una richiesta di rimborso rifiutata. Tipo di evento explicit | |||
| Rifiuto ricevuto | Indica il rifiuto, da parte del pagatore, di una richiesta di rimborso o di specifiche voci, come riportato nel rendiconto. Spesso l’evento si deduce dai codici di rifiuto presenti nei dati del rendiconto. | ||
| Perché è importante Tracciare i rifiuti è essenziale per individuarne le cause profonde, come errori di codifica o problemi di idoneità, e migliorare il tasso di richieste corrette al primo invio. Dove reperirli Deducibile dai dati del rendiconto (ERA/835). L’evento si verifica quando una richiesta o una voce presenta un importo di rifiuto diverso da zero e il relativo codice motivo. Acquisizione Deducibile dai dati del rendiconto che contengono codici motivo di rifiuto (CARC/RARC). Tipo di evento inferred | |||
Guide all’estrazione
Passaggi
- Richieda l’accesso al database: ottenga credenziali di sola lettura per il database Oracle Health Revenue Cycle. Dovrà accedere agli schemi che contengono i dati relativi a pazienti, incontri, fatturazione e transazioni finanziarie. In genere, è necessaria l’approvazione dei team di sicurezza IT e amministrazione del database.
- Individui i nomi di schemi e tabelle: collabori con un amministratore del database o un analista di sistema per confermare i nomi esatti degli schemi e delle tabelle dell’istanza Oracle Health in uso. I nomi indicati nella query sono segnaposto comuni e devono essere adattati all’ambiente specifico.
- Installi un client SQL: installi sulla postazione di lavoro un client SQL compatibile, ad esempio Oracle SQL Developer o DBeaver. Lo userà per connettersi al database ed eseguire lo script di estrazione.
- Configuri la connessione al database: crei una nuova connessione nel client SQL utilizzando host, porta, nome del servizio e credenziali forniti. Verifichi che la connessione funzioni correttamente.
- Personalizzi la query SQL: copi lo script SQL fornito in una nuova finestra dell’editor di query. Individui i valori segnaposto, come
[START_DATE]e[END_DATE], e li sostituisca con l’intervallo di date desiderato per l’analisi, ad esempio «2023-01-01». Modifichi le condizioni di filtro in base alle esigenze dell’analisi, ad esempio filtrando per una specifica Patient Class. - Esegua lo script di estrazione: esegua lo script SQL personalizzato. La query è completa e, a seconda dell’intervallo di date e delle dimensioni del database, potrebbe richiedere da alcuni minuti a diverse ore.
- Controlli i primi risultati: al termine della query, esamini le prime centinaia di righe nella griglia dei risultati del client SQL. Verifichi che non vi siano errori evidenti, come colonne interamente nulle o formati di dati errati, per accertarsi che lo script sia stato eseguito correttamente.
- Esporti i dati in CSV: esporti l’intero insieme di risultati in un file CSV. Utilizzi la codifica UTF-8 per evitare problemi con i caratteri. Verifichi che il file esportato includa una riga di intestazione con i nomi delle colonne specificati negli alias della query, ad esempio «BillingEvent» e «ActivityName».
- Prepari il file per il caricamento: prima di caricarlo in uno strumento di Process Mining, apra il file CSV e ne verifichi l’integrità. Controlli che il formato dei timestamp sia coerente e che le intestazioni delle colonne corrispondano esattamente agli attributi richiesti. Il file è ora pronto per il caricamento.
Configurazione
- Intervallo di date: la query utilizza i segnaposto
[START_DATE]e[END_DATE]. Per controllare il volume dei dati, è fondamentale definire un intervallo specifico e ragionevole. Per l’analisi iniziale si consiglia un periodo di 3-6 mesi. - Filtri: nella sezione
RelevantEncounters, i dati iniziali vengono filtrati in base alla data di registrazione dell’incontro (reg_dt_tm). Può aggiungere altre clausoleWHEREin questa sezione per restringere l’ambito, ad esempioe.patient_class_code IN ('INPATIENT', 'OUTPATIENT')per concentrarsi su specifici tipi di incontro. - Prestazioni: l’esecuzione di query dirette su un database di produzione può incidere sulle prestazioni. Si consiglia vivamente di eseguire l’estrazione nelle ore di minore attività o, se disponibile, su una replica di sola lettura del database di produzione.
- Prerequisiti: questo metodo richiede un account utente del database con privilegi
SELECTsu tutte le tabelle citate nella query, comprese quelle relative a incontri, fatturazione, addebiti, richieste di rimborso, rimesse e transazioni finanziarie. - Mappatura di tabelle e colonne: lo script fornito utilizza nomi rappresentativi e di uso comune per tabelle e colonne. Dovrà verificarli e associarli ai nomi effettivi dello schema del database Oracle Health della Sua organizzazione. Ad esempio, nel Suo sistema
FINANCIAL_TRANSACTIONpotrebbe chiamarsiAR_TRANSACTIONS.
Query di esempio sql
WITH RelevantEncounters AS (
SELECT
e.billing_event_id
FROM ENCOUNTER e
WHERE e.reg_dt_tm BETWEEN TO_DATE('[START_DATE]', 'YYYY-MM-DD') AND TO_DATE('[END_DATE]', 'YYYY-MM-DD')
)
SELECT
e.billing_event_id AS "BillingEvent",
'Patient Encounter Created' AS "ActivityName",
e.reg_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
e.total_account_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM ENCOUNTER e
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON e.reg_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON e.reg_facility_org_id = org.organization_id
LEFT JOIN PAYER pyr ON e.primary_payer_id = pyr.payer_id
UNION ALL
SELECT
cd.billing_event_id AS "BillingEvent",
'Charges Captured' AS "ActivityName",
cd.charge_entry_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
cd.charge_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM CHARGE_DETAIL cd
JOIN ENCOUNTER e ON cd.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON cd.entry_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON cd.performing_dept_org_id = org.organization_id
LEFT JOIN PAYER pyr ON e.primary_payer_id = pyr.payer_id
UNION ALL
SELECT
ch.billing_event_id AS "BillingEvent",
'Charges Coded' AS "ActivityName",
ch.coded_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
e.total_account_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM CODING_HISTORY ch
JOIN ENCOUNTER e ON ch.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON ch.coder_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON p.default_org_id = org.organization_id
LEFT JOIN PAYER pyr ON e.primary_payer_id = pyr.payer_id
UNION ALL
SELECT
cl.billing_event_id AS "BillingEvent",
'Claim Generated' AS "ActivityName",
cl.create_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
cl.claim_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM CLAIM cl
JOIN ENCOUNTER e ON cl.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON cl.create_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON cl.billing_entity_org_id = org.organization_id
LEFT JOIN PAYER pyr ON cl.payer_id = pyr.payer_id
UNION ALL
SELECT
csl.billing_event_id AS "BillingEvent",
'Claim Submitted To Payer' AS "ActivityName",
csl.submission_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
cl.claim_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM CLAIM_SUBMISSION_LOG csl
JOIN CLAIM cl ON csl.claim_id = cl.claim_id
JOIN ENCOUNTER e ON cl.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON csl.submit_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON cl.billing_entity_org_id = org.organization_id
LEFT JOIN PAYER pyr ON cl.payer_id = pyr.payer_id
WHERE csl.submission_type = 'INITIAL'
UNION ALL
SELECT
ra.billing_event_id AS "BillingEvent",
'Remittance Received' AS "ActivityName",
ra.remit_received_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
e.total_account_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM REMITTANCE_ADVICE ra
JOIN ENCOUNTER e ON ra.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON ra.processed_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON ra.processing_org_id = org.organization_id
LEFT JOIN PAYER pyr ON ra.payer_id = pyr.payer_id
UNION ALL
SELECT
ft.billing_event_id AS "BillingEvent",
'Payment Posted' AS "ActivityName",
ft.transaction_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
ft.ending_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM FINANCIAL_TRANSACTION ft
JOIN ENCOUNTER e ON ft.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON ft.post_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON ft.post_dept_org_id = org.organization_id
LEFT JOIN PAYER pyr ON ft.payer_id = pyr.payer_id
WHERE ft.transaction_type_code = 'PAYMENT'
UNION ALL
SELECT
rd.billing_event_id AS "BillingEvent",
'Denial Received' AS "ActivityName",
ra.remit_received_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
e.total_account_balance AS "OutstandingBalance",
rd.denial_reason_code AS "DenialReasonCode"
FROM REMITTANCE_DETAIL rd
JOIN REMITTANCE_ADVICE ra ON rd.remit_id = ra.remit_id
JOIN ENCOUNTER e ON ra.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON ra.processed_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON ra.processing_org_id = org.organization_id
LEFT JOIN PAYER pyr ON ra.payer_id = pyr.payer_id
WHERE rd.denial_reason_code IS NOT NULL
UNION ALL
SELECT
at.billing_event_id AS "BillingEvent",
'Denial Appealed' AS "ActivityName",
at.appeal_filed_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
e.total_account_balance AS "OutstandingBalance",
at.related_denial_code AS "DenialReasonCode"
FROM APPEAL_TRACKING at
JOIN ENCOUNTER e ON at.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON at.appeal_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON p.default_org_id = org.organization_id
LEFT JOIN PAYER pyr ON at.payer_id = pyr.payer_id
UNION ALL
SELECT
csl.billing_event_id AS "BillingEvent",
'Corrected Claim Submitted' AS "ActivityName",
csl.submission_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
cl.claim_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM CLAIM_SUBMISSION_LOG csl
JOIN CLAIM cl ON csl.claim_id = cl.claim_id
JOIN ENCOUNTER e ON cl.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON csl.submit_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON cl.billing_entity_org_id = org.organization_id
LEFT JOIN PAYER pyr ON cl.payer_id = pyr.payer_id
WHERE csl.submission_type = 'CORRECTED'
UNION ALL
SELECT
psl.billing_event_id AS "BillingEvent",
'Patient Statement Sent' AS "ActivityName",
psl.statement_sent_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
NULL AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
psl.statement_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM PATIENT_STATEMENT_LOG psl
JOIN ENCOUNTER e ON psl.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON psl.sent_by_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON p.default_org_id = org.organization_id
UNION ALL
SELECT
ash.billing_event_id AS "BillingEvent",
'Collection Activity Started' AS "ActivityName",
ash.status_change_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
NULL AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
ash.account_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM ACCOUNT_STATUS_HISTORY ash
JOIN ENCOUNTER e ON ash.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON ash.change_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON ash.responsible_org_id = org.organization_id
WHERE ash.new_status_code = 'COLLECTIONS'
UNION ALL
SELECT
ft.billing_event_id AS "BillingEvent",
'Account Adjusted' AS "ActivityName",
ft.transaction_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
ft.transaction_amount AS "AdjustmentAmount",
ft.ending_balance AS "OutstandingBalance",
ft.adjustment_reason_code AS "DenialReasonCode"
FROM FINANCIAL_TRANSACTION ft
JOIN ENCOUNTER e ON ft.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON ft.post_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON ft.post_dept_org_id = org.organization_id
LEFT JOIN PAYER pyr ON ft.payer_id = pyr.payer_id
WHERE ft.transaction_type_code = 'ADJUSTMENT'
UNION ALL
SELECT
e.billing_event_id AS "BillingEvent",
'Account Closed' AS "ActivityName",
e.account_closed_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
NULL AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
0 AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM ENCOUNTER e
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON e.closed_by_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON e.reg_facility_org_id = org.organization_id
WHERE e.total_account_balance = 0 AND e.account_closed_dt_tm IS NOT NULL; È pronto a iniziare?
Utilizzi questo template per preparare i dati e ottenere risultati affidabili. Inizi oggi a migliorare il processo di gestione del ciclo attivo.
Ottimizzi il ciclo attivo per ricevere i pagamenti più rapidamente
Elimini i colli di bottiglia, riduca del 30% il tempo di ciclo e migliori il flusso di cassa.
Non è richiesta la carta di credito. La configurazione richiede pochi minuti.