Votre modèle de données pour le 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 | Descriptionn | ||
|---|---|---|---|
| Heure de l'événement EventTime | La date et l'heure précises auxquelles l'activité s'est produite. | ||
| Descriptionn Ce horodatage marque le moment exact où une activité a été enregistrée dans le système. Il est indispensable 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 points de blocage et la surveillance des SLA. Pourquoi est-ce important ? : Ce horodatage est indispensable pour ordonner les événements, calculer les temps de cycle et les durées, et identifier les retards dans le processus. Source des données : 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. | ||
| Descriptionn 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 l'essence du Process Mining. Elle permet la découverte de modèles de processus, l'identification des points de blocage, la détection des boucles de reprise et l'analyse des écarts de processus. Pourquoi est-ce important ? : Il définit les étapes du processus, pour visualiser des cartes de processus et l'analyse des flux de processus et des points de blocage. Source des données : 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. | ||
| Descriptionn L'ID de sinistre est la base 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 vision globale 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 complet. Ceci est indispensable 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 est-ce important ? : C'est l'élément clé qui relie tous les événements connexes, permettant de tracer et d'analyser l'intégralité du parcours d'une seule réclamation. Source des données : 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). | ||
| Descriptionn 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 informationsns clés aident à élaborer des procédures de traitement plus spécialisées et efficientes. Pourquoi est-ce 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. Source des données : 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. | ||
| Descriptionn 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 indispensablele 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 est-ce important ? : Suit l'implication des utilisateurs, permettant l'analyse de la charge de travail, la comparaison des performances et l'identification des points de blocage liés aux ressources. Source des données : 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é). | ||
| Descriptionn 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 est-ce 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. Source des données : 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. | ||
| Descriptionn Le type de sinistre représente une classification clée, é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 pistes d'amélioration concrètes. Cette approche permet de comparer les performances des processus sur diverses lignes d'activité, de détecter les points de blocage propres à chaque type et d'adapter les initiatives d'amélioration des processus aux particularités de chaque catégorie de sinistre. Pourquoi est-ce 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. Source des données : Dérivé de l'entité Policy ou Claim dans ClaimCenter, souvent basé sur le code de la ligne d'activité (LOB). Exemples Automobile personnellePropriété commercialeResponsabilité 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. | ||
| Descriptionn 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 indispensable 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 dans les délais et identifier quels types de sinistres ou services ont des difficultés à atteindre leurs objectifs. Pourquoi est-ce 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. Source des données : 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 ayant déclenché la déclaration est survenu. | ||
| Descriptionn 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 clés sur le comportement des clients et l'efficacité des canaux de première déclaration de sinistre. Pourquoi est-ce important ? : Fournit un contexte essentiel sur l'origine du sinistre et aide à analyser le délai de déclaration (temps entre l'incident et la soumission du sinistre). Source des données : Il s'agit d'un champ de date clé 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. | ||
| Descriptionn 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 contribue directement au 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 est-ce 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 reprises. Source des données : Calculé dans 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. | ||
| Descriptionn 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 indispensablele pour comprendre la performance du processus au niveau organisationnel. Elle permet d'identifier les retards de transfert interdépartementaux, de comparer l'efficacité entre les équipes et d'allouer les ressources de manière plus efficace dans l'organisation des sinistres. Pourquoi est-ce 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. Source des données : Cette information est généralement associée au profil de l'utilisateur ou du groupe assigné dans ClaimCenter. Exemples Division des sinistres automobilesUnité des sinistres immobiliersUnité des Enquêtes Spéciales (UES) | |||
| Dernière mise à jour des données LastDataUpdate | Le *horodatage* indiquant quand les *data* ont été rafraîchies ou extraites pour la dernière fois du système source. | ||
| Descriptionn 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 la réactualisation 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 est-ce important ? : Indique la la réactualisation des données, garantissant que les utilisateurs comprennent l'actualité de l'analyse des processus. Source des données : Cette valeur est générée et stockée pendant le processus ETL ; elle représente l'horodatage 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. | ||
| Descriptionn 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 indispensablele pour comprendre le niveau d'automatisation dans le processus de gestion des sinistres. Elle aide à identifier les zones critiques 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 est-ce 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 points de blocage humains. Source des données : 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 un reprises IsRework | Un indicateur signalant si une activité représente une boucle de reprises, c'est-à-dire un retour à une étape antérieure du processus. | ||
| Descriptionn 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 clée pour déceler les inefficacités de processus et les problèmes de qualité. Le tableau de bord « 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 est-ce 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 reprises. Source des données : Ceci est calculé dans 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. | ||
| Descriptionn 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 est-ce important ? : Indispensable pour l'analyse de la conformité, car différentes juridictions sont soumises à des réglementations distinctes qui impactent le processus de traitement des sinistres. Source des données : 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. | ||
| Descriptionn L'Heure de Fin marque la fin 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 horodatages. 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 est-ce 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. Source des données : 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. | ||
| Descriptionn 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 indispensable 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 est-ce 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. Source des données : 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. | ||
| Descriptionn 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 est-ce important ? : Permet de segmenter les sinistres par valeur financière, car les sinistres à forte valeur peuvent suivre des processus différents, plus complexes. Source des données : 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. | ||
| Descriptionn 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 contribue directement au le tableau de bord « 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 d'efficacité.x global de respect des SLA et pour approfondir les raisons des retards. Pourquoi est-ce 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 respect des délais. Source des données : Champ calculé : SI (ActualCloseDate <= ResolutionTargetDate, 'Dans les délais', 'En retard'). Exemples À tempsEn retard | |||
| Système source SourceSystem | Le système d'où les données ont été extraites. | ||
| Descriptionn 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 indispensablele 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 clées du processus des activités de support issues des systèmes périphériques. Pourquoi est-ce important ? : Permet d'identifier l'origine des données, essentiel pour leur gouvernance et pour les analyses impliquant plusieurs systèmes intégrés. Source des données : 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 | |||
| 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. | ||
| Descriptionn Le type de police offre une classification plus granulairesre 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 est-ce 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. Source des données : 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é | Descriptionn | ||
|---|---|---|---|
| Demande refusée | 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 est-ce 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. Source des données : 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. L'horodatage 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 | |||
| 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 est-ce important ? : Les expositions sont clées 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. Source des données : 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 l'horodatage 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 est-ce 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. Source des données : 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 est-ce important ? : Cette activité est indispensablele 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. Source des données : 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 l’horodatage 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 est-ce important ? : Ce jalon est indispensable 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. Source des données : 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 l'horodatage 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 est-ce important ? : En tant qu'événement de fin principal, cette activité est indispensablele pour calculer le temps de cycle complet et mesurer l'adhésion aux SLA. Elle marque l'achèvement du cycle de vie du sinistre. Source des données : Déduit d'un changement dans le champ State de la table cc_claim passant à 'Closed'. L'horodatage 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 est-ce important ? : En tant qu'événement de début principal, cette activité est indispensablele pour mesurer le temps de cycle complet du sinistre. Elle fournit la base de référence pour tous les KPI de performance et de durée suivants. Source des données : 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 l'horodatage de création du nouvel enregistrement dans la table d'entité de base Claim. Type d'événement explicit | |||
| 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 est-ce 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 points de blocage dans les étapes d'enquête et d'évaluation. Source des données : 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. L'horodatage 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 est-ce 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 points de blocage majeurs. Source des données : 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 est-ce 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. Source des données : 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 est-ce 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. Source des données : 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 est-ce 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. Source des données : 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 l'horodatage 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 est-ce important ? : Le suivi des affectations est indispensable pour analyser la charge de travail des experts, identifier les points de blocage de l'acheminement et mesurer le délai de première action effectuée par le gestionnaire assigné. Source des données : 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. L'horodatage 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 est-ce important ? : Cette activité signale un reprises. 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é. Source des données : 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 la réactualisation 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
-- 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 la réactualisation 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
-- 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 la réactualisation 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
-- 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';