Modèle de données : Traitement des sinistres
Votre modèle de données pour le traitement des sinistres
- Attributs recommandés à collecter
- Activités clés à suivre
- Guide d'extraction pour Guidewire ClaimCenter
Attributs de Gestion des Sinistres
| Nom | Description | ||
|---|---|---|---|
Heure de l'événement EventTime | La date et l'heure précises auxquelles l'activité s'est produite. | ||
Description Ce timestamp marque le moment exact où une activité a été enregistrée dans le système. Il est fondamental pour toute analyse de processus basée sur le temps. L'ordonnancement chronologique du EventTime pour un identifiant de sinistre unique (Claim ID) permet la reconstitution du flux de processus. La différence de temps entre des événements consécutifs est utilisée pour calculer les temps de cycle, les temps d'attente et les temps de traitement, qui sont essentiels pour l'analyse des performances, l'identification des goulots d'étranglement et la surveillance des SLA. Pourquoi c'est important Ce timestamp est essentiel pour ordonner les événements, calculer les temps de cycle et les durées, et identifier les retards dans le processus. Où obtenir Se trouve à côté des données d'événement ou d'activité dans les tables d'historique ou d'audit de Guidewire ClaimCenter, souvent en tant que champ 'CreateTime' ou 'UpdateTime'. Exemples 2023-05-15T09:00:00Z2023-05-16T14:30:15Z2023-06-01T11:20:00Z | |||
Nom de l'activité ActivityName | Le nom de l'activité ou de l'événement commercial qui s'est produit à un moment précis du cycle de vie du sinistre. | ||
Description Cet attribut décrit une étape ou un jalon spécifique du processus de sinistres, tels que « Sinistre Créé », « Enquête Démarrée » ou « Paiement Émis ». La séquence de ces activités pour un ID de sinistre donné forme le flux de processus. L'analyse de la séquence, de la fréquence et de la durée entre les activités est le cœur du Process Mining. Elle permet la découverte de modèles de processus, l'identification des goulots d'étranglement, la détection des boucles de retravail et l'analyse des déviations de processus. Pourquoi c'est important Il définit les étapes du processus, permettant la visualisation des cartes de processus et l'analyse des flux de processus et des goulots d'étranglement. Où obtenir Cette information est généralement tirée des tables d'événements ou des journaux d'audit de ClaimCenter, souvent en associant des événements système ou des changements de statut spécifiques à des noms d'activité standardisés. Exemples Sinistre crééDécision de responsabilité prisePaiement émisSinistre Clos | |||
Numéro de Sinistre ClaimID | L'identifiant unique pour chaque demande d'indemnisation, servant d'identifiant principal du dossier. | ||
Description L'ID de sinistre est la pierre angulaire de l'analyse des processus de sinistres, identifiant de manière unique chaque dossier de la soumission à la clôture. Il relie toutes les activités, documents, paiements et communications associés, assurant une vue complète et cohérente du cycle de vie d'un sinistre. En Process Mining, chaque événement du jeu de données est lié à un ID de sinistre, permettant la reconstruction du flux de processus de bout en bout. Ceci est essentiel pour analyser les temps de cycle, identifier les variantes de processus et suivre le parcours d'un sinistre à travers les différents services et experts en sinistres. Pourquoi c'est important C'est la clé fondamentale qui relie tous les événements connexes, permettant de tracer et d'analyser l'intégralité du parcours d'une seule réclamation. Où obtenir Ceci est une clé primaire dans Guidewire ClaimCenter, généralement trouvée sous le nom de Claim.ClaimNumber ou un champ similaire dans l'entité centrale Claim. Exemples 000-123-45678000-987-65432001-456-11223 | |||
Cause du sinistre LossCause | La raison ou la cause spécifique de l'événement de perte (sinistre) (ex : Collision, Incendie, Dégâts des eaux). | ||
Description Cet attribut offre un contexte détaillé sur la raison du dépôt de la réclamation. La cause du sinistre dicte souvent les étapes d'enquête requises, le type d'experts nécessaires et la complexité globale du dossier. L'analyse du processus par cause du sinistre peut révéler des schémas cachés. Par exemple, les réclamations liées aux « Dégâts des eaux » peuvent présenter un taux de retouche plus élevé ou nécessiter davantage l'intervention de spécialistes, comparativement aux réclamations pour « Vol ». Ces informations clés aident à élaborer des procédures de traitement plus spécialisées et efficientes. Pourquoi c'est important Fournit un contexte sur la nature du sinistre, permettant d'analyser comment différentes causes de pertes impactent le flux et la durée du processus. Où obtenir Il s'agit d'un champ standard de l'entité Claim, généralement appelé 'LossCause'. Exemples CollisionIncendieDégât des eauxVol | |||
Expert en sinistres désigné AssignedAdjuster | Le nom ou l'ID de l'utilisateur assigné pour gérer le sinistre ou une activité spécifique. | ||
Description Cet attribut permet d'identifier le gestionnaire de sinistres individuel responsable d'une réclamation à un moment donné. Un gestionnaire peut être affecté à l'ensemble du dossier ou à des tâches spécifiques de celui-ci. L'analyse par gestionnaire de sinistres est essentielle pour équilibrer la charge de travail, optimiser la gestion de la performance et identifier les besoins en formation. Elle permet de répondre à des questions clés telles que : « Quels gestionnaires ont la charge de travail la plus élevée ? », « Y a-t-il des écarts de performance entre les gestionnaires ? » et « Le travail est-il réparti équitablement ? ». Pourquoi c'est important Suit l'implication des utilisateurs, permettant l'analyse de la charge de travail, la comparaison des performances et l'identification des goulots d'étranglement liés aux ressources. Où obtenir Disponible dans l'entité Sinistre ou Exposition de ClaimCenter, souvent lié à l'objet Utilisateur (par ex., Claim.Assignee). Exemples j.doem.smiths.jones | |||
Statut du Sinistre ClaimStatus | Le statut global du sinistre au moment de l'événement (ex : Ouvert, Clos, Refusé). | ||
Description Cet attribut reflète l'état global de la réclamation. Les statuts clés incluent « Open », « Closed », « Denied » et « Reopened ». Le statut final d'une réclamation est une métrique de résultat essentielle. Le suivi des changements de statut de la réclamation aide à définir les jalons et les résultats clés du processus. Il est utilisé pour identifier la résolution finale d'une réclamation, calculer les taux de rejet et analyser la fréquence des réclamations rouvertes après leur clôture, ce qui indique souvent des problèmes de processus ou une insatisfaction client. Pourquoi c'est important Indique l'issue d'une réclamation, essentielle pour analyser les taux de rejet, les modèles de clôture et les fréquences de réouverture des réclamations. Où obtenir Il s'agit d'un champ central de l'entité Claim, généralement nommé 'State' ou 'Status'. Exemples OuvertClôturéRefuséRouvert | |||
Type de Sinistre ClaimType | La catégorie du sinistre d'assurance, telle que Automobile, Biens ou Responsabilité civile. | ||
Description Le type de sinistre représente une classification fondamentale, établie selon la ligne d'activité concernée ou la nature de la perte. Les différentes catégories de sinistres suivent fréquemment des processus distincts, présentent des niveaux de complexité variables et sont soumises à des réglementations spécifiques. Une segmentation de l'analyse des processus par type de sinistre est donc indispensable pour obtenir des informations exploitables. Cette approche permet de comparer les performances des processus sur diverses lignes d'activité, de détecter les goulets d'étranglement propres à chaque type et d'adapter les initiatives d'amélioration des processus aux particularités de chaque catégorie de sinistre. Pourquoi c'est important Permet la segmentation des sinistres, car les différents types (par ex., automobile vs. immobilier) suivent souvent des processus distincts et ont des objectifs de performance variés. Où obtenir Dérivé de l'entité Policy ou Claim dans ClaimCenter, souvent basé sur le code de la ligne d'activité (LOB). Exemples Automobile personnelleBiens commerciauxResponsabilité civile généraleIndemnisation des travailleurs | |||
Date cible de résolution ResolutionTargetDate | La date à laquelle le sinistre est censé être résolu conformément aux SLA internes ou réglementaires. | ||
Description La Date Cible de Résolution est une échéance fixée pour la clôture des sinistres, souvent déterminée par des facteurs tels que la juridiction, le type de sinistre et les termes de la police. Elle sert de référence pour mesurer la performance et la conformité. Cet attribut est essentiel pour construire des dashboards et des KPI de conformité SLA. En comparant la date réelle de 'Sinistre Clos' à cette date cible, l'analyse peut automatiquement signaler les sinistres en retard, mesurer les taux de performance en temps voulu et identifier quels types de sinistres ou services ont des difficultés à atteindre leurs objectifs. Pourquoi c'est important C'est la référence pour mesurer le respect des accords de niveau de service (SLA) et identifier les réclamations qui risquent d'être en retard. Où obtenir Il peut s'agir d'un champ personnalisé ou d'une valeur dérivée selon les règles métier configurées dans ClaimCenter, potentiellement liée à des métriques de sinistre spécifiques. Exemples 2023-06-142023-07-202023-08-28 | |||
Date du sinistre LossDate | La date à laquelle l'incident ou le sinistre qui a déclenché la demande d'indemnisation est survenu. | ||
Description La Date de Perte est la date de l'événement réel (ex : accident de voiture, dommages matériels) pour lequel le sinistre est déclaré. Ceci est distinct de la date à laquelle le sinistre a été déclaré ou créé. Le décalage temporel entre la Date de Perte et l'activité 'Sinistre Créé' (connu sous le nom de délai de déclaration) est un KPI important. L'analyse de ce délai peut fournir des informations précieuses sur le comportement des clients et l'efficacité des canaux de première déclaration de sinistre. Pourquoi c'est important Fournit un contexte crucial sur l'origine du sinistre et aide à analyser le délai de déclaration (temps entre l'incident et la soumission du sinistre). Où obtenir Il s'agit d'un champ de date fondamental sur l'entité Claim, souvent nommé 'LossDate'. Exemples 2023-05-102023-04-202023-05-28 | |||
Demande d'informations répétée RepeatedInfoRequestFlag | Un indicateur signalant si l'activité « Informations supplémentaires demandées » est survenue plus d'une fois pour le même sinistre. | ||
Description Ce drapeau booléen est défini sur vrai si une réclamation comporte plus d'une activité « Demande d'informations supplémentaires ». Ce scénario indique souvent des inefficacités dans la phase initiale de collecte d'informations. Cet attribut soutient directement le KPI « Taux de demandes d'informations répétées ». Il aide à quantifier le problème d'une collecte initiale de faits incomplète, ce qui peut entraîner des retards importants et la frustration des clients. L'analyse des réclamations avec ce drapeau peut aider à améliorer les listes de contrôle et les procédures pour les gestionnaires de sinistres afin de s'assurer que toutes les informations nécessaires sont demandées en une seule fois. Pourquoi c'est important Identifie les inefficacités lorsque la collecte d'informations n'est pas complète dès la première fois, ce qui entraîne des retards de processus et du retravail. Où obtenir Calculé au sein de l'outil de Process Mining en comptant les occurrences de l'activité « Informations supplémentaires demandées » par dossier. Exemples truefaux | |||
Département Department | L'unité commerciale ou le service responsable du traitement de l'activité de sinistre. | ||
Description Cet attribut précise le département ou l'équipe du gestionnaire de sinistres assigné, par exemple « Sinistres automobiles », « Sinistres immobiliers » ou « Unité des enquêtes spéciales ». Il offre un éclairage sur le contexte organisationnel du processus. L'analyse par département est essentielle pour comprendre la performance du processus au niveau organisationnel. Elle permet d'identifier les retards de transfert inter-départementaux, de comparer l'efficacité entre les équipes et d'allouer les ressources de manière plus efficace au sein de l'organisation des sinistres. Pourquoi c'est important Fournit un contexte organisationnel, permettant une analyse des performances entre les différentes équipes et mettant en évidence les problèmes de transfert interdépartemental. Où obtenir Cette information est généralement associée au profil de l'utilisateur ou du groupe assigné au sein de ClaimCenter. Exemples Division des sinistres automobilesUnité des sinistres immobiliersUnité des Enquêtes Spéciales (UES) | |||
Dernière mise à jour des données LastDataUpdate | Le timestamp indiquant la dernière actualisation ou extraction des données du système source. | ||
Description Cet attribut fournit l'horodatage de la dernière extraction de données du système source. Il s'agit d'un champ de métadonnées essentiel pour évaluer l'actualité de l'analyse. Les dashboards et les analyses devraient afficher cette information de manière visible afin que les utilisateurs soient conscients de la fraîcheur des données. Cela aide à déterminer si les informations reflètent l'état actuel des opérations ou si elles sont basées sur des données plus anciennes. Pourquoi c'est important Indique la fraîcheur des données, garantissant que les utilisateurs comprennent l'actualité de l'analyse des processus. Où obtenir Cette valeur est générée et stockée pendant le processus ETL ; elle représente le timestamp du chargement des données. Exemples 2024-07-28T04:00:00Z2024-07-29T04:00:00Z | |||
Est Automatisé IsAutomated | Un indicateur spécifiant si une activité a été réalisée automatiquement par le système ou par un utilisateur humain. | ||
Description Cet attribut booléen permet de distinguer les activités exécutées par un système (par exemple, la création automatique de réserves, la correspondance générée par le système) de celles effectuées manuellement par un gestionnaire de sinistres. L'analyse de cet attribut est essentielle pour comprendre le niveau d'automatisation dans le processus de traitement des réclamations. Elle aide à identifier les points chauds d'intervention manuelle, à mesurer l'efficacité des initiatives de traitement direct (straight-through processing) et à découvrir de nouvelles opportunités d'automatisation en ciblant les tâches répétitives et basées sur des règles actuellement exécutées par des humains. Pourquoi c'est important Permet de distinguer les activités automatisées de celles qui sont réalisées manuellement, un élément clé pour analyser l'automatisation et identifier les goulots d'étranglement humains. Où obtenir Cette information doit souvent être dérivée. Par exemple, les événements enregistrés par un utilisateur 'système' générique peuvent être identifiés comme automatisés. Exemples truefaux | |||
Est une reprise IsRework | Un indicateur signalant si une activité représente une boucle de retravail, c'est-à-dire un retour à une étape antérieure du processus. | ||
Description Cet attribut calculé signale les activités qui font partie d'une boucle de retouche. Par exemple, si le processus passe de « Investigation Completed » à nouveau à « Investigation Started », la deuxième activité « Investigation Started » serait signalée comme une retouche. L'identification des retouches est fondamentale pour déceler les inefficacités de processus et les problèmes de qualité. Le dashboard « Fréquence des retouches et des rejets » s'appuie sur cette métrique pour quantifier la fréquence à laquelle les réclamations s'écartent du « chemin idéal » (happy path). L'analyse des causes de ces retouches peut conduire à des améliorations significatives de la qualité et de la rapidité des processus. Pourquoi c'est important Met en évidence les inefficacités de processus et les problèmes de qualité en signalant explicitement les activités qui font partie d'une boucle de retravail. Où obtenir Ceci est calculé au sein de l'outil de Process Mining en analysant la séquence d'activités pour chaque cas. Exemples truefaux | |||
État de juridiction JurisdictionState | L'état ou la juridiction régissant le sinistre, qui dicte les exigences réglementaires. | ||
Description Cet attribut précise la juridiction légale (par exemple, l'État américain) sous laquelle la réclamation est traitée. Les réglementations d'assurance peuvent varier considérablement d'une juridiction à l'autre, ce qui impacte les étapes de processus requises, les délais de communication et la documentation. Ceci est un attribut essentiel pour le suivi de la conformité. L'analyse du processus par juridiction garantit que les exigences réglementaires spécifiques à l'État sont respectées. Elle peut également expliquer les variations dans les temps de cycle ou les chemins de processus qui sont dictées par des contraintes légales plutôt que par une inefficacité opérationnelle. Pourquoi c'est important Crucial pour l'analyse de la conformité, car différentes juridictions sont soumises à des réglementations distinctes qui impactent le processus de traitement des sinistres. Où obtenir Un champ standard de l'entité Sinistre, généralement nommé 'JurisdictionState'. Exemples CANYTXFL | |||
Heure de fin EndTime | L'horodatage indiquant quand une activité a été achevée. | ||
Description L'Heure de Fin marque l'achèvement d'une activité, en particulier pour les tâches ayant une durée mesurable, comme l'« Enquête » ou la « Révision de documents ». Bien que de nombreuses activités de Process Mining soient instantanées (StartTime est suffisant), les activités ayant un début et une fin distincts sont mieux représentées avec les deux timestamps. Cet attribut permet le calcul précis du temps de traitement d'une activité, distinct du temps d'attente. Il aide à identifier quelles tâches spécifiques sont chronophages, plutôt que de simplement observer de longs délais entre différentes étapes. Pourquoi c'est important Il permet la mesure précise du temps nécessaire à la réalisation d'une activité, en distinguant le temps de traitement du temps d'attente. Où obtenir Cette information peut être dérivée en identifiant un événement subséquent qui conclut logiquement l'activité (par exemple, un changement de statut de 'En cours' à 'Terminé'). Exemples 2023-05-15T17:00:00Z2023-05-16T15:00:00Z2023-06-02T10:00:00Z | |||
Montant du paiement PaymentAmount | Le montant réel versé pour une activité de paiement. | ||
Description Cet attribut enregistre la valeur de chaque paiement individuel effectué pour une réclamation. Une réclamation unique peut donner lieu à plusieurs paiements au cours de son cycle de vie. Ceci est essentiel pour l'analyse financière dans le contexte du Process Mining. Il peut être utilisé pour suivre le montant total versé par réclamation, analyser les délais d'approbation des paiements en fonction de leur montant, et associer les inefficacités de processus aux résultats financiers. Par exemple, les réclamations présentant des cycles de traitement longs pourraient être corrélées à des paiements totaux plus élevés. Pourquoi c'est important Suit les transactions financières au sein d'un sinistre, permettant l'analyse des montants de paiement et de leur relation avec les activités du processus. Où obtenir Se trouve dans les entités liées au paiement associées au sinistre, souvent dans une table de transactions ou de chèques. Exemples 4500.00125000.00500.00 | |||
Montant réclamé ClaimedAmount | Le montant monétaire total initialement réclamé par le preneur d'assurance. | ||
Description Cet attribut représente la valeur du sinistre telle que déclarée par le demandeur. Il s'agit souvent d'une estimation initiale qui peut évoluer à mesure que la réclamation est examinée et que les réserves sont constituées. L'analyse du montant réclamé aide à segmenter les réclamations en fonction de leur impact financier. Les réclamations de grande valeur suivent souvent un processus plus rigoureux et complexe que celles de faible valeur. La comparaison des processus pour différentes tranches de valeur peut révéler des opportunités de rationalisation du traitement pour les petites réclamations ou d'application de contrôles plus stricts pour les plus importantes. Pourquoi c'est important Permet de segmenter les sinistres par valeur financière, car les sinistres à forte valeur peuvent suivre des processus différents, plus complexes. Où obtenir Cette information n'est peut-être pas un champ unique, mais elle peut être dérivée des estimations initiales de perte enregistrées sur les expositions. Exemples 5000.00150000.00750.50 | |||
Statut SLA SLAState | Indique si la réclamation a été clôturée dans le respect de sa date cible de résolution. | ||
Description Cet attribut calculé fournit un statut catégoriel de conformité aux SLA pour chaque réclamation clôturée. Il est dérivé en comparant l'horodatage de l'activité « Claim Closed » avec la « Resolution Target Date ». Cet attribut soutient directement le dashboard « Respect de l'objectif de résolution des réclamations » en simplifiant l'analyse en catégories claires comme « On Time » ou « Late ». Il permet un filtrage et une agrégation faciles pour calculer le taux global de respect des SLA et pour approfondir les raisons des retards. Pourquoi c'est important Fournit un résultat clair et catégorique pour le respect des SLA, facilitant ainsi le filtrage, l'agrégation et l'analyse de la performance à temps. Où obtenir Champ calculé : SI (ActualCloseDate <= ResolutionTargetDate, 'Dans les délais', 'En retard'). Exemples À tempsEn retard | |||
Système source SourceSystem | Le système d'où les data ont été extraites. | ||
Description Cet attribut détermine la source des données d'événement. Dans un environnement d'entreprise moderne, les événements liés à une réclamation peuvent provenir de divers systèmes : un système central comme Guidewire, un système de gestion documentaire ou un portail client, par exemple. La spécification du système source est cruciale pour la gouvernance des données, le dépannage des incohérences de données et la compréhension de l'architecture technologique du processus. Elle permet de distinguer les étapes fondamentales du processus des activités de support issues des systèmes périphériques. Pourquoi c'est important Permet d'identifier l'origine des données, essentiel pour leur gouvernance et pour les analyses impliquant plusieurs systèmes intégrés. Où obtenir Il s'agit généralement d'une valeur statique ajoutée lors du processus d'extraction, de transformation et de chargement des données (ETL). Exemples Guidewire ClaimCenter v10API du portail clientDocumentum | |||
Temps de traitement ProcessingTime | La durée passée à travailler activement sur une activité. | ||
Description Le temps de traitement mesure le temps pendant lequel une activité est activement travaillée, calculé comme la différence entre son heure de fin et son heure de début. Ceci est distinct du temps de cycle, qui inclut les périodes d'attente. Cette métrique calculée est vitale pour l'analyse des performances car elle isole l'effort réel requis pour une tâche du temps d'inactivité ou d'attente. Elle aide à identifier avec précision les étapes qui sont véritablement chronophages et où des gains d'efficacité peuvent être réalisés par le biais de la formation, de meilleurs outils ou de la refonte des processus. Pourquoi c'est important Mesure le temps de travail actif d'une activité, permettant de distinguer le temps à valeur ajoutée du temps d'attente. Où obtenir Champ calculé : EndTime - StartTime. Nécessite que les deux timestamps soient disponibles dans les données source. Exemples PT8HPT15MP2D | |||
Type de police PolicyType | Le type spécifique de police d'assurance en vertu de laquelle la demande d'indemnisation a été déposée. | ||
Description Le type de police offre une classification plus granulaire que le type de sinistre, détaillant le produit d'assurance spécifique, tel que « habitation », « automobile commerciale » ou « cyber-responsabilité ». Ce niveau de détail peut révéler des variations de processus liées à des produits spécifiques. L'analyse du processus par type de police aide à découvrir les inefficacités spécifiques à un produit. Par exemple, les sinistres pour une police nouvellement lancée peuvent suivre un processus moins mature, entraînant des retards. Cette analyse peut éclairer la conception des produits et les efforts de standardisation des processus. Pourquoi c'est important Permet d'analyser les processus pour des produits d'assurance spécifiques, aidant ainsi à identifier les variations de traitement basées sur les particularités des polices. Où obtenir Cette information se trouve dans l'entité Policy, laquelle est liée à l'entité Claim. Exemples Multirisque HabitationResponsabilité civile automobile commercialeAssurance maritime intérieure | |||
Activités de Gestion des Sinistres
| Activité | Description | ||
|---|---|---|---|
Exposition créée | Cette activité signifie la création d'une exposition, qui représente une responsabilité potentielle spécifique ou un type de perte dans le cadre du sinistre (ex : dommages au véhicule, blessures). C'est un événement explicite dans Guidewire. | ||
Pourquoi c'est important Les expositions sont fondamentales pour la segmentation et l'analyse des sinistres. Suivre leur création aide à comprendre les variations de processus en fonction de la complexité du sinistre et du type de perte. Où obtenir Collecté à partir de la valeur CreateTime d'un nouvel enregistrement dans la table cc_exposure. Chaque enregistrement est rattaché à un unique Claim ID. Capture Identifier le timestamp de création d'un nouvel enregistrement dans la table d'entité Exposure. Type d'événement explicit | |||
Paiement approuvé | Représente l'approbation formelle d'un paiement de règlement. C'est un événement d'audit critique et il est explicitement capturé lorsqu'un utilisateur avec autorité approuve la transaction. | ||
Pourquoi c'est important Ce jalon clé permet de débloquer l'étape finale du paiement. L'analyse du temps avant et après cette activité aide à isoler les retards causés par les workflows d'approbation ou la disponibilité des gestionnaires. Où obtenir Il s'agit souvent d'un événement explicite enregistré dans la table cc_history, lié à une entité cc_check ou cc_transaction, et qui consigne un changement de statut de « Pending Approval » à « Approved ». Capture Suivre l'événement de changement de statut à 'Approuvé' pour une transaction de paiement spécifique. Type d'événement explicit | |||
Paiement émis | Cette activité marque la dernière étape du processus de paiement, où le paiement est officiellement émis et envoyé au système financier. Il s'agit d'une transaction financière explicite et enregistrée. | ||
Pourquoi c'est important Cette activité est cruciale pour mesurer l'efficacité du processus d'envoi des paiements. Elle aide à différencier les retards d'approbation des retards dans l'émission réelle des fonds. Où obtenir Collecté à partir de la IssueDate ou d'un changement de statut à 'Issued' ou 'Submitted' sur l'entité cc_check ou cc_transaction. C'est souvent un event horodaté explicite. Capture Identifier l'IssueDate ou le timestamp du changement de statut à 'Issued' sur l'enregistrement de paiement. Type d'événement explicit | |||
Réserve initiale établie | Marque la création de la première transaction de réserve financière pour une exposition, estimant le coût potentiel de la réclamation. Il s'agit d'un événement financier critique, et il est enregistré explicitement. | ||
Pourquoi c'est important Ce jalon est essentiel pour l'analyse financière et pour comprendre la rapidité d'évaluation de la responsabilité potentielle. Les retards peuvent avoir un impact sur la planification financière et le reporting. Où obtenir Cet événement est capturé lors de la création du premier enregistrement cc_reserveline associé à une exposition sur la réclamation. Le CreateTime de la transaction est l'horodatage de l'événement. Capture Trouver le timestamp de création minimum de toutes les lignes de réserve pour les expositions d'un sinistre donné. Type d'événement explicit | |||
Sinistre Clos | Marque la clôture réussie d'une réclamation après l'achèvement de toutes les activités et de tous les paiements. C'est l'événement de fin principal, déduit d'un changement dans le statut principal de la réclamation. | ||
Pourquoi c'est important En tant qu'événement de fin principal, cette activité est essentielle pour calculer le temps de cycle de bout en bout et mesurer l'adhésion aux SLA. Elle marque l'achèvement du cycle de vie du sinistre. Où obtenir Déduit d'un changement dans le champ State de la table cc_claim passant à 'Closed'. Le timestamp de l'événement est le CloseDate de l'enregistrement de réclamation. Capture Identifier le moment où le champ du statut maître de la réclamation est mis à jour à 'Closed'. Type d'événement inferred | |||
Sinistre créé | Cette activité marque la première déclaration de sinistre (FNOL) et la création officielle d'un nouveau dossier de sinistre dans Guidewire ClaimCenter. Elle est capturée explicitement lorsqu'une nouvelle entité de sinistre est enregistrée pour la première fois dans la base de données. | ||
Pourquoi c'est important En tant qu'événement de début principal, cette activité est essentielle pour mesurer le temps de cycle de bout en bout du sinistre. Elle fournit la base de référence pour tous les KPI de performance et de durée suivants. Où obtenir C'est un événement explicite capturé à partir du CreateTime de la table cc_claim. La création d'un nouvel enregistrement avec un Claim ID unique sert de déclencheur d'événement. Capture Identifier le timestamp de création du nouvel enregistrement dans la table d'entité de base Claim. Type d'événement explicit | |||
Sinistre Refusé | Représente la décision finale de refuser un sinistre, servant de point d'arrivée terminal pour le processus. Cet événement est déduit du statut du sinistre passant à un état fermé avec un motif « Refusé ». | ||
Pourquoi c'est important C'est un événement de résultat critique. L'analyse de la fréquence, des raisons et des chemins de processus menant aux refus aide à identifier les problèmes liés à la réception de la réclamation, à l'enquête ou à l'interprétation de la politique. Où obtenir Déduit d'un changement dans le champ State de la table cc_claim passant à 'Closed', combiné au champ CloseReason qui a la valeur 'Denied' ou une valeur similaire. Le timestamp de l'événement est le CloseDate. Capture Filtrer les changements de statut des sinistres vers 'Clos' lorsque le code de raison indique un refus. Type d'événement inferred | |||
Décision de responsabilité prise | Marque le moment où une décision concernant la responsabilité ou la faute a été prise pour une exposition. Cet événement est généralement déduit d'un changement de statut de l'entité d'exposition. | ||
Pourquoi c'est important C'est un jalon décisionnel critique qui précède les phases de règlement et de paiement. L'analyse du temps nécessaire pour parvenir à cette décision aide à identifier les goulots d'étranglement dans les étapes d'enquête et d'évaluation. Où obtenir Déduit de la table cc_history en suivant un changement dans le champ State ou un champ de statut de responsabilité personnalisé sur l'entité cc_exposure. Le timestamp de l'enregistrement d'historique indique l'heure de l'événement. Capture Surveiller les journaux d'audit ou les tables d'historique afin de détecter les mises à jour de l'état de l'exposition ou de son statut de responsabilité. Type d'événement inferred | |||
Enquête initiée | Indique le début formel de la phase d'investigation pour une réclamation ou une exposition. Cela est souvent déduit de la création de la première Activity (tâche) liée à l'investigation dans Guidewire. | ||
Pourquoi c'est important Cette activité marque le début d'une phase clé, souvent longue. L'analyse du temps écoulé jusqu'au début de l'enquête et de la durée de l'enquête elle-même révèle des goulots d'étranglement majeurs. Où obtenir Déduit du CreateTime d'un enregistrement cc_activity où l'ActivityPattern est lié à l'investigation (par exemple, 'Initial Investigation', 'Contact Witness'). Capture Identifier la première création d'une tâche dont le modèle ou le sujet est lié à une investigation. Type d'événement inferred | |||
Indemnisation calculée | Cette activité représente le moment où un montant de règlement a été déterminé mais n'a pas encore été approuvé pour paiement. Elle peut être déduite de la création d'un paiement en état d'« Approbation en attente ». | ||
Pourquoi c'est important Marque la transition de l'évaluation au paiement. C'est le point de départ pour mesurer le KPI 'Payment Authorization Lead Time', révélant les retards dans la chaîne d'approbation. Où obtenir Déduit du CreateTime d'un enregistrement cc_check ou cc_transaction dont le statut initial est 'Pending Approval' ou un état similaire avant 'Approved'. Capture Identifier la création d'un enregistrement de paiement ou de transaction en statut pré-approuvé. Type d'événement inferred | |||
Informations supplémentaires demandées | Représente une demande envoyée au demandeur ou à un tiers pour obtenir plus d'informations ou de documentation. Ceci est généralement enregistré comme une « Activité » (tâche) explicite créée dans ClaimCenter. | ||
Pourquoi c'est important Cette activité est le point de départ pour mesurer le KPI du « Temps de Cycle de Collecte d'Informations Supplémentaires ». Des occurrences fréquentes peuvent signaler des processus FNOL incomplets ou une collecte d'informations inefficace. Où obtenir Capturé à partir du CreateTime d'un enregistrement cc_activity où le ActivityPattern est lié à la demande de documentation ou d'informations auprès d'une partie externe. Capture Identifier la création d'une tâche de demande d'informations externes. Type d'événement explicit | |||
Informations supplémentaires reçues | Marque l'achèvement d'une demande d'informations complémentaires. Cela est enregistré lorsque l'Activity (tâche) correspondante est marquée comme 'Completed'. | ||
Pourquoi c'est important Ce jalon marque la fin de l'indicateur clé de performance (KPI) 'Temps de cycle de collecte d'informations supplémentaires'. Des délais importants entre la demande et la réception sont des causes fréquentes de retard dans le traitement des sinistres. Où obtenir Capturé à partir du CloseTime d'un enregistrement cc_activity où le ActivityPattern est lié à une demande d'informations. Le statut de l'activité doit être 'Completed'. Capture Identifier le timestamp de complétion d'une tâche de demande d'informations externes. Type d'événement explicit | |||
Sinistre Attribué | Représente l'affectation d'un sinistre à un utilisateur (expert) ou à un groupe spécifique pour traitement. Cela est généralement déduit en surveillant les modifications des champs d'affectation sur l'entité Sinistre. | ||
Pourquoi c'est important Le suivi des affectations est essentiel pour analyser la charge de travail des experts, identifier les goulots d'étranglement de l'acheminement et mesurer le délai de première action effectuée par le gestionnaire assigné. Où obtenir Déduit de la table cc_history en suivant les changements apportés aux champs AssignedUser ou AssignedGroup associés à un ID de réclamation spécifique. Le timestamp du changement indique le moment où l'événement s'est produit. Capture Surveiller les journaux d'audit ou les tables d'historique afin de détecter les mises à jour des champs d'affectation des sinistres. Type d'événement inferred | |||
Sinistre rouvert | Représente un sinistre passant d'un état « fermé » à un état « ouvert » pour effectuer un travail supplémentaire. Cet événement est déduit d'une séquence spécifique de changement de statut. | ||
Pourquoi c'est important Cette activité signale un retravail. Un volume élevé de sinistres rouverts indique des problèmes avec le règlement initial, des dommages non détectés ou d'autres défaillances de processus, entraînant une augmentation des coûts et une inefficacité. Où obtenir Déduit de la table cc_history en identifiant un changement dans le champ State de l'entité cc_claim de 'Closed' à 'Open' ou à un autre état actif. Capture Surveiller le champ de statut principal du sinistre afin de détecter une transition d'un état fermé vers un état ouvert. Type d'événement inferred | |||
Guides d'extraction
Étapes
- Vérification des prérequis : Confirmez que vous disposez des autorisations et identifiants nécessaires pour accéder à la base de données du data mart Guidewire DataHub / InfoCenter avec des privilèges de lecture. Assurez-vous que les jobs ETL qui alimentent le data mart des sinistres s'exécutent correctement et que les données sont à jour.
- Connexion à la base de données : Utilisez un client SQL standard (comme DBeaver, SQL Server Management Studio ou des outils similaires) pour établir une connexion au serveur de la base de données du data mart.
- Exploration du schéma : Avant d'exécuter la requête complète, familiarisez-vous avec le schéma du data mart. Identifiez les tables principales pour les sinistres, les expositions, les activités et les transactions financières. Les tables clés sont généralement nommées avec des suffixes comme _dim (dimension) et _fact (fait). Cela vous aidera à valider les noms de table et de colonne des placeholders dans le script fourni.
- Préparer la requête SQL : Copiez le script SQL complet fourni dans la section query dans l'éditeur de requêtes de votre client SQL.
- Personnaliser les placeholders : Examinez attentivement le script et remplacez toutes les valeurs de placeholder. Ceci inclut le nom de la base de données/du schéma (par ex., [YourDataMart]), les paramètres de plage de dates ('[StartDate]', '[EndDate]'), et toute valeur de configuration spécifique au système (par ex., modèles d'activité, codes de statut).
- Exécution de la requête : Exécutez la requête SQL modifiée sur le data mart. Le temps d'exécution peut varier en fonction de la plage de dates sélectionnée et du volume de données dans votre système.
- Examen initial des données : Une fois la requête terminée, examinez les premières centaines de lignes du jeu de résultats. Vérifiez que les colonnes ClaimID, ActivityName et EventTime sont renseignées comme prévu et que différents types d'activités sont présents.
- Exporter au format CSV : Exportez l'ensemble du jeu de résultats de votre client SQL vers un fichier CSV. Nommez le fichier de manière descriptive, par exemple, guidewire_claimcenter_event_log.csv.
- Formatage pour ProcessMind : Assurez-vous que le fichier CSV est enregistré avec l'encodage UTF-8. Vérifiez que le fichier comporte une ligne d'en-tête correspondant aux alias de colonnes dans la requête SQL. Le fichier est maintenant prêt à être importé dans ProcessMind.
Configuration
- Source de données : Guidewire DataHub/InfoCenter Claims Data Mart. Il s'agit d'une base de données dimensionnelle pré-agrégée, conçue pour le reporting et l'analyse, distincte de la base de données de production de ClaimCenter.
- Autorisations requises : Accès en lecture seule à la base de données SQL hébergeant le data mart. Vous aurez besoin d'un nom d'utilisateur, d'un mot de passe et des détails de connexion (adresse du serveur, nom de la base de données).
- Statut des jobs ETL : La précision de cette extraction dépend de l'exécution réussie et ponctuelle des jobs ETL de Guidewire qui alimentent le data mart. Vérifiez la date de la dernière exécution réussie pour évaluer la fraîcheur des données.
- Filtrage par plage de dates : La requête fournie inclut des clauses WHERE avec les placeholders '[StartDate]' et '[EndDate]'. Il est recommandé de commencer avec une plage de dates limitée (par ex., 3 à 6 mois) afin de gérer les performances. Le filtre de date est appliqué sur le champ CreateTime du sinistre.
- Valeurs spécifiques à la configuration : Guidewire est hautement configurable. Vous devez ajuster les valeurs dans les clauses WHERE pour qu'elles correspondent à la configuration de votre organisation. Ceci inclut :
- les noms ActivityPattern (par ex., 'fnol', 'investigation', 'Request additional information')
- les codes ClaimStatus, ExposureStatus et CloseReason (par ex., 'denied', 'closed')
- les codes TransactionStatus (par ex., 'pendingapproval', 'approved', 'issued')
- Performance : L'interrogation de grandes tables d'historique ou d'audit peut être gourmande en ressources. L'exécution de la requête en dehors des heures de pointe est recommandée pour les très grands ensembles de données. Assurez-vous que les colonnes ClaimID ou ClaimNumber sont indexées sur les tables pertinentes.
a Exemple de requête 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';
`Étapes
- Vérification des prérequis : Confirmez que vous disposez des autorisations et identifiants nécessaires pour accéder à la base de données du data mart Guidewire DataHub / InfoCenter avec des privilèges de lecture. Assurez-vous que les jobs ETL qui alimentent le data mart des sinistres s'exécutent correctement et que les données sont à jour.
- Connexion à la base de données : Utilisez un client SQL standard (comme DBeaver, SQL Server Management Studio ou des outils similaires) pour établir une connexion au serveur de la base de données du data mart.
- Exploration du schéma : Avant d'exécuter la requête complète, familiarisez-vous avec le schéma du data mart. Identifiez les tables principales pour les sinistres, les expositions, les activités et les transactions financières. Les tables clés sont généralement nommées avec des suffixes comme _dim (dimension) et _fact (fait). Cela vous aidera à valider les noms de table et de colonne des placeholders dans le script fourni.
- Préparer la requête SQL : Copiez le script SQL complet fourni dans la section query dans l'éditeur de requêtes de votre client SQL.
- Personnaliser les placeholders : Examinez attentivement le script et remplacez toutes les valeurs de placeholder. Ceci inclut le nom de la base de données/du schéma (par ex., [YourDataMart]), les paramètres de plage de dates ('[StartDate]', '[EndDate]'), et toute valeur de configuration spécifique au système (par ex., modèles d'activité, codes de statut).
- Exécution de la requête : Exécutez la requête SQL modifiée sur le data mart. Le temps d'exécution peut varier en fonction de la plage de dates sélectionnée et du volume de données dans votre système.
- Examen initial des données : Une fois la requête terminée, examinez les premières centaines de lignes du jeu de résultats. Vérifiez que les colonnes ClaimID, ActivityName et EventTime sont renseignées comme prévu et que différents types d'activités sont présents.
- Exporter au format CSV : Exportez l'ensemble du jeu de résultats de votre client SQL vers un fichier CSV. Nommez le fichier de manière descriptive, par exemple, guidewire_claimcenter_event_log.csv.
- Formatage pour ProcessMind : Assurez-vous que le fichier CSV est enregistré avec l'encodage UTF-8. Vérifiez que le fichier comporte une ligne d'en-tête correspondant aux alias de colonnes dans la requête SQL. Le fichier est maintenant prêt à être importé dans ProcessMind.
Configuration
- Source de données : Guidewire DataHub/InfoCenter Claims Data Mart. Il s'agit d'une base de données dimensionnelle pré-agrégée, conçue pour le reporting et l'analyse, distincte de la base de données de production de ClaimCenter.
- Autorisations requises : Accès en lecture seule à la base de données SQL hébergeant le data mart. Vous aurez besoin d'un nom d'utilisateur, d'un mot de passe et des détails de connexion (adresse du serveur, nom de la base de données).
- Statut des jobs ETL : La précision de cette extraction dépend de l'exécution réussie et ponctuelle des jobs ETL de Guidewire qui alimentent le data mart. Vérifiez la date de la dernière exécution réussie pour évaluer la fraîcheur des données.
- Filtrage par plage de dates : La requête fournie inclut des clauses WHERE avec les placeholders '[StartDate]' et '[EndDate]'. Il est recommandé de commencer avec une plage de dates limitée (par ex., 3 à 6 mois) afin de gérer les performances. Le filtre de date est appliqué sur le champ CreateTime du sinistre.
- Valeurs spécifiques à la configuration : Guidewire est hautement configurable. Vous devez ajuster les valeurs dans les clauses WHERE pour qu'elles correspondent à la configuration de votre organisation. Ceci inclut :
- les noms ActivityPattern (par ex., 'fnol', 'investigation', 'Request additional information')
- les codes ClaimStatus, ExposureStatus et CloseReason (par ex., 'denied', 'closed')
- les codes TransactionStatus (par ex., 'pendingapproval', 'approved', 'issued')
- Performance : L'interrogation de grandes tables d'historique ou d'audit peut être gourmande en ressources. L'exécution de la requête en dehors des heures de pointe est recommandée pour les très grands ensembles de données. Assurez-vous que les colonnes ClaimID ou ClaimNumber sont indexées sur les tables pertinentes.
a Exemple de requête 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';
`Étapes
- Vérification des prérequis : Confirmez que vous disposez des autorisations et identifiants nécessaires pour accéder à la base de données du data mart Guidewire DataHub / InfoCenter avec des privilèges de lecture. Assurez-vous que les jobs ETL qui alimentent le data mart des sinistres s'exécutent correctement et que les données sont à jour.
- Connexion à la base de données : Utilisez un client SQL standard (comme DBeaver, SQL Server Management Studio ou des outils similaires) pour établir une connexion au serveur de la base de données du data mart.
- Exploration du schéma : Avant d'exécuter la requête complète, familiarisez-vous avec le schéma du data mart. Identifiez les tables principales pour les sinistres, les expositions, les activités et les transactions financières. Les tables clés sont généralement nommées avec des suffixes comme _dim (dimension) et _fact (fait). Cela vous aidera à valider les noms de table et de colonne des placeholders dans le script fourni.
- Préparer la requête SQL : Copiez le script SQL complet fourni dans la section query dans l'éditeur de requêtes de votre client SQL.
- Personnaliser les placeholders : Examinez attentivement le script et remplacez toutes les valeurs de placeholder. Ceci inclut le nom de la base de données/du schéma (par ex., [YourDataMart]), les paramètres de plage de dates ('[StartDate]', '[EndDate]'), et toute valeur de configuration spécifique au système (par ex., modèles d'activité, codes de statut).
- Exécution de la requête : Exécutez la requête SQL modifiée sur le data mart. Le temps d'exécution peut varier en fonction de la plage de dates sélectionnée et du volume de données dans votre système.
- Examen initial des données : Une fois la requête terminée, examinez les premières centaines de lignes du jeu de résultats. Vérifiez que les colonnes ClaimID, ActivityName et EventTime sont renseignées comme prévu et que différents types d'activités sont présents.
- Exporter au format CSV : Exportez l'ensemble du jeu de résultats de votre client SQL vers un fichier CSV. Nommez le fichier de manière descriptive, par exemple, guidewire_claimcenter_event_log.csv.
- Formatage pour ProcessMind : Assurez-vous que le fichier CSV est enregistré avec l'encodage UTF-8. Vérifiez que le fichier comporte une ligne d'en-tête correspondant aux alias de colonnes dans la requête SQL. Le fichier est maintenant prêt à être importé dans ProcessMind.
Configuration
- Source de données : Guidewire DataHub/InfoCenter Claims Data Mart. Il s'agit d'une base de données dimensionnelle pré-agrégée, conçue pour le reporting et l'analyse, distincte de la base de données de production de ClaimCenter.
- Autorisations requises : Accès en lecture seule à la base de données SQL hébergeant le data mart. Vous aurez besoin d'un nom d'utilisateur, d'un mot de passe et des détails de connexion (adresse du serveur, nom de la base de données).
- Statut des jobs ETL : La précision de cette extraction dépend de l'exécution réussie et ponctuelle des jobs ETL de Guidewire qui alimentent le data mart. Vérifiez la date de la dernière exécution réussie pour évaluer la fraîcheur des données.
- Filtrage par plage de dates : La requête fournie inclut des clauses WHERE avec les placeholders '[StartDate]' et '[EndDate]'. Il est recommandé de commencer avec une plage de dates limitée (par ex., 3 à 6 mois) afin de gérer les performances. Le filtre de date est appliqué sur le champ CreateTime du sinistre.
- Valeurs spécifiques à la configuration : Guidewire est hautement configurable. Vous devez ajuster les valeurs dans les clauses WHERE pour qu'elles correspondent à la configuration de votre organisation. Ceci inclut :
- les noms ActivityPattern (par ex., 'fnol', 'investigation', 'Request additional information')
- les codes ClaimStatus, ExposureStatus et CloseReason (par ex., 'denied', 'closed')
- les codes TransactionStatus (par ex., 'pendingapproval', 'approved', 'issued')
- Performance : L'interrogation de grandes tables d'historique ou d'audit peut être gourmande en ressources. L'exécution de la requête en dehors des heures de pointe est recommandée pour les très grands ensembles de données. Assurez-vous que les colonnes ClaimID ou ClaimNumber sont indexées sur les tables pertinentes.
a Exemple de requête 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';
`