Data Template: Elaborazione Sinistri
Il tuo Data Template per la Gestione dei Sinistri
- Attributi consigliati da raccogliere
- Attività chiave da monitorare
- Guida all'Estrazione per Guidewire ClaimCenter
Attributi di Elaborazione Sinistri
| Nome | Descrizione | ||
|---|---|---|---|
ID Sinistro ClaimID | L'identificatore univoco per ogni sinistro assicurativo, che funge da identificatore primario del caso. | ||
Descrizione Il Claim ID è la pietra angolare dell'analisi del processo dei sinistri, identificando in modo univoco ogni caso dalla presentazione alla chiusura. Collega tutte le attività, i documenti, i pagamenti e le comunicazioni associate, garantendo una visione completa e coerente del ciclo di vita di un sinistro. Nel process mining, ogni evento nel dataset è collegato a un Claim ID, consentendo la ricostruzione del flusso di processo end-to-end. Ciò è essenziale per analizzare i tempi di ciclo, identificare le varianti di processo e tracciare il percorso di un sinistro tra i diversi dipartimenti e liquidatori. Perché è importante È la chiave fondamentale che collega tutti gli eventi correlati, rendendo possibile tracciare e analizzare l'intero percorso di un singolo sinistro. Dove trovare Questa è una chiave primaria in Guidewire ClaimCenter, tipicamente trovata come Claim.ClaimNumber o un campo simile nell'entità principale Sinistro. Esempi 000-123-45678000-987-65432001-456-11223 | |||
Nome Attività ActivityName | Il nome dell'attività di business o dell'evento che si è verificato in un punto specifico del ciclo di vita del sinistro. | ||
Descrizione Questo attributo descrive una fase specifica o una tappa fondamentale nel processo di gestione dei sinistri, come ad esempio 'Sinistro creato', 'Indagine avviata' o 'Pagamento emesso'. La sequenza di queste attività per un dato ID Sinistro forma il flusso del processo. L'analisi della sequenza, frequenza e durata tra le attività è il cuore del Process Mining. Permette di scoprire modelli di processo, identificare colli di bottiglia, rilevare cicli di rilavorazione e analizzare le deviazioni del processo. Perché è importante Definisce i passaggi del processo, consentendo la visualizzazione delle process map e l'analisi del flusso di processo e dei colli di bottiglia. Dove trovare Questo è solitamente derivato dalle tabelle degli eventi o dai log di audit in ClaimCenter, spesso mappando eventi di sistema specifici o cambiamenti di stato a nomi di attività standardizzati. Esempi Sinistro CreatoDecisione sulla Responsabilità presaPagamento EmessoSinistro Chiuso | |||
Ora Evento EventTime | La data e l'ora precise in cui si è verificata l'attività. | ||
Descrizione Questo timestamp segna il momento esatto in cui un'attività è stata registrata nel sistema. È fondamentale per tutte le analisi di processo basate sul tempo. L'ordinamento cronologico di EventTime per un singolo Claim ID consente la ricostruzione del flusso di processo. La differenza di tempo tra eventi consecutivi viene utilizzata per calcolare i tempi di ciclo, i tempi di attesa e i tempi di elaborazione, che sono critici per l'analisi delle performance, l'identificazione dei colli di bottiglia e il monitoraggio degli SLA. Perché è importante Questo timestamp è essenziale per ordinare gli eventi, calcolare i tempi di ciclo e le durate, e identificare i ritardi nel processo. Dove trovare Trovato insieme ai dati di eventi o attività nelle tabelle di cronologia o audit di Guidewire ClaimCenter, spesso come campo 'CreateTime' o 'UpdateTime'. Esempi 2023-05-15T09:00:00Z2023-05-16T14:30:15Z2023-06-01T11:20:00Z | |||
Causa del Sinistro LossCause | La ragione specifica o la causa dell'evento di danno (ad es. Collisione, Incendio, Danni da Acqua). | ||
Descrizione Questo attributo fornisce un contesto dettagliato sul motivo della denuncia di sinistro. La causa del danno spesso determina le fasi di indagine richieste, il tipo di esperti necessari e la complessità complessiva del sinistro. Analizzare il processo in base alla Causa del Danno può rivelare schemi nascosti. Ad esempio, i sinistri correlati a 'Danni da Acqua' potrebbero avere un tasso più elevato di rilavorazione o richiedere un maggiore coinvolgimento di specialisti rispetto ai sinistri per 'Furto'. Queste intuizioni aiutano a creare procedure di gestione più specializzate ed efficienti. Perché è importante Fornisce contesto sulla natura del sinistro, analizzando come diverse cause di perdita influenzano il flusso e la durata del processo. Dove trovare Questo è un campo standard sull'entità Sinistro, tipicamente chiamato 'LossCause'. Esempi CollisioneIncendioDanni da AcquaFurto | |||
Liquidatore Assegnato AssignedAdjuster | Il nome o l'ID dell'utente assegnato alla gestione del sinistro o di un'attività specifica. | ||
Descrizione Questo attributo identifica il perito liquidatore responsabile di un sinistro in un dato momento. Un liquidatore può essere assegnato all'intero sinistro o a compiti specifici. L'analisi per Liquidatore Assegnato è fondamentale per il bilanciamento del carico di lavoro, la gestione delle performance e l'identificazione di opportunità di formazione. Aiuta a rispondere a domande come: 'Quali liquidatori hanno il carico di lavoro più elevato?', 'Esistono variazioni di performance tra i liquidatori?' e 'Il lavoro è distribuito in modo equo?'. Perché è importante Tiene traccia del coinvolgimento degli utenti, permettendo l'analisi del carico di lavoro, il confronto delle performance e l'identificazione dei colli di bottiglia legati alle risorse. Dove trovare Disponibile nell'entità Sinistro o Esposizione in ClaimCenter, spesso collegato all'oggetto User (es. Claim.Assignee). Esempi j.doem.smiths.jones | |||
Stato del Sinistro ClaimStatus | Lo stato complessivo del sinistro al momento dell'evento (ad es. Aperto, Chiuso, Rifiutato). | ||
Descrizione Questo attributo riflette lo stato generale del sinistro. Gli stati chiave includono 'Aperto', 'Chiuso', 'Rifiutato' e 'Riaperto'. Lo stato finale di un sinistro è una metrica di risultato critica. Il monitoraggio dei cambiamenti nello Stato del Sinistro aiuta a definire tappe e risultati chiave del processo. Viene utilizzato per identificare la risoluzione finale di un sinistro, calcolare i tassi di rifiuto e analizzare la frequenza con cui i sinistri vengono riaperti dopo la chiusura, il che spesso indica problemi di processo o insoddisfazione del cliente. Perché è importante Indica l'esito di un sinistro, essenziale per analizzare i tassi di rifiuto, i pattern di chiusura e le frequenze di riapertura dei sinistri. Dove trovare Questo è un campo centrale sull'entità Sinistro, tipicamente chiamato 'Stato' o 'Status'. Esempi ApertoChiusoNegatoRiaperto | |||
Tipo di Sinistro ClaimType | La categoria del sinistro assicurativo, come Auto, Proprietà o Responsabilità Civile. | ||
Descrizione Il Tipo di Sinistro è una categorizzazione fondamentale di un sinistro basata sul settore di attività o sulla natura del danno. I diversi tipi di sinistro seguono spesso processi distinti, presentano livelli di complessità differenti e sono soggetti a normative diverse. Segmentare l'analisi di processo per Tipo di Sinistro è essenziale per ottenere insight significativi. Consente di confrontare le performance dei processi tra diversi settori di attività, identificare i colli di bottiglia specifici per tipo e adattare le iniziative di miglioramento dei processi alle caratteristiche uniche di ciascuna categoria di sinistro. Perché è importante Consente la segmentazione dei sinistri, poiché diversi tipi (ad esempio, Auto vs. Proprietà) seguono spesso processi distinti e hanno obiettivi di performance differenti. Dove trovare Derivato dall'entità Polizza o Sinistro in ClaimCenter, spesso basato sul codice della Linea di Business (LOB). Esempi Auto PrivatiProprietà CommercialeResponsabilità civile generaleInfortuni sul Lavoro | |||
Data del Sinistro LossDate | La data in cui si è verificato l'incidente o il danno che ha attivato il sinistro. | ||
Descrizione La Data del Danno è la data dell'evento effettivo (ad es. incidente d'auto, danno alla proprietà) per il quale è stato aperto il sinistro. Questa è diversa dalla data in cui il sinistro è stato segnalato o creato. Il ritardo temporale tra la Data del Danno e l'attività 'Claim Created' (noto come reporting lag) è un KPI importante. Analizzarlo può fornire insight sul comportamento dei clienti e sull'efficacia dei canali di prima notifica del sinistro (FNOL). Perché è importante Fornisce contesto cruciale sull'origine del sinistro e aiuta ad analizzare il ritardo di segnalazione (tempo dall'incidente alla presentazione). Dove trovare Questo è un campo data fondamentale sull'entità Sinistro, spesso chiamato 'LossDate'. Esempi 2023-05-102023-04-202023-05-28 | |||
Data Obiettivo di Risoluzione ResolutionTargetDate | La data entro cui si prevede che il sinistro venga risolto secondo gli SLA interni o regolamentari. | ||
Descrizione La Data Obiettivo di Risoluzione è una scadenza fissata per la chiusura del sinistro, spesso determinata da fattori come la giurisdizione, il tipo di sinistro e le condizioni della polizza. Serve come benchmark per misurare le prestazioni e la conformità. Questo attributo è fondamentale per la creazione di dashboard di aderenza agli SLA e KPI. Confrontando la data effettiva di 'Claim Closed' con questa data obiettivo, l'analisi può segnalare automaticamente i sinistri in ritardo, misurare le percentuali di adempimento nei tempi previsti e identificare quali tipi di sinistri o dipartimenti faticano a raggiungere i loro obiettivi. Perché è importante Questo è il riferimento per misurare l'adesione ai Service Level Agreement (SLA) e identificare le richieste a rischio di ritardo. Dove trovare Questo può essere un campo personalizzato o derivato in base alle regole di business configurate in ClaimCenter, eventualmente correlato a metriche di sinistro specifiche. Esempi 2023-06-142023-07-202023-08-28 | |||
Dipartimento Department | L'unità di business o il dipartimento responsabile della gestione dell'attività del sinistro. | ||
Descrizione Questo attributo indica il dipartimento o il team a cui appartiene il liquidatore assegnato, come 'Sinistri Auto', 'Sinistri Proprietà' o 'Unità Investigativa Speciale'. Fornisce un contesto organizzativo per il processo. L'analisi per Dipartimento è cruciale per comprendere le performance del processo a livello organizzativo. Aiuta a identificare i ritardi nei passaggi di consegne tra dipartimenti, a confrontare l'efficienza tra i team e ad allocare le risorse in modo più efficace all'interno dell'organizzazione dei sinistri. Perché è importante Fornisce contesto organizzativo, permettendo l'analisi delle performance tra team e evidenziando problemi di passaggio tra reparti. Dove trovare Questa informazione è tipicamente associata al profilo dell'utente o del gruppo assegnato all'interno di ClaimCenter. Esempi Divisione Sinistri AutoUnità Sinistri ProprietàUnità Investigazioni Speciali (UIS) | |||
È automatizzato IsAutomated | Un flag che indica se un'attività è stata eseguita automaticamente dal sistema o da un utente umano. | ||
Descrizione Questo attributo booleano distingue tra le attività eseguite da un sistema (ad esempio, la creazione automatica di riserve, la corrispondenza generata dal sistema) e quelle svolte manualmente da un liquidatore. L'analisi di questo attributo è fondamentale per comprendere il livello di automazione nel processo dei sinistri. Aiuta a identificare i punti critici di intervento manuale, a misurare l'efficacia delle iniziative di straight-through processing e a trovare nuove opportunità di automazione individuando attività ripetitive e basate su regole attualmente eseguite dagli operatori. Perché è importante Distingue tra attività guidate dal sistema e attività umane, aspetto chiave per l'analisi dell'automazione e l'identificazione dei colli di bottiglia manuali. Dove trovare Questo deve spesso essere derivato. Ad esempio, gli eventi registrati da un utente 'di sistema' generico possono essere contrassegnati come automatizzati. Esempi truefalse | |||
È rilavorazione IsRework | Un flag che indica se un'attività rappresenta un ciclo di rilavorazione, che implica un ritorno a una fase di processo precedente. | ||
Descrizione Questo attributo calcolato contrassegna le attività che fanno parte di un ciclo di rilavorazione. Ad esempio, se il processo passa da 'Indagine Completata' a 'Indagine Avviata', la seconda attività 'Indagine Avviata' verrebbe contrassegnata come rilavorazione. Identificare la rilavorazione è fondamentale per scoprire le inefficienze del processo e i problemi di qualità. Il dashboard di Frequenza di Rilavorazione e Rifiuto si basa su questa metrica per quantificare quanto spesso i sinistri deviano dal 'percorso ideale'. L'analisi delle cause di rilavorazione può portare a miglioramenti significativi nella qualità e nella velocità del processo. Perché è importante Evidenzia le inefficienze di processo e i problemi di qualità segnalando esplicitamente le attività che fanno parte di un ciclo di rilavorazione. Dove trovare Questo viene calcolato all'interno dello strumento di process mining analizzando la sequenza di attività per ogni caso. Esempi truefalse | |||
Importo del Pagamento PaymentAmount | L'importo effettivo di denaro pagato per un'attività di pagamento. | ||
Descrizione Questo attributo registra il valore di ogni singolo pagamento effettuato per un sinistro. Un singolo sinistro può avere più pagamenti nel corso del suo ciclo di vita. Questo è essenziale per l'analisi finanziaria nel contesto del Process Mining. Può essere utilizzato per tracciare il totale liquidato per sinistro, analizzare i tempi di approvazione dei pagamenti in base all'importo e collegare le inefficienze del processo ai risultati finanziari. Ad esempio, i sinistri con lunghi tempi di ciclo potrebbero correlare con pagamenti totali più elevati. Perché è importante Tiene traccia delle transazioni finanziarie all'interno di un sinistro, consentendo l'analisi dei valori di pagamento e la loro relazione con le attività di processo. Dove trovare Trovato nelle entità relative al pagamento collegate al sinistro, spesso in una tabella di transazioni o assegni. Esempi 4500.00125000.00500.00 | |||
Importo Richiesto ClaimedAmount | L'importo monetario totale inizialmente richiesto dal contraente. | ||
Descrizione Questo attributo rappresenta il valore del danno come denunciato dal richiedente. Spesso si tratta di una stima iniziale che può cambiare man mano che il sinistro viene indagato e le riserve vengono accantonate. L'analisi dell'Importo Richiesto aiuta a segmentare i sinistri in base all'impatto finanziario. I sinistri di valore elevato spesso seguono un processo più rigoroso e complesso rispetto a quelli di valore inferiore. Confrontare il processo per diverse fasce di valore può rivelare opportunità per semplificare la gestione dei sinistri più piccoli o applicare controlli più stringenti per quelli più grandi. Perché è importante Consente di segmentare i sinistri in base al valore finanziario, poiché i sinistri di alto valore possono seguire processi diversi e più complessi. Dove trovare Questa informazione potrebbe non essere un singolo campo, ma potrebbe essere derivata dalle stime iniziali del danno registrate sulle esposizioni. Esempi 5000.00150000.00750.50 | |||
Ora di Fine EndTime | Il timestamp che indica quando un'attività è stata completata. | ||
Descrizione L'Ora di Fine segna il completamento di un'attività, soprattutto per i task che hanno una durata misurabile, come 'Investigation' o 'Document Review'. Mentre molte attività di process mining sono istantanee (StartTime è sufficiente), le attività con un inizio e una fine distinti sono meglio rappresentate con entrambi i timestamp. Questo attributo consente il calcolo preciso del tempo di elaborazione dell'attività, distinto dal tempo di attesa. Aiuta a identificare quali task specifici richiedono molto tempo, piuttosto che limitarsi a osservare lunghi ritardi tra i diversi passaggi. Perché è importante Consente la misurazione precisa di quanto tempo impiega un'attività per essere completata, separando il tempo di elaborazione dal tempo di attesa. Dove trovare Questo potrebbe dover essere derivato trovando un evento successivo che conclude logicamente l'attività (ad esempio, un cambio di stato da 'In corso' a 'Completato'). Esempi 2023-05-15T17:00:00Z2023-05-16T15:00:00Z2023-06-02T10:00:00Z | |||
Richiesta Informazioni Ripetuta RepeatedInfoRequestFlag | Un flag che indica se l'attività 'Informazioni Aggiuntive Richieste' si è verificata più di una volta per lo stesso sinistro. | ||
Descrizione Questo flag booleano è impostato su true se un sinistro presenta più di un'attività 'Richiesta Info Aggiuntive'. Questo scenario spesso indica inefficienze nella fase iniziale di raccolta delle informazioni. Questo attributo supporta direttamente il KPI 'Tasso di Richieste di Informazioni Ripetute'. Aiuta a quantificare il problema della raccolta iniziale incompleta dei fatti, che può portare a ritardi significativi e frustrazione del cliente. L'analisi dei sinistri con questo flag può aiutare a migliorare le checklist e le procedure per i liquidatori al fine di garantire che tutte le informazioni necessarie vengano richieste in una sola volta. Perché è importante Identifica le inefficienze dove la raccolta di informazioni non viene completata la prima volta, causando ritardi di processo e rilavorazioni. Dove trovare Calcolato all'interno dello strumento di Process Mining contando le occorrenze dell'attività 'Informazioni Aggiuntive Richieste' per ciascun caso. Esempi truefalse | |||
Sistema sorgente SourceSystem | Il sistema da cui i dati sono stati estratti. | ||
Descrizione Questo attributo identifica l'origine dei dati degli eventi. In un contesto aziendale moderno, gli eventi relativi ai sinistri possono provenire da diversi sistemi, come un sistema gestionale principale (ad esempio Guidewire), un sistema di gestione documentale o un portale clienti. Specificare il sistema di origine è cruciale per la data governance, la risoluzione di incongruenze nei dati e la comprensione del panorama tecnologico del processo. Aiuta a distinguere tra le fasi centrali del processo e le attività di supporto provenienti da sistemi periferici. Perché è importante Identifica l'origine dei dati, cruciale per la data governance e per le analisi che coinvolgono sistemi multipli integrati. Dove trovare Questo è solitamente un valore statico aggiunto durante il processo di estrazione, trasformazione e caricamento (ETL) dei dati. Esempi Guidewire ClaimCenter v10Customer Portal APIDocumentum | |||
Stato di Giurisdizione JurisdictionState | Lo stato o la giurisdizione che regola il sinistro, e che detta i requisiti normativi. | ||
Descrizione Questo attributo specifica la giurisdizione legale (ad esempio, lo stato federale) sotto la quale viene gestito il sinistro. Le normative assicurative possono variare significativamente tra le giurisdizioni, influenzando le fasi di processo richieste, i tempi di comunicazione e la documentazione. Questo è un attributo vitale per il monitoraggio della compliance. Analizzare il processo per giurisdizione assicura che i requisiti normativi specifici dello stato siano soddisfatti. Può anche spiegare variazioni nei tempi di ciclo o nei percorsi di processo che sono determinate da vincoli legali piuttosto che da inefficienza operativa. Perché è importante Cruciale per l'analisi della compliance, poiché diverse giurisdizioni hanno regolamentazioni diverse che influenzano il processo dei sinistri. Dove trovare Un campo standard sull'entità Sinistro, solitamente denominato 'JurisdictionState'. Esempi CANYTXFL | |||
Stato SLA SLAState | Indica se il sinistro è stato chiuso entro la sua data obiettivo di risoluzione. | ||
Descrizione Questo attributo calcolato fornisce uno stato categorico di rispetto degli SLA per ogni sinistro chiuso. È derivato confrontando il timestamp dell'attività 'Sinistro Chiuso' con la 'Data Obiettivo di Risoluzione'. Questo attributo supporta direttamente il dashboard 'Rispetto Obiettivi di Risoluzione Sinistri' semplificando l'analisi in categorie chiare come 'In Tempo' o 'In Ritardo'. Permette un facile filtraggio e aggregazione per calcolare il tasso complessivo di rispetto degli SLA e per approfondire le ragioni dei ritardi. Perché è importante Fornisce un risultato chiaro per l'aderenza agli SLA, semplificando la filtrazione, l'aggregazione e l'analisi della puntualità. Dove trovare Campo calcolato: IF (ActualCloseDate <= ResolutionTargetDate, 'On Time', 'Late'). Esempi In TempoIn Ritardo | |||
Tempo di Elaborazione ProcessingTime | La durata trascorsa lavorando attivamente su un'attività. | ||
Descrizione Il Tempo di Elaborazione misura il tempo in cui un'attività viene effettivamente lavorata, calcolato come la differenza tra il suo Tempo di Fine e Tempo di Inizio. Questo è distinto dal tempo di ciclo, che include i periodi di attesa. Questa metrica calcolata è vitale per l'analisi delle performance, poiché isola lo sforzo reale richiesto per un'attività dal tempo di inattività o di attesa. Aiuta a identificare con precisione quali passaggi sono realmente dispendiosi in termini di tempo e dove si possono ottenere guadagni di efficienza tramite formazione, strumenti migliori o riprogettazione del processo. Perché è importante Misura il tempo di lavoro effettivo per un'attività, aiutando a distinguere il tempo a valore aggiunto dal tempo di attesa. Dove trovare Campo calcolato: EndTime - StartTime. Entrambi i timestamp devono essere disponibili nei dati di origine. Esempi PT8HPT15MP2D | |||
Tipo di Polizza PolicyType | Lo specifico tipo di polizza assicurativa in base al quale è stato presentato il sinistro. | ||
Descrizione Il Tipo di Polizza offre una classificazione più granulare rispetto al Tipo di Sinistro, dettagliando lo specifico prodotto assicurativo, come 'Polizze Casa', 'Auto Commerciale' o 'Cyber Risk'. Questo livello di dettaglio può rivelare variazioni di processo legate a prodotti specifici. L'analisi del processo per Tipo di Polizza aiuta a scoprire inefficienze specifiche del prodotto. Ad esempio, i sinistri per una polizza appena lanciata potrebbero seguire un processo meno maturo, causando ritardi. Questa analisi può informare la progettazione del prodotto e gli sforzi di standardizzazione dei processi. Perché è importante Consente l'analisi dei processi per specifici prodotti assicurativi, aiutando a identificare le variazioni nella gestione basate sulle specifiche della polizza. Dove trovare Questa informazione si trova nell'entità Polizza, che è collegata al Sinistro. Esempi Multirischio AbitazioniResponsabilità Civile Auto CommercialeInland Marine | |||
Ultimo Aggiornamento Dati LastDataUpdate | Il timestamp che indica l'ultimo aggiornamento o l'estrazione dei dati dal sistema sorgente. | ||
Descrizione Questo attributo fornisce il timestamp dell'ultima estrazione dati dal sistema di origine. È un campo di metadati essenziale per comprendere l'attualità dell'analisi. I dashboard e le analisi dovrebbero visualizzare queste informazioni in modo prominente, in modo che gli utenti siano consapevoli dell'aggiornamento dei dati. Aiuta a valutare se gli insight riflettono lo stato attuale delle operazioni o si basano su dati meno recenti. Perché è importante Indica l'attualità dei dati, garantendo che gli utenti comprendano quanto sia aggiornata l'analisi del processo. Dove trovare Questo valore viene generato e memorizzato durante il processo ETL, rappresentando il timestamp del caricamento dei dati. Esempi 2024-07-28T04:00:00Z2024-07-29T04:00:00Z | |||
Attività di Elaborazione Sinistri
| Activity | Descrizione | ||
|---|---|---|---|
Esposizione Creata | Questa attività indica la creazione di un'esposizione, che rappresenta una specifica potenziale responsabilità o tipo di danno nell'ambito del sinistro (ad es. danni al veicolo, lesioni). Questo è un evento esplicito in Guidewire. | ||
Perché è importante Le esposizioni sono fondamentali per la segmentazione e l'analisi dei sinistri. Tracciare la loro creazione aiuta a comprendere le variazioni di processo basate sulla complessità del sinistro e sul tipo di danno. Dove trovare Rilevato dal CreateTime di un nuovo record nella tabella cc_exposure. Ogni record è collegato a un singolo Claim ID. Acquisisci Identifica il timestamp di creazione di un nuovo record nella tabella dell'entità Exposure. Tipo di evento explicit | |||
Pagamento Approvato | Rappresenta l'approvazione formale di un pagamento di risarcimento. Questo è un evento di audit critico ed è esplicitamente catturato quando un utente con autorità approva la transazione. | ||
Perché è importante Questa pietra miliare sblocca il passaggio finale del pagamento. Analizzare il tempo prima e dopo questa attività aiuta a isolare i ritardi causati dai workflow di approvazione o dalla disponibilità del manager. Dove trovare Questo è spesso un evento esplicito registrato nella tabella cc_history, correlato a un'entità cc_check o cc_transaction, che documenta un cambio di stato da 'In attesa di approvazione' ad 'Approvato'. Acquisisci Monitorare l'evento di cambio di stato a 'Approvato' per una specifica transazione di pagamento. Tipo di evento explicit | |||
Pagamento Emesso | Questa attività segna la fase finale nel processo di pagamento, dove il pagamento viene ufficialmente emesso e inviato al sistema finanziario. Questa è una transazione finanziaria esplicita, registrata. | ||
Perché è importante Questa attività è cruciale per misurare l'efficienza del processo di invio dei pagamenti. Aiuta a differenziare tra i ritardi di approvazione e i ritardi nell'effettiva emissione dei fondi. Dove trovare Rilevato dalla IssueDate o da un cambio di stato a 'Issued' o 'Submitted' sull'entità cc_check o cc_transaction. Questo è spesso un event esplicito con timestamp. Acquisisci Identifica la IssueDate o il timestamp del cambiamento di stato in 'Issued' sul record di pagamento. Tipo di evento explicit | |||
Riserva Iniziale Impostata | Segna la creazione della prima transazione di riserva finanziaria per un'esposizione, stimando il costo potenziale del sinistro. Questo è un evento finanziario critico e viene acquisito esplicitamente. | ||
Perché è importante Questa pietra miliare è fondamentale per l'analisi finanziaria e per comprendere quanto rapidamente venga valutata la potenziale responsabilità. I ritardi possono avere un impatto sulla pianificazione finanziaria e sul reporting. Dove trovare Questo evento viene rilevato dalla creazione del primo record cc_reserveline associato a un'esposizione sul sinistro. Il CreateTime della transazione è il timestamp dell'evento. Acquisisci Trova il timestamp di creazione minimo di tutte le linee di riserva per le esposizioni di un dato sinistro. Tipo di evento explicit | |||
Sinistro Chiuso | Indica la chiusura di un sinistro con successo, dopo attività e pagamenti. È l'evento finale principale, dedotto dal cambiamento di stato del sinistro. | ||
Perché è importante Come evento finale primario, questa attività è essenziale per calcolare il tempo di ciclo end-to-end e misurare l'aderenza agli SLA. Segna il completamento del ciclo di vita del sinistro. Dove trovare Dedotto da un cambiamento nel campo State della tabella cc_claim a 'Closed'. Il timestamp dell'evento è la CloseDate sul record del sinistro. Acquisisci Identifica quando il campo dello stato master della richiesta di risarcimento viene aggiornato a 'Closed'. Tipo di evento inferred | |||
Sinistro Creato | Questa attività segna la prima notifica di sinistro (FNOL) e la creazione ufficiale di un nuovo record di sinistro in Guidewire ClaimCenter. Viene acquisita esplicitamente quando una nuova entità Claim viene salvata nel database per la prima volta. | ||
Perché è importante Come evento iniziale primario, questa attività è essenziale per misurare il tempo di ciclo end-to-end del sinistro. Fornisce la base di riferimento per tutti i KPI di performance e durata successivi. Dove trovare Questo è un evento esplicito catturato dal CreateTime della tabella cc_claim. La creazione di un nuovo record con un ID Sinistro univoco funge da trigger dell'evento. Acquisisci Identifica il timestamp di creazione del nuovo record nella tabella dell'entità base Claim. Tipo di evento explicit | |||
Sinistro Negato | Rappresenta la decisione finale di rifiutare un sinistro, servendo come punto finale del processo. Questo evento è dedotto dal cambiamento di stato del sinistro in uno stato chiuso con la ragione 'Rifiutato'. | ||
Perché è importante Questo è un evento di risultato critico. L'analisi della frequenza, delle ragioni e dei percorsi di processo che portano ai rifiuti aiuta a identificare problemi nell'acquisizione del sinistro, nell'indagine o nell'interpretazione della polizza. Dove trovare Dedotto da un cambiamento nel campo State della tabella cc_claim a 'Closed', combinato con il campo CloseReason che è 'Denied' o un valore simile. Il timestamp dell'evento è la CloseDate. Acquisisci Filtra per i cambiamenti di stato del sinistro a 'Chiuso' dove il codice motivo indica un rifiuto. Tipo di evento inferred | |||
Decisione sulla Responsabilità presa | Indica il momento in cui è stata presa una decisione sulla responsabilità o sulla colpa per un'esposizione. Questo evento è tipicamente dedotto da un cambio di stato sull'entità Esposizione. | ||
Perché è importante Questo è un traguardo decisionale critico che precede le fasi di liquidazione e pagamento. L'analisi del tempo impiegato per giungere a questa decisione aiuta a identificare i colli di bottiglia nelle fasi di indagine e valutazione. Dove trovare Dedotto dalla tabella cc_history monitorando un cambiamento nel campo State o in un campo di stato di responsabilità personalizzato sull'entità cc_exposure. Il timestamp del record di cronologia indica l'ora dell'evento. Acquisisci Monitorare i log di audit o le tabelle di storico per gli aggiornamenti allo stato dell'esposizione o allo stato di responsabilità. Tipo di evento inferred | |||
Indagine avviata | Indica l'inizio formale della fase di indagine per un sinistro o un'esposizione. Questo è spesso inferito dalla creazione della prima 'Activity' (task) correlata all'indagine in Guidewire. | ||
Perché è importante Questa attività segna l'inizio di una fase chiave, spesso lunga. Analizzare il tempo fino all'avvio dell'indagine e la durata dell'indagine stessa rivela i maggiori colli di bottiglia. Dove trovare Dedotto dal CreateTime di un record cc_activity dove l'ActivityPattern è correlato all'indagine (es. 'Initial Investigation', 'Contact Witness'). Acquisisci Identifica la prima creazione di un task con un pattern o un oggetto correlato all'indagine. Tipo di evento inferred | |||
Informazioni Aggiuntive Ricevute | Segna il completamento di una richiesta di informazioni aggiuntive. Ciò viene rilevato quando la corrispondente 'Activity' (task) per la richiesta di informazioni viene contrassegnata come 'Completed'. | ||
Perché è importante Questo è il punto finale per il KPI 'Tempo di Ciclo di Raccolta Informazioni Aggiuntive'. Lunghi intervalli tra richiesta e ricezione sono fonti comuni di ritardo nel processo di gestione dei sinistri. Dove trovare Catturato dal CloseTime di un record cc_activity laddove l'ActivityPattern si riferisce a una richiesta di informazioni. Lo stato dell'attività deve essere 'Completato'. Acquisisci Identifica il timestamp di completamento di un task per la richiesta di informazioni esterne. Tipo di evento explicit | |||
Informazioni Aggiuntive Richieste | Rappresenta una richiesta inviata al richiedente o a una terza parte per maggiori informazioni o documentazione. Questo viene tipicamente catturato come un'esplicita 'Attività' (task) creata in ClaimCenter. | ||
Perché è importante Questa attività è il punto di partenza per misurare il KPI 'Additional Info Gathering Cycle Time'. Frequenti occorrenze possono segnalare processi FNOL incompleti o una raccolta di informazioni inefficiente. Dove trovare Rilevato dal CreateTime di un record cc_activity dove l'ActivityPattern è correlato alla richiesta di documentazione o informazioni a una parte esterna. Acquisisci Identifica la creazione di un task per la richiesta di informazioni esterne. Tipo di evento explicit | |||
Liquidazione Calcolata | Questa attività rappresenta il momento in cui è stato determinato un importo di liquidazione, ma non ancora approvato per il pagamento. Può essere dedotta dalla creazione di un pagamento in stato di 'Pending Approval'. | ||
Perché è importante Segna il passaggio dalla valutazione al pagamento, punto di partenza per il KPI 'Tempo di Autorizzazione Pagamento', rivelando ritardi nella catena di approvazione. Dove trovare Dedotto dal CreateTime di un record cc_check o cc_transaction il cui stato iniziale è 'Pending Approval' o uno stato simile prima di 'Approved'. Acquisisci Identifica la creazione di un record di pagamento o transazione in uno stato di pre-approvazione. Tipo di evento inferred | |||
Sinistro Assegnato | Rappresenta l'assegnazione di un sinistro a un utente specifico (liquidatore) o a un gruppo per la gestione. Questo viene tipicamente dedotto monitorando i cambiamenti nei campi di assegnazione sull'entità Sinistro. | ||
Perché è importante Il tracciamento degli incarichi è fondamentale per analizzare il carico di lavoro dei periti, identificare i colli di bottiglia nel routing e misurare il tempo di prima azione da parte del gestore assegnato. Dove trovare Dedotto dalla tabella cc_history monitorando i cambiamenti ai campi AssignedUser o AssignedGroup associati a uno specifico Claim ID. Il timestamp del cambiamento indica quando si è verificato l'evento. Acquisisci Monitorare i log di audit o le tabelle di storico per gli aggiornamenti ai campi di assegnazione del sinistro. Tipo di evento inferred | |||
Sinistro Riaperto | Rappresenta un sinistro che viene spostato da uno stato 'Chiuso' a uno stato 'Aperto' per eseguire lavori aggiuntivi. Questo evento è dedotto da una sequenza specifica di cambiamento di stato. | ||
Perché è importante Questa attività indica una rilavorazione. Volumi elevati di sinistri riaperti indicano problemi con la liquidazione iniziale, danni non rilevati o altri fallimenti di processo, portando a maggiori costi e inefficienza. Dove trovare Dedotto dalla tabella cc_history identificando un cambiamento nel campo State dell'entità cc_claim da 'Closed' di nuovo a 'Open' o a un altro stato attivo. Acquisisci Monitorare il campo dello stato principale del sinistro per una transizione da uno stato chiuso a uno aperto. Tipo di evento inferred | |||
Guide all'Estrazione
Fasi
- Verifica Prerequisiti: Assicurati di disporre delle autorizzazioni e delle credenziali necessarie per accedere al database del data mart Guidewire DataHub / InfoCenter con privilegi di sola lettura. Verifica che i job ETL che popolano il data mart dei sinistri funzionino correttamente e che i dati siano aggiornati.
- Connessione al Database: Utilizza un client SQL standard (come DBeaver, SQL Server Management Studio o strumenti simili) per stabilire una connessione al server del database del data mart.
- Esplorazione dello Schema: Prima di eseguire l'intera query, familiarizza con lo schema del data mart. Identifica le tabelle principali relative ai sinistri, alle esposizioni, alle attività e alle transazioni finanziarie. Le tabelle chiave sono tipicamente denominate con suffissi come _dim (dimensione) e _fact (fatto). Questo ti aiuterà a convalidare i nomi delle tabelle e delle colonne placeholder nello script fornito.
- Prepara la Query SQL: Copia lo script SQL completo fornito nella sezione query nell'editor di query del tuo client SQL.
- Personalizza i Placeholder: Esamina attentamente lo script e sostituisci tutti i valori placeholder. Ciò include il nome del database/schema (ad esempio, [YourDataMart]), i parametri dell'intervallo di date ('[StartDate]', '[EndDate]') e qualsiasi valore di configurazione specifico del sistema (ad esempio, modelli di attività, codici di stato).
- Esecuzione della Query: Esegui la query SQL modificata sul data mart. Il tempo di esecuzione potrebbe variare a seconda dell'intervallo di date selezionato e del volume di dati nel tuo sistema.
- Revisione Iniziale dei Dati: Una volta completata la query, controlla le prime centinaia di righe del set di risultati. Verifica che le colonne ClaimID, ActivityName e EventTime siano popolate come previsto e che siano presenti diversi tipi di attività.
- Esporta in CSV: Esporta l'intero set di risultati dal tuo client SQL in un file CSV. Nomina il file in modo descrittivo, ad esempio, guidewire_claimcenter_event_log.csv.
- Formattazione per ProcessMind: Assicurati che il file CSV sia salvato con codifica UTF-8. Verifica che il file abbia una riga di intestazione corrispondente agli alias delle colonne nella query SQL. Il file è ora pronto per essere caricato su ProcessMind.
Configurazione
- Origine Dati: Guidewire DataHub/InfoCenter Claims Data Mart. Si tratta di un database dimensionale pre-aggregato, progettato per il reporting e l'analisi, separato dal database di produzione live di ClaimCenter.
- Autorizzazioni Richieste: Accesso in sola lettura al database SQL che ospita il data mart. Saranno necessari un nome utente, una password e i dettagli di connessione (indirizzo del server, nome del database).
- Stato dei Job ETL: L'accuratezza di questa estrazione dipende dall'esecuzione corretta e tempestiva dei job ETL di Guidewire che popolano il data mart. Verificare l'ora dell'ultima esecuzione riuscita per comprendere la freschezza dei dati.
- Filtro per Intervallo di Date: La query fornita include clausole WHERE con i placeholder '[StartDate]' e '[EndDate]'. Si consiglia di iniziare con un intervallo di date limitato (ad es., 3-6 mesi) per gestire le performance. Il filtro data viene applicato sul campo CreateTime del sinistro.
- Valori Specifici della Configurazione: Guidewire è altamente configurabile. È necessario adattare i valori nelle clausole WHERE affinché corrispondano alla configurazione della propria organizzazione. Questo include:
- Nomi di ActivityPattern (ad es., 'fnol', 'investigation', 'Request additional information')
- Codici di ClaimStatus, ExposureStatus e CloseReason (ad es., 'denied', 'closed')
- Codici di TransactionStatus (ad es., 'pendingapproval', 'approved', 'issued')
- Performance: L'interrogazione di tabelle di storico o di audit di grandi dimensioni può richiedere molte risorse. Per dataset molto grandi, si raccomanda di eseguire la query durante le ore non di punta. Assicurarsi che le colonne ClaimID o ClaimNumber siano indicizzate sulle tabelle pertinenti.
a Query di Esempio sql
`sql
-- This query extracts a process mining event log for claims processing from a Guidewire DataHub/InfoCenter Data Mart.
-- Replace placeholders: [YourDataMart], [StartDate], [EndDate], and any configuration-specific string literals.
WITH ClaimHistory AS (
-- Pre-process claim history to identify status changes, especially for Reopened events.
SELECT
ClaimID,
Status,
UpdateTime,
LAG(Status, 1) OVER (PARTITION BY ClaimID ORDER BY UpdateTime) AS PreviousStatus
FROM [YourDataMart].[dbo].[ClaimHistory_dim] -- Placeholder for claim history/audit table
),
BaseClaims AS (
-- Select the set of claims to be analyzed based on a date range.
SELECT
c.ClaimID AS ClaimPublicID, -- Using PublicID as it's often the user-facing ID
c.ClaimNumber AS ClaimID,
c.AssignedAdjusterName AS AssignedAdjuster,
c.PolicyType AS ClaimType,
c.ClaimStatus AS ClaimStatus,
c.LossCause AS LossCause,
c.CreateTime
FROM [YourDataMart].[dbo].[Claim_dim] c
WHERE c.CreateTime >= '[StartDate]' AND c.CreateTime < '[EndDate]'
)
-- 1. Claim Created
SELECT
bc.ClaimID AS ClaimID,
'Claim Created' AS ActivityName,
bc.CreateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
UNION ALL
-- 2. Claim Assigned
-- This captures the first assignment event from the history table.
SELECT
bc.ClaimID,
'Claim Assigned' AS ActivityName,
MIN(ch.UpdateTime) AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[ClaimHistory_dim] ch ON bc.ClaimPublicID = ch.ClaimID
WHERE ch.EventType = 'Assignment' -- Assumes an EventType column exists to identify assignment changes
GROUP BY bc.ClaimID, bc.AssignedAdjuster, bc.ClaimType, bc.ClaimStatus, bc.LossCause
UNION ALL
-- 3. Exposure Created
SELECT
bc.ClaimID,
'Exposure Created' AS ActivityName,
e.CreateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Exposure_dim] e ON bc.ClaimPublicID = e.ClaimID
UNION ALL
-- 4. Initial Reserve Set
-- Finds the very first reserve transaction for any exposure on the claim.
SELECT
x.ClaimID,
'Initial Reserve Set' AS ActivityName,
x.EventTime,
x.AssignedAdjuster,
x.ClaimType,
x.ClaimStatus,
x.LossCause
FROM (
SELECT
bc.ClaimID,
t.CreateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause,
ROW_NUMBER() OVER(PARTITION BY bc.ClaimID ORDER BY t.CreateTime) as rn
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Transaction_fact] t ON bc.ClaimPublicID = t.ClaimID
WHERE t.TransactionType = 'Reserve'
) x
WHERE x.rn = 1
UNION ALL
-- 5. Investigation Started
-- Finds the creation of the first investigation-related activity.
SELECT
x.ClaimID,
'Investigation Started' AS ActivityName,
x.EventTime,
x.AssignedAdjuster,
x.ClaimType,
x.ClaimStatus,
x.LossCause
FROM (
SELECT
bc.ClaimID,
a.CreateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause,
ROW_NUMBER() OVER(PARTITION BY bc.ClaimID ORDER BY a.CreateTime) as rn
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Activity_dim] a ON bc.ClaimPublicID = a.ClaimID
WHERE a.ActivityPatternName LIKE '%Investigation%'
) x
WHERE x.rn = 1
UNION ALL
-- 6. Additional Info Requested
SELECT
bc.ClaimID,
'Additional Info Requested' AS ActivityName,
a.CreateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Activity_dim] a ON bc.ClaimPublicID = a.ClaimID
WHERE a.ActivityPatternName LIKE '%Request%Information%'
UNION ALL
-- 7. Additional Info Received
SELECT
bc.ClaimID,
'Additional Info Received' AS ActivityName,
a.CompletionTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Activity_dim] a ON bc.ClaimPublicID = a.ClaimID
WHERE a.ActivityPatternName LIKE '%Request%Information%' AND a.CompletionTime IS NOT NULL
UNION ALL
-- 8. Liability Decision Made
-- Captures when an exposure's liability decision is first set.
SELECT
x.ClaimID,
'Liability Decision Made' AS ActivityName,
x.EventTime,
x.AssignedAdjuster,
x.ClaimType,
x.ClaimStatus,
x.LossCause
FROM (
SELECT
bc.ClaimID,
eh.UpdateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause,
ROW_NUMBER() OVER(PARTITION BY bc.ClaimID ORDER BY eh.UpdateTime) as rn
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[ExposureHistory_dim] eh ON bc.ClaimPublicID = eh.ClaimID
WHERE eh.LiabilityDecision IS NOT NULL AND eh.PreviousLiabilityDecision IS NULL -- Captures the first time it was set
) x
WHERE x.rn = 1
UNION ALL
-- 9. Settlement Calculated
-- Captures the creation of a payment transaction that is pending approval.
SELECT
bc.ClaimID,
'Settlement Calculated' AS ActivityName,
t.CreateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Transaction_fact] t ON bc.ClaimPublicID = t.ClaimID
WHERE t.TransactionType = 'Payment' AND t.TransactionStatus = 'PendingApproval'
UNION ALL
-- 10. Payment Approved
SELECT
bc.ClaimID,
'Payment Approved' AS ActivityName,
t.ApprovalDate AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Transaction_fact] t ON bc.ClaimPublicID = t.ClaimID
WHERE t.TransactionType = 'Payment' AND t.ApprovalDate IS NOT NULL AND t.TransactionStatus = 'Approved'
UNION ALL
-- 11. Payment Issued
SELECT
bc.ClaimID,
'Payment Issued' AS ActivityName,
t.IssueDate AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Transaction_fact] t ON bc.ClaimPublicID = t.ClaimID
WHERE t.TransactionType = 'Payment' AND t.IssueDate IS NOT NULL AND t.TransactionStatus = 'Issued'
UNION ALL
-- 12. Claim Denied
SELECT
bc.ClaimID,
'Claim Denied' AS ActivityName,
ch.UpdateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
'Denied' AS ClaimStatus, -- Overriding status for clarity
bc.LossCause
FROM BaseClaims bc
JOIN ClaimHistory ch ON bc.ClaimPublicID = ch.ClaimID
WHERE ch.Status = 'Closed' AND ch.PreviousStatus <> 'Closed'
AND EXISTS (SELECT 1 FROM [YourDataMart].[dbo].[Claim_dim] c2 WHERE c2.ClaimID = bc.ClaimPublicID AND c2.CloseReason = 'Denied')
UNION ALL
-- 13. Claim Closed
SELECT
bc.ClaimID,
'Claim Closed' AS ActivityName,
ch.UpdateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
'Closed' AS ClaimStatus, -- Overriding status for clarity
bc.LossCause
FROM BaseClaims bc
JOIN ClaimHistory ch ON bc.ClaimPublicID = ch.ClaimID
WHERE ch.Status = 'Closed' AND ch.PreviousStatus <> 'Closed'
AND NOT EXISTS (SELECT 1 FROM [YourDataMart].[dbo].[Claim_dim] c2 WHERE c2.ClaimID = bc.ClaimPublicID AND c2.CloseReason = 'Denied')
UNION ALL
-- 14. Claim Reopened
SELECT
bc.ClaimID,
'Claim Reopened' AS ActivityName,
ch.UpdateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
'Open' AS ClaimStatus, -- Overriding status for clarity
bc.LossCause
FROM BaseClaims bc
JOIN ClaimHistory ch ON bc.ClaimPublicID = ch.ClaimID
WHERE ch.PreviousStatus = 'Closed' AND ch.Status <> 'Closed';
`Fasi
- Verifica Prerequisiti: Assicurati di disporre delle autorizzazioni e delle credenziali necessarie per accedere al database del data mart Guidewire DataHub / InfoCenter con privilegi di sola lettura. Verifica che i job ETL che popolano il data mart dei sinistri funzionino correttamente e che i dati siano aggiornati.
- Connessione al Database: Utilizza un client SQL standard (come DBeaver, SQL Server Management Studio o strumenti simili) per stabilire una connessione al server del database del data mart.
- Esplorazione dello Schema: Prima di eseguire l'intera query, familiarizza con lo schema del data mart. Identifica le tabelle principali relative ai sinistri, alle esposizioni, alle attività e alle transazioni finanziarie. Le tabelle chiave sono tipicamente denominate con suffissi come _dim (dimensione) e _fact (fatto). Questo ti aiuterà a convalidare i nomi delle tabelle e delle colonne placeholder nello script fornito.
- Prepara la Query SQL: Copia lo script SQL completo fornito nella sezione query nell'editor di query del tuo client SQL.
- Personalizza i Placeholder: Esamina attentamente lo script e sostituisci tutti i valori placeholder. Ciò include il nome del database/schema (ad esempio, [YourDataMart]), i parametri dell'intervallo di date ('[StartDate]', '[EndDate]') e qualsiasi valore di configurazione specifico del sistema (ad esempio, modelli di attività, codici di stato).
- Esecuzione della Query: Esegui la query SQL modificata sul data mart. Il tempo di esecuzione potrebbe variare a seconda dell'intervallo di date selezionato e del volume di dati nel tuo sistema.
- Revisione Iniziale dei Dati: Una volta completata la query, controlla le prime centinaia di righe del set di risultati. Verifica che le colonne ClaimID, ActivityName e EventTime siano popolate come previsto e che siano presenti diversi tipi di attività.
- Esporta in CSV: Esporta l'intero set di risultati dal tuo client SQL in un file CSV. Nomina il file in modo descrittivo, ad esempio, guidewire_claimcenter_event_log.csv.
- Formattazione per ProcessMind: Assicurati che il file CSV sia salvato con codifica UTF-8. Verifica che il file abbia una riga di intestazione corrispondente agli alias delle colonne nella query SQL. Il file è ora pronto per essere caricato su ProcessMind.
Configurazione
- Origine Dati: Guidewire DataHub/InfoCenter Claims Data Mart. Si tratta di un database dimensionale pre-aggregato, progettato per il reporting e l'analisi, separato dal database di produzione live di ClaimCenter.
- Autorizzazioni Richieste: Accesso in sola lettura al database SQL che ospita il data mart. Saranno necessari un nome utente, una password e i dettagli di connessione (indirizzo del server, nome del database).
- Stato dei Job ETL: L'accuratezza di questa estrazione dipende dall'esecuzione corretta e tempestiva dei job ETL di Guidewire che popolano il data mart. Verificare l'ora dell'ultima esecuzione riuscita per comprendere la freschezza dei dati.
- Filtro per Intervallo di Date: La query fornita include clausole WHERE con i placeholder '[StartDate]' e '[EndDate]'. Si consiglia di iniziare con un intervallo di date limitato (ad es., 3-6 mesi) per gestire le performance. Il filtro data viene applicato sul campo CreateTime del sinistro.
- Valori Specifici della Configurazione: Guidewire è altamente configurabile. È necessario adattare i valori nelle clausole WHERE affinché corrispondano alla configurazione della propria organizzazione. Questo include:
- Nomi di ActivityPattern (ad es., 'fnol', 'investigation', 'Request additional information')
- Codici di ClaimStatus, ExposureStatus e CloseReason (ad es., 'denied', 'closed')
- Codici di TransactionStatus (ad es., 'pendingapproval', 'approved', 'issued')
- Performance: L'interrogazione di tabelle di storico o di audit di grandi dimensioni può richiedere molte risorse. Per dataset molto grandi, si raccomanda di eseguire la query durante le ore non di punta. Assicurarsi che le colonne ClaimID o ClaimNumber siano indicizzate sulle tabelle pertinenti.
a Query di Esempio sql
`sql
-- This query extracts a process mining event log for claims processing from a Guidewire DataHub/InfoCenter Data Mart.
-- Replace placeholders: [YourDataMart], [StartDate], [EndDate], and any configuration-specific string literals.
WITH ClaimHistory AS (
-- Pre-process claim history to identify status changes, especially for Reopened events.
SELECT
ClaimID,
Status,
UpdateTime,
LAG(Status, 1) OVER (PARTITION BY ClaimID ORDER BY UpdateTime) AS PreviousStatus
FROM [YourDataMart].[dbo].[ClaimHistory_dim] -- Placeholder for claim history/audit table
),
BaseClaims AS (
-- Select the set of claims to be analyzed based on a date range.
SELECT
c.ClaimID AS ClaimPublicID, -- Using PublicID as it's often the user-facing ID
c.ClaimNumber AS ClaimID,
c.AssignedAdjusterName AS AssignedAdjuster,
c.PolicyType AS ClaimType,
c.ClaimStatus AS ClaimStatus,
c.LossCause AS LossCause,
c.CreateTime
FROM [YourDataMart].[dbo].[Claim_dim] c
WHERE c.CreateTime >= '[StartDate]' AND c.CreateTime < '[EndDate]'
)
-- 1. Claim Created
SELECT
bc.ClaimID AS ClaimID,
'Claim Created' AS ActivityName,
bc.CreateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
UNION ALL
-- 2. Claim Assigned
-- This captures the first assignment event from the history table.
SELECT
bc.ClaimID,
'Claim Assigned' AS ActivityName,
MIN(ch.UpdateTime) AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[ClaimHistory_dim] ch ON bc.ClaimPublicID = ch.ClaimID
WHERE ch.EventType = 'Assignment' -- Assumes an EventType column exists to identify assignment changes
GROUP BY bc.ClaimID, bc.AssignedAdjuster, bc.ClaimType, bc.ClaimStatus, bc.LossCause
UNION ALL
-- 3. Exposure Created
SELECT
bc.ClaimID,
'Exposure Created' AS ActivityName,
e.CreateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Exposure_dim] e ON bc.ClaimPublicID = e.ClaimID
UNION ALL
-- 4. Initial Reserve Set
-- Finds the very first reserve transaction for any exposure on the claim.
SELECT
x.ClaimID,
'Initial Reserve Set' AS ActivityName,
x.EventTime,
x.AssignedAdjuster,
x.ClaimType,
x.ClaimStatus,
x.LossCause
FROM (
SELECT
bc.ClaimID,
t.CreateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause,
ROW_NUMBER() OVER(PARTITION BY bc.ClaimID ORDER BY t.CreateTime) as rn
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Transaction_fact] t ON bc.ClaimPublicID = t.ClaimID
WHERE t.TransactionType = 'Reserve'
) x
WHERE x.rn = 1
UNION ALL
-- 5. Investigation Started
-- Finds the creation of the first investigation-related activity.
SELECT
x.ClaimID,
'Investigation Started' AS ActivityName,
x.EventTime,
x.AssignedAdjuster,
x.ClaimType,
x.ClaimStatus,
x.LossCause
FROM (
SELECT
bc.ClaimID,
a.CreateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause,
ROW_NUMBER() OVER(PARTITION BY bc.ClaimID ORDER BY a.CreateTime) as rn
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Activity_dim] a ON bc.ClaimPublicID = a.ClaimID
WHERE a.ActivityPatternName LIKE '%Investigation%'
) x
WHERE x.rn = 1
UNION ALL
-- 6. Additional Info Requested
SELECT
bc.ClaimID,
'Additional Info Requested' AS ActivityName,
a.CreateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Activity_dim] a ON bc.ClaimPublicID = a.ClaimID
WHERE a.ActivityPatternName LIKE '%Request%Information%'
UNION ALL
-- 7. Additional Info Received
SELECT
bc.ClaimID,
'Additional Info Received' AS ActivityName,
a.CompletionTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Activity_dim] a ON bc.ClaimPublicID = a.ClaimID
WHERE a.ActivityPatternName LIKE '%Request%Information%' AND a.CompletionTime IS NOT NULL
UNION ALL
-- 8. Liability Decision Made
-- Captures when an exposure's liability decision is first set.
SELECT
x.ClaimID,
'Liability Decision Made' AS ActivityName,
x.EventTime,
x.AssignedAdjuster,
x.ClaimType,
x.ClaimStatus,
x.LossCause
FROM (
SELECT
bc.ClaimID,
eh.UpdateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause,
ROW_NUMBER() OVER(PARTITION BY bc.ClaimID ORDER BY eh.UpdateTime) as rn
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[ExposureHistory_dim] eh ON bc.ClaimPublicID = eh.ClaimID
WHERE eh.LiabilityDecision IS NOT NULL AND eh.PreviousLiabilityDecision IS NULL -- Captures the first time it was set
) x
WHERE x.rn = 1
UNION ALL
-- 9. Settlement Calculated
-- Captures the creation of a payment transaction that is pending approval.
SELECT
bc.ClaimID,
'Settlement Calculated' AS ActivityName,
t.CreateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Transaction_fact] t ON bc.ClaimPublicID = t.ClaimID
WHERE t.TransactionType = 'Payment' AND t.TransactionStatus = 'PendingApproval'
UNION ALL
-- 10. Payment Approved
SELECT
bc.ClaimID,
'Payment Approved' AS ActivityName,
t.ApprovalDate AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Transaction_fact] t ON bc.ClaimPublicID = t.ClaimID
WHERE t.TransactionType = 'Payment' AND t.ApprovalDate IS NOT NULL AND t.TransactionStatus = 'Approved'
UNION ALL
-- 11. Payment Issued
SELECT
bc.ClaimID,
'Payment Issued' AS ActivityName,
t.IssueDate AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Transaction_fact] t ON bc.ClaimPublicID = t.ClaimID
WHERE t.TransactionType = 'Payment' AND t.IssueDate IS NOT NULL AND t.TransactionStatus = 'Issued'
UNION ALL
-- 12. Claim Denied
SELECT
bc.ClaimID,
'Claim Denied' AS ActivityName,
ch.UpdateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
'Denied' AS ClaimStatus, -- Overriding status for clarity
bc.LossCause
FROM BaseClaims bc
JOIN ClaimHistory ch ON bc.ClaimPublicID = ch.ClaimID
WHERE ch.Status = 'Closed' AND ch.PreviousStatus <> 'Closed'
AND EXISTS (SELECT 1 FROM [YourDataMart].[dbo].[Claim_dim] c2 WHERE c2.ClaimID = bc.ClaimPublicID AND c2.CloseReason = 'Denied')
UNION ALL
-- 13. Claim Closed
SELECT
bc.ClaimID,
'Claim Closed' AS ActivityName,
ch.UpdateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
'Closed' AS ClaimStatus, -- Overriding status for clarity
bc.LossCause
FROM BaseClaims bc
JOIN ClaimHistory ch ON bc.ClaimPublicID = ch.ClaimID
WHERE ch.Status = 'Closed' AND ch.PreviousStatus <> 'Closed'
AND NOT EXISTS (SELECT 1 FROM [YourDataMart].[dbo].[Claim_dim] c2 WHERE c2.ClaimID = bc.ClaimPublicID AND c2.CloseReason = 'Denied')
UNION ALL
-- 14. Claim Reopened
SELECT
bc.ClaimID,
'Claim Reopened' AS ActivityName,
ch.UpdateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
'Open' AS ClaimStatus, -- Overriding status for clarity
bc.LossCause
FROM BaseClaims bc
JOIN ClaimHistory ch ON bc.ClaimPublicID = ch.ClaimID
WHERE ch.PreviousStatus = 'Closed' AND ch.Status <> 'Closed';
`Fasi
- Verifica Prerequisiti: Assicurati di disporre delle autorizzazioni e delle credenziali necessarie per accedere al database del data mart Guidewire DataHub / InfoCenter con privilegi di sola lettura. Verifica che i job ETL che popolano il data mart dei sinistri funzionino correttamente e che i dati siano aggiornati.
- Connessione al Database: Utilizza un client SQL standard (come DBeaver, SQL Server Management Studio o strumenti simili) per stabilire una connessione al server del database del data mart.
- Esplorazione dello Schema: Prima di eseguire l'intera query, familiarizza con lo schema del data mart. Identifica le tabelle principali relative ai sinistri, alle esposizioni, alle attività e alle transazioni finanziarie. Le tabelle chiave sono tipicamente denominate con suffissi come _dim (dimensione) e _fact (fatto). Questo ti aiuterà a convalidare i nomi delle tabelle e delle colonne placeholder nello script fornito.
- Prepara la Query SQL: Copia lo script SQL completo fornito nella sezione query nell'editor di query del tuo client SQL.
- Personalizza i Placeholder: Esamina attentamente lo script e sostituisci tutti i valori placeholder. Ciò include il nome del database/schema (ad esempio, [YourDataMart]), i parametri dell'intervallo di date ('[StartDate]', '[EndDate]') e qualsiasi valore di configurazione specifico del sistema (ad esempio, modelli di attività, codici di stato).
- Esecuzione della Query: Esegui la query SQL modificata sul data mart. Il tempo di esecuzione potrebbe variare a seconda dell'intervallo di date selezionato e del volume di dati nel tuo sistema.
- Revisione Iniziale dei Dati: Una volta completata la query, controlla le prime centinaia di righe del set di risultati. Verifica che le colonne ClaimID, ActivityName e EventTime siano popolate come previsto e che siano presenti diversi tipi di attività.
- Esporta in CSV: Esporta l'intero set di risultati dal tuo client SQL in un file CSV. Nomina il file in modo descrittivo, ad esempio, guidewire_claimcenter_event_log.csv.
- Formattazione per ProcessMind: Assicurati che il file CSV sia salvato con codifica UTF-8. Verifica che il file abbia una riga di intestazione corrispondente agli alias delle colonne nella query SQL. Il file è ora pronto per essere caricato su ProcessMind.
Configurazione
- Origine Dati: Guidewire DataHub/InfoCenter Claims Data Mart. Si tratta di un database dimensionale pre-aggregato, progettato per il reporting e l'analisi, separato dal database di produzione live di ClaimCenter.
- Autorizzazioni Richieste: Accesso in sola lettura al database SQL che ospita il data mart. Saranno necessari un nome utente, una password e i dettagli di connessione (indirizzo del server, nome del database).
- Stato dei Job ETL: L'accuratezza di questa estrazione dipende dall'esecuzione corretta e tempestiva dei job ETL di Guidewire che popolano il data mart. Verificare l'ora dell'ultima esecuzione riuscita per comprendere la freschezza dei dati.
- Filtro per Intervallo di Date: La query fornita include clausole WHERE con i placeholder '[StartDate]' e '[EndDate]'. Si consiglia di iniziare con un intervallo di date limitato (ad es., 3-6 mesi) per gestire le performance. Il filtro data viene applicato sul campo CreateTime del sinistro.
- Valori Specifici della Configurazione: Guidewire è altamente configurabile. È necessario adattare i valori nelle clausole WHERE affinché corrispondano alla configurazione della propria organizzazione. Questo include:
- Nomi di ActivityPattern (ad es., 'fnol', 'investigation', 'Request additional information')
- Codici di ClaimStatus, ExposureStatus e CloseReason (ad es., 'denied', 'closed')
- Codici di TransactionStatus (ad es., 'pendingapproval', 'approved', 'issued')
- Performance: L'interrogazione di tabelle di storico o di audit di grandi dimensioni può richiedere molte risorse. Per dataset molto grandi, si raccomanda di eseguire la query durante le ore non di punta. Assicurarsi che le colonne ClaimID o ClaimNumber siano indicizzate sulle tabelle pertinenti.
a Query di Esempio sql
`sql
-- This query extracts a process mining event log for claims processing from a Guidewire DataHub/InfoCenter Data Mart.
-- Replace placeholders: [YourDataMart], [StartDate], [EndDate], and any configuration-specific string literals.
WITH ClaimHistory AS (
-- Pre-process claim history to identify status changes, especially for Reopened events.
SELECT
ClaimID,
Status,
UpdateTime,
LAG(Status, 1) OVER (PARTITION BY ClaimID ORDER BY UpdateTime) AS PreviousStatus
FROM [YourDataMart].[dbo].[ClaimHistory_dim] -- Placeholder for claim history/audit table
),
BaseClaims AS (
-- Select the set of claims to be analyzed based on a date range.
SELECT
c.ClaimID AS ClaimPublicID, -- Using PublicID as it's often the user-facing ID
c.ClaimNumber AS ClaimID,
c.AssignedAdjusterName AS AssignedAdjuster,
c.PolicyType AS ClaimType,
c.ClaimStatus AS ClaimStatus,
c.LossCause AS LossCause,
c.CreateTime
FROM [YourDataMart].[dbo].[Claim_dim] c
WHERE c.CreateTime >= '[StartDate]' AND c.CreateTime < '[EndDate]'
)
-- 1. Claim Created
SELECT
bc.ClaimID AS ClaimID,
'Claim Created' AS ActivityName,
bc.CreateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
UNION ALL
-- 2. Claim Assigned
-- This captures the first assignment event from the history table.
SELECT
bc.ClaimID,
'Claim Assigned' AS ActivityName,
MIN(ch.UpdateTime) AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[ClaimHistory_dim] ch ON bc.ClaimPublicID = ch.ClaimID
WHERE ch.EventType = 'Assignment' -- Assumes an EventType column exists to identify assignment changes
GROUP BY bc.ClaimID, bc.AssignedAdjuster, bc.ClaimType, bc.ClaimStatus, bc.LossCause
UNION ALL
-- 3. Exposure Created
SELECT
bc.ClaimID,
'Exposure Created' AS ActivityName,
e.CreateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Exposure_dim] e ON bc.ClaimPublicID = e.ClaimID
UNION ALL
-- 4. Initial Reserve Set
-- Finds the very first reserve transaction for any exposure on the claim.
SELECT
x.ClaimID,
'Initial Reserve Set' AS ActivityName,
x.EventTime,
x.AssignedAdjuster,
x.ClaimType,
x.ClaimStatus,
x.LossCause
FROM (
SELECT
bc.ClaimID,
t.CreateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause,
ROW_NUMBER() OVER(PARTITION BY bc.ClaimID ORDER BY t.CreateTime) as rn
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Transaction_fact] t ON bc.ClaimPublicID = t.ClaimID
WHERE t.TransactionType = 'Reserve'
) x
WHERE x.rn = 1
UNION ALL
-- 5. Investigation Started
-- Finds the creation of the first investigation-related activity.
SELECT
x.ClaimID,
'Investigation Started' AS ActivityName,
x.EventTime,
x.AssignedAdjuster,
x.ClaimType,
x.ClaimStatus,
x.LossCause
FROM (
SELECT
bc.ClaimID,
a.CreateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause,
ROW_NUMBER() OVER(PARTITION BY bc.ClaimID ORDER BY a.CreateTime) as rn
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Activity_dim] a ON bc.ClaimPublicID = a.ClaimID
WHERE a.ActivityPatternName LIKE '%Investigation%'
) x
WHERE x.rn = 1
UNION ALL
-- 6. Additional Info Requested
SELECT
bc.ClaimID,
'Additional Info Requested' AS ActivityName,
a.CreateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Activity_dim] a ON bc.ClaimPublicID = a.ClaimID
WHERE a.ActivityPatternName LIKE '%Request%Information%'
UNION ALL
-- 7. Additional Info Received
SELECT
bc.ClaimID,
'Additional Info Received' AS ActivityName,
a.CompletionTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Activity_dim] a ON bc.ClaimPublicID = a.ClaimID
WHERE a.ActivityPatternName LIKE '%Request%Information%' AND a.CompletionTime IS NOT NULL
UNION ALL
-- 8. Liability Decision Made
-- Captures when an exposure's liability decision is first set.
SELECT
x.ClaimID,
'Liability Decision Made' AS ActivityName,
x.EventTime,
x.AssignedAdjuster,
x.ClaimType,
x.ClaimStatus,
x.LossCause
FROM (
SELECT
bc.ClaimID,
eh.UpdateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause,
ROW_NUMBER() OVER(PARTITION BY bc.ClaimID ORDER BY eh.UpdateTime) as rn
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[ExposureHistory_dim] eh ON bc.ClaimPublicID = eh.ClaimID
WHERE eh.LiabilityDecision IS NOT NULL AND eh.PreviousLiabilityDecision IS NULL -- Captures the first time it was set
) x
WHERE x.rn = 1
UNION ALL
-- 9. Settlement Calculated
-- Captures the creation of a payment transaction that is pending approval.
SELECT
bc.ClaimID,
'Settlement Calculated' AS ActivityName,
t.CreateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Transaction_fact] t ON bc.ClaimPublicID = t.ClaimID
WHERE t.TransactionType = 'Payment' AND t.TransactionStatus = 'PendingApproval'
UNION ALL
-- 10. Payment Approved
SELECT
bc.ClaimID,
'Payment Approved' AS ActivityName,
t.ApprovalDate AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Transaction_fact] t ON bc.ClaimPublicID = t.ClaimID
WHERE t.TransactionType = 'Payment' AND t.ApprovalDate IS NOT NULL AND t.TransactionStatus = 'Approved'
UNION ALL
-- 11. Payment Issued
SELECT
bc.ClaimID,
'Payment Issued' AS ActivityName,
t.IssueDate AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Transaction_fact] t ON bc.ClaimPublicID = t.ClaimID
WHERE t.TransactionType = 'Payment' AND t.IssueDate IS NOT NULL AND t.TransactionStatus = 'Issued'
UNION ALL
-- 12. Claim Denied
SELECT
bc.ClaimID,
'Claim Denied' AS ActivityName,
ch.UpdateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
'Denied' AS ClaimStatus, -- Overriding status for clarity
bc.LossCause
FROM BaseClaims bc
JOIN ClaimHistory ch ON bc.ClaimPublicID = ch.ClaimID
WHERE ch.Status = 'Closed' AND ch.PreviousStatus <> 'Closed'
AND EXISTS (SELECT 1 FROM [YourDataMart].[dbo].[Claim_dim] c2 WHERE c2.ClaimID = bc.ClaimPublicID AND c2.CloseReason = 'Denied')
UNION ALL
-- 13. Claim Closed
SELECT
bc.ClaimID,
'Claim Closed' AS ActivityName,
ch.UpdateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
'Closed' AS ClaimStatus, -- Overriding status for clarity
bc.LossCause
FROM BaseClaims bc
JOIN ClaimHistory ch ON bc.ClaimPublicID = ch.ClaimID
WHERE ch.Status = 'Closed' AND ch.PreviousStatus <> 'Closed'
AND NOT EXISTS (SELECT 1 FROM [YourDataMart].[dbo].[Claim_dim] c2 WHERE c2.ClaimID = bc.ClaimPublicID AND c2.CloseReason = 'Denied')
UNION ALL
-- 14. Claim Reopened
SELECT
bc.ClaimID,
'Claim Reopened' AS ActivityName,
ch.UpdateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
'Open' AS ClaimStatus, -- Overriding status for clarity
bc.LossCause
FROM BaseClaims bc
JOIN ClaimHistory ch ON bc.ClaimPublicID = ch.ClaimID
WHERE ch.PreviousStatus = 'Closed' AND ch.Status <> 'Closed';
`